On-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 technology]

[0002] Patent document 1 describes a technology for efficiently handling a large number of types of communication protocols in an in-vehicle relay device capable of relaying communication frames involving protocol conversion between CAN (Control Area Network: registered trademark) and Ethernet (registered trademark). Patent document 2 describes a technology for generating a communication frame suitable for transmitting information to an ECU (Electronic Control Unit) connected to a CAN bus in an in-vehicle relay device that relays communication frames involving protocol conversion between CAN and Ethernet. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] JP 2021-138263 A [Patent Document 2] JP 2021-119724 A Summary of the Invention [Problem to be solved by the invention]

[0004] In conventional on-board repeaters, when adding or removing expansion devices or changing the connection position of the CAN communication port, the maintenance staff must manually update the repeater table, which results in the problem that changing the network configuration is time-consuming. The present disclosure has an object to provide an in-vehicle relay device and the like that allows easy modification of the network configuration. [Means for solving the problem]

[0005] An apparatus according to one embodiment of the present disclosure is an extended-side vehicle-mounted relay device capable of performing relay processing of communication frames, and includes a first memory in which original data of multiple relay tables that can be used for the relay processing is stored, a second memory in which one relay table expanded from the original data is stored, a first communication unit including multiple communication ports and configured to transmit and receive a first frame conforming to a first communication protocol at each of the multiple communication ports, a second communication unit configured to transmit and receive a second frame conforming to a second communication protocol, and a control unit configured to perform the relay processing for the first frame and the second frame, wherein the control unit performs at least one of a first update process of updating the relay table expanded in the second memory from the original data in the first memory based on identification information of an extension device connected to the communication port, and a second update process of adding to the first memory the relay table for a newly installed device that is a new extension device that was not scheduled to be connected to the apparatus.

[0006] A method according to one aspect of the present disclosure is a relay method performed by an extended-side vehicle-mounted relay device capable of relaying communication frames, the vehicle-mounted relay device having a first memory in which original data of multiple relay tables that can be used for the relaying process is stored, and a second memory that stores one relay table expanded from the original data, and the relay method includes the steps of transmitting and receiving a first frame conforming to a first communication protocol at at least one of multiple communication ports, transmitting and receiving a second frame conforming to a second communication protocol, executing the relaying process for the first frame and the second frame, performing at least one of the following update processes: a first update process of updating the relay table expanded in the second memory from the original data in the first memory based on identification information of an extension device connected to the communication port, and a second update process of adding to the first memory the relay table for a newly installed device that is a new extension device that was not scheduled to be connected to the device itself.

[0007] A computer program according to one embodiment of the present disclosure is a computer program for causing a computer to function as an extended-side vehicle-mounted relay device capable of performing relay processing of a communication frame, the computer program causing the computer to function as a first memory in which original data of a plurality of relay tables that can be used for the relay processing is stored, a second memory in which one relay table expanded from the original data, a first communication unit including a plurality of communication ports and configured to transmit and receive a first frame conforming to a first communication protocol at each of the plurality of communication ports, a second communication unit configured to transmit and receive a second frame conforming to a second communication protocol, and a control unit configured to execute the relay processing for the first frame and the second frame, the control unit executing at least one of a first update process for updating the relay table expanded in the second memory from the original data in the first memory based on identification information of an extension device connected to the communication port, and a second update process for adding to the first memory the relay table for a newly installed device that is a new extension device that was not scheduled to be connected to the device itself. Effect of the Invention

[0008] According to the present disclosure, it is possible to easily change the network configuration. [Brief description of the drawings]

[0009] [Figure 1] FIG. 1 is a network configuration diagram showing an example of the configuration of an in-vehicle communication system. [Diagram 2] FIG. 2 is a block diagram illustrating an example of the internal configuration of the extension-side gateway. [Diagram 3] FIG. 3 is an explanatory diagram showing an example of a conversion process of a communication frame. [Figure 4] FIG. 4 is an explanatory diagram illustrating an example of the extension side relay table. [Diagram 5] FIG. 5 is an explanatory diagram showing a conventional example of a method for storing and updating a relay table. [Figure 6] FIG. 6 is an explanatory diagram showing an embodiment of a method for storing and updating a relay table. [Figure 7] FIG. 7 is a flowchart illustrating an example of a relay process of a communication frame on the extension side. [Figure 8] FIG. 8 is an explanatory diagram showing an example of a confirmation process and a response process for a newly installed device that can be executed by the existing gateway and the new gateway, respectively. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0010] <Overview of the embodiment of the present disclosure> Below, an overview of the embodiments of the present disclosure will be listed and described.

