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

Abstract

To facilitate changing an on-vehicle network configuration.SOLUTION: An on-vehicle relay device on an extension side that can execute relay processing of a communication frame includes: a first memory that stores original data of a plurality of relay tables which can be used for the relay processing; a second memory that stores one relay table which is expanded from the original data; a first communication unit that includes a plurality of communication ports, and transmits and receives 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 processing for the first frame and the second frame. The control unit executes 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.SELECTED DRAWING: Figure 3

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 personnel must manually update the repeater table, which results in a 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 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 an update process to update the relay table expanded in the second memory from the original data in the first memory based on identification information of an extended device connected to the communication port.

[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, performing the relaying process for the first frame and the second frame, and performing an update process to update the relay table expanded in the second memory from the original data in the first memory based on identification information of an extended device connected to the communication port.

[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 communication frames, the computer program causing the computer to function as 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, 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 that performs the relay processing for the first frame and the second frame, and the control unit performs an update process to update 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. 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. 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 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 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 an update process to update the relay table expanded in the second memory from the original data in the first memory based on identification information of an extended device connected to the communication port.

[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 control unit executes an update process for updating the relay table to be expanded in the second memory from the original data in the first memory based on the identification information of the extension device connected to the communication port. Therefore, the relay table can be automatically updated in response to the addition or reduction of extension devices or changes in the connection positions without the need to manually update the relay table, and the network configuration can be easily changed.

[0013] (2) In the vehicle-mounted relay device of the present embodiment, the identification information of the extension device may be identification information of the extension device that has been recognized as authentic through an authentication process performed by the vehicle-mounted relay device itself or the other vehicle-mounted relay device. In this way, an update process using the identification information of an unauthorized extension device will not be executed, so that it is possible to prevent an unauthorized extension device from invading the in-vehicle communication system.

[0014] (3) In the vehicle-mounted relay device of this embodiment, if the original data is text-based data including information of the multiple relay tables, the table update may include a process of converting the text-based data into a table format. The reason is that it is difficult to directly determine a single relay table to be expanded in the second memory from the text-based data, so conversion from the text-based data to multiple relay tables is required as a preprocessing step for determining a single relay table.

[0015] (4) In the vehicle-mounted relay device of this embodiment, the control unit may be configured to send a connection-unavailable message to the extension device if the amount of data of the relay table expanded in the second memory exceeds the memory capacity for storing the table in the second memory. In this case, the extension device that has received the message indicating that connection is not possible can display or output a warning, thereby informing the user that a new extension device cannot be connected.

[0016] (5) 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.

[0017] (6) 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.

[0018] (7) 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.

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

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

[0021] <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.

[0022] [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.

[0023] 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.

[0024] 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.

[0025] 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".

[0026] 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."

[0027] 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".

[0028] The C-ECU 40 is connected to the gateways 10, 20 by 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 a 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.

[0029] 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.

[0030] 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.

[0031] 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.

[0032] 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.

[0033] 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."

[0034] [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.

[0035] 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.

[0036] 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.

[0037] 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.

[0038] 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).

[0039] 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.

[0040] 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 information on the multiple relay tables Tn included in the relay table group TG2.

[0041] 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.

[0042] 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).

[0043] 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

[0044] 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.

[0045] 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.

[0046] 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.

[0047] 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.

[0048] 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.

[0049] 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.

[0050] 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.

[0051] 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.

[0052] [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. As shown in Fig. 4, the relay table Tn (n = 1, 2 ... N) on the extended side is data in a matrix format in which a "relay source", "relay destination", and "sending node" are defined for each entry. The relay source means the type of receiving port of the communication frame, and the relay destination means the type of transmitting port of the communication frame. The transmitting node means the identification information of the sending source.

[0053] 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 value be "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.

[0054] 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.

[0055] 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.

[0056] 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.

[0057] 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.

[0058] 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.

[0059] 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.

[0060] 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.

[0061] [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.

[0062] 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.

[0063] 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.

[0064] 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.

[0065] 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.

[0066] 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.

[0067] 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.

[0068] 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.

[0069] 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.

[0070] [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.

[0071] 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).

[0072] 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.

[0073] 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.

[0074] 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.

[0075] 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.

[0076] 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.

[0077] 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.

[0078] 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.

[0079] 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.

[0080] 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.

[0081] 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.

[0082] 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 10 and including the authenticated CANID, and outputs the generated control frame to the frame processing unit 21.

[0083] 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.

[0084] 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.

[0085] [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.

[0086] [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.

[0087] 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 align the identification information of both the existing device 40C and the extension device 40E to the CANID.

[0088] [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 (transmitter). 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.

[0089] [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.

[0090] [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.

[0091] [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.

[0092] 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.

[0093] 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).

[0094] In the above-described embodiment, the existing device 40C and the extension 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]

[0095] 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) 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 The vehicle-mounted relay device executes an 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.

2. The identification information of the extension device is The vehicle-mounted relay device according to claim 1 , wherein the identification information is identification information of the extension device that is recognized as authentic through an authentication process performed by the vehicle-mounted relay device itself or the other vehicle-mounted relay device.

3. The original data is text-based data including information on the plurality of relay tables; The table update is 3. The vehicle-mounted relay device according to claim 1, further comprising a process for converting the text-based data into a table format.

4. The control unit is 3. The vehicle-mounted relay device according to claim 1, wherein if the amount of data of the relay table expanded in the second memory exceeds the storage capacity for storing the table in the second memory, a message indicating that connection is not possible is sent to the extended device.

5. 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.

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

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

8. 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; and executing an 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.

9. 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 computer program that executes an 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;

Images