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

Abstract

A device according to one embodiment of the present disclosure is an in-vehicle relay device capable of performing a relay process of a communication frame, the in-vehicle relay device being provided with: a storage unit in which a plurality of relay tables required for the relay process are stored; a first communication unit that includes a plurality of communication ports and that transmits and receives a first frame following a first communication protocol at each of the plurality of communication ports; a second communication unit that transmits and receives a second frame following a second communication protocol; and a control unit that performs the relay process relating to the first frame and the second frame, the control unit performing a selection process of selecting the first frame based on identification information included in the first frame transmitted by an extension device connected to one of the plurality of communication ports, the extension device being connected to one of the plurality of communication ports, and the extension device being connected to one of the plurality of communication ports. And a selection unit that selects one relay table from among the plurality of relay tables stored in the storage unit.

Description

Technical Field

[0001] The present disclosure relates to an in-vehicle relay device, a relay method, and a computer program. This application claims priority based on Japanese application No. 2023-17346, filed on February 8, 2023, and incorporates all of the content described in the aforementioned Japanese application by reference. Background Art

[0002] Patent Document 1 describes a technology for efficiently handling the number of communication protocol types in an on-vehicle relay device capable of relaying communication frames with protocol conversion between CAN (Control Area Network: registered trademark) and Ethernet (registered trademark).

[0003] 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 on-vehicle relay device that performs a communication frame relay process involving protocol conversion between CAN and Ethernet.

[0004] Prior art literature

[0005] Patent Document 1: Japanese Patent Application Laid-Open No. 2021-138263

[0006] Patent Document 2: Japanese Patent Application Laid-Open No. 2021-119724 Summary of the Invention

[0007] A device of a technical solution disclosed herein is an on-vehicle relay device capable of performing relay processing of communication frames, and the on-vehicle relay device comprises: a storage unit, which stores a plurality of relay tables required for the above-mentioned relay processing; a first communication unit, which includes a plurality of communication ports, and respectively sends and receives a first frame that complies with a first communication protocol at the above-mentioned plurality of communication ports; a second communication unit, which sends and receives a second frame that complies with a second communication protocol; and a control unit, which performs the above-mentioned relay processing related to the above-mentioned first frame and the above-mentioned second frame, and the above-mentioned control unit performs the following selection processing: based on the identification information contained in the above-mentioned first frame sent by the extension device connected to one of the above-mentioned plurality of communication ports, one of the above-mentioned relay tables stored in the above-mentioned storage unit is selected.

[0008] A method of a technical solution disclosed herein is a relay method performed by an on-vehicle relay device, wherein the on-vehicle relay device is capable of performing relay processing of communication frames and has a storage unit storing a plurality of relay tables required for the above-mentioned relay processing. The above-mentioned relay method includes the following steps: sending and receiving a first frame that complies with a first communication protocol in at least one communication port among a plurality of communication ports; sending and receiving a second frame that complies with a second communication protocol; performing the above-mentioned relay processing related to the above-mentioned first frame and the above-mentioned second frame; and performing the following selection processing: selecting the above-mentioned relay table from the above-mentioned plurality of relay tables stored in the above-mentioned storage unit based on identification information contained in the above-mentioned first frame sent by an extension device connected to a certain communication port among the above-mentioned plurality of communication ports.

[0009] A computer program of a technical solution disclosed herein is used to enable a computer to function as an in-vehicle relay device capable of performing relay processing of communication frames. The computer program enables the computer to function as a storage unit, a first communication unit, a second communication unit and a control unit. The storage unit stores a plurality of relay tables required for the relay processing. The first communication unit includes a plurality of communication ports, and the first frames complying with the first communication protocol are sent and received at the plurality of communication ports respectively. The second communication unit sends and receives the second frames complying with the second communication protocol. The control unit performs the relay processing related to the first frame and the second frame. The control unit performs the following selection processing: based on the identification information contained in the first frame sent by the extension device connected to one of the plurality of communication ports, one of the relay tables stored in the storage unit is selected. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] Figure 1 This is a network configuration diagram showing an example configuration of an in-vehicle communication system.

[0011] Figure 2 This is a block diagram showing an example of the internal structure of a conventional gateway.

[0012] Figure 3 This is a block diagram showing an example of the internal structure of a gateway on the extension side.

[0013] Figure 4 This is an explanatory diagram showing an example of the conversion process of the communication frame.

[0014] Figure 5 This is an explanatory diagram showing an example of a conventional relay table.

[0015] Figure 6 This is an explanatory diagram showing an example of a relay table on the extension side.

[0016] Figure 7This is an explanatory diagram showing a conventional example of a method for storing and updating a relay table.

[0017] Figure 8 This is an explanatory diagram showing an embodiment of a method for storing and updating a relay table.

[0018] Figure 9 This is a flowchart showing an example of conventional communication frame relay processing.

[0019] Figure 10 This is a flowchart showing an example of a relay process of a communication frame on the extension side. DETAILED DESCRIPTION

[0020] <Problems to be Solved by the Present Disclosure>

[0021] In conventional in-vehicle relay devices, when adding or removing expansion devices or changing the connection location of CAN communication ports, maintenance personnel must manually update the relay table. This poses a problem of time-consuming changes to the network configuration.

[0022] An object of the present disclosure is to provide an in-vehicle relay device or the like that can easily change the network configuration.

[0023] <Effects of the Present Disclosure>

[0024] According to the present disclosure, the network configuration can be easily changed.

[0025] <Overview of Embodiments of the Present Disclosure>

[0026] Hereinafter, embodiments of the present disclosure will be described with reference to their outlines.

[0027] (1) The device of this embodiment is an on-vehicle relay device capable of performing relay processing of communication frames, and the on-vehicle relay device comprises: a storage unit storing a plurality of relay tables required for the relay processing; a first communication unit including a plurality of communication ports, wherein the first frame complying with a first communication protocol is sent and received at the plurality of communication ports respectively; a second communication unit transmitting and receiving a second frame complying with a second communication protocol; and a control unit performing the relay processing related to the first frame and the second frame, wherein the control unit performs the following selection processing: selecting one of the relay tables stored in the storage unit based on identification information included in the first frame sent by an extension device connected to one of the plurality of communication ports.

[0028] In addition, the relay processing related to the first frame and the second frame includes mutual relay between the first frame and the second frame.

[0029] According to the vehicle-mounted relay device of this embodiment, the control unit performs the following selection processing: based on the identification information included in the first frame sent by the expansion device connected to one of the multiple communication ports, a relay table is selected from the multiple relay tables stored in the storage unit.

