In-vehicle relay device, relay method, and computer program

Abstract

To facilitate changing an on-vehicle network configuration.SOLUTION: An extension-side gateway includes: a first memory that stores original data of a plurality of relay tables used for relay processing; a second memory that stores one relay table expanded from the original data; a transceiver that includes a plurality of communication ports PE, PYj, and transmits and receives a first frame conforming to a first communication protocol at each of the plurality of communication ports; a frame processing unit that transmits and receives a second frame conforming to a second communication protocol; and a control unit that executes relay processing for the first frame and the second frame. The control unit executes at least one of the update processing steps including: first update processing of updating the relay table to be expanded from the original data in the first memory to the second memory, based on identification information of an extension apparatus connected to the communication port; and second update processing of adding to the first memory a relay table for a new apparatus which is a new extension apparatus which is not scheduled to be connected to its own device.SELECTED DRAWING: Figure 2

Description

Technical Field

[0001] The present disclosure relates to an in-vehicle relay device, a relay method, and a computer program.

Background Art

[0002] Patent Document 1 describes a technique for efficiently coping with the number of types of communication protocols in an in-vehicle relay device capable of executing relay processing of communication frames involving protocol conversion between CAN (Control Area Network: registered trademark) and Ethernet (registered trademark). Patent Document 2 describes a technique for generating a communication frame suitable for information transmission to an ECU (Electronic Control Unit) connected to a CAN bus in an in-vehicle relay device that performs relay processing of communication frames involving protocol conversion between CAN and Ethernet.

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Patent Document 2

Summary of the Invention

Problems to be Solved by the Invention

[0004] In a conventional in-vehicle relay device, when adding, reducing, or changing the connection position of an expansion device to a CAN communication port, the maintenance staff has to manually update the relay table. For this reason, there is a problem that it takes time to change the network configuration. An object of the present disclosure is to provide an in-vehicle relay device or the like that can easily change the network configuration.

Means for Solving the Problems

[0005] An apparatus according to one aspect of the present disclosure is an extended-side in-vehicle relay device capable of performing relay processing of communication frames, comprising: a first memory storing raw data for a plurality of relay tables that can be used for the relay processing; a second memory storing one relay table expanded from the raw data; a first communication unit including a plurality of communication ports, each of which transmits and receives a first frame conforming to a first communication protocol; a second communication unit transmitting and receiving a second frame conforming to a second communication protocol; and a control unit that performs the relay processing relating to the first frame and the second frame, wherein the control unit performs at least one of the following update processes based on identification information of an extended device connected to the communication port: a first update process that updates the relay table expanded from the raw data in the first memory to the second memory; and a second update process that adds the relay table for a newly installed device, which is a new extended device that was not planned to be connected to the device, to the first memory.

[0006] A method according to one aspect of the present disclosure is a relay method performed by an extended-side in-vehicle relay device capable of performing relay processing of communication frames, the in-vehicle relay device comprising: a first memory storing raw data for a plurality of relay tables that can be used for the relay processing; and a second memory storing one relay table expanded from the raw data, the relay method comprising: sending and receiving a first frame conforming to a first communication protocol at at least one of a plurality of communication ports; sending and receiving a second frame conforming to a second communication protocol; performing the relay processing relating to the first frame and the second frame; performing at least one of the following update processes: a first update process that updates the relay table expanded from the raw data in the first memory to the second memory based on identification information of an extended device connected to the communication port; and a second update process that adds the relay table for a newly installed device, which is a new extended device that was not planned to be connected to the device, to the first memory.

[0007] A computer program according to one aspect of the present disclosure is a computer program for causing a computer to function as an extended in-vehicle relay device capable of performing relay processing of communication frames, wherein the computer program causes the computer to function as a first memory storing raw data for a plurality of relay tables that can be used for the relay processing, a second memory storing one relay table expanded from the raw data, a plurality of communication ports, each of which is a first communication unit that sends and receives first frames conforming to a first communication protocol, a second communication unit that sends and receives second frames conforming to a second communication protocol, and a control unit that performs the relay processing relating to the first frame and the second frame, wherein the control unit performs at least one of the following update processes: a first update process that updates the relay table expanded from the raw data in the first memory to the second memory based on identification information of an extended device connected to the communication port, and a second update process that adds the relay table for a newly installed device, which is a new extended device that was not planned to be connected to the device, to the first memory. [Effects of the Invention]

[0008] According to this disclosure, network configurations can be easily modified. [Brief explanation of the drawing]

[0009] [Figure 1] Figure 1 is a network configuration diagram showing an example of an in-vehicle communication system. [Figure 2] Figure 2 is a block diagram showing an example of the internal configuration of the extension gateway. [Figure 3] Figure 3 is an explanatory diagram showing an example of the communication frame conversion process. [Figure 4] Figure 4 is an explanatory diagram showing an example of a relay table on the extension side. [Figure 5] Figure 5 is an explanatory diagram showing a conventional method for storing and updating relay tables. [Figure 6] Figure 6 is an explanatory diagram showing an example of a method for storing and updating relay tables. [Figure 7] Figure 7 is a flowchart showing an example of communication frame relay processing on the extension side. [Figure 8] Figure 8 is an explanatory diagram showing an example of the verification process and response process for the new equipment that the existing gateway and the newly installed gateway can each perform. [Modes for carrying out the invention]

[0010] <Summary of the embodiments of this disclosure> The embodiments of this disclosure are outlined below.

[0011] (1) The device according to this embodiment is an extended-side in-vehicle relay device capable of performing relay processing of communication frames, comprising: a first memory storing raw data for a plurality of relay tables that can be used for the relay processing; a second memory storing one relay table expanded from the raw data; a first communication unit including a plurality of communication ports, each of which transmits and receives a first frame conforming to a first communication protocol; a second communication unit transmitting and receiving a second frame conforming to a second communication protocol; and a control unit that performs the relay processing relating to the first frame and the second frame, wherein the control unit performs at least one of the following update processes based on identification information of an extended device connected to the communication port: a first update process that updates the relay table expanded from the raw data in the first memory to the second memory; and a second update process that adds the relay table for a newly installed device, which is a new extended device that is not yet connected, to the first memory.