[0011] (1) The device of this embodiment is an extended-side vehicle-mounted relay device capable of performing relay processing of communication frames, and includes a first memory in which original 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 original data, a first communication unit that includes multiple communication ports and transmits and receives a first frame that conforms to a first communication protocol at each of the multiple communication ports, a second communication unit that transmits and receives a second frame that conforms to a second communication protocol, and a control unit that performs the relay processing for the first frame and the second frame, and the control unit performs at least one of a first update process that updates the relay table expanded in the second memory from the original data in the first memory based on identification information of an extension device connected to the communication port, and a second update process that adds the relay table for a new device that is a new, unconnected extension device to the first memory.

[0012] The relay process relating to the first frame and the second frame includes mutual relaying of the first frame and the second frame. According to the vehicle-mounted relay device of this embodiment, the update process executed by the control unit includes a first update process that updates the relay table expanded from the original data in the first memory to the second memory based on identification information of an expansion device connected to a communication port. Therefore, when the above-mentioned first update process is executed, the relay table can be automatically updated according to the addition or reduction of the extension device or the change in the connection position without having to update the relay table manually, and the network configuration can be easily changed. The update process executed by the control unit also includes a second update process for adding to the first memory a relay table for a new device that is a new extension device that was not scheduled to be connected to the device itself. Therefore, when the second update process is executed, even if the extension device is the newly installed device, it can be included in the target of the first update process.

[0013] (2) In the vehicle-mounted relay device of this embodiment, prior to the second update process, the control unit may execute a confirmation process to inquire of an external device about the presence or absence of existing equipment that is scheduled to communicate with the newly installed equipment based on the first communication protocol. The reason is that if there is no existing device that is scheduled to communicate with the newly installed device using the first communication protocol, there is no need to add a relay table.

[0014] (3) In the vehicle-mounted relay device of this embodiment, the confirmation process may include a process of transmitting a confirmation request including identification information of the newly installed device to the external device. The reason is that in order for an external device to determine the presence or absence of an existing device that is scheduled to communicate with the newly installed device, identification information of the newly installed device is required.

[0015] (4) In the vehicle-mounted relay device of this embodiment, the control unit may execute the second update process if the confirmation result of the confirmation response obtained from the external device is positive, and may not execute the second update process if the confirmation result is negative. The reason is that if the confirmation result is positive, a relay table needs to be added, but if the confirmation result is negative, there is no need to add a relay table.

[0016] (5) In the vehicle-mounted 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 make the generated relay table a target for addition to the first memory. In this way, a new relay table for communicating between the existing devices and the newly installed devices is added to the first memory, and the new relay table becomes the target of the first update process. Therefore, even if the relay table is not updated manually, the relay table can be automatically updated to one corresponding to the addition of the newly installed device, and the network configuration can be easily changed.

[0017] (6) In the vehicle-mounted relay device of this embodiment, when the first communication protocol and the second communication protocol are different, the control unit may execute the relay process involving protocol conversion. In this case, even if the first communication protocol and the second communication protocol are different, the first frame and the second frame can be appropriately relayed to each other.

[0018] (7) In the vehicle-mounted 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 on the first frame of CAN or CAN-FD and the second frame of Ethernet.

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

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

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

[0022] <Details of the embodiment of the present invention> Hereinafter, the details of the embodiments of the present invention will be described with reference to the drawings. Note that at least some of the embodiments described below may be combined in any desired manner.

[0023] [Example of vehicle-mounted communication system configuration] FIG. 1 is a network configuration diagram showing an example of the configuration of an in-vehicle communication system 100. As shown in FIG. 1, an in-vehicle communication system 100 according to the present embodiment is an in-vehicle Local Area Network (LAN) built inside a vehicle 1. The in-vehicle communication system 100 includes a plurality of gateways 10 and 20, a switching hub 30, and ECUs 40 and 50 as communication nodes constituting the network.

[0024] The ECUs 40 and 50 are electronic control units for the vehicle that control various in-vehicle devices such as sensors and actuators in the vehicle 1. Moreover, the ECUs 40 and 50 are communication nodes that constitute the in-vehicle communication system 100, and can be considered as a type of "in-vehicle communication device" from the viewpoint of communication.

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

[0026] In terms of communication protocols, the in-vehicle communication system 100 is a network in which an ECU 40 that performs communication in accordance with a "first communication protocol" and an ECU 50 that performs communication in accordance with a "second communication protocol" are mixed. The first communication protocol may be, for example, CAN (Control Area Network: registered trademark), CAN-FD (CAN with flexible data rate), LIN (Local Interconnect Network), or FlexRay (registered trademark). In this embodiment, the first communication protocol is assumed to be "CAN".

[0027] The second communication protocol is not particularly limited in 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. In the following, Ethernet may be abbreviated as "ETH."