[0030] Therefore, even without manually updating the relay table, the relay table can be automatically updated to correspond to the addition or removal of expansion devices or changes in connection positions, making it possible to easily change the network configuration.

[0031] (2) In the vehicle-mounted relay device of the present embodiment, the identification information may be identification information of the expansion device, the control unit may be capable of performing authentication processing for the expansion device, and the identification information of the expansion device used in the selection processing may be identification information of the expansion device that has been recognized as legitimate through the authentication processing.

[0032] In this manner, selection processing using identification information of an unauthorized expansion device is not executed, and thus intrusion of an unauthorized expansion device into the in-vehicle communication system can be prevented beforehand.

[0033] (3) In the vehicle-mounted relay device of the present embodiment, the vehicle-mounted relay device may belong to the extended network in a vehicle-mounted communication system including an existing network constructed as a standard in a vehicle and an extended network constructed additionally in the vehicle, and the control unit may notify the identification information of the extended device recognized as legitimate through the authentication process to other vehicle-mounted relay devices belonging to the existing network.

[0034] In this way, other in-vehicle relay devices belonging to the existing network can use the notified identification information of the expansion device to perform relay table selection processing.

[0035] (4) In the vehicle-mounted relay device of this embodiment, the identification information may be included in a predetermined extended target range, and the control unit may exclude the first frame including the identification information not included in the extended target range from the target of the relay process.

[0036] The reason is that the transmission source of the first frame whose identification information is not within the extension target range is not an extension device for which extension is pre-considered, and therefore relay processing cannot be performed using any of the plurality of relay tables stored in the storage unit.

[0037] (5) In the vehicle-mounted relay device of this embodiment, the plurality of relay tables may be defined so as to correspond one-to-one to a plurality of addition modes when one or more expansion devices are connected to the vehicle-mounted relay device in a predetermined topology.

[0038] In this way, the additional connection mode (topology) including one or more expansion devices communicating using the first communication protocol as components can be limited to a mode desired by a vehicle manufacturer or the like.

[0039] (6) In the vehicle-mounted relay device of the present embodiment, when the first communication protocol and the second communication protocol are different, the control unit may execute the relay process with protocol conversion.

[0040] In this case, even when 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.

[0041] (7) In the in-vehicle relay device of this embodiment, the first communication protocol may be CAN or CAN-FD, and the second communication protocol may be Ethernet.

[0042] In this case, a relay process involving protocol conversion can be performed on the first frame of CAN or CAN-FD and the second frame of Ethernet.

[0043] (8) In the vehicle-mounted relay device of this embodiment, the identification information of the expansion device may be a CANID.

[0044] The reason for this is that since CANID is often used as identification information for existing devices, the identification information of expansion devices should also use CANID to match the information.

[0045] (9) The method of this embodiment is a relay method performed by the vehicle-mounted relay device of (1) to (8) above. Therefore, the relay device of this embodiment has the same function and effect as the vehicle-mounted relay device of (1) to (8) above.

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

[0047] <Details of Embodiments of the Invention>

[0048] Hereinafter, the details of the embodiments of the present invention will be described with reference to the accompanying drawings. In addition, at least part of the embodiments described below may be arbitrarily combined.

[0049] [Configuration example of an in-vehicle communication system]

[0050] Figure 1 is a network configuration diagram showing a configuration example of the in-vehicle communication system 100 .

[0051] like Figure 1 As shown, the vehicle communication system 100 of this embodiment is an in-vehicle LAN (Local Area Network) constructed inside the vehicle 1. The 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.

[0052] The ECUs 40 and 50 are vehicle electronic control units that control various in-vehicle devices such as sensors and actuators in the vehicle 1 .

[0053] The ECUs 40 and 50 are communication nodes constituting the in-vehicle communication system 100 , and can be considered as a type of “in-vehicle communication device” from the viewpoint of communication.

[0054] Focusing on the controlled objects, the types of ECUs 40 and 50 include an engine control ECU, a transmission control ECU, a power steering control ECU, an air-conditioning control ECU, and an AV (Audio / Visual) system control ECU.

[0055] The ECUs 40 and 50 take measurement information from sensors connected thereto (such as speed sensors, acceleration sensors, temperature sensors, and pressure sensors) into the system, and control various actuators connected thereto (such as motors) based on the measurement information.

[0056] Focusing on the communication protocol, the in-vehicle communication system 100 is a network in which the ECU 40 that performs communication in accordance with the “first communication protocol” and the ECU 50 that performs communication in accordance with the “second communication protocol” coexist.