[0012] Furthermore, the relay processing for the first and second frames includes mutual relaying between the first and second frames. According to the in-vehicle relay device of this embodiment, the update process performed by the control unit includes a first update process that updates the relay table, which is expanded from the original data in the first memory to the second memory, based on the identification information of the extended device connected to the communication port. Therefore, when the above-described first update process is executed, the relay table can be automatically updated according to the addition, reduction, or change in the connection position of the expansion device without manually updating the relay table, and the network configuration can be easily changed. In addition, the update process executed by the control unit includes a second update process of adding a relay table for a new device, which is a new expansion device for which there is no planned connection to the own device, to the first memory. Therefore, when the above-described second update process is executed, even if the expansion device is the above-described new device, it can be included in the target of the first update process.

[0013] (2) In the in-vehicle relay device of the present embodiment, the control unit may execute a confirmation process of inquiring an external device about the existence of an existing device that plans to communicate with the new device based on the first communication protocol prior to the second update process. The reason is that if there is no existing device that plans to communicate with the new device according to the first communication protocol, there is no need to add a relay table.

[0014] (3) In the in-vehicle relay device of the present embodiment, the confirmation process may include a process of transmitting a confirmation request including the identification information of the new device to the external device. The reason is that the identification information of the new device is required for the external device to determine the existence of an existing device that plans to communicate with the new device.

[0015] (4) In the in-vehicle relay device of the present embodiment, when the confirmation result of the confirmation response acquired from the external device is positive, the control unit may execute the second update process, and when the confirmation result is negative, the control unit may not execute the second update process. The reason is that when the confirmation result is positive, it is necessary to add a relay table, but when the confirmation result is negative, there is no need to add a relay table.

[0016] (5) In the in-vehicle relay device of this embodiment, if the confirmation result is positive, the control unit may generate a new relay table for communicating between the existing equipment and the newly installed equipment, and may add the generated relay table to the first memory. In this way, a new relay table for communication between existing and newly installed equipment is added to the first memory, and this new relay table becomes the target of the first update process. Therefore, the relay table can be automatically updated to reflect the addition of new equipment without manual updating, making it easy to change the network configuration.

[0017] (6) In the in-vehicle relay device of this embodiment, if the first communication protocol and the second communication protocol are different, the control unit may perform the relay process that includes protocol conversion. In this case, even if the first and second communication protocols are different, the first and second frames can be properly relayed to each other.

[0018] (7) In the in-vehicle relay device of this embodiment, the first communication protocol may be CAN or CAN-FD, and the second communication protocol may be Ethernet. In this case, relay processing involving protocol conversion can be performed for the first frame of CAN or CAN-FD and the second frame of Ethernet.

[0019] (8) In the in-vehicle relay device of this embodiment, the identification information of the expansion device may be a CANID. The reason is that CANID is often used as identification information for existing devices, so CANID should also be adopted for the identification information of expansion devices to ensure information consistency.

[0020] (9) The method according to this embodiment is a relay method performed by the in-vehicle relay device described in (1) to (8) above. Therefore, the relay of this embodiment method This produces the same effects as the in-vehicle relay devices described in (1) to (8) above.

[0021] (10) The computer program according to this embodiment is a computer program for causing the computer to function as the in-vehicle relay device described in (1) to (8) above. Therefore, the computer program according to this embodiment has the same effects as the in-vehicle relay device described in (1) to (8) above.

[0022] <Details of Embodiments of the Invention> The embodiments of the present invention will be described in detail below with reference to the drawings. At least some of the embodiments described below may be combined in any way.

[0023] [Example of an in-vehicle communication system configuration] Figure 1 is a network configuration diagram showing an example of the configuration of the in-vehicle communication system 100. As shown in Figure 1, the in-vehicle communication system 100 according to this embodiment is an in-vehicle LAN (Local Area Network) constructed inside the vehicle 1. The in-vehicle communication system 100 includes multiple gateways 10, 20, a switching hub 30, and ECUs 40, 50, etc., as communication nodes that constitute the network.

[0024] ECU40 and 50 are electronic control units for vehicles that control various in-vehicle equipment such as sensors or actuators within the vehicle 1. Furthermore, ECU40 and 50 are communication nodes that constitute the in-vehicle communication system 100, and from a communication perspective, they can be considered a type of "in-vehicle communication device."

[0025] Focusing on the controlled objects, the types of ECUs 40 and 50 include engine control ECUs, transmission control ECUs, power steering control ECUs, air conditioning control ECUs, and AV (Audio / Visual) system control ECUs. ECU40 and 50 take measurement information from sensors connected to them (such as speed sensors, acceleration sensors, temperature sensors, and pressure sensors) into the system and control various actuators connected to them (such as electric motors) based on the measurement information.

[0026] Focusing on the communication protocol, the in-vehicle communication system 100 is a network in which ECUs 40 that perform communication compliant with the "first communication protocol" and ECUs 50 that perform communication compliant with the "second communication protocol" coexist. As the first communication protocol, for example, CAN (Control Area Network: registered trademark), CAN-FD (CAN with flexible data rate), LIN (Local Interconnect Network), or FlexRay (registered trademark) may be adopted. In this embodiment, the first communication protocol is assumed to be "CAN".

[0027] The second communication protocol is not limited to any particular type as long as it is a communication protocol different from the first communication protocol. However, in this embodiment, the second communication protocol is assumed to be "Ethernet," which has a higher transmission speed than the first communication protocol. Hereafter, Ethernet may be abbreviated as "ETH."