[0028] The ECU 40 is an ECU that performs communication in compliance with CAN (first communication protocol). In this embodiment, a communication frame conforming to CAN is referred to as a "CAN frame" or a "first frame", and an ECU that performs CAN communication is referred to as a "C-ECU". The ECU 50 is an ECU that performs communication in compliance with ETH (second communication protocol). In this embodiment, a communication frame conforming to ETH is referred to as an "Ethernet (ETH) frame" or a "second frame", and an ECU that performs ETH communication is referred to as an "E-ECU".

[0029] The C-ECU 40 is connected to the gateways 10, 20 via a CAN bus 60. The CAN bus 60 is a communication line made up of high-side and low-side wiring. A plurality of C-ECUs 40 can be connected in line to one CAN bus 60. The E-ECU 50 is connected to the gateways 10, 20 or the switching hub 30 by a LAN cable 70. The LAN cable 70 is a communication line that supports a category of CAT5 or higher, which can ensure a communication speed of, for example, 100 Mbps or 1 Gbps.

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

[0031] 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 in the vehicle 1 as standard, and the extended network 120 is a network that is built as an option in the vehicle 1. The extended network 120 can be added when the vehicle 1 is serviced, for example. Potential needs for additions include, for example, strengthening the safety functions of the vehicle 1 and adding new functions desired by the user of the vehicle 1.

[0032] In the example of FIG. 1, the existing network 110 includes one existing side gateway 10, two C-ECUs 40 (40C), one switching hub 30, and one E-ECU 50 as communication nodes that are components. However, the types and numbers of communication nodes described above are merely examples, and the actual existing network 110 may include many more gateways 10, switching hubs 30, and ECUs 40 and 50 than those shown in the example.

[0033] In the example of FIG. 1, the extension network 120 includes one extension-side gateway 20, two switching hubs 30, two C-ECUs 40 (40E), and one E-ECU 50 as component communication nodes. The types and numbers of communication nodes described above are also just examples. For example, the gateway 20 may be connected to the gateway 10 via a LAN cable 70 without going through the switching hub 30, or the expansion side E-ECU 40 may be connected to the gateway 10 via a LAN cable 70.

[0034] As described above, the C-ECU 40 of the in-vehicle communication system 100 includes the C-ECU 40C that is already included in the existing network 110 and the C-ECU 40E that may be adopted as a communication node of the extended network 120 in the future. Therefore, in the following description, C-ECU 40C, which is a component of existing network 110, may be referred to as "existing device 40C," and C-ECU 40E, which may be a component of expansion network 120, may be referred to as "expansion device 40E."

[0035] [Example of gateway configuration on the expansion side] FIG. 2 is a block diagram showing an example of the internal configuration of the extension-side gateway 20. As shown in FIG. 2, the extension-side gateway 20 includes a frame processor 21 for ETH communication, a microcomputer 22, and a transceiver 23 for CAN communication. The extension-side gateway 20 also includes 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 a "second communication unit" that transmits and receives an ETH frame (second frame) that complies 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 the Ethernet, and includes a PHY unit 21A and a MAC unit 21B. The PHY unit 21A is an integrated circuit that performs modulation and demodulation of signals in accordance with the Ethernet, and is provided corresponding to the Ethernet communication port PE.

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

[0038] The microcomputer 22 is a microcomputer including a control unit 24 and a storage unit 25 . The control unit 24 is a processor including one or more central processing units (CPUs). The control unit 24 may include other integrated circuits such as an FPGA. The control unit 24 reads out the computer program 26 stored in the first memory 25A of the storage unit 25 into the second memory 25B, and executes information processing required for relaying communications in accordance with the read out program 26. The details of this information processing will be described later.

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

[0040] The second memory 25B is a main storage device including a volatile memory such as an SRAM (Static RAM) or a DRAM (Dynamic RAM). The information loaded in the second memory 25B includes the computer program 26 as well as a relay table Tn (described later) used in relay processing involving protocol conversion.

[0041] In addition to the computer program 26, the first memory 25A stores as an archive the original data of a relay table group TG2 including multiple relay tables Tn (n=1, 2...N) that may be required when relaying communication frames involving protocol conversion. The data format of the original data may be a table format of the multiple relay tables Tn as they are, or may be a text-based data format including all the information of the multiple relay tables Tn included in the relay table group TG2.

[0042] However, in order to determine one relay table Tn to be developed in the second memory 25B from the text-based original data, a process of converting the text-based data into a table format is required. Examples of text-based data formats that can be adopted include CSV (Comma Separated Values), XML (Extensible Markup Language), and JSON (JavaScript Object Notation), etc. The data contents of the relay table group TG2 will be described later.