[0057] The first communication protocol may be, for example, CAN (Control Area Network: a 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 CAN.

[0058] The second communication protocol is not particularly limited in type as long as it is a communication protocol different from the first communication protocol.

[0059] However, in this embodiment, the second communication protocol is "Ethernet" having a higher transmission speed than the first communication protocol. Hereinafter, Ethernet may be abbreviated as "ETH".

[0060] The ECU 40 is an ECU that performs communication in compliance with CAN (a first communication protocol).

[0061] In the present 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”.

[0062] The ECU 50 is an ECU that performs communication in compliance with the ETH (second communication protocol).

[0063] In the present embodiment, a communication frame conforming to the 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”.

[0064] The C-ECU 40 is connected to the gateways 10 and 20 via a CAN bus 60. The CAN bus 60 is a communication line composed of high-side and low-side wiring. A plurality of C-ECUs 40 can be connected to one CAN bus 60 in a linear manner.

[0065] The E-ECU 50 is connected to the gateways 10 and 20 or the switching hub 30 via a LAN cable 70. The LAN cable 70 is a communication line corresponding to CAT5 or higher that can ensure a communication speed of 100 Mbps or 1 Gbps, for example.

[0066] The gateways 10 and 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 and 50 (C-ECU 40 and E-ECU 50 in this embodiment) using different communication protocols.

[0067] The switching hub 30 is, for example, an in-vehicle relay device capable of relaying Ethernet frames at the L2 or L3 layer, that is, the switching hub 30 is an in-vehicle relay device that complies only with the first communication protocol.

[0068] like Figure 1 As shown, the vehicle communication system 100 includes an existing network 110 and an extension network 120. The existing network 110 is a network built as standard in the vehicle 1, and the extension network 120 is a network built selectively in the vehicle 1. The extension network 120 can be added during maintenance of the vehicle 1, for example.

[0069] As a demand for additional functionality, for example, enhancement of the safety function of the vehicle 1 and addition of a new function desired by the user of the vehicle 1 are assumed.

[0070] exist Figure 1 In the example of FIG. 1 , the existing network 110 includes an existing gateway 10 , two C-ECUs 40 ( 40C), a switching hub 30 , and an E-ECU 50 as communication nodes serving as components.

[0071] However, the types and numbers of the communication nodes described above are merely examples, and the actual existing network 110 may include more gateways 10 , switching hubs 30 , and ECUs 40 and 50 than those shown in the figure.

[0072] exist Figure 1 In the example of FIG. 1 , the extended network 120 includes one extended-side gateway 20 , two switching hubs 30 , two C-ECUs 40 ( 40E) and one E-ECU 50 as communication nodes serving as constituent elements.

[0073] The types and numbers of communication nodes described above are examples. For example, the gateway 20 may be connected to the gateway 10 via a LAN cable 70 instead of the switching hub 30 , or the E-ECU 40 on the extension side may be connected to the gateway 10 via a LAN cable 70 .

[0074] As described above, the C-ECU 40 of the in-vehicle communication system 100 includes the C-ECU 40C already included in the existing network 110 and the C-ECU 40E to be employed as a communication node of the extended network 120 in the future.

[0075] Therefore, in the following description, C-ECU 40C as a component of existing network 110 may be referred to as “existing device 40C”, and C-ECU 40E that can become a component of expansion network 120 may be referred to as “expansion device 40E”.

[0076] [Example of the existing gateway configuration]

[0077] Figure 2 This is a block diagram showing an example of the internal structure of the conventional gateway 10 .

[0078] like Figure 2 As shown, the conventional gateway 10 includes a frame processing unit 11 for ETH communication, a microcomputer 12, and a transceiver 13 for CAN communication. Furthermore, the conventional gateway 10 has multiple communication ports PXi (i=1, 2, ..., I) for CAN and one communication port PE for ETH.

[0079] The frame processing unit 11 corresponds to a “second communication unit” that transmits and receives an ETH frame (second frame) conforming to the second communication protocol.

[0080] The frame processing unit 11 is composed of one or more integrated circuits that perform signal processing according to Ethernet, and includes a PHY unit 11A and a MAC unit 11B. The PHY unit 11A is an integrated circuit that performs modulation and demodulation of signals according to Ethernet and is provided corresponding to the Ethernet communication port PE.

[0081] The MAC unit 11B is an integrated circuit that performs signal processing related to the MAC (Media Access Control) layer of Ethernet.

[0082] The MAC unit 11B is formed of, for example, a Field Programmable Gate Array (FPGA) and is electrically connected to the microcomputer 12 and the PHY unit 11A.

[0083] The microcomputer 12 is a microcomputer including a control unit 14 and a storage unit 15 .

[0084] The control unit 14 is a processing device including one or more CPUs (Central Processing Units) and RAMs (Random Access Memory). The control unit 14 may also include other integrated circuits such as FPGAs.

[0085] The control unit 14 reads the computer program 16 stored in the storage unit 15 into the main memory (RAM), and executes information processing required for relaying communication according to the read program 16. Details of this information processing will be described later.

[0086] The storage unit 15 is an auxiliary storage device including a nonvolatile memory such as an EEPROM (Electrically Erasable Programmable ROM) and a flash ROM (Read Only Memory).

[0087] The storage unit 15 stores, in addition to the computer program 16 , a relay table group TG1 including a plurality of relay tables Tm (m=1, 2, ..., M) required for relaying communication frames with protocol conversion. The relay table group TG1 will be described in detail later.

[0088] The transceiver 13 corresponds to a “first communication unit” that transmits and receives a CAN frame (first frame) conforming to the first communication protocol.

[0089] The transceiver 13 is a transceiver that performs signal processing in accordance with the CAN physical layer and includes a plurality of PHY units 13A. The PHY unit 13A is an integrated circuit provided for each CAN communication port PXi (j=1, 2, ..., N) and performs signal conversion at the CAN L1 level.

[0090] Specifically, the PHY unit 13A decodes the differential signal of the CAN bus 60 into a digital signal and outputs it to the control unit 14. Conversely, the PHY unit 13A generates a CAN differential signal based on the digital signal input from the control unit 14 and sends it to the communication port PXi (CAN bus 60).

[0091] The information processing executed by the controller 14 of the microcomputer 12 includes at least the following three processes.

[0092] S11: Acquisition process of identification information of extension device 40E

[0093] S12: Relay table selection process

[0094] S13: Protocol conversion processing

[0095] The acquisition process S11 is a process of acquiring identification information (for example, CANID) of the expansion device (C-ECU) 40E newly added to the gateway 20 on the expansion side.

[0096] Acquisition processing S11 involves receiving a control frame containing identification information of an authenticated expansion device 40E from the gateway 20 on the expansion side, which is an external device. In this case, the identification information of the expansion device 40E can be acquired by extracting the identification information from the received control frame. For example, Ethernet OAM (Operations, Administration, and Maintenance) frames can be used as these control frames.

[0097] The selection process S12 is a process of selecting one relay table Tm used for relaying a communication frame accompanied by protocol conversion from among a plurality of relay tables Tm (m=1, 2, . . . M) constituting the relay table group TG1 stored in the storage unit 15 .

[0098] The selection process S12 is executed based on, for example, the identification information (eg, CANID) of all the expansion devices 40E notified from the gateway 20 up to the present time.

[0099] The conversion process S13 refers to the one relay table Tm selected in the selection process S12 and performs protocol conversion between CAN and ETH in a bidirectional manner.

[0100] Specifically, the control unit 21 performs “first conversion” of converting the ETH frame input from the frame processing unit 21 into a CAN frame, and outputs the converted CAN frame to the transceiver 13 .

[0101] In this case, the control unit 14 determines to which PHY unit 13A included in the transceiver 13 the converted CAN frame is to be output (to which communication port Pxi) based on the selected relay table Tm.

[0102] On the contrary, the control unit 14 performs “second conversion” of converting a CAN frame input from a certain PHY unit 23A into an ETH frame, and outputs the converted ETH frame to the frame processing unit 11 .

[0103] Figure 4 This is an explanatory diagram showing an example of the communication frame conversion process S13 performed by the control unit 14 of the microcomputer 12.

[0104] like Figure 4 As shown, here, a method of storing all data of the CAN frame in the payload of the ETH frame is adopted.

[0105] In this case, the control unit 14 extracts the CAN frame from the payload of the ETH frame input from the frame processing unit 11 , thereby performing the “first conversion” from the ETH frame to the CAN frame.

[0106] Furthermore, the control unit 14 generates an ETH frame in which the CAN frame input from the transceiver 13 is stored in the payload, thereby performing the “second conversion” from the CAN frame to the ETH frame.

[0107] The control unit 14 of the microcomputer 12 executes a transmission process of the converted communication frame. The transmission process of the control unit 14 includes the following processes.

[0108] ETH transmission: A process of outputting the converted ETH frame to the frame processing unit 11 .

[0109] CAN transmission: A process of outputting the converted CAN frame to the transceiver 13. In this case, the output destination (transmission port PXi) of the CAN frame complies with the regulations of the relay table Tm.

[0110] [Example of the configuration of the gateway on the extension side]

[0111] Figure 3 This is a block diagram showing an example of the internal structure of the gateway 20 on the extension side.

[0112] like Figure 3 As shown, the gateway 20 on the expansion side includes a frame processing unit 21 for ETH communication, a microcomputer 22, and a transceiver 23 for CAN communication. Furthermore, the gateway 20 on the expansion side has multiple communication ports PYj (j=1, 2, ... J) for CAN and one communication port PE for ETH.

[0113] The frame processing unit 21 corresponds to a “second communication unit” that transmits and receives an ETH frame (second frame) conforming to the second communication protocol.

[0114] The frame processing unit 21 is composed of one or more integrated circuits that perform signal processing according to 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 according to Ethernet and is provided corresponding to the Ethernet communication port PE.

[0115] The MAC unit 21B is an integrated circuit that performs signal processing related to the MAC (Media Access Control) layer of Ethernet.

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

[0117] The microcomputer 22 is a microcomputer including a control unit 24 and a storage unit 25 .

[0118] The control unit 24 is a processing device including one or more CPUs (Central Processing Units) and RAMs (Random Access Memory). The control unit 24 may also include other integrated circuits such as FPGAs.

[0119] The control unit 24 reads the computer program 26 stored in the storage unit 25 into the main memory (RAM), and executes information processing required for relaying communication according to the read program 26. Details of this information processing will be described later.

[0120] The storage unit 25 is an auxiliary storage device including a nonvolatile memory such as an EEPROM (Electrically Erasable Programmable ROM) and a flash ROM (Read Only Memory).

[0121] The storage unit 25 stores, in addition to the computer program 26 , a relay table group TG2 including a plurality of relay tables Tn (n=1, 2, ..., N) required for relaying communication frames with protocol conversion. The relay table group TG2 will be described in detail later.

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

[0123] The transceiver 23 is a transceiver that performs signal processing in accordance with the CAN physical layer and includes a plurality of PHY units 23A. The PHY unit 23A is an integrated circuit provided for each CAN communication port PYj (j=1, 2, ..., N) and performs signal conversion at the CAN L1 level.

[0124] 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 based on the digital signal input from the control unit 24 and sends it to the communication port PYj (CAN bus 60).

[0125] The information processing performed by the controller 24 of the microcomputer 22 includes at least the following three processes.

[0126] S21: Authentication process of the extension device 40E

[0127] S22: Relay table selection process

[0128] S23: Protocol conversion processing

[0129] The authentication process S21 is a process for determining whether the expansion device (C-ECU) 40E newly connected to the own device is a legitimate communication node.

[0130] As the authentication process S21 , for example, key exchange using a message authentication code or a digital signature performed with the expansion device 40E newly added to the CAN bus 60 connected to the communication port PYj can be employed.

[0131] The selection process S22 is a process of selecting one relay table Tn used for relaying a communication frame accompanied by protocol conversion from among a plurality of relay tables Tn (m=1, 2 . . . N) constituting the relay table group TG2 stored in the storage unit 25 .

[0132] The selection process S22 is executed based on, for example, the identification information (eg, CANID) of all the expansion devices 40E that have been recognized as legitimate by the authentication process S1 .

[0133] The conversion process S23 refers to the one relay table Tn selected in the selection process S22 and performs protocol conversion between CAN and ETH in a bidirectional manner.

[0134] Specifically, the control unit 21 performs “first conversion” of converting the ETH frame input from the frame processing unit 21 into a CAN frame, and outputs the converted CAN frame to the transceiver 23 .

[0135] 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 ) based on the selected relay table Tn.