[0028] ECU40 is an ECU that performs communication compliant with CAN (Canal Communication Protocol). In this embodiment, a communication frame compliant with CAN is referred to as a "CAN frame" or "first frame," and an ECU that performs CAN communication is referred to as a "C-ECU." ECU50 is an ECU that performs communication compliant with ETH (Second Communication Protocol). In this embodiment, a communication frame compliant with ETH is referred to as an "Ethernet (ETH) frame" or "second frame," and an ECU that performs ETH communication is referred to as an "E-ECU."

[0029] The C-ECU40 is connected to gateways 10 and 20 via the CAN bus 60. The CAN bus 60 is a communication line consisting of high and low wires. Multiple C-ECU40s can be connected in a line configuration to a single CAN bus 60. The E-ECU50 is connected to gateways 10, 20, or switching hub 30 via a LAN cable 70. The LAN cable 70 is, for example, a communication line corresponding to category CAT5 or higher, which can ensure a communication speed of 100 Mbps or 1 Gbps.

[0030] Gateways 10 and 20 are in-vehicle relay devices that have the function of relaying CAN communication between different CAN buses 60 and the function of relaying communication between ECUs 40 and 50 (in this embodiment, "C-ECU40" and "E-ECU50") that employ different communication protocols. The switching hub 30 is an in-vehicle relay device capable of relaying Ethernet frames at the L2 or L3 layer, for example. In other words, the switching hub 30 is an in-vehicle relay device that complies only with the first communication protocol.

[0031] As shown in Figure 1, the in-vehicle communication system 100 includes an existing network 110 and an extended network 120. The existing network 110 is a network that is built into the vehicle 1 as standard, and the extended network 120 is a network that is optionally built into the vehicle 1. The extended network 120 can be added when the vehicle 1 is being serviced, etc. Potential needs for expansion include, for example, enhancing the safety features of vehicle 1, and adding new functions requested by users of vehicle 1.

[0032] In the example shown in Figure 1, the existing network 110 includes, as constituent communication nodes, one existing gateway 10, two C-ECUs 40 (40C), one switching hub 30, and one E-ECU 50. However, the types and number of communication nodes described above are just examples, and an actual existing network 110 may include more gateways 10, switching hubs 30, and ECUs 40, 50 than shown in the diagram.

[0033] In the example shown in Figure 1, the extended network 120 includes, as constituent communication nodes, one extended gateway 20, two switching hubs 30, two C-ECUs 40 (40E), and one E-ECU 50. The types and number of communication nodes described above are just examples; for instance, gateway 20 could be connected to gateway 10 via LAN cable 70 without going through switching hub 30, or the expansion-side E-ECU 40 could be connected to gateway 10 via LAN cable 70.

[0034] As described above, the C-ECU40 of the in-vehicle communication system 100 includes C-ECU40C, which is already included in the existing network 110, and C-ECU40E, which may be adopted in the future as a communication node of the extended network 120. Therefore, in the following explanation, C-ECU40C, which is a component of the existing network 110, may be referred to as "existing equipment 40C," and C-ECU40E, which can be a component of the extended network 120, may be referred to as "extended equipment 40E."

[0035] [Example of gateway configuration on the extension side] Figure 2 is a block diagram showing an example of the internal configuration of the extension gateway 20. As shown in Figure 2, the extension gateway 20 includes a frame processing unit 21 for ETH communication, a microcontroller 22, and a transceiver 23 for CAN communication. The extension gateway 20 also has multiple communication ports PYj (j=1,2...J) for CAN and one communication port PE for ETH.

[0036] The frame processing unit 21 corresponds to the "second communication unit" that sends and receives ETH frames (second frames) compliant with the second communication protocol. The frame processing unit 21 is composed of one or more integrated circuits that perform signal processing in accordance with Ethernet, and includes a PHY unit 21A and a MAC unit 21B. The PHY unit 21A is an integrated circuit that performs signal modulation and demodulation in accordance with Ethernet, and is provided corresponding to the Ethernet communication port PE.

[0037] The MAC unit 21B is an integrated circuit that performs signal processing related to the MAC (Media Access Control) layer of Ethernet. The MAC unit 21B is composed of, for example, an FPGA (Field Programmable Gate Array) and is electrically connected to the microcontroller 22 and the PHY unit 21A, respectively.

[0038] The microcontroller 22 is a microcomputer comprising a control unit 24 and a memory unit 25. The control unit 24 is an arithmetic processing unit that includes one or more CPUs (Central Processing Units). The control unit 24 may also include other integrated circuits such as FPGAs. The control unit 24 reads the computer program 26 stored in the first memory 25A of the storage unit 25 into the second memory 25B, and performs the information processing necessary for relaying communications according to the read program 26. Details of this information processing will be described later.

[0039] The memory unit 25 includes a first memory 25A and a second memory 25B. The first memory 25A is an auxiliary storage device that includes non-volatile memory such as EPROM (Erasable Programmable ROM), EEPROM (Electrically Erasable Programmable ROM), or flash ROM (Read Only Memory). The first memory 25A may also be a non-rewritable ROM (Read Only Memory).

[0040] The second memory 25B is a main memory that includes volatile memory such as SRAM (Static RAM) or DRAM (Dynamic RAM). The information expanded into the second memory 25B includes the computer program 26, as well as the relay table Tn, which is used for relay processing involving protocol conversion, as described later.

[0041] The first memory 25A stores, as an archive, the original data of a group of relay tables TG2, which includes multiple relay tables Tn (n=1,2...N), in addition to the computer program 26, and which may be necessary when relaying communication frames that involve protocol conversion. The data format of the source data may be a table format in the form of multiple relay tables Tn, or it may be a text-based data format that includes all the information of multiple relay tables Tn contained in the relay table group TG2.