[0043] The transceiver 23 corresponds to a "first communication unit" that transmits and receives a CAN frame (first frame) that complies with the first communication protocol. The transceiver 23 is a transmitter / receiver that performs physical layer signal processing in accordance with the CAN, and includes multiple PHY units 23 A. The PHY units 23 A are integrated circuits that are provided for each communication port PYj (j=1, 2...N) of the CAN and perform signal conversion at the L1 level of the CAN. 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 executed by the control unit 24 of the microcomputer 22 includes at least the following three processes. S21: Authentication process of the extension device 40E S22: Relay table update process S23: Protocol conversion process

[0045] The authentication process S21 is a process for determining whether or not the extension device (C-ECU) 40E newly connected to the own device is a legitimate communication node. The authentication process S21 may employ, for example, key exchange using a message authentication code or a digital signature performed with the expansion device 40E that is newly added to the CAN bus 60 connected to the communication port PYj.

[0046] The update process S22 is a process for updating the relay table Tn expanded in 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 executed based on, for example, the identification information (for example, CANID) of all the extension devices 40E that have been recognized as authentic in the authentication process S21.

[0047] Specifically, the control unit 24 determines which of the multiple relay tables Tn should be loaded in the second memory 25B based on the identification information of the authenticated extension device 40E. Then, the control unit 24 updates one relay table Tn used in the relay process by loading the data of the determined relay table Tn in the second memory 25B.

[0048] The conversion process S23 is a process of performing protocol conversion between CAN and ETH in both directions by referring to one relay table Tn that is stored in the second memory 25B and updated in the update process S22. Specifically, the control unit 21 performs a “first conversion” to convert 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 to which PHY unit 23A included in the transceiver 23 the converted CAN frame is to be output (to which CAN bus 60 the converted CAN frame is to be output), based on one relay table Tn expanded in the second memory 15B. Conversely, the control unit 21 performs a “second conversion” to convert a CAN frame input from any PHY unit 23A included in the transceiver 23 into an ETH frame, and outputs the converted ETH frame to the frame processing unit 21.

[0050] FIG. 3 is an explanatory diagram showing an example of the communication frame conversion process S13 executed by the control unit 24 of the microcomputer 22. As shown in FIG. As shown in Figure 3, we adopt a method in which all data of the CAN frame is stored in the payload of the ETH frame.

[0051] In this case, the control unit 24 extracts the CAN frame from the payload of the ETH frame input from the frame processing unit 21, thereby executing a “first conversion” from the ETH frame to the CAN frame. In addition, the control unit 24 executes a "second conversion" from the CAN frame to the 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 microcomputer 22 executes a transmission process of the converted communication frame. The transmission process by the control unit 24 includes the following processes. ETH transmission: A process of outputting the converted ETH frame to the frame processing unit 21. CAN transmission: A process of outputting the converted CAN frame to the transceiver 23. In this case, the output destination of the CAN frame (transmission port PYj) complies with the provisions of the relay table Tn.

[0053] [Specific example of relay table group on extension side] FIG. 4 is an explanatory diagram showing an example of the extension side relay table group TG2. The relay table Tn (n=1, 2...N) on the extended side in Fig. 4 is data in a matrix format in which a "relay source," "relay destination," and "sending node" are defined for each entry. The relay source refers to the type of receiving port of the communication frame, and the relay destination refers to the type of transmitting port of the communication frame. The transmitting node refers to the identification information of the sending source.

[0054] In this embodiment, assuming an increase or decrease in the extension device 40E on the extension side, for example, an "information transmission protocol" including the following multiple protocols is adopted. Rule 1: The identification information (CANID) of existing devices shall have the third lowest digit as "1". Rule 2: The third lowest digit of the extension device identification information (CANID) shall be "2". Rule 3: Communication nodes with the same value in the second lowest digit of their identification information (CANID) can exchange information.

[0055] In this embodiment, it is assumed that one existing device (ID=0x110) is connected to the CAN communication port PX1 and one existing device (ID=0x120) is connected to the CAN communication port PX2 in the existing side gateway 10. Furthermore, from this existing state, the following three types of topology patterns are assumed as patterns for adding an extension device to the extension side 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 extension device (ID=0x210) to PY1, and connect one extension device (ID=0x220) to PY2.

[0056] 4, relay table T1 is a table used for pattern 1. In the case of pattern 1, it is sufficient to specify a relay path (dashed arrow in FIG. 4) between an extension device with ID=0x210 and an existing device with ID=0x110 according to rule 3. For this reason, the relay table T1 includes entry 1 that specifies the transmission and reception ports when relaying a communication frame from an extension device with ID=0x210 to an existing device with ID=0x110, and entry 2 that specifies the transmission and reception ports in the opposite case.