[0136] In contrast, the control unit 21 performs “second conversion” of converting a CAN frame input from a PHY unit 23A included in the transceiver 23 into an ETH frame, and outputs the converted ETH frame to the frame processing unit 21 .

[0137] Figure 4 The conversion processing can also be used as the conversion processing S23 of the control unit 24.

[0138] 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 performing the “first conversion” from the ETH frame to the CAN frame.

[0139] Furthermore, the control unit 24 generates an ETH frame in which the CAN frame input from the transceiver 23 is stored in the payload, thereby performing the “second conversion” from the CAN frame to the ETH frame.

[0140] The control unit 24 of the microcomputer 22 executes a transmission process of the converted communication frame. The transmission process of the control unit 24 includes the following processes.

[0141] ETH transmission: A process of outputting the converted ETH frame to the frame processing unit 21 .

[0142] CAN transmission: This is a process of outputting the converted CAN frame to the transceiver 23. In this case, the output destination (transmission port PYj) of the CAN frame complies with the regulations of the relay table Tn.

[0143] [Specific example of conventional relay table group]

[0144] Figure 5 It is an explanatory diagram showing an example of the conventional relay table group TG1.

[0145] like Figure 5 As shown, the conventional relay table Tm (m = 1, 2, ..., M) is a matrix-formatted data structure that defines a "relay source," a "relay destination," and a "sending node" for each entry. A relay source refers to the type of port that receives a communication frame, while a relay destination refers to the type of port that sends a communication frame. A sending node is identification information for the sending source.

[0146] In this embodiment, the addition or reduction of the expansion device 40E on the expansion side is assumed, and, for example, an “information transmission rule” including the following multiple rules is adopted.

[0147] Rule 1: The identification information (CANID) of an existing device has the value of the third digit from the bottom set to "1".

[0148] Rule 2: The third digit from the bottom of the identification information (CANID) of the extended device is set to "2".

[0149] Rule 3: Communication nodes whose identification information (CANID) has the same second digit from the bottom exchange information with each other.

[0150] In this embodiment, it is assumed that an existing device (ID = 0x110) is connected to PX1 and an existing device (ID = 0x120) is connected to PX2 on the existing gateway 10. Furthermore, based on this existing state, the following three topologies are envisioned as additional modes for adding expansion devices to the expansion-side gateway 20.

[0151] Mode 1: Connect an expansion device (ID = 0x210) to PY1.

[0152] Mode 2: Connect an expansion device (ID = 0x220) to PY2.

[0153] Mode 3: Connect an expansion device (ID = 0x210) to PY1, and connect an expansion device (ID = 0x220) to PY2.