[0042] However, determining a single relay table Tn to be expanded into the second memory 25B from the text-based source data requires a process to convert the text-based data into a table format. Text-based data formats such as CSV (Comma Separated Values), XML (Extensible Markup Language), and JSON (JavaScript Object Notation) can be used. The data content of the relay table group TG2 will be described later.

[0043] Transceiver 23 corresponds to the "first communication unit" that transmits and receives CAN frames (first frames) compliant with the first communication protocol. The transceiver 23 is a transceiver that performs physical layer signal processing in accordance with CAN, and includes multiple PHY units 23A. Each PHY unit 23A is an integrated circuit that performs L1 level signal conversion of CAN, and is provided for each CAN communication port PYj (j=1,2...N). Specifically, the PHY unit 23A decodes the differential signal of the CAN bus 60 into a digital signal and outputs it to the control unit 24. Conversely, the PHY unit 23A generates a CAN differential signal from the digital signal input from the control unit 24 and sends it to the communication port PYj (CAN bus 60).

[0044] The information processing performed by the control unit 24 of the microcontroller 22 includes at least the following three processes: S21: Authentication process for expansion device 40E S22: Relay table update process S23: Protocol conversion process

[0045] Authentication process S21 is a process that determines whether the newly connected expansion device (C-ECU) 40E is a legitimate communication node. For the authentication process S21, for example, a key exchange using a message authentication code or a digital signature may be employed, performed between the newly added extension device 40E on the CAN bus 60 connected to the communication port PYj.

[0046] The update process S22 is a process that updates the relay table Tn, which is expanded into the second memory 25B, from the original data of the relay table group TG2 (={Tn}: n=1,2...N), which is an archive stored in the first memory 25A. The update process S22 is performed, for example, based on the identification information (e.g., CANID) of all extended devices 40E that have been recognized as legitimate by the authentication process S21.

[0047] Specifically, the control unit 24 determines which of the multiple relay tables Tn to load into the second memory 25B based on the identification information of the authenticated extension device 40E. Then, the control unit 24 updates the single relay table Tn used for relay processing by loading the data of the determined relay table Tn into the second memory 25B.

[0048] The conversion process S23 is a process that performs bidirectional protocol conversion between CAN and ETH by referring to a relay table Tn, which is stored in the second memory 25B and has been updated by the update process S22. Specifically, the control unit 24The first unit performs a "first conversion" which converts the ETH frame input from the frame processing unit 21 into a CAN frame, and outputs the converted CAN frame to the transceiver 23.

[0049] In this case, the control unit 24 determines which PHY unit 23A in the transceiver 23 to output the converted CAN frame to (which CAN bus 60 to output it to) in the second memory. 25B This is determined by a single relay table Tn that is expanded. Conversely, the control unit 24 The transceiver 23 performs a "second conversion" which converts a CAN frame input from any of the PHY units 23A into an ETH frame, and outputs the converted ETH frame to the frame processing unit 21.

[0050] Figure 3 is an explanatory diagram showing an example of a communication frame conversion process S13 performed by the control unit 24 of the microcontroller 22. As shown in Figure 3, this method employs storing all the data from the CAN frame in the payload of the ETH frame.

[0051] In this case, the control unit 24 performs a "first conversion" from an ETH frame to a CAN frame by extracting a CAN frame from the payload of the ETH frame input from the frame processing unit 21. Furthermore, the control unit 24 performs a "second conversion" from a CAN frame to an ETH frame by generating an ETH frame in which the CAN frame input from the transceiver 23 is stored in the payload.

[0052] The control unit 24 of the microcontroller 22 executes the transmission process of the converted communication frame. The transmission process by the control unit 24 includes the following: ETH transmission: This process outputs the converted ETH frame to the frame processing unit 21. CAN transmission: This is the process of outputting the converted CAN frame to transceiver 23. In this case, the output destination of the CAN frame (transmission port PYj) follows the specifications of the relay table Tn.

[0053] [Specific examples of relay tables on the extension side] Figure 4 is an explanatory diagram showing an example of the relay table group TG2 on the extension side. The relay table Tn (n=1,2...N) on the extended side in Figure 4 is a matrix-formatted data where "relay source," "relay destination," and "transmitting node" are defined for each entry. The relay source represents the type of receiving port of the communication frame, and the relay destination represents the type of transmitting port of the communication frame. The transmitting node represents the identification information of the sender.

[0054] In this embodiment, assuming an increase or decrease in the expansion device 40E on the expansion side, an "information transmission protocol" including, for example, the following multiple protocols will be adopted. Rule 1: The identification information (CANID) of existing devices shall have the third digit from the bottom set to "1". Rule 2: The identification information (CANID) for expansion devices shall have the third digit from the bottom set to "2". Rule 3: Communication nodes whose second-to-last digit of their identification information (CANID) is the same will exchange information.

[0055] In this embodiment, it is assumed that at the existing gateway 10, one existing device (ID=0x110) is connected to the CAN communication port PX1, and another existing device (ID=0x120) is connected to the CAN communication port PX2. Furthermore, from this existing state, the following three types of topologies are assumed as patterns for adding expansion devices to the expansion gateway 20. Pattern 1: Connect one expansion device (ID=0x210) to PY1. Pattern 2: Connect one expansion device (ID=0x220) to PY2. Pattern 3: Connect one expansion device (ID=0x210) to PY1 and one expansion device (ID=0x220) to PY2.

[0056] In the relay table group TG2 in Figure 4, relay table T1 is the table used for pattern 1. In the case of pattern 1, according to convention 3, it is sufficient to define the relay path (dashed arrow in Figure 4) between the extended device with ID=0x210 and the existing device with ID=0x110. Therefore, relay table T1 includes entry 1, which defines the transmit and receive ports when relaying a communication frame from an extended device with ID=0x210 to an existing device with ID=0x110, and entry 2, which defines the transmit and receive ports in the reverse case.