[0057] 4, relay table T2 is a table used for pattern 2. In the case of pattern 2, it is sufficient to specify a relay path (dashed arrow in FIG. 4) between an extension device with ID=0x220 and an existing device with ID=0x120 according to rule 3. For this reason, relay table T2 includes entry 1 that specifies the transmission and reception ports when relaying a communication frame from an extension device with ID=0x220 to an existing device with ID=0x120, and entry 2 that specifies the transmission and reception ports in the opposite case.

[0058] 4, relay table T3 is a table used for pattern 3. In the case of pattern 3, it is sufficient to specify a relay route (dashed arrow in FIG. 4) between an extension device with ID=0x210 and an existing device with ID=0x110, and a relay route (dashed arrow in FIG. 4) between an extension device with ID=0x220 and an existing device with ID=0x120, according to rule 3.

[0059] For this reason, relay table T3 includes entry 1 that specifies the transmission and reception ports when relaying a communication frame from an extension device with ID=0x210 to an existing device with ID=0x110, and entry 3 that specifies the transmission and reception ports in the opposite case. The relay table T3 also includes an entry 2 that specifies the transmission and reception ports when relaying a communication frame from an extension device with ID=0x220 to an existing device with ID=0x120, and an entry 4 that specifies the transmission and reception ports in the reverse case.

[0060] The relay tables Tn included in the relay table group TG2 are individually defined for each possible addition pattern, and are not limited to the three types illustrated in FIG. For example, when a pattern 4 is assumed in which an extension device with ID=0x210 is connected to PY2 instead of PY1 on the extension side, a relay table T4 corresponding to the pattern 4 is also included in the relay table group TG2.

[0061] If the number of extension devices to be added is K (K is a natural number greater than or equal to 3), multiple topologies for addition patterns when connecting k (k=3, 4....K) extension devices to PYj (j=1, 2....J) are identified, and a relay table Tn is defined for each identified addition 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 extension devices to the communication port PYj of the gateway 20 in a specified topology.

[0062] [Problems with conventional gateways and how to solve them] FIG. 5 is an explanatory diagram showing a conventional example of a method for storing and updating relay tables X and Y. In FIG. As shown in FIG. 5, relay table X is a table defined so that only extension device A is a relay target, and relay table Y is a table defined so that extension device A and extension device B are relay targets.

[0063] Unlike a LAN within a building such as an in-house LAN or a home LAN, in an in-vehicle LAN, the frequency with which a communication node such as a C-ECU is added, removed, or the connection position is changed is relatively low. For this reason, in conventional gateways that perform relay processing involving protocol conversion, only one relay table X, Y is stored in the memory of the microcomputer.

[0064] Therefore, as shown in FIG. 5, when changing from a “first configuration” in which extension device A is connected to CAN bus 1 to a “second configuration” in which extension device B is additionally connected to CAN bus 2, a process of rewriting relay table X to relay table Y is required. The rewriting of the relay tables X and Y is required to be performed manually by, for example, a maintenance person of the vehicle 1 by connecting a management terminal (for example, a notebook PC) to the gateway and using a monitoring tool such as a command line, which is a time-consuming task. For example, in the case of the gateway 10 of the existing network 110, such rewriting of the relay tables is required.

[0065] FIG. 6 is an explanatory diagram showing an embodiment of a method for storing and updating relay tables X, Y, and Z. In FIG. 6 as well, relay table X is a table defined so that only extension device A is the relay target, and relay table Y is a table defined so that extension device A and extension device B are the relay targets. Moreover, relay table Z is a table used in the case of a connection configuration in which an extension device (not shown) other than extension device A and extension device B is added.

[0066] As described above, in this embodiment, the first memory 25A of the microcomputer 22 stores original data of the relay table group TG2 including a plurality of relay tables X, Y, and Z for each possible addition pattern. Moreover, the relay table X (or Y) stored in the second memory 25B is updated by being expanded point by point from the original data based on the identification information of the extension devices A and B currently connected to the gateway 20 on the extension side.

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

[0068] In this manner, according to the gateway 20 of this embodiment, the original data of the relay table group TG2, which is a collection of relay tables X, Y, Z for each conceivable addition pattern, is stored in the first memory 25A of the microcomputer 22, and the relay table Y to be expanded in the second memory 25B is determined according to the identification information of the extension devices A and B, etc., so that the relay tables X, Y, Z used in the relay processing can be automatically updated by plug-and-play.

[0069] Therefore, it is possible to add or remove extension devices A and B or change their connection positions without having to manually rewrite relay tables X, Y, and Z, which has the advantage of facilitating changes to the network configuration. In addition, by performing CAN transmission according to relay tables X, Y, and Z, the CAN frame is relayed only to the CAN bus to which extension devices A and B are connected, rather than being broadcast, which has the advantage of reducing the bus load and improving security.

[0070] Furthermore, since only one relay table X, Y required in the current connection configuration of the extension device is loaded in the second memory 25B, there is also the advantage that the storage capacity of the second memory 25B can be reduced.