[0154] Figure 5 The relay table T1 in the relay table group TG1 is a table used in mode 1. In the case of mode 1, as long as the relay path between the existing device with ID = 0x110 and the extension device with ID = 0x210 can be specified by rule 3 ( Figure 5 ) in the figure.

[0155] Therefore, the relay table T1 includes entry 1 defining the transmission and reception ports when relaying a communication frame from the existing device with ID=0x110 to the extension device with ID=0x210, and entry 2 defining the transmission and reception ports in the opposite case.

[0156] Figure 5 The relay table T2 in the relay table group TG1 is a table used in mode 2. In the case of mode 2, as long as the relay path between the existing device with ID = 0x120 and the extension device with ID = 0x220 can be specified by rule 3 ( Figure 5 ) in the figure.

[0157] Therefore, the relay table T2 includes entry 1 defining the transmission and reception ports when relaying a communication frame from the existing device with ID=0x120 to the extension device with ID=0x220, and entry 2 defining the transmission and reception ports in the opposite case.

[0158] Figure 5 The relay table T3 in the relay table group TG1 is a table used in mode 3. In the case of mode 3, as long as the relay path between the existing device with ID = 0x110 and the extension device with ID = 0x210 can be specified by rule 3 ( Figure 5 The dotted arrow in the figure) and the relay path between the existing device with ID = 0x120 and the extended device with ID = 0x220 ( Figure 5 ) in the figure.

[0159] Therefore, the relay table T3 includes entry 1 that specifies the transmission / reception port when relaying a communication frame from the existing device with ID=0x110 to the extension device with ID=0x210, and entry 3 that specifies the transmission / reception port when relaying the communication frame from the existing device with ID=0x110 to the extension device with ID=0x210.

[0160] The relay table T3 includes entry 2 that specifies the transmission / reception port when relaying a communication frame from the existing device with ID=0x120 to the extension device with ID=0x220, and entry 4 that specifies the transmission / reception port when relaying the communication frame from the existing device with ID=0x120 to the extension device with ID=0x220.

[0161] The relay table Tm included in the relay table group TG1 is defined individually for each pre-conceivable addition pattern and is not limited to Figure 5 The three examples shown.

[0162] For example, on the extension side, assuming pattern 4 in which an extension device with ID=0x210 is connected to PY2 instead of PY1, the relay table T4 corresponding to pattern 4 is also included in the relay table group TG1.

[0163] When there are K (K is a natural number greater than or equal to 3) expansion devices to be added, determine the topology of multiple additional modes in which k (k=3, 4...K) expansion devices are connected to PYj (j=1, 2...J), and define the relay table Tm according to each determined additional mode.

[0164] In this manner, the plurality of relay tables Tm are defined to correspond one-to-one to a plurality of addition patterns when a user such as a vehicle manufacturer adds one or more expansion devices to the communication port PYj of the gateway 20 in a predetermined topology, for example.

[0165] [Specific example of the relay table group on the extension side]

[0166] Figure 6 It is an explanatory diagram showing an example of the relay table group TG2 on the extension side.

[0167] Figure 6 The relay table Tn (n = 1, 2, ..., N) on the extended side also defines a matrix of data: a "relay source," a "relay destination," and a "sending node" for each entry. A "relay source" refers to the type of port that receives a communication frame, while a "relay destination" refers to the type of port that sends a communication frame. A "sending node" is the identification information for the sending source.

[0168] about Figure 6 The relay table Tn also follows the above-mentioned "information transmission rules". As additional modes on the expansion side, the following three modes of topology are envisioned.

[0169] Mode 1: Connect an expansion device (ID = 0x210) to PY1.

[0170] Mode 2: Connect an expansion device (ID = 0x220) to PY2.

[0171] Mode 3: Connect an expansion device (ID = 0x210) to PY1, and connect an expansion device (ID = 0x220) to PY2.

[0172] Figure 6 The relay table T1 in the relay table group TG2 is a table used in mode 1. In the case of mode 1, as long as the relay path between the extension device with ID = 0x210 and the existing device with ID = 0x110 can be specified by rule 3 ( Figure 6 ) in the figure.

[0173] Therefore, the relay table T1 includes entry 1 defining the transmission and reception ports when relaying a communication frame from the extension device with ID=0x210 to the existing device with ID=0x110, and entry 2 defining the transmission and reception ports in the opposite case.

[0174] Figure 6 The relay table T2 in the relay table group TG2 is a table used in mode 2. In the case of mode 2, as long as the relay path between the extension device with ID = 0x220 and the existing device with ID = 0x120 can be specified by rule 3 ( Figure 6 ) in the figure.

[0175] Therefore, the relay table T2 includes entry 1 defining the transmission and reception ports when relaying a communication frame from the extension device with ID=0x220 to the existing device with ID=0x120, and entry 2 defining the transmission and reception ports in the opposite case.

[0176] Figure 6 The relay table T3 in the relay table group TG2 is a table used in mode 3. In the case of mode 3, as long as the relay path between the extension device with ID = 0x210 and the existing device with ID = 0x110 can be specified by rule 3 ( Figure 6 The dotted arrow in the figure) and the relay path between the expansion device with ID = 0x220 and the existing device with ID = 0x120 ( Figure 6 ) in the figure.

[0177] Therefore, the relay table T3 includes entry 1 defining the transmission and reception ports when relaying a communication frame from the extension device with ID=0x210 to the existing device with ID=0x110, and entry 3 defining the transmission and reception ports in the opposite case.

[0178] Furthermore, the relay table T3 includes entry 2 defining the transmission and reception ports when relaying a communication frame from the expansion device with ID=0x220 to the existing device with ID=0x120, and entry 4 defining the transmission and reception ports in the reverse case.

[0179] The relay table Tn included in the relay table group TG2 is also defined individually for each pre-conceivable addition pattern and is not limited to Figure 6 The three illustrated types.

[0180] For example, on the extension side, assuming mode 4 in which an extension device with ID=0x210 is connected to PY2 instead of PY1, the relay table T4 corresponding to this mode 4 is also included in the relay table group TG2.

[0181] When there are K (K is a natural number greater than or equal to 3) expansion devices to be added, determine the topology of multiple additional modes in which k (k=3, 4...K) expansion devices are connected to PYj (j=1, 2...J), and define the relay table Tn according to each determined additional mode.

[0182] In this manner, the plurality of relay tables Tn are also defined to correspond one-to-one to a plurality of addition patterns when a user such as a vehicle manufacturer adds one or more expansion devices to the communication port PYj of the gateway 20 in a predetermined topology.

[0183] [Problems with existing gateways and their solutions]