[0057] In the relay table group TG2 in Figure 4, relay table T2 is the table used for pattern 2. In the case of pattern 2, according to convention 3, it is sufficient to define the relay path (dashed arrow in Figure 4) between the extended device with ID=0x220 and the existing device with ID=0x120. Therefore, relay table T2 includes entry 1, which defines the transmit and receive ports when relaying a communication frame from an extended device with ID=0x220 to an existing device with ID=0x120, and entry 2, which defines the transmit and receive ports in the reverse case.

[0058] In the relay table group TG2 in Figure 4, relay table T3 is the table used for pattern 3. In the case of pattern 3, according to convention 3, it is sufficient to define the relay path between the extended device with ID=0x210 and the existing device with ID=0x110 (dashed arrow in Figure 4), and the relay path between the extended device with ID=0x220 and the existing device with ID=0x120 (dashed arrow in Figure 4).

[0059] Therefore, relay table T3 includes entry 1, which defines the transmit and receive ports when relaying a communication frame from an extended device with ID=0x210 to an existing device with ID=0x110, and entry 3, which defines the transmit and receive ports in the reverse case. Furthermore, relay table T3 includes entry 2, which defines the transmit and receive ports when relaying a communication frame from an extended device with ID=0x220 to an existing device with ID=0x120, and entry 4, which defines the transmit and receive ports in the reverse case.

[0060] The relay table Tn included in the relay table group TG2 is defined individually for each additional pattern that can be anticipated in advance, and is not limited to the three types exemplified in Figure 4. For example, if we consider pattern 4 on the extension side, where the extension device with ID=0x210 is connected to PY2 instead of PY1, then the relay table T4 corresponding to pattern 4 is also included in the relay table group TG2.

[0061] If there are K (a natural number greater than or equal to 3) expansion devices to be added, then multiple topology patterns for connecting k (k=3, 4...K) expansion devices to PYj (j=1, 2...J) can be identified, and a relay table Tn can be defined for each identified expansion pattern. In this way, the multiple relay tables Tn are defined to correspond one-to-one with multiple types of addition patterns when a user, such as a vehicle manufacturer, adds one or more expansion devices to the communication port PYj of the gateway 20 in a predetermined topology.

[0062] [Problems with conventional gateways and their solutions] Figure 5 is an explanatory diagram showing a conventional example of a method for storing and updating relay tables X and Y. As shown in Figure 5, relay table X is a table defined to relay only extension device A, and relay table Y is a table defined to relay both extension device A and extension device B.

[0063] Unlike building LANs such as company LANs or home LANs, the frequency of adding, removing, or changing the connection location of communication nodes such as C-ECUs in vehicle LANs is relatively low. Therefore, conventional gateways that perform relay processing involving protocol conversion are designed to store only one relay table X,Y in the microcontroller's memory.

[0064] Therefore, as shown in Figure 5, when changing from the "first configuration" in which expansion device A is connected to CAN bus 1 to the "second configuration" in which expansion device B is additionally connected to CAN bus 2, it is necessary to rewrite relay table X to relay table Y. Rewriting the relay tables X and Y requires, for example, a maintenance worker for vehicle 1 to connect a management terminal (e.g., a laptop) to the gateway and perform the task manually using a monitoring tool such as a command line, which is time-consuming. For example, in the case of gateway 10 of the existing network 110, such rewriting of the relay tables is necessary.

[0065] Figure 6 is an explanatory diagram showing an example of a method for storing and updating relay tables X, Y, and Z. In Figure 6, relay table X is defined as a table that relays only extension device A, and relay table Y is defined as a table that relays both extension device A and extension device B. Furthermore, relay table Z is used when other expansion devices (not shown) other than expansion devices A and B are added to the connection configuration.

[0066] As described above, in this embodiment, the first memory 25A of the microcontroller 22 stores the raw data of the relay table group TG2, which includes multiple relay tables X, Y, and Z for each of the possible additional patterns. Furthermore, the relay table X (or Y) stored in the second memory 25B is updated by sequentially expanding it from the original data based on the identification information of the expansion devices A and B connected to the expansion gateway 20.

[0067] Therefore, as shown in Figure 6, when changing from the "first configuration" in which expansion device A is connected to CAN bus 1 to the "second configuration" in which expansion device B is additionally connected to CAN bus 2, the second memory 25B The table that is stored is updated from relay table X to relay table Y. The update of such relay tables X and Y can be automatically performed by the microcontroller based on, for example, the identification information of a newly connected extension device B.

[0068] Thus, according to the gateway 20 of this embodiment, the raw data of the relay table group TG2, which is a collection of relay tables X, Y, and Z for each conceivable additional pattern, is stored in the first memory 25A of the microcontroller 22, and the relay table Y to be expanded into the second memory 25B is determined according to the identification information of the expansion devices A and B, etc., so that the updates of the relay tables X, Y, and Z used for relay processing can be performed automatically with plug and play.

[0069] Therefore, it is possible to add, remove, or change the connection location of expansion devices A and B without manually rewriting relay tables X, Y, and Z, which has the advantage of making it easier to change the network configuration. Furthermore, by performing CAN transmission according to relay tables X, Y, and Z, CAN frames are relayed only to the CAN bus to which expansion devices A and B are connected, rather than being broadcast. This has the advantage of reducing bus load and improving security.

[0070] Furthermore, since only one relay table X,Y required for the current connection configuration of expansion devices is deployed to the second memory 25B, there is also the advantage of being able to reduce the storage capacity of the second memory 25B.

[0071] [Relaying of communication frames on the extension side] Figure 7 is a flowchart showing an example of communication frame relay processing on the extension side, which is performed by the control unit 24 of the extension gateway 20. The relay processing shown in Figure 7 is performed using the relay table group TG2 (Figure 4) and is the relay processing of communication frames used for information exchange between the existing device (C-ECU) 40C and the expansion device (C-ECU) 40E. Relaying between CAN bus 60, which does not require protocol conversion, is not included.