[0071] [Relay processing of communication frames on the extension side] FIG. 7 is a flowchart showing an example of a relay process of a communication frame on the extension side, which is executed by the control unit 24 of the gateway 20 on the extension side. The relay process in FIG. 7 is a relay process of a communication frame used for information exchange between the existing device (C-ECU) 40C and the extension device (C-ECU) 40E, which is performed using the relay table group TG2 (FIG. 4), and does not include relaying between CAN buses 60 that do not require protocol conversion.

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

[0073] If the determination result in step ST32 is "CAN", the control unit 24 determines whether or not the value of the CANID included in the CAN frame is within the extension target range (step ST33). The extension target range is a numerical range of CANIDs (for example, 0x100 to 0x400) that is assigned in advance to the extension device 40E.

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

[0075] If the determination result in step ST33 is positive, the control unit 24 determines whether or not the CAN ID included in the CAN frame has been authenticated (step ST34). If the determination result in step ST34 is positive, the control unit 24 determines whether or not 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 includes a CANID included in the currently selected relay table Tn.

[0076] If the determination result in step ST35 is negative, the control section 24 skips steps ST36 and ST37, and returns the process to before step ST31. The reason is that a source of a CANID that does not exist in the current relay table Tn may be a communication frame from an unauthorized source, and therefore relay processing should not be performed 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 the 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 a transmission process of the converted ETH frame (step ST37), and then returns the process to before step ST31. The above transmission process is a process of outputting the converted ETH frame to the frame processing unit 21. If the determination result in step ST34 is negative, the control unit 24 executes authentication processing with the unauthenticated extension device 40E (step ST38). Through information exchange during this authentication processing, the control unit 24 acquires the CANID of the new extension device 40E.

[0079] Next, the control unit 24 performs an update process of the relay table Tn by using the CANID of the extension device 40E for which authentication has been completed (step ST39). The above-mentioned update process is performed based on all CANID values ​​that have been authenticated up to now. Specifically, the update process in step ST39 includes, for example, the following steps.

[0080] Step 1: Read all CANIDs that have been authenticated, including the one that has been authenticated this time, from memory. Step 2: At least one relay table Tn in which the CANID read out in step 1 is included in the sending node column is extracted from the relay table group TG2.

[0081] Step 3: If only one relay table Tn is extracted in step 2, the extracted relay table Tn is determined as the relay table Tn to be developed in the second memory 25B. Step 4: If multiple relay tables Tn are extracted by step 2, the relay table Tn in which the port numbers of the multiple currently operating PYj match the multiple port numbers included in the sending node column is determined to be the relay table Tn to be expanded in the second memory 25B.

[0082] When the relay table group TG2 (original data) is stored in the first memory 25A as text-based data, a process of generating a plurality of relay tables Tn in table format from the original data is added as a pre-process of the process 1.

[0083] Next, the control unit 24 notifies the existing gateway 10 of the currently authenticated CANID (step ST40), and then returns the process to before step ST31. Specifically, the control unit 24 generates an Ethernet control unit frame (for example, an Ethernet OAM frame) addressed to the gateway 19 including the authenticated CANID, and outputs the generated control frame to the frame processing unit 21.

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

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

[0086] [Confirmation and response processing of newly installed equipment and update processing of change table group] FIG. 8 is an explanatory diagram showing an example of a confirmation process and a response process of the new device 40N that can be executed by the existing-side gateway 10 and the extension-side gateway 20, respectively. Here, the following states 1 to 4 are assumed as "prerequisite states" for executing the above confirmation process and response process.

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

[0088] State 3: The existing gateway 10 stores a relay table group TG1 including a relay table Tm for an unconnected extension device (ID=0x230). State 4: Since the original design did not include plans to connect an extension device (ID=0x230), the relay table group TG2 of the extension side gateway 20 does not include a relay table Tn for connecting an unconnected extension device (ID=0x230) to the communication port PY3 of its own device (the extension side gateway 20).

[0089] In the above-mentioned premise state, when an unplanned new expansion device (ID=0x230: hereinafter referred to as the "new device 40N") is connected to the communication port PY3 of the gateway 20, even if the new device 40N is authenticated, the gateway 20 cannot perform relay processing to the new device 40N because the relay table Tn intended for relaying to the 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 assumes the new device 40N.

[0090] Therefore, if the gateway 20 on the expansion side cannot find a relay table Tn including the new device 40N from the relay table group TG2, it performs a confirmation process to inquire of the gateway 10 on the existing side about the presence or absence of the existing device 40C that is scheduled to perform CAN communication with the new device 40N. Specifically, the control unit 24 of the gateway 20 on the expansion side executes the following "confirmation process". Confirmation process (S100): A control frame (ETH frame) of a confirmation request CR is generated and transmitted to the existing side gateway 10. The confirmation request CR includes the CANID (=0x230) of the new device 40N.