[0184] Figure 7 This is an explanatory diagram showing a conventional example of a method for storing and updating relay tables X and Y.

[0185] like Figure 7As shown, the relay table X is a table defined to use only the extension device A as a relay target, and the relay table Y is a table defined to use the extension device A and the extension device B as relay targets.

[0186] Unlike in-building LANs such as company LANs and home LANs, the frequency of adding or removing communication nodes such as C-ECUs or changing their connection locations is relatively low in in-vehicle LANs.

[0187] Therefore, in conventional gateways that perform relay processing accompanied by protocol conversion, only one relay table X, Y is stored in the memory of the microcomputer.

[0188] Therefore, if Figure 7 As shown, when switching from the "first mode" where expansion device A is connected to CAN bus 1 to the "second mode" where expansion device B is additionally connected to CAN bus 2, the relay table A needs to be rewritten to the relay table B.

[0189] Rewriting the relay tables A and B requires, for example, a person in charge of maintenance of the vehicle 1 to connect a management terminal (eg, a laptop PC) to the gateway and manually perform the rewriting via a monitoring tool such as a command line, which is labor-intensive.

[0190] Figure 8 This is an explanatory diagram showing an embodiment of a method for storing and updating relay tables X, Y, and Z.

[0191] like Figure 8 As shown, the relay table X is a table defined to use only the extension device A as a relay target, and the relay table Y is a table defined to use the extension device A and the extension device B as relay targets.

[0192] As described above, in this embodiment, the relay tables X and Y are stored together with the other relay table Z as relay table groups TG1 and TG2 in the memory of the microcomputer.

[0193] Therefore, if Figure 8 As shown, when changing from the "first mode" where the expansion device A is connected to the CAN bus 1 to the "second mode" where the expansion device B is additionally connected to the CAN bus 2, the desired relay table Y can be selected from the relay table groups TG1 and TG2.

[0194] The selection process of the relay tables X and Y can be automatically executed by the microcomputer based on the identification information of the newly connected expansion device B, for example.

[0195] Thus, according to this embodiment, relay table groups TG1 and TG2, which are a collection of relay tables X, Y, and Z for each conceivable additional mode, are stored in the memory of the microcomputer. The microcomputer selects the required relay table Y based on the identification information of the expansion devices A and B, etc., so that the relay tables X, Y, and Z can be automatically updated in a plug-and-play manner.

[0196] Therefore, without manually rewriting the relay tables X, Y, and Z, it is possible to add or remove extension devices A and B or change their connection positions, which has the advantage of facilitating changes in the network configuration.

[0197] In addition, by performing CAN transmission according to the relay tables X, Y, and Z, CAN frames are relayed only to the CAN buses connected to the expansion devices A and B, rather than broadcasting them. This also has the advantages of reducing bus load and improving safety.

[0198] [Relay processing of communication frames on the existing side]

[0199] Figure 9 This is a flowchart showing an example of relay processing of existing communication frames executed by the control unit 14 of the existing gateway 10 .

[0200] Figure 9 The relay processing is done using relay table group TG1 ( Figure 5 ) is performed for relay processing of communication frames used for information exchange between the existing device (C-ECU) 40C and the expansion device (C-ECU) 40E, and relay between CAN buses 60 that does not require protocol conversion is not an object.

[0201] like Figure 9 As shown, the control unit 14 of the gateway 10 monitors whether a frame is received (step ST11 ), and when a received frame is detected, determines whether the received frame is a CAN frame or an ETH frame (step ST12 ).

[0202] If the result of determination in step ST12 is “CAN”, the control unit 24 determines whether the value of the CANID included in the CAN frame is within the extension target range (step ST13 ).

[0203] The extension target range refers to a numerical range of CANIDs that is pre-allocated for the extension device 40E (for example, 0x100 to 0x400, etc.).

[0204] If the determination result of step ST13 is negative, the control unit 14 skips steps ST14 to ST18 and returns the process to before step ST11 .

[0205] The reason is that the transmission source of the CAN frame having a CANID value outside the extension target range is not the extension device 40E for which extension is preliminarily assumed, and therefore relay processing cannot be performed using any relay table Tm included in the relay table group TG1.

[0206] If the result of the determination in step ST13 is affirmative, the control unit 24 determines whether the CAN ID included in the CAN frame is the ID notified from the gateway 20 on the extension side (step ST14 ).

[0207] If the result of step ST14 is positive, the control unit 24 determines whether the CAN frame is a frame to be relayed from CAN to ETH (step ST15 ). The frame to be relayed is a CAN frame including the CAN ID included in the currently selected relay table Tm.

[0208] If the determination result of step ST15 is negative, the control unit 14 skips steps ST16 and ST17 and returns the process to before step ST11 .

[0209] The reason for this is that the transmission source of the CANID that does not exist in the relay table Tm at the current time point may be a communication frame from an unauthorized transmission source, and therefore relay processing based on the relay table Tm should not be performed.

[0210] If the result of the determination in step ST15 is affirmative, the control unit 24 performs a conversion process from CAN to ETH on the received CAN frame (step ST16 ).

[0211] The above conversion process is equivalent to the second conversion of storing the received CAN frame in the payload of the ETH frame (refer to Figure 4 ).

[0212] Next, the control unit 14 executes the transmission process of the converted ETH frame (step ST17 ), and then returns the process to the process before step ST11 . The transmission process described above is a process of outputting the converted ETH frame to the frame processing unit 21 .

[0213] If the result of determination in step ST14 is negative, the CANID of the authenticated new expansion device 40E has been notified, and therefore the control unit 14 performs a process of selecting the relay table Tn based on the notified CANID (step ST18 ).

[0214] The above-mentioned selection process is performed based on all the CANIDs notified so far. Specifically, the selection process of step ST18 includes the following steps, for example.

[0215] Step 1: Read out from the memory the existing CANID whose second digit value from the bottom is identical to the CANIDs of all the extension sides notified from the gateway 20 including the currently notified portion.

[0216] Step 2: Extract at least one relay table Tm whose CAN ID read in step 1 is included in the transmission node column from the relay table group TG1.

[0217] Step 3: When there is only one relay table Tm extracted in step 2, the extracted relay table Tm is determined as the relay table Tm to be selected.

[0218] Step 4: When there are multiple relay tables Tn extracted in step 2, the relay table Tm whose port numbers of the currently operating PXi match the multiple port numbers included in the transmission node column is determined as the relay table Tm to be selected.

[0219] If the result of determination in step ST12 is “ETH”, the control unit 24 refers to the current relay table Tm (step ST19 ) and converts the received ETH frame from ETH to CAN (step ST20 ).

[0220] The above conversion process is equivalent to the first conversion of extracting the CAN frame from the payload of the received ETH frame (refer to Figure 4 ).

[0221] Next, the control unit 24 executes a transmission process of the converted CAN frame (step ST21 ), and then returns the process to before step ST11 . The above-mentioned transmission process includes, for example, the following steps.

[0222] Step 1: Extract from the relay table Tm an entry in which the value of the CANID read from the converted CAN frame is written in the transmission node column.

[0223] Step 2: The port number of PXi is read from the relay destination column of the extracted entry, and the converted CAN frame is output to the CAN-PHY unit 13A corresponding to the port number.

[0224] [Relay processing of communication frames on the extension side]

[0225] Figure 10 This 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.

[0226] Figure 10 The relay processing is done using relay table group TG2 ( Figure 6) is performed for relay processing of communication frames used for information exchange between the existing device (C-ECU) 40C and the expansion device (C-ECU) 40E, and relay between CAN buses 60 that does not require protocol conversion is not an object.

[0227] like Figure 10 As shown, the control unit 24 of the gateway 20 monitors whether a frame is received (step ST31 ), and when a frame is detected, determines whether the frame is a CAN frame or an ETH frame (step ST32 ).

[0228] If the result of determination in step ST32 is “CAN”, the control unit 24 determines whether the value of the CANID included in the CAN frame is within the extension target range (step ST33 ).

[0229] The extension target range refers to a numerical range of CANIDs that is pre-allocated for the extension device 40E (for example, 0x100 to 0x400, etc.).

[0230] If the determination result of step ST33 is negative, the control unit 24 skips steps ST34 to ST40 and returns the process to before step ST31 .

[0231] The reason is that the transmission source of the CAN frame having a CANID value outside the extension target range is not the extension device 40E for which extension is preliminarily assumed, and therefore relay processing cannot be performed using any relay table Tn included in the relay table group TG2.

[0232] If the result of the determination in step ST33 is affirmative, the control unit 24 determines whether the CANID included in the CAN frame is authenticated (step ST34 ).

[0233] If the result of step ST34 is positive, the control unit 24 determines whether the CAN frame is a frame to be relayed from CAN to ETH (step ST35). The frame to be relayed is a CAN frame containing the CANID included in the currently selected relay table Tn.

[0234] If the determination result of step ST35 is negative, the control unit 24 skips steps ST36 and ST37 and returns the process to before step ST31.

[0235] The reason for this is that the transmission source of the CANID that does not exist in the relay table Tn at the current time point may be a communication frame from an unauthorized transmission source, and therefore relay processing based on the relay table Tn should not be performed.

[0236] If the result of the determination in step ST35 is affirmative, the control unit 24 performs a conversion process from CAN to ETH on the received CAN frame (step ST36 ).

[0237] The above conversion process is equivalent to the second conversion of storing the received CAN frame in the payload of the ETH frame (refer to Figure 4 ).

[0238] Next, the control unit 24 executes the transmission process of the converted ETH frame (step ST37 ), and then returns the process to the process before step ST31 . The transmission process described above is a process of outputting the converted ETH frame to the frame processing unit 21 .

[0239] If the result of the determination in step ST34 is negative, the control unit 24 performs authentication processing with the unauthenticated expansion device 40E (step ST38 ). Through the information exchange during the authentication processing, the control unit 24 obtains the CANID of the new expansion device 40E.

[0240] Next, the control unit 24 performs a process of selecting the relay table Tn using the CANID of the authenticated extension device 40E (step ST39 ).

[0241] The above selection process is performed based on the values ​​of all CANIDs that have been authenticated so far. Specifically, the selection process in step ST39 includes the following steps, for example.

[0242] Step 1: Read all authenticated CAN IDs including the currently authenticated ones from the memory.

[0243] Step 2: Extract at least one relay table Tn whose CAN ID read in step 1 is included in the transmission node column from the relay table group TG2.

[0244] Step 3: When there is only one relay table Tn extracted in step 2, the extracted relay table Tn is determined as the relay table Tn to be selected.

[0245] Step 4: When there are multiple relay tables Tn extracted in step 2, the relay table Tn whose port numbers of the currently operating PYj match the multiple port numbers included in the transmission node column is determined as the relay table Tn to be selected.

[0246] Next, the control unit 24 notifies the existing gateway 10 of the CANID of this authentication (step ST40 ), and then returns the process to before step ST31 .

[0247] Specifically, the control unit 24 generates an Ethernet control frame (for example, an Ethernet OAM frame) including the authenticated CAN ID and addressed to the gateway 10 , and outputs the generated control frame to the frame processing unit 21 .

[0248] If the result of determination in step ST32 is “ETH”, the control unit 24 refers to the current relay table Tn (step ST41 ) and converts the received ETH frame from ETH to CAN (step ST42 ).

[0249] The above conversion process is equivalent to the first conversion of extracting the CAN frame from the payload of the received ETH frame (refer to Figure 4 ).

[0250] 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-mentioned transmission process includes, for example, the following steps.

[0251] Step 1: Extract from the relay table Tn an entry in which the value of the CANID read from the converted CAN frame is written in the transmission node column.

[0252] 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 corresponding to the port number.

[0253] [First Modification]

[0254] In the above-described embodiment, CANID (ie, basic ID of CAN) is used as identification information of the “transmitting node” used in the relay tables Tm and Tn. However, the identification information of the transmitting node may be another identifier.

[0255] For example, the identification information of the transmitting node may be information that can uniquely identify the device, such as a product ID assigned to the ECU by the manufacturer or a serial number that is a sequential number assigned to the product by the manufacturer.

[0256] In addition, when a product ID or a serial number is used as identification information of a transmitting node, for example, a control area or an extended ID of a CAN can be used as a definition area.

[0257] However, CANID is often used as identification information for the existing device 40C in the existing network 110. Therefore, from the perspective of achieving compatibility between the existing side and the expansion side, it is preferable that the identification information of both the existing device 40C and the expansion device 40E be consistent with CANID.

[0258] [Second Modification]

[0259] In the above-mentioned embodiment, the CANID may be defined not as identification information of the transmission node (transmission source) but as identification information of the data type of the transmission target.

[0260] In this case, the relay tables Tm and Tn may be configured to include columns for "Relay Source," "Relay Destination," and "Data Type." Thus, the relay tables Tm and Tn define to which CAN bus 60 the data to be transmitted is to be relayed.

[0261] [Third Modification]

[0262] In the above-mentioned embodiment, the types of the first communication protocol and the second communication protocol are not limited to the combination of CAN and ETH, but may be the following combination examples.

[0263] Combination Example 1: Combination of CAN and USB (Universal Serial Bus: USB is a registered trademark). In this case, the first communication protocol can be CAN and the second communication protocol can be USB, or vice versa.

[0264] Combination Example 2: Combination of USB and ETH In this case, the first communication protocol can be USB and the second communication protocol can be ETH, or vice versa.

[0265] [Fourth Modification]

[0266] In the above embodiment, the first communication protocol and the second communication protocol do not necessarily have to be different types such as CAN and ETH. For example, they may be the same type of protocol such as both are CAN, both are USB, and both are ETH.

[0267] In this case, the control units 14 and 24 of the gateways 10 and 20 do not need to perform protocol conversion processing of the communication frames when relaying the communication frames (for example, Figure 4 ).

[0268] [Other Modifications]

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

[0270] In the above-mentioned embodiment, the vehicle-mounted relay device may be a relay device having multiple Ethernet ports, which is configured by housing the gateways 10 and 20 and one or more switching hubs 30 in one housing.

[0271] In the above-mentioned embodiment, the microcomputer 22 of the gateway 10, 20 performs both relay processing between the CAN buses 60 without protocol conversion and relay processing with protocol conversion between CAN and ETH, but it can also be configured so that different microcomputers (integrated circuits) share the execution of these relay processes.

[0272] In the above embodiment, the existing device 40C and the expansion device 40E are not necessarily ECUs, and may be in-vehicle devices other than ECUs that can independently perform CAN communication, such as sensors or actuators having CAN communication functions.

[0273] Description of Reference Numerals

[0274] 1 vehicle

[0275] 10 Existing gateway (vehicle-mounted relay device)

[0276] 11 Frame processing unit (second communication unit)

[0277] 12 Microcomputer

[0278] 13. Transceiver (first communication unit)

[0279] 13 APHY components

[0280] 14 Control Unit

[0281] 15 Storage

[0282] 16 Computer Program

[0283] 20 Gateway on the expansion side (vehicle-mounted relay device)

[0284] 21 Frame processing unit (second communication unit)

[0285] 21 APHY components

[0286] 21 BMAC components

[0287] 22 Microcomputer

[0288] 23 Transceiver (First Communication Unit)

[0289] 24 Control Department

[0290] 25 Storage

[0291] 26 Computer Programs

[0292] 30 switching hubs

[0293] 40 C-ECU (on-board communication unit)

[0294] 40C C-ECU on the existing side (existing equipment)

[0295] 40E C-ECU (expansion device) on the expansion side

[0296] 50 E-ECU (on-board communication unit)

[0297] 60 CAN bus

[0298] 70 Ethernet cable

[0299] 100 Vehicle Communication System

[0300] 110 Existing Network

[0301] 120 Extended Network

[0302] TG1 relay table set (existing side)

[0303] Tm relay table (existing side)

[0304] TG2 relay table set (extension side)

[0305] Tn relay table (extension side)

[0306] PXi CAN communication port (existing side)

[0307] PYj CAN communication port (expansion side)

[0308] PE ETH communication port.

Claims

1. An on-vehicle relay device capable of performing relay processing of communication frames, the on-vehicle relay device comprising: a storage unit storing a plurality of relay tables required for the relay processing; A first communication unit includes a plurality of communication ports, and the plurality of communication ports are configured to respectively send and receive a first frame that complies with a first communication protocol; a second communication unit for sending and receiving a second frame conforming to a second communication protocol; and a control unit that performs the relay processing related to the first frame and the second frame, The control unit performs selection processing for selecting one relay table from among the plurality of relay tables stored in the storage unit based on identification information included in the first frame transmitted by an expansion device connected to one of the plurality of communication ports.

2. The vehicle-mounted relay device according to claim 1, wherein: The identification information is the identification information of the expansion device, The control unit is capable of executing authentication processing for the expansion device, The identification information of the expansion device used in the selection process is the identification information of the expansion device that has been recognized as legitimate through the authentication process.

3. The vehicle-mounted relay device according to claim 2, wherein: The vehicle-mounted relay device belongs to the extended network in the vehicle-mounted communication system including an existing network constructed as a standard in the vehicle and an extended network constructed additionally in the vehicle. The control unit notifies the other in-vehicle relay devices belonging to the existing network of the identification information of the expansion device recognized as legitimate through the authentication process.

4. The vehicle-mounted relay device according to any one of claims 1 to 3, wherein: The identification information is information included in a predetermined extended target range, The control unit excludes the first frame including the identification information that is not within the extended target range from targets of the relay process.

5. The vehicle-mounted relay device according to any one of claims 1 to 4, wherein: The plurality of relay tables are defined so as to correspond one-to-one to a plurality of addition modes when one or more of the expansion devices are connected to the in-vehicle relay apparatus in a predetermined topology.

6. The vehicle-mounted relay device according to any one of claims 1 to 5, wherein: In the case where the first communication protocol is different from the second communication protocol, The control unit executes the relay processing accompanied by protocol conversion.

7. The vehicle-mounted relay device according to any one of claims 1 to 6, wherein: The first communication protocol is CAN or CAN-FD, The second communication protocol is Ethernet.

8. The vehicle-mounted relay device according to any one of claims 1 to 7, wherein: The identification information of the expansion device is CANID.

9. A relay method, performed by an on-vehicle relay device, the on-vehicle relay device being capable of performing relay processing of communication frames and having a storage unit storing a plurality of relay tables required for the relay processing, the relay method comprising the following steps: Sending or receiving a first frame in accordance with a first communication protocol in at least one communication port among the plurality of communication ports; Sending and receiving a second frame that complies with a second communication protocol; performing the relay processing associated with the first frame and the second frame; and A selection process is performed to select one of the relay tables stored in the storage unit based on identification information included in the first frame transmitted by an expansion device connected to one of the plurality of communication ports.

10. A computer program for causing a computer to function as an in-vehicle relay device capable of executing a relay process of a communication frame. The computer program causes the computer to function as a storage unit, a first communication unit, a second communication unit, and a control unit. The storage unit stores a plurality of relay tables required for the relay processing. The first communication unit includes a plurality of communication ports, and the plurality of communication ports respectively send and receive first frames that comply with a first communication protocol. The second communication unit sends and receives a second frame that complies with a second communication protocol. The control unit performs the relay processing related to the first frame and the second frame, and the control unit performs selection processing: based on identification information included in the first frame sent by an expansion device connected to one of the multiple communication ports, selects the relay table from the multiple relay tables stored in the storage unit.

Images