[0072] As shown in Figure 7, the control unit 24 of the gateway 20 monitors for the presence or absence of a received frame (step ST31), and if a received frame is detected, it determines whether the received frame is a CAN frame or an ETH frame (step ST32).

[0073] If the result of step ST32 is "CAN", the control unit 24 determines whether the value of CANID included in the CAN frame is within the extended range (step ST33). The extended range refers to the numerical range of CANIDs pre-assigned for the extension device 40E (for example, 0x100 to 0x400).

[0074] If the result of step ST33 is negative, the control unit 24 skips steps ST34 through ST40 and returns the process to before step ST31. The reason is that the source of a CAN frame whose CANID value is outside the extended range is not an extension device 40E that was pre-planned for extension, and therefore, relay processing cannot be performed using any of the relay tables Tn included in the relay table group TG2.

[0075] If the result of step ST33 is positive, the control unit 24 determines whether the CANID included in the CAN frame is authenticated or not (step ST34). If the result of step ST34 is positive, the control unit 24 determines whether the CAN frame is a frame to be relayed from CAN to ETH (step ST35). A frame to be relayed is a CAN frame that contains a CANID included in the relay table Tn currently selected.

[0076] If the result of step ST35 is negative, the control unit 24 skips steps ST36 and ST37 and returns the process to before step ST31. The reason is that a CANID source that does not currently exist in the relay table Tn may be a communication frame from an invalid source, and therefore should not be relayed by the relay table Tn.

[0077] If the determination result in step ST35 is positive, the control unit 24 performs a conversion process from CAN to ETH on the received CAN frame (step ST36). The above conversion process corresponds to a second conversion (see Figure 3) in which the received CAN frame is stored in the payload of the ETH frame.

[0078] Next, the control unit 24 executes the transmission process for the converted ETH frame (step ST37), and then returns to the process before step ST31. The above transmission process is the process of outputting the converted ETH frame to the frame processing unit 21. If the result of step ST34 is negative, the control unit 24 performs an authentication process with the unauthenticated expansion device 40E (step ST38). Through the exchange of information during this authentication process, the control unit 24 obtains the CANID of the new expansion device 40E.

[0079] Next, the control unit 24 uses the CANID of the authenticated extension device 40E to perform the relay table Tn update process (step ST39). The above update process is performed based on all CANID values ​​that have been authenticated to date. Specifically, the update process in step ST39 includes, for example, the following steps:

[0080] Step 1: Read all authenticated CANIDs from memory, including those already authenticated. Step 2: From the relay table group TG2, extract at least one relay table Tn in which the CANID read in Step 1 is included in the field for the transmitting node.

[0081] Step 3: If only one relay table Tn is extracted in Step 2, the extracted relay table Tn is determined to be the relay table Tn to be expanded into the second memory 25B. Step 4: If there are multiple relay tables Tn extracted in Step 2, the relay table Tn whose port numbers match those of multiple currently operating PYj nodes is determined to be the relay table Tn to be expanded into the second memory 25B.

[0082] Furthermore, if the relay table group TG2 (original data) is stored as text-based data in the first memory 25A, a process is added as a preceding step to process 1 to generate multiple relay tables Tn in table format from the original data.

[0083] Next, the control unit 24 notifies the existing gateway 10 of the CANID that was authenticated this time (step ST40), and then returns the process to before step ST31. Specifically, the control unit 24 is a gateway that includes an authenticated CANID. 10 Ethernet to control A frame (for example, an Ethernet OAM frame) is generated, and the generated control frame is output to the frame processing unit 21.

[0084] If the result of the determination in step ST32 is "ETH", the control unit 24 refers to the current relay table Tn (step ST41) and performs the conversion process from ETH to CAN on the received ETH frame (step ST42). The above conversion process corresponds to the first conversion (see Figure 4), which extracts the CAN frame from the payload of the received ETH frame.

[0085] Next, the control unit 24 performs the transmission process for the converted CAN frame (step ST43), and then returns to the process before step ST31. The above transmission process includes, for example, the following steps. Step 1: Extract the entry from the relay table Tn where the CANID value read from the converted CAN frame is recorded in the transmitting node column. Step 2: Read the PYj port number from the relay destination field of the extracted entry, and output the converted CAN frame to the CAN-PHY section 23A corresponding to this port number.

[0086] [Confirmation and response processing for newly installed equipment and update processing of change tables] Figure 8 is an explanatory diagram showing an example of the verification and response processing for the newly installed equipment 40N that the existing gateway 10 and the expanded gateway 20 can each perform. Here, we assume the following states 1 to 4 as the "prerequisite states" for the above confirmation and response processes to be executed.

[0087] (Prerequisites) State 1: Three existing devices (CANIDs 0x110, 0x120, and 0x130, respectively) are currently connected to the existing gateway 10. State 2: Two expansion devices (CANIDs 0x210 and 0x220, respectively) are currently connected to the expansion gateway 20.

[0088] State 3: The existing gateway 10 stores relay table group TG1, which includes relay table Tm for the unconnected expansion device (ID=0x230). State 4: In the initial design, there was no plan to connect the expansion device (ID=0x230), so the relay table group TG2 of the expansion gateway 20 does not include the relay table Tn for connecting the unconnected expansion device (ID=0x230) to the communication port PY3 of the device itself (the expansion gateway 20).

[0089] Under the above preconditions, if an unexpected new expansion device (ID=0x230; hereinafter referred to as "new device 40N") is connected to the communication port PY3 of gateway 20, even if new device 40N is authenticated, gateway 20 cannot perform relay processing to new device 40N because relay table Tn, which is intended for relaying to new device 40N, does not exist in the relay table group TG2. On the other hand, the relay table group TG2 of the existing gateway 20 includes a relay table Tm that is intended for the newly installed equipment 40N.

[0090] Therefore, if the extension gateway 20 cannot find the relay table Tn containing the newly installed equipment 40N in the relay table group TG2, it performs a confirmation process to query the existing gateway 10 for the existence of the existing equipment 40C that is scheduled to communicate with the newly installed equipment 40N via CAN. Specifically, the control unit 24 of the extension gateway 20 performs the following "confirmation process". Verification process (S100): Generate a control frame (ETH frame) for the verification request CR and send it to the existing gateway 10. The verification request CR includes the CANID (=0x230) of the newly installed equipment 40N.

[0091] In response, the control unit 14 of the existing gateway 10, which has received the confirmation request CR, performs the following "response processing". Response processing (S200): Generate a control frame (ETH frame) for the acknowledgment AQ and send it to the extension gateway 10. Acknowledgment AQ The confirmation result should include either "OK" or "NG" as identifying information.

[0092] Specifically, if the control unit 24 of the gateway 20 can retrieve the relay table Tm containing the CANID (=0x230) notified by the confirmation request CR from the relay table group TG1, it sets the confirmation result of the confirmation response AQ to "OK" (affirmative). If the confirmation result is OK, the control unit 24 of the gateway 20 includes the notified CANID (=0x230) and the CANID (=0x130) of the existing device 40C to be connected in the confirmation response AQ.

[0093] The above assumptions were based on the premise that a relay table Tm containing the CANID (=0x230) of the newly installed device 40N exists in the relay table group TG1 (State 3). However, if the addition of the new device 40N was not planned on the existing side, then the relay table Tm does not exist. In this case, the control unit 24 of the gateway 20 sets the confirmation result of the acknowledgment response AQ to "NG" (negative). Furthermore, if the confirmation result is NG, the control unit 24 of the gateway 20 does not include the CANID (=0x130) of the existing device 40C in the acknowledgment response AQ.

[0094] Upon receiving the Acknowledgment Response (AQ), the control unit 24 of the gateway 20 performs the following processing depending on the type of acknowledgment result (OK or NG) included in the Acknowledgment Response. If the verification result is OK, the control unit 24 of the gateway 20 executes the "update process" for the next relay table group TG2.

[0095] Update process (S300): Based on the CANID (=0x130) of the existing device 40C and the CANID (=0x230) of the new device 40N included in the acknowledgment AQ, a new relay table Tn is generated to enable communication between the existing device 40C and the new device 40N, and the generated relay table Tn is stored in the first memory. 25A This is added to the first memory 25A. This updates the relay table group TG2. Furthermore, if the data format of the relay table group TG2 stored in the first memory 25A is text-based, the above update process includes conversion to text format.

[0096] If the verification result is NG, the control unit 24 of the gateway 20 does not perform the update process (S300) of the relay table group TG2. In addition, it sends a CAN frame containing a connection failure message to the newly connected device 40N. In this case, if the expansion device 40E receives the above message and displays a warning or outputs an audio message indicating that connection is not possible, it can inform the user that the newly installed device 40N cannot be connected.

[0097] In the example shown in Figure 8, the communication partner for the verification process by the extended gateway 20 is the existing gateway 10, but this communication partner may be another gateway or ECU included in the extended network 120. Furthermore, if the gateway 20 can communicate with the management server of vehicle 1 via the TCU (Telematics Control Unit), the communication partner for the verification process may also be the management server. In short, the "external device" that acts as the communication partner for the verification process may be located on the existing network, the extended network, or outside of vehicle 1.

[0098] [First variation] In the above-described embodiment, the control unit 24 of the microcontroller 22 of the extension gateway 20 may, for example, determine whether the amount of data in the relay table Tn to be expanded in the second memory 25B exceeds the storage capacity for table storage in the second memory 25B, and if it does, send a CAN frame containing a connection failure message to the extension device 40E. In this case, if the expansion device 40E that receives the above message displays a warning or emits an audio output indicating that it cannot connect, it can inform the user that it is not possible to connect the expansion device 40E again.

[0099] [Second variation] In the embodiment described above, CANID (i.e., the base ID of CAN) is used as the identification information for the "transmitting node" in the relay table Tn, but the identification information for the transmitting node may be an identifier other than this. For example, the identification information for the transmitting node can be any information that can individually identify the device, such as a product ID assigned to the ECU by the manufacturer, or a serial number which is a sequential number assigned to the product by the manufacturer.

[0100] Furthermore, when using product IDs or serial numbers as identification information for the transmitting node, for example, the CAN control area or extended ID can be used as the definition area. However, in the existing network 110, CANID is often used as identification information for existing equipment 40C. Therefore, from the perspective of ensuring consistency between the existing and extended sides, it is preferable to unify the identification information of both existing equipment 40C and extended equipment 40E to CANID.

[0101] [Third variation] In the above embodiment, CANID may be defined not as identification information for the transmitting node (source), but as identification information for the type of data to be transmitted. In this case, the relay table Tn may be formatted to include columns for "relay source," "relay destination," and "data type." In this way, the relay table Tn becomes a table that defines which CAN bus 60 at the relay destination the data to be transmitted will be sent to.

[0102] [Fourth variation] In the embodiments described above, the types of the first and second communication protocols may be not limited to the combination of CAN and ETH, but may also be the following combination examples. Combination Example 1: A combination of CAN and USB (Universal Serial Bus: USB is a registered trademark). In this case, the first communication protocol may be CAN and the second communication protocol may be USB, or vice versa. Combination example 2: USB and ETH combination. In this case, the first communication protocol may be USB and the second communication protocol may be ETH, or vice versa.

[0103] [Fifth variation] In the embodiments described above, the first communication protocol and the second communication protocol do not necessarily have to be of different types, such as CAN and ETH. For example, they may both be CAN, both be USB, or both be ETH. In this case, the control unit 24 of the gateway 20 does not need to perform protocol conversion processing of the communication frame when relaying the communication frame (for example, Figure 3).

[0104] [Sixth variation] In the above embodiment, an example was given in which the control unit 24 of the gateway 20 performs the following two types of update processing. However, the control unit 24 may perform either the first update processing or the second update processing. First update process: Update process for relay table Tn (step S22 in Figure 2) Second update process: Update process for relay table group TG2 (step S100 in Figure 8)

[0105] [Other variations] The embodiments disclosed herein are illustrative in all respects and not restrictive. The scope of the present invention is not limited to the embodiments described above, and includes all modifications within the scope equivalent to the configurations described in the claims.

[0106] In the above-described embodiment, the in-vehicle relay device may be a relay device having multiple Ethernet ports, configured by housing a gateway 20 and one or more switching hubs 30 in a single enclosure.

[0107] In the above embodiment, the microcontroller 22 of the gateway 20 performs both relay processing between CAN buses 60 without protocol conversion and relay processing that involves protocol conversion between CAN and ETH. However, these relay processes may be divided and performed by different microcontrollers (integrated circuits).

[0108] In the above-described embodiment, the existing device 40C and the extended device 40E do not necessarily have to be ECUs; for example, they may be other in-vehicle devices capable of performing CAN communication independently, such as sensors or actuators with CAN communication functionality. [Explanation of Symbols]

[0109] 1 vehicle 10. Existing gateway (in-vehicle relay device) 20. Expansion gateway (vehicle-mounted relay device) 21 Frame Processing Unit (Second Communication Unit) 21A PHY section 21B MAC section 22 Microcontrollers 23. Transceiver (1st Communications Section) 24 Control Unit 25 Memory section 25A First Memory 25B Second Memory 26 Computer Programs 30 Switching Hubs 40 C-ECU (vehicle communication unit) 40C Existing C-ECU (existing equipment) 40E C-ECU (Expansion Device) on the expansion side 40N Expansion side C-ECU (newly installed equipment) 50 E-ECU (vehicle communication device) 60 CAN bus 70 Ethernet Cables 100 In-vehicle communication systems 110 Existing Network 120 Extended Network TG2 relay table group (extension side) Tn relay table (extension side) PXi CAN communication port (existing side) PYj CAN communication port (extension side) PE ETH communication port

Claims

1. An extended in-vehicle relay device capable of performing relay processing of communication frames, A first memory in which raw data for multiple relay tables that can be used in the relay processing is stored, A second memory that stores a relay table expanded from the aforementioned original data, A first communication unit that includes multiple communication ports and transmits and receives a first frame conforming to a first communication protocol at each of the multiple communication ports, A second communication unit that transmits and receives a second frame conforming to the second communication protocol, The system comprises a control unit that performs the relay processing relating to the first frame and the second frame, The control unit, A first update process updates the relay table, which is expanded from the original data in the first memory into the second memory, based on the identification information of the expansion device connected to the communication port. An in-vehicle relay device that performs a second update process which adds the relay table for a newly installed device, which is a new extension device that was not planned to be connected to the device itself, to the first memory.

2. The control unit, Prior to the second update process, The in-vehicle relay device according to claim 1, which performs a confirmation process to inquire with an external device about the existence of existing equipment that is scheduled to communicate with the newly installed equipment based on the first communication protocol.

3. The aforementioned verification process is: The in-vehicle relay device according to claim 2, further comprising the process of transmitting a confirmation request including identification information of the newly installed equipment to the external device.

4. The control unit, The in-vehicle relay device according to claim 3, wherein if the confirmation result of the confirmation response obtained from the external device is positive, the second update process is executed, and if the confirmation result is negative, the second update process is not executed.

5. The control unit, If the above confirmation result is positive, The in-vehicle relay device according to claim 4, which generates a new relay table for communicating between the existing equipment and the newly installed equipment, and adds the generated relay table to the first memory.

6. If the first communication protocol and the second communication protocol are different, The control unit, An in-vehicle relay device according to any one of claims 1 to 5, which performs the relay processing that involves protocol conversion.

7. The first communication protocol is, It is CAN or CAN-FD, The aforementioned second communication protocol is, The in-vehicle relay device according to claim 6, wherein it is Ethernet.

8. The identification information of the aforementioned expansion device is: The in-vehicle relay device according to claim 7, wherein the CANID is...

9. A relay method performed by an extended in-vehicle relay device capable of relaying communication frames, The in-vehicle relay device is A first memory in which raw data for multiple relay tables that can be used in the relay processing is stored, The system includes a second memory that stores a relay table expanded from the original data, The aforementioned relay method, The steps include sending and receiving a first frame conforming to a first communication protocol in at least one of a plurality of communication ports, The steps include sending and receiving a second frame conforming to the second communication protocol, The steps include: performing the relay processing relating to the first frame and the second frame; A relay method comprising the steps of: performing a first update process to update the relay table expanded from the original data in the first memory to the second memory based on identification information of an extension device connected to the communication port; and a second update process to add the relay table for a newly installed device, which is a new extension device that was not planned to be connected to the device, to the first memory.

10. A computer program for causing a computer to function as an extended in-vehicle relay device capable of performing relay processing of communication frames, The aforementioned computer program controls the computer, A first memory in which the raw data of multiple relay tables that can be used in the relay processing is stored, A second memory that stores one relay table expanded from the aforementioned original data, A first communication unit that includes multiple communication ports and transmits and receives a first frame conforming to a first communication protocol at each of the multiple communication ports, A second communication unit that transmits and receives a second frame conforming to the second communication protocol, and It functions as a control unit that performs the relay processing relating to the first frame and the second frame, The control unit, A first update process updates the relay table, which is expanded from the original data in the first memory into the second memory, based on the identification information of the expansion device connected to the communication port. A computer program that performs a second update process, which adds the relay table for a newly installed device, which is a new expansion device that was not planned to be connected to the device itself, to the first memory.

Images