[0091] In response to this, the control unit 14 of the existing gateway 10 that has received the confirmation request CR executes the following "response process." Response process (S200): A control frame (ETH frame) of an acknowledgement response AQ is generated and transmitted to the extension-side gateway 10. The acknowledgement response AC includes "OK" or "NG" as identification information of the confirmation result.

[0092] Specifically, if the control unit 24 of the gateway 20 can search the relay table Tm including 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" (positive). If the confirmation result is OK, the control unit 24 of the gateway 20 includes in the confirmation response AQ the CANID (=0x130) of the existing device 40C to be connected to the notified CANID (=0x230).

[0093] In the above premise state, it is assumed that a relay table Tm including the CANID (=0x230) of the new device 40N exists in the relay table group TG1 (state 3). However, if the addition of the new device 40N is not planned on the existing side either, the relay table Tm does not exist. In this case, the control unit 24 of the gateway 20 sets the confirmation result of the confirmation response AQ to "NG" (negative). Also, when the confirmation result is NG, the control unit 24 of the gateway 20 does not include the CANID (=0x130) of the preexisting device 40C in the confirmation response AQ.

[0094] The control unit 24 of the gateway 20 that has received the confirmation response AQ executes the following processes according to the type of confirmation result (OK or NG) contained in the confirmation response AQ. If the confirmation result is OK, the control unit 24 of the gateway 20 executes the "update process" of 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 confirmation response AQ, a new relay table Tn for communicating between the existing device 40C and the new device 40N is generated, and the generated relay table Tn is added to the first memory 25B. This updates the relay table group TG2 in the first memory 25A. It should be noted that, 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 the text format.

[0096] If the confirmation result is NG, the control unit 24 of the gateway 20 does not execute the update process (S300) of the relay table group TG2, and transmits a CAN frame including a message indicating that connection is not possible to the connected new device 40N. In this case, if the extension device 40E that has received the above message displays a warning or outputs a sound indicating that connection is not possible, it is possible to notify the user that the new device 40N cannot be newly connected.

[0097] In the example of FIG. 8, the communication partner of the confirmation process by the extension-side gateway 20 is the existing-side gateway 10, but the communication partner may be another gateway or ECU included in the extension network 120. In addition, if the gateway 20 can communicate with a management server of the vehicle 1 via a TCU (Telematics Control Unit), the communication partner for performing the confirmation process may be the management server. In other words, the "external device" that is the communication partner for the confirmation process may be present in any of the existing network, the extended network, and outside the vehicle 1.

[0098] [First Modification] In the above-described embodiment, the control unit 24 of the microcomputer 22 of the gateway 20 on the expansion side may, for example, determine whether or not the amount of data of the relay table Tn to be expanded in the second memory 25B exceeds the storage capacity for storing the table in the second memory 25B, and if so, may transmit a CAN frame including a message indicating that connection is not possible to the expansion device 40E. In this case, if the extension device 40E that has received the above message displays a warning or outputs a sound indicating that connection is not possible, it is possible to notify the user that the extension device 40E cannot be newly connected.

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

[0100] Furthermore, when a product ID, a serial number, or the like is used as identification information for a transmitting node, for example, a control area or an extension ID of the CAN may be used as a definition area. However, the CANID is often used as identification information for the existing device 40C in the existing network 110. For this reason, from the viewpoint of achieving consistency between the existing side and the extension side, it is preferable to use the same CANID as identification information for both the existing device 40C and the extension device 40E.

[0101] [Third Modification] In the above embodiment, the CANID may be defined as identification information of the type of data to be transmitted, rather than as identification information of the transmitting node (transmission source). In this case, the relay table Tn may be in a format including the columns of “relay source”, “relay destination”, and “data type”. In this way, the relay table Tn becomes a table that defines to which of the destination CAN buses 60 the data to be transmitted is to be transmitted.

[0102] [Fourth Modification] In the above-described embodiment, the types of the first communication protocol and the second communication protocol are not limited to the combination of CAN and ETH, and may be any of the following combination examples. Combination example 1: 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: combination of USB and ETH In this case, the first communication protocol may be USB and the second communication protocol may be ETH, or vice versa.

[0103] [Fifth Modification] In the above-described embodiments, the first communication protocol and the second communication protocol do not necessarily have to be different types, such as CAN and ETH, but may be the same type of protocol, for example, both CAN, both USB, and both ETH. In this case, the control unit 24 of the gateway 20 does not need to perform a protocol conversion process (eg, FIG. 3) of the communication frame when relaying the communication frame.

[0104] [Sixth Modification] In the above embodiment, an example was given of the control unit 24 of the gateway 20 executing the two types of update processing described below, but the control unit 24 may execute either the first update processing or the second update processing. First update process: Update process of relay table Tn (step S22 in FIG. 2) Second update process: Update process of relay table group TG2 (step S100 in FIG. 8)

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

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

[0107] In the above-described embodiment, the microcomputer 22 of the gateway 20 performs both relay processing between CAN buses 60 without protocol conversion, and relay processing involving protocol conversion between CAN and ETH. However, the relay processing may be shared and performed by different microcomputers (integrated circuits).

[0108] In the above-described embodiment, the existing device 40C and the expansion device 40E do not necessarily need to be ECUs, and may be, for example, in-vehicle devices other than ECUs that can perform CAN communication independently, such as sensors or actuators having a CAN communication function. [Explanation of symbols]

[0109] 1 vehicle 10 Existing gateway (vehicle-mounted relay device) 20 Expansion gateway (vehicle-mounted relay device) 21 Frame processing unit (second communication unit) 21A PHY section 21B MAC section 22 Microcomputer 23 Transceiver (first communication unit) 24 Control Unit 25 Memory section 25A 1st Memory 25B Second memory 26 Computer Programs 30 Switching Hub 40 C-ECU (vehicle communication unit) 40C Existing C-ECU (existing equipment) 40E Expansion side C-ECU (expansion device) 40N Expansion side C-ECU (new equipment) 50 E-ECU (vehicle communication device) 60 CAN Bus 70 Ethernet Cable 100 In-vehicle communication system 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 extension-side in-vehicle relay device capable of relaying a communication frame, a first memory in which original data of a plurality of relay tables that can be used in the relay process is stored; a second memory for storing one relay table developed from the original data; a first communication unit including a plurality of communication ports, the first communication unit transmitting and receiving a first frame conforming to a first communication protocol at each of the plurality of communication ports; a second communication unit that transmits and receives a second frame conforming to a second communication protocol; a control unit that executes the relay process for the first frame and the second frame, The control unit is a first update process for updating the relay table expanded in the second memory from the original data in the first memory based on identification information of an extension device connected to the communication port; a second update process for adding to the first memory the relay table for a newly installed device that is a new extension device that was not scheduled to be connected to the vehicle-mounted relay device; and

2. The control unit is Prior to the second update process, The vehicle-mounted relay device according to claim 1 , further comprising: a confirmation process for inquiring of an external device as to whether or not there is an existing device that is scheduled to communicate with the newly installed device based on the first communication protocol.

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

4. The control unit is The vehicle-mounted relay device according to claim 3, further comprising: a first update process for updating a first received signal from the external device; a second update process for updating a second received signal from the external device;

5. The control unit is If the result of said confirmation is positive, 4. The vehicle-mounted relay device according to claim 3, further comprising: a relay table for communicating between the existing device and the newly installed device; and a relay table for adding the newly generated relay table to the first memory.

6. When the first communication protocol and the second communication protocol are different, The control unit is The vehicle-mounted relay device according to claim 1 , wherein the relay process involves a protocol conversion.

7. The first communication protocol is CAN or CAN-FD, The second communication protocol is 7. The vehicle-mounted relay device according to claim 6, wherein the relay device is an Ethernet.

8. The identification information of the extension device is The vehicle-mounted relay device according to claim 7, which is a CANID.

9. A relay method executed by an extension-side in-vehicle relay device capable of relaying a communication frame, comprising: The vehicle-mounted relay device a first memory in which original data of a plurality of relay tables that can be used in the relay process is stored; a second memory for storing one relay table developed from the original data; The relay method includes: transmitting and receiving a first frame conforming to a first communications protocol at at least one of a plurality of communications ports; transmitting and receiving a second frame conforming to a second communications protocol; performing the relay process for the first frame and the second frame; A relay method comprising the steps of: executing at least one of a first update process for updating 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 for adding to the first memory the relay table for a newly installed device, which is a new extension device that was not scheduled to be connected to the device itself.

10. A computer program for causing a computer to function as an extension-side in-vehicle relay device capable of relaying a communication frame, comprising: The computer program causes the computer to: a first memory in which original data of a plurality of relay tables that can be used in the relay process is stored; a second memory for storing one relay table developed from the original data; a first communication unit including a plurality of communication ports, the first communication unit transmitting and receiving a first frame conforming to a first communication protocol at each of the plurality of communication ports; a second communication unit that transmits and receives a second frame conforming to a second communication protocol; and a control unit that executes the relay process for the first frame and the second frame; The control unit is a first update process for updating the relay table expanded in the second memory from the original data in the first memory based on identification information of an extension device connected to the communication port; a second update process of adding to the first memory the relay table for a new device that is a new extension device that was not scheduled to be connected to the device itself;

Images