On-vehicle device, program, and information processing method

Abstract

This on-vehicle device is mounted on a vehicle and is connected to an on-vehicle network in which communication is performed by using Ethernet and CAN. The on-vehicle device comprises a control unit that performs processing related to relay of data flowing in the on-vehicle network. The data includes an Ethernet packet using the Ethernet and a CAN message using the CAN. The control unit acquires one or more of the Ethernet packets transmitted from the same transmission source, extracts a plurality of CAN messages included in the acquired one or more of the Ethernet packets, and when there are a plurality of CAN messages having the same message ID in the extracted plurality of CAN messages, transmits some of the CAN messages among the plurality of CAN messages having the same message ID and discards the other CAN messages.

Description

In-vehicle device, program, and information processing method

[0001] This application claims priority to Japanese Patent Application No. 2023-218289 filed on December 25, 2023, and incorporates by reference all of the contents of that application.

[0002] A vehicle is equipped with an on-board ECU (Electronic Control Unit) for controlling on-board devices such as powertrain devices (e.g., engine control) and body devices (e.g., air conditioning control). The on-board ECU includes a processing unit such as an MPU, a rewritable nonvolatile storage unit such as a RAM, and a communication unit for communicating with other on-board ECUs, and controls the on-board devices by reading and executing control programs stored in the storage unit. The vehicle also includes a relay device equipped with wireless communication capabilities (see, for example, Patent Document 1).

[0003] Japanese Patent Application Laid-Open No. 2017-97851

[0004] An in-vehicle device according to one aspect of the present disclosure is an in-vehicle device that is mounted on a vehicle and connected to an in-vehicle network in which communication is performed using Ethernet and CAN, and includes a control unit that performs processing related to relaying data flowing on the in-vehicle network, wherein the data includes an Ethernet packet using the Ethernet and a CAN message using the CAN, and the control unit acquires one or more of the Ethernet packets transmitted from the same sender, extracts multiple CAN messages contained in the one or more acquired Ethernet packets, and, if multiple CAN messages with the same message ID exist among the extracted multiple CAN messages, transmits some of the CAN messages with the same message ID and discards the other CAN messages.

[0005] FIG. 1 is a schematic diagram illustrating the configuration of an in-vehicle system according to a first embodiment; FIG. 2 is a block diagram illustrating the configuration of an in-vehicle device; FIG. 3 is an explanatory diagram illustrating data (frame format) flowing through an in-vehicle network; FIG. 4 is a flowchart illustrating processing (duplicate frames) by a control unit of an in-vehicle device; FIG. 5 is an explanatory diagram illustrating unpacking of a CAN message; FIG. 6 is a flowchart illustrating processing (relay setting table) by a control unit of an in-vehicle device according to a second embodiment; FIG. 7 is an explanatory diagram illustrating a relay setting table; FIG. 8 is a flowchart illustrating processing (relay frequency: number of times) by a control unit of an in-vehicle device; FIG. 9 is a flowchart illustrating processing (relay frequency: time) by a control unit of an in-vehicle device;

[0006] [Problem that the present disclosure aims to solve] The relay device of Patent Document 1 has a problem in that, when connected to an in-vehicle network in which communication is carried out using Ethernet and CAN, no consideration is given to how to handle processes such as sending or discarding multiple CAN messages contained in an acquired Ethernet packet.

[0007] The object of the present disclosure is to provide an in-vehicle device, etc., that, when connected to an in-vehicle network in which communication is performed using Ethernet and CAN, can efficiently perform processing such as sending or discarding multiple CAN messages contained in an acquired Ethernet packet.

[0008] [Effects of the Present Disclosure] According to one aspect of the present disclosure, it is possible to provide an in-vehicle device or the like that, when connected to an in-vehicle network in which communication is performed using Ethernet and CAN, efficiently performs processing such as sending or discarding for multiple CAN messages contained in an acquired Ethernet packet.

[0009] [Description of Embodiments of the Present Disclosure] First, embodiments of the present disclosure will be listed and described. In addition, at least some of the embodiments described below may be combined in any desired manner.

[0010] (1) An in-vehicle device according to one aspect of the present disclosure is an in-vehicle device that is mounted on a vehicle and connected to an in-vehicle network where communication is performed using Ethernet and CAN, and includes a control unit that performs processing related to relaying data flowing through the in-vehicle network, where the data includes an Ethernet packet using the Ethernet and a CAN message using the CAN, and the control unit acquires one or more of the Ethernet packets transmitted from the same sender, extracts multiple CAN messages contained in the one or more acquired Ethernet packets, and, if multiple CAN messages with the same message ID exist among the extracted multiple CAN messages, transmits some of the CAN messages with the same message ID and discards the other CAN messages.

[0011] In this aspect, the on-board device is mounted on a vehicle and connected to an on-board network in which communication is performed using Ethernet and CAN. The on-board network includes an Ethernet segment in which communication is performed using, for example, a TCP / IP protocol via an Ethernet cable, and a CAN segment in which communication is performed using, for example, a CAN (Controller Area Network) or CAN FD (CAN with Flexible Data Rate) protocol via a CAN bus. One or more on-board ECUs (Eth nodes) that perform Ethernet communication are connected to the Ethernet segment (Ethernet network). One or more on-board ECUs (CAN nodes) are connected to the CAN segment (CAN network). The on-board device is connected to the on-board ECUs (Eth nodes) and on-board ECUs (CAN nodes) via the on-board network so as to be able to communicate with them. The control unit of the in-vehicle device performs protocol conversion between in-vehicle ECUs with different communication protocols, thereby relaying data transmitted from an Ethernet-connected in-vehicle ECU (Eth node) to a CAN-connected in-vehicle ECU (CAN node), functioning as an in-vehicle relay device. When the control unit of the in-vehicle device acquires an Ethernet packet from an Ethernet-connected in-vehicle ECU (Eth node), the control unit extracts multiple CAN messages included in the payload area of ​​the Ethernet packet and divides (unpacks) the multiple CAN messages from a single Ethernet packet. That is, multiple CAN messages are packed into an Ethernet packet. The packing pattern may be, for example, a pattern compliant with AUTOSAR (registered trademark). The CAN header format packed into the Ethernet packet may be, for example, a long header (full header) format or a short header format. For example, when the CAN header format is the Long Header (Full Header) format, the format of the CAN message is defined with the CANID field (4 bytes) at the beginning, followed by the DLC field (4 bytes), and then the payload field, in that order.The control unit of the in-vehicle device acquires one or more Ethernet packets transmitted from the same sender, i.e., the same in-vehicle ECU (Eth node). The control unit of the in-vehicle device can identify the in-vehicle ECU (Eth node) that is the sender of the Ethernet packet based on the sender IP address (source address) included in the header of the Ethernet packet. When acquiring multiple Ethernet packets from the same in-vehicle ECU, the control unit of the in-vehicle device may acquire these multiple Ethernet packets consecutively in chronological order. The control unit of the in-vehicle device may group multiple CAN messages extracted from one or more Ethernet packets acquired from the same in-vehicle ECU by message ID included in the header of the CAN message. This results in one or more CAN message groups being formed according to the number (number of types) of message IDs. The control unit of the in-vehicle device transmits (relays) only some of the CAN messages (each CAN message group) with the same message ID and discards the other CAN messages without transmitting them. Therefore, when multiple CAN messages extracted (unpacked) from one or more Ethernet packets from the same source contain CAN messages with overlapping message IDs, for example, only one of the multiple CAN messages with overlapping message IDs is transmitted (relayed by protocol conversion), and the other CAN messages are discarded without being transmitted (relayed). This makes it possible to efficiently transmit or discard multiple CAN messages contained in the acquired Ethernet packet, and prevents CAN messages from remaining excessively stuck in the in-vehicle device when performing protocol conversion and relay processing from Ethernet packets to CAN messages.In particular, there is a large difference in throughput (communication bandwidth) between Ethernet and CAN or CAN-FD, meaning that CAN etc. has a lower transfer speed than Ethernet. However, by appropriately thinning out all CAN messages extracted (unpacked) from Ethernet packets, it is possible to transmit (relay) only some of the CAN messages, thereby ensuring communication quality and performing efficient relay processing.

[0012] (2) In an in-vehicle device according to one aspect of the present disclosure, when a single Ethernet packet contains multiple CAN messages with the same message ID among the one or more acquired Ethernet packets, the control unit transmits the CAN message that is stored last in the Ethernet packet among the multiple CAN messages with the same message ID, and discards the other CAN messages.

[0013] In this aspect, it is assumed that a single Ethernet packet acquired from an onboard ECU (Eth node) contains multiple CAN messages with the same message ID. In this case, the control unit of the onboard device transmits at least the CAN message that is stored last in the Ethernet packet, i.e., the most recent CAN message, among the multiple CAN messages (CAN messages with the same message ID) containing the same message ID, and discards the other CAN messages. When storing (packing) multiple CAN messages in the payload area of ​​a single Ethernet packet, the onboard ECU (Eth node) stores the CAN messages in the order they were received (in order from oldest to newest), starting from the front (first byte) of the payload area. Therefore, the CAN message that was received most recently, i.e., the most recent CAN message, is stored at the end of the payload area. Therefore, when multiple CAN messages with the same message ID are stored in a single Ethernet packet, the control unit of the onboard device can transmit the most recent CAN message by transmitting (relaying) the last CAN message in the payload area. When storing (packing) a CAN message in an Ethernet packet, the in-vehicle ECU (Eth node) may pack the CAN message by attaching (associating) a timestamp indicating the time or date when the CAN message was received. In this case, the control unit of the in-vehicle device may transmit the latest CAN message according to the timestamp attached to each unpacked CAN message.

[0014] (3) In an in-vehicle device according to one aspect of the present disclosure, when a CAN message with the same message ID is present in each of the acquired multiple Ethernet packets, the control unit transmits the CAN message contained in one of the multiple Ethernet packets depending on the number of times the Ethernet packet is received, and discards the CAN messages contained in the other Ethernet packets.

[0015] In this aspect, when the control unit of the on-board device acquires (receives) Ethernet packets including a CAN message with the same message ID from the same on-board ECU (Eth node) multiple times, the control unit increments (counts up) the number of receptions each time the packet is acquired (received), and stores the number of receptions in the storage unit of the on-board device in association with the ECU name of the on-board ECU (Eth node) that is the sender of the Ethernet packet and the message ID of the CAN message included in the Ethernet packet. This allows the control unit of the on-board device to save or manage the number of receptions of Ethernet packets including the CAN message for each combination of the on-board ECU (Eth node) that is the sender of the Ethernet packet and the message ID of the CAN message included in the Ethernet packet. For each CAN message for each combination of sender and message ID, the control unit of the on-board device transmits the CAN message at a predetermined frequency, such as once out of four times the Ethernet packet including the CAN message is received. That is, the control unit of the in-vehicle device may transmit an unpacked CAN message when the number of times (n) an Ethernet packet containing a CAN message with the same message ID is received, the Ethernet packet being sent from the same in-vehicle ECU (Eth node), is divided by, for example, a predetermined frequency constant (k), and the remainder is 1, and may discard the unpacked CAN message when the remainder is other than 1.

[0016] (4) In an in-vehicle device according to one aspect of the present disclosure, if the control unit acquires an Ethernet packet between the time the control unit transmits the CAN message contained in the acquired Ethernet packet and the time a predetermined non-transmission period has elapsed, the control unit discards the CAN message contained in the acquired Ethernet packet, and if the control unit acquires an Ethernet packet after the non-transmission period has elapsed, the control unit transmits the CAN message contained in the acquired Ethernet packet.

[0017] In this aspect, the control unit of the in-vehicle device discards the CAN message contained in the received Ethernet packet without transmitting it, even if the control unit receives an Ethernet packet containing a CAN message with the same message ID and sender as the CAN message at the time of transmission within a predetermined non-transmission period starting from the time of transmission of the unpacked CAN message. Then, if the control unit of the in-vehicle device receives an Ethernet packet containing a CAN message with the same message ID and sender as the previously transmitted CAN message after the non-transmission period has elapsed, the control unit of the in-vehicle device unpacks and transmits the CAN message contained in the received Ethernet packet. In this way, when transmitting (relaying) CAN messages of the same type, i.e., CAN messages with the same message ID and sender onboard ECU (Eth node), a non-transmission period is set for each type of CAN message, and CAN message transmission processing is not performed during the non-transmission period. This prevents excessive communication load, ensures communication quality, and enables efficient relay processing. The starting point of the non-transmission period is not limited to the time when the CAN message is transmitted, but may be the time when the CAN message is stored (put into) a transmission queue used for transmitting the CAN message (queue input time). By using such a transmission queue, it is possible to suppress resource contention in the CAN communication unit (CAN transceiver, etc.), for example, when transmitting multiple CAN messages simultaneously.

[0018] (5) In an in-vehicle device according to one aspect of the present disclosure, the control unit refers to the stored values ​​stored in the payloads of the CAN messages with the same message ID contained in the multiple Ethernet packets acquired from the same source, and transmits any CAN message with a different stored value from the stored value of the previously transmitted CAN message, and discards any CAN message with the same stored value as the stored value of the previously transmitted CAN message.

[0019] In this aspect, when the control unit of the in-vehicle device acquires Ethernet packets transmitted from the same sender (in-vehicle ECU) multiple times, each of these consecutively acquired Ethernet packets contains a CAN message with the same message ID (the same type of CAN message). If the stored value of the payload of the previously transmitted (relayed) CAN message is substantially the same as the stored value of the payload of the currently extracted (unpacked) CAN message in the same type of CAN message consecutively acquired from the same sender (in-vehicle ECU), the control unit of the in-vehicle device discards the currently extracted CAN message without transmitting (relaying). If the payload of the previously transmitted (relayed) CAN message is substantially different from the payload of the currently extracted (unpacked) CAN message, the control unit of the in-vehicle device transmits (relays) the currently extracted CAN message. As a result, even when Ethernet packets containing CAN messages with the same message ID (same type of CAN message) are received multiple times consecutively from the same sender (on-board ECU), it is possible to eliminate (thin out) the need to transmit (relay) CAN messages containing substantially the same stored value in the payload of the previously transmitted (relayed) CAN message. This allows for efficient relay processing while ensuring communication quality and suppressing excessive communication load. That is, by unpacking multiple Ethernet packets transmitted from the same sender (on-board ECU), even when there are multiple chronologically consecutive CAN messages of the same type, if the stored values ​​in the payload of these multiple CAN messages are substantially identical, only the CAN message extracted (unpacked) from the earliest acquired Ethernet packet can be transmitted (relayed). Therefore, when there are multiple chronologically consecutive CAN messages of the same type, if the stored values ​​in the payload of these CAN messages do not change, it is possible to avoid redundant transmission (relay) of CAN messages with the same stored value, thereby ensuring communication quality and enabling efficient relay processing.When performing processing related to discarding CAN messages according to the identity of the stored values ​​in the payload, the control unit of the in-vehicle device may count the number of discards (discard count) and, if the number of discards exceeds or reaches a predetermined upper limit (discard upper limit), transmit the CAN message that has reached the discard upper limit. By unpacking Ethernet packets in this way, when there are multiple consecutive CAN messages of the same type in chronological order, there is a concern that continuing to discard the CAN messages because the stored values ​​in the payloads of these CAN messages do not change (the same stored values ​​continue), which could affect the processing of the in-vehicle ECU (CAN node) to which the CAN messages are sent. In contrast, by transmitting a CAN message when the discard upper limit is reached, even if the stored values ​​continue to be substantially the same, it is possible to prevent CAN messages from being discarded beyond the discard upper limit, thereby ensuring communication quality and performing efficient relay processing.

[0020] (6) In an in-vehicle device according to one aspect of the present disclosure, the control unit refers to the discard conditions for CAN messages stored in an accessible storage area, and determines which CAN messages to send and which CAN messages to discard based on the referred discard conditions.

[0021] In this aspect, information defining discard conditions for CAN messages is stored, for example, in a table format (relay setting table) in a storage area accessible from the control unit of the in-vehicle device, such as the storage unit of the in-vehicle device. The relay setting table stores, for example, discard conditions (relay settings) corresponding to each type of CAN message (for each type defined by a combination of a sender and a CAN message) corresponding to the type of CAN message. The discard conditions (relay settings) may include, for example, a relay frequency based on the number of times the message has been received, a period of non-transmission since the previous transmission, discard of duplicate frames (CAN messages with the same message ID) contained in the same Ethernet packet, or discard based on the identity of the stored values ​​in the payload. By referring to the relay setting table for CAN messages extracted (unpacked) from the acquired Ethernet packet, the control unit of the in-vehicle device can efficiently determine a discard condition (relay setting) or a combination of multiple discard conditions corresponding to each CAN message.

[0022] (7) In an in-vehicle device according to one aspect of the present disclosure, the control unit updates the discarding conditions stored in the memory area by obtaining information regarding the discarding conditions from an external server located outside the vehicle.

[0023] In this aspect, the in-vehicle device is communicatively connected to an external server provided outside the vehicle. When campaign information indicating the distribution of an update program is received from the external server, the in-vehicle device receives the update program and functions as a control device that performs reprogramming processing, such as transmitting and activating the update program, for in-vehicle ECUs that require a program update. When the in-vehicle device receives campaign information from the external server, the in-vehicle device acquires information about discard conditions (relay setting table) from the external server as needed. The in-vehicle device updates the discard conditions (relay setting table) stored in the storage unit using the information about the discard conditions (relay setting table) from the external server. In this way, the in-vehicle device acquires and updates the discard conditions (relay setting table) as part of a reprogramming process, such as acquiring an update program to be applied to the in-vehicle ECUs. This allows the in-vehicle device to flexibly respond to, for example, design changes or development of variations of the in-vehicle system, thereby improving availability according to the type and function of the in-vehicle ECUs installed in the vehicle.

[0024] (8) In an in-vehicle device according to one aspect of the present disclosure, a memory unit including a plurality of receive buffers is provided, and the control unit acquires a plurality of Ethernet packets transmitted from a plurality of different senders using the plurality of receive buffers, respectively, and extracts the plurality of CAN messages contained in the Ethernet packets from the receive buffers, thereby performing parallel processing according to the number of senders.

[0025] In this aspect, the storage unit of the in-vehicle device includes a plurality of receive buffers predetermined according to the number of senders, i.e., the storage unit has areas reserved corresponding to each of these receive buffers. The number of receive buffers may be two or more, and may be the same number as the number of in-vehicle ECUs (Eth nodes) that are senders of Ethernet packets. In this case, a receive buffer may be provided corresponding to each in-vehicle ECU that is a sender of the Ethernet packets. When the control unit of the in-vehicle device sequentially receives Ethernet packets from a plurality of in-vehicle ECUs (Eth nodes), the control unit stores each Ethernet packet in a different receive buffer and executes a process of extracting (unpacking) CAN messages from each Ethernet packet in parallel (performs parallel processing) on ​​these receive buffers. In this case, the control unit has hardware resources such as multiple cores or multiple CPUs and is configured to support parallel processing, and the number of cores or CPUs may be equal to or greater than the number of receive buffers. The control unit of the in-vehicle device may store (put) the CAN messages extracted (unpacked) by this parallel processing in a transmission queue in the order of extraction. The transmission queue may be configured as a software function unit executed by the control unit by executing a queuing program, or may be configured as a hardware function unit implemented in an FPGA, ASIC, or the like included in a CAN communication unit of a CAN controller or the like. By using multiple receive buffers in this way to unpack multiple Ethernet packets by parallel processing, the control unit of the in-vehicle device can shorten the lead time (elapse time) required for processing each Ethernet packet and reduce the transmission wait time when transmitting (relaying) CAN messages.

[0026] (9) In an in-vehicle device according to one aspect of the present disclosure, the device includes a plurality of CAN communication units for performing communication via the CAN and a plurality of Ethernet communication units for performing communication via the Ethernet, and the control unit performs relay processing of CAN messages transmitted and received between the plurality of CAN communication units and relay processing of Ethernet packets transmitted and received between the plurality of Ethernet communication units.

[0027] In this aspect, the in-vehicle device includes a plurality of CAN communication units (CAN transceivers) for performing communication via CAN and a plurality of Ethernet communication units (Ethernet PHY units) for performing communication via Ethernet. The control unit of the in-vehicle device relays CAN messages transmitted and received between the plurality of CAN communication units and functions as a CAN relay unit. Furthermore, the control unit of the in-vehicle device relays Ethernet packets transmitted and received between the plurality of Ethernet communication units and functions as an Ethernet relay unit. That is, the in-vehicle device functions as a protocol conversion unit (CAN-Eth relay unit) that performs protocol conversion between in-vehicle ECUs with different communication protocols, as well as an Ethernet switch (Ethernet relay unit: Layer 1 switch or Layer 2 switch) that relays Ethernet packets and a CAN gateway (CAN-CAN relay unit) that relays CAN messages. In an in-vehicle network where different protocols (CAN, Ethernet (TCP / IP)) are mixed, by implementing functions in the in-vehicle device that relay data of each protocol and also perform protocol conversion, it is possible to consolidate relay-related processing in the in-vehicle device, thereby reducing the number of devices installed in the vehicle.

[0028] (10) In an in-vehicle device according to one aspect of the present disclosure, the control unit determines whether the Ethernet packet contains the CAN message based on the source address, destination address, port number, or information stored in the payload of the acquired Ethernet packet. If the Ethernet packet contains the CAN message, the control unit performs processing related to sending or discarding each of the multiple CAN messages. If the Ethernet packet does not contain the CAN message, the control unit performs relay processing of the Ethernet packet based on predetermined routing information.

[0029] In this aspect, the control unit of the in-vehicle device determines whether an acquired Ethernet packet packs (contains) multiple CAN messages based on the source address, destination address, or port number (UDP port number or TCP port number) included in the header of the Ethernet packet (unpacking frame determination). The storage unit of the in-vehicle device stores setting information or a parameter sheet for defining an Ethernet packet packing multiple CAN messages using port numbers, etc., and the control unit of the in-vehicle device can make this determination by referring to the parameter sheet, etc. Alternatively, the control unit of the in-vehicle device may determine whether multiple CAN messages are stored (packed) in the payload of an acquired Ethernet packet by referring to information stored in the payload of the Ethernet packet. If the control unit of the in-vehicle device determines that the Ethernet packet contains (is packed with) multiple CAN messages, the control unit of the in-vehicle device performs a series of processes related to protocol conversion and relay (unpacking process, etc.) by transmitting or discarding each of the multiple CAN messages according to, for example, a discard condition (relay setting table). When the control unit of the in-vehicle device determines that an Ethernet packet does not contain multiple CAN messages (is not packed), the control unit performs relay processing of the Ethernet packet based on predetermined routing information without performing processing related to protocol conversion (e.g., unpacking processing). The relay processing of the Ethernet packet based on the routing information is not limited to relaying from the Ethernet communication unit that received the Ethernet packet to another Ethernet communication unit, but also includes, for example, discarding the received Ethernet packet if it is determined that relaying is not necessary based on the routing information. In this way, even when the control unit of the in-vehicle device receives a large number of Ethernet packets, the control unit performs a series of processing related to protocol conversion (e.g., unpacking processing) only on Ethernet packets that pack CAN messages, thereby reducing the processing load.

[0030] (11) A program according to one aspect of the present disclosure is a program that causes a computer to execute processing connected to an in-vehicle network in which communication is performed using Ethernet and CAN, and to perform processing related to relaying data flowing through the in-vehicle network, wherein the data includes an Ethernet packet using the Ethernet and a CAN message using the CAN, and the program acquires one or more of the Ethernet packets transmitted from the same sender, extracts multiple CAN messages contained in the one or more acquired Ethernet packets, and, if multiple CAN messages with the same message ID exist among the extracted multiple CAN messages, transmits some of the multiple CAN messages with the same message ID and discards the other CAN messages.

[0031] In this aspect, a program can be provided that causes a computer to function as an in-vehicle device that efficiently performs processes such as sending or discarding multiple CAN messages contained in acquired Ethernet packets when the computer is connected to an in-vehicle network where communication is performed using Ethernet and CAN.

[0032] (12) An information processing method according to one aspect of the present disclosure is an information processing method that causes a computer connected to an in-vehicle network in which communication is performed using Ethernet and CAN to perform processing related to relaying data flowing through the in-vehicle network, wherein the data includes an Ethernet packet using the Ethernet and a CAN message using the CAN, and the information processing method acquires one or more of the Ethernet packets transmitted from the same sender, extracts multiple CAN messages contained in the acquired one or more Ethernet packets, and, if multiple CAN messages with the same message ID exist among the extracted multiple CAN messages, transmits some of the multiple CAN messages with the same message ID and discards the other CAN messages.

[0033] In this aspect, an information processing method can be provided that, when a computer is connected to an in-vehicle network in which communication is performed using Ethernet and CAN, causes the computer to function as an in-vehicle device that efficiently performs processing such as sending or discarding multiple CAN messages contained in an acquired Ethernet packet.

[0034] [Details of the Embodiments of the Present Disclosure] The present disclosure will be specifically described with reference to the drawings illustrating the embodiments. An in-vehicle device 2 according to the embodiments of the present disclosure will be described below with reference to the drawings. Note that the present disclosure is not limited to these examples, but is defined by the claims, and is intended to include all modifications within the meaning and scope equivalent to the claims.

[0035] (Embodiment 1) Hereinafter, an embodiment will be described with reference to the drawings. FIG. 1 is a schematic diagram illustrating the configuration of an in-vehicle system S according to embodiment 1. FIG. 2 is a block diagram illustrating the configuration of an in-vehicle device 2. The in-vehicle system S is composed of an in-vehicle device 2 connected to an in-vehicle network 4 and a plurality of in-vehicle ECUs 3. The in-vehicle device 2 is connected to each of the plurality of in-vehicle ECUs 3 via the in-vehicle network 4 so as to be able to communicate with them. The in-vehicle device 2 relays communication between the plurality of in-vehicle ECUs 3 mounted on the vehicle. Furthermore, the in-vehicle device 2 may communicate with an external server 100 connected to the extra-vehicle network via an extra-vehicle communication device 1, and relay communication between the external server 100 and the in-vehicle ECUs 3 mounted on the vehicle.

[0036] The external server 100 is a computer such as a server connected to an external network such as the Internet or a public line network. The storage unit of the external server 100 may store update programs to be applied to the in-vehicle ECU 3 or information related to a relay setting table, which will be described later.

[0037] The in-vehicle network 4 is configured by a plurality of communication lines 41, each of which is made up of an Ethernet cable 411 or a CAN bus 412. That is, the in-vehicle network 4 includes an Ethernet segment in which communication is performed via the Ethernet cable 411 using, for example, a TCP / IP protocol, and a CAN segment in which communication is performed via the CAN bus 412 using, for example, a CAN (Controller Area Network) protocol or a CAN with Flexible Data Rate (CANFD) protocol.

[0038] One or more in-vehicle ECUs 3 (Eth nodes) that perform Ethernet communication are connected to an Ethernet segment (Ethernet network). One or more in-vehicle ECUs 3 (CAN nodes) that perform CAN communication are connected to a CAN segment (CAN network).

[0039] The in-vehicle device 2 functions as an Ethernet relay unit (Ethernet relay unit: Ethernet switch) that relays data (Ethernet packets) transmitted and received between multiple in-vehicle ECUs 3 (Eth nodes) connected to an Ethernet segment. Furthermore, the in-vehicle device 2 functions as a CAN relay unit (CAN-CAN relay unit: CAN gateway) that relays data (CAN messages) transmitted and received between multiple in-vehicle ECUs 3 (CAN nodes) connected to a CAN segment. Furthermore, the in-vehicle device 2 functions as a protocol converter (CAN-Eth relay unit) that converts and relays protocols between in-vehicle ECUs 3 (between Eth nodes and CAN nodes) that use different communication protocols for CAN and Ethernet. Thus, the control unit 20 of the in-vehicle device 2 functions as an Ethernet relay unit, a CAN relay unit, and a protocol converter by executing a program stored in the storage unit 21. The Ethernet relay unit, the CAN relay unit, and the protocol converter correspond to software functional units that execute a relay application (GW app) included in the program.

[0040] Note that, among the functions performed by the Ethernet relay unit and the CAN relay unit, processing related to the data link layer, for example, may be executed by a hardware processing unit such as an ASIC (Application Specific Integrated Circuit) or FPGA (Field-Programmable Gate Array) provided in the in-vehicle device 2, rather than by software processing by the control unit 20. In the present embodiment, the Ethernet relay unit, the CAN relay unit, and the protocol conversion unit are implemented in the in-vehicle device 2 configured as a single device, but this is not limited to this. The Ethernet relay unit, the CAN relay unit, and the protocol conversion unit may each be mounted in a separate in-vehicle device 2, and in-vehicle devices 2 implementing these respective functional units may be communicatively connected. In this case, the in-vehicle device 2 implementing the protocol conversion unit may be the center, and an Ethernet switch (Ethernet relay device) functioning as the Ethernet relay unit and a CAN gateway (CAN relay device) functioning as the CAN relay unit may each be connected to the in-vehicle device 2 implementing the protocol conversion unit.

[0041] The exterior-vehicle communication device 1 includes an exterior-vehicle communication unit (not shown) and an input / output I / F for communicating with the in-vehicle device 2. The exterior-vehicle communication unit is a communication device for wireless communication using a mobile communication protocol such as 4G, LTE (Long Term Evolution), 5G, or Wi-Fi, and transmits and receives data to and from an external server 100 via an antenna 11 connected to the exterior-vehicle communication unit. Communication between the exterior-vehicle communication device 1 and the external server 100 is performed via an external network such as a public line network or the Internet. The input / output I / F is a communication interface for, for example, serial communication with the in-vehicle device 2. The exterior-vehicle communication device 1 and the in-vehicle device 2 communicate with each other via the input / output I / F and a wire harness such as a serial cable connected to the input / output I / F. In this embodiment, the exterior-vehicle communication device 1 is a separate device from the in-vehicle device 2, and these devices are communicatively connected via the input / output I / F, but this is not limiting. The exterior-vehicle communication device 1 may be built into the in-vehicle device 2 as a component of the in-vehicle device 2.

[0042] The in-vehicle device 2 includes a control unit 20, a storage unit 21, an input / output I / F 22, and an in-vehicle communication unit 23. The in-vehicle device 2 may be a PLB (Power LAN Box) having a power distribution function in addition to a data communication relay function, or an integrated ECU having a relay function and performing integrated control of the entire vehicle C. The in-vehicle device 2 may be configured as one functional unit of a body ECU that controls all body actuators. The in-vehicle device 2 may be configured to acquire, from the exterior communication device 1, an update program received by the exterior communication device 1 from the external server 100 via wireless communication, and transmit the update program to a predetermined in-vehicle ECU 3 (the in-vehicle ECU 3 to be updated) via the in-vehicle network 4.

[0043] The control unit 20 is composed of a CPU (Central Processing Unit) or an MPU (Micro Processing Unit), and performs various control processes and calculation processes by reading and executing programs P and data pre-stored in the memory unit 21.

[0044] The storage unit 21 is configured with a volatile memory element such as a RAM (Random Access Memory) or a non-volatile memory element such as a ROM (Read Only Memory), an EEPROM (Electrically Erasable Programmable ROM), or a flash memory, and stores in advance a program P and data to be referenced during processing. The program P stored in the storage unit 21 may be a program P read from a recording medium M readable by the in-vehicle device 2. Alternatively, the program P may be downloaded from an external computer (not shown) connected to a communication network (not shown) and stored in the storage unit 21. The storage unit 21 also stores a relay setting table (described later) and the like.

[0045] The storage unit 21 stores relay route information (routing table) used in relay processing for communication between the in-vehicle ECUs 3 or communication between the in-vehicle ECUs 3 and the external server 100. The format of the relay route information is determined based on the communication protocol. When the communication protocol is CAN, the CAN relay route information includes a message identifier (CANID) included in the CAN message and a relay destination associated with the CANID (I / O port number of the CAN communication unit 232). When the communication protocol is TCP / IP (Ethernet), the TCP / IP relay route information includes a destination address (MAC address or IP address) included in the IP packet and a relay destination associated with the destination address (physical port number of the Ethernet communication unit 231).

[0046] The input / output I / F 22 is a communication interface for, for example, serial communication, similar to the input / output I / F of the exterior-vehicle communication device 1. The in-vehicle device 2 is connected to the exterior-vehicle communication device 1 via the input / output I / F 22. The in-vehicle device 2 and the exterior-vehicle communication device 1 may be connected via a CAN bus 412 or an Ethernet cable 411.

[0047] The in-vehicle communication unit 23 is an input / output interface (CAN communication unit 232, Ethernet communication unit 231) that uses a communication protocol such as CAN (Control Area Network), CAN-FD (CAN with Flexible Data Rate), or Ethernet (registered trademark), and the control unit 20 communicates with in-vehicle devices such as the in-vehicle ECU 3 or other relay devices connected to the in-vehicle network 4 via the in-vehicle communication unit 23. The in-vehicle device 2 is provided with a plurality of CAN communication units 232 and Ethernet communication units 231.

[0048] The Ethernet communication unit 231 is an Ethernet PHY unit that supports TCP / IP packets transmitted over an Ethernet cable 411 such as 100BASE-T1 or 1000BASE-T1.

[0049] CAN communication unit 232 is compatible with the CAN or CAN-FD communication protocol, and is compatible with CAN messages transmitted on CAN bus 412. CAN communication unit 232 is a CAN transceiver or CAN-FD transceiver that receives a waveform due to the potential difference of the differential voltage on CAN bus 412, which is composed of two wires, high and low, and decodes the received waveform into a signal represented by a bit string of 1s and 0s. Alternatively, CAN communication unit 232 may include a CAN transceiver and a CAN controller, or a CAN-FD transceiver and a CAN-FD controller.

[0050] A plurality of in-vehicle communication units 23 (Ethernet communication unit 231, CAN communication unit 232) are provided, and each in-vehicle communication unit 23 is connected to a respective communication line 41 (Ethernet cable 411, CAN bus 412), i.e., a respective bus, that constitutes the in-vehicle network 4. By providing a plurality of in-vehicle communication units 23 in this way, the in-vehicle network 4 may be divided into a plurality of segments, and the in-vehicle ECU 3 may be connected to each segment according to the function of the in-vehicle ECU 3.

[0051] The in-vehicle ECU 3 includes a control unit, a storage unit, and an in-vehicle communication unit, similar to the in-vehicle device 2. The storage unit is configured with a volatile memory element such as a random access memory (RAM) or a non-volatile memory element such as a read-only memory (ROM), an electrically erasable programmable read-only memory (EEPROM), or a flash memory, and stores programs or data for the in-vehicle ECU 3. The in-vehicle communication unit includes an Ethernet communication unit or a CAN communication unit, similar to the in-vehicle device 2, and the in-vehicle ECU 3 communicates with the in-vehicle device 2 via the in-vehicle communication unit. The in-vehicle device 2 includes an Eth node for performing Ethernet communication and a CAN node for performing CAN communication.

[0052] 3 is an explanatory diagram illustrating an example of data (frame format) flowing through the in-vehicle network 4. The data flowing through the in-vehicle network 4 includes Ethernet packets (Eth frames) using Ethernet and CAN messages (CAN frames) using CAN. In the in-vehicle network 4, Ethernet packets are transmitted and received through an Ethernet segment (Ethernet network) formed by an Ethernet cable 411. In the in-vehicle network 4, CAN messages are transmitted and received through a CAN segment (CAN network) formed by a CAN bus 412.

[0053] The frame format of an Ethernet packet is defined by a communication standard such as IEEE 802.3, and includes areas such as a header, payload, and FCS (Frame Check Sequence). The header area (header section) is subdivided according to the communication standard, and various header information such as source and destination addresses in IP and MAC addresses, and port numbers (UDP port numbers or TCP port numbers) is stored. An Ethernet packet that packs multiple CAN messages stores these multiple CAN messages in the payload area. An Ethernet packet that does not pack multiple CAN messages, i.e., an Ethernet packet transmitted and received between on-board ECUs 3 (Eth nodes) connected to the Ethernet cable 411, stores content data according to the application of the Ethernet packet in the payload area.

[0054] The frame format of a CAN message is defined by a communication standard such as ISO118983 and includes a header (header section) and a payload. The header section is subdivided according to the communication standard and includes a CANID section and a DLC section. The CANID section stores a message ID (CANID). The DLC section stores the data length of the CAN message.

[0055] 4 is a flowchart illustrating the processing (overlapping frame) of the control unit 20 of the in-vehicle device 2. The control unit 20 of the in-vehicle device 2 steadily performs the following processing, for example, when the vehicle C is in a running state (IG switch is on) or a stopped state (IG switch is off).

[0056] The control unit 20 of the in-vehicle device 2 acquires an Ethernet packet (S101). In the in-vehicle network 4, an in-vehicle ECU 3 operating as an Eth node is connected to an Ethernet segment (Ethernet network) formed by an Ethernet cable 411. The control unit 20 of the in-vehicle device 2 acquires (receives) data transmitted from the in-vehicle ECU 3 operating as the Eth node and flowing through the in-vehicle network 4 (Ethernet network) via the Ethernet communication unit 231.

[0057] The control unit 20 of the in-vehicle device 2 extracts multiple CAN messages included in the Ethernet packet (S102). The control unit 20 of the in-vehicle device 2 stores the acquired Ethernet packet in the storage unit 21 and extracts the multiple CAN messages stored in the payload area of ​​the Ethernet packet, thereby performing unpacking processing on the packed CAN messages. The control unit 20 of the in-vehicle device 2 stores each of the extracted (unpacked) multiple CAN messages in the storage unit 21.

[0058] The control unit 20 of the in-vehicle device 2 identifies CAN messages with duplicate message IDs (S103). In multiple CAN messages (frames) stored (packed) in an Ethernet packet, each CAN message is assigned a message ID (stored in the header). It is assumed that there are multiple CAN messages with the same message ID (CAN messages with duplicate message IDs) for each of these multiple CAN messages. That is, multiple CAN messages stored in a single Ethernet packet are classified into one or more CAN message groups according to the identity of the message IDs.

[0059] The control unit 20 of the in-vehicle device 2 may classify or group multiple CAN messages with the same message ID into a CAN message group. The control unit 20 of the in-vehicle device 2 may perform the following process on each of one or more CAN message groups classified (grouped) in this way, thereby transmitting only the latest CAN message in each CAN message group and discarding the other CAN messages, i.e., performing CAN message thinning process.

[0060] The control unit 20 of the in-vehicle device 2 identifies a CAN message with the latest value among the multiple CAN messages with overlapping message IDs (S104). The control unit 20 of the in-vehicle device 2 identifies a CAN message with the latest value (stored in the payload) among the multiple CAN messages with overlapping message IDs, i.e., a CAN message group formed according to the identity of the message IDs.

[0061] 5 is an explanatory diagram illustrating the unpacking of CAN messages. As described above, the control unit 20 of the in-vehicle device 2 unpacks (extracts) CAN messages and identifies frames with duplicate IDs (CAN messages with the same message ID). In the illustration of this embodiment, among the CAN messages (frames) stored (packed) in an Ethernet packet, four CAN messages (frames A, B, C, and D) are CAN messages (frames) with duplicate message IDs, i.e., CAN messages (CAN message group) with the same message ID.

[0062] In multiple CAN messages (frames) with overlapping message IDs, i.e., multiple CAN messages (frames) containing the same message ID, the CAN message (frame) whose payload contains the latest value is stored at the end (rearmost part) of the payload of the Ethernet packet. Alternatively, if the CAN message containing the latest value is stored at the beginning (forefront) of an Ethernet packet, the control unit 20 of the in-vehicle device 2 may identify the CAN message stored at the beginning (forefront) as the CAN message with the latest value. Alternatively, when the in-vehicle ECU 3 (Eth node) stores (packs) the CAN message in an Ethernet packet, if the in-vehicle ECU 3 packs the CAN message by attaching (associating) a timestamp indicating the time or date when the CAN message was received or generated, the control unit 20 of the in-vehicle device 2 may identify the CAN message with the latest value according to the timestamp attached to each unpacked CAN message. The control unit 20 of the in-vehicle device 2 may identify the latest CAN message based on the storage order of the CAN messages, which is predefined according to the type of Ethernet packet, such as the port number or source address of the Ethernet packet.

[0063] The control unit 20 of the in-vehicle device 2 stores only the latest CAN message (frame) and discards (deletes from the storage unit 21) other CAN messages. The control unit 20 of the in-vehicle device 2 may reconstruct data stored in the payload of an Ethernet packet including the latest CAN message as preprocessing before transmitting the latest CAN message.

[0064] In the illustrated embodiment, four CAN messages (frames A, B, C, and D) are frames with duplicated IDs (CAN messages with the same message ID), while the other CAN messages have different message IDs (frames without duplicated IDs). In this case, the control unit 20 of the in-vehicle device 2 reconstructs the data stored in the payload of the Ethernet packet by storing the latest CAN message (frame D) in the position of the CAN message (frame A) located at the front (beginning) of the CAN messages to be thinned (frames A, B, and C) in the payload of the Ethernet packet. That is, the control unit 20 of the in-vehicle device 2 may move the latest CAN message (frame D) to the storage position of the CAN message (frame A) located at the front (beginning) in the payload of the Ethernet packet, and then perform relay processing from the front (beginning) of the payload. In this case, the control unit 20 of the in-vehicle device 2 can shorten the data length (frame length) of the Ethernet packet payload by deleting the CAN messages (frames A, B, and C) to be thinned out, thereby improving communication efficiency.

[0065] When reconstructing the data stored in the payload of the Ethernet packet, if the length of the CAN message (frame A) is smaller than the length of the CAN message (frame D) (A<D), the control unit 20 of the in-vehicle device 2 may shift (expand) the area for frame D in the payload of the Ethernet packet to the right (toward the end) so that the CAN message (frame D) can be stored. If the length of the CAN message (frame A) is greater than the length of the CAN message (frame D) (A>D), the control unit 20 may left-justify the remaining portion when the CAN message (frame D) is stored, thereby shrinking the area for frame D in the payload of the Ethernet packet toward the beginning. In this way, even if the data lengths of a CAN message that is to be relayed because it is the latest value and a CAN message that is to be discarded (thinned out) because it is not the latest value differ, the difference in data length can be efficiently accommodated by changing the storage area in the payload of the Ethernet packet.

[0066] The control unit 20 of the in-vehicle device 2 transmits the identified CAN message with the latest value (S105). The control unit 20 of the in-vehicle device 2 transmits the latest CAN message among multiple CAN messages with overlapping message IDs via the Ethernet communication unit 231. This makes it possible to transmit only the latest CAN message among multiple CAN messages with overlapping message IDs (the same message ID) stored (packed) in a single Ethernet packet. When the data stored in the payload of the Ethernet packet is reconstructed as described above, the control unit 20 of the in-vehicle device 2 may store (input) the reconstructed payload in, for example, a transmission queue used when transmitting CAN messages. By storing (inputting) the payload in the transmission queue, each CAN message included in the payload is sequentially transmitted via the Ethernet communication unit 231.

[0067] The control unit 20 of the in-vehicle device 2 discards the other CAN messages other than the latest CAN message among the multiple CAN messages with duplicate message IDs (S106). As described above, among the multiple CAN messages stored (packed) in a single Ethernet packet and with duplicate message IDs (the same message ID), the CAN messages other than the latest one are discarded without being transmitted (relayed). The control unit 20 of the in-vehicle device 2 may determine whether to perform thinning processing on the CAN message according to the message ID of the CAN message, for example, by referring to a relay setting table described later.

[0068] In the present embodiment, only the most recent CAN message is transmitted (relayed), but this is not limited thereto, and for example, among multiple CAN messages with overlapping message IDs, the oldest CAN message may be discarded, i.e., thinned out, and the other CAN messages may be transmitted (relayed). The storage unit 21 of the in-vehicle device 2 may store setting information regarding the degree of thinning out of CAN messages corresponding to each message ID, and the control unit 20 of the in-vehicle device 2 may determine the CAN messages to be thinned out corresponding to each message ID based on the setting information regarding the thinning out degree.

[0069] 6 is a flowchart illustrating the process (relay setting table) of the control unit 20 of the in-vehicle device 2 according to the second embodiment. The control unit 20 of the in-vehicle device 2 steadily performs the following process, for example, when the vehicle C is in a running state (IG switch is on) or a stopped state (IG switch is off).

[0070] The control unit 20 of the in-vehicle device 2 acquires an Ethernet packet (S201). The control unit 20 of the in-vehicle device 2 extracts a CAN message included in the Ethernet packet (S202). The control unit 20 of the in-vehicle device 2 performs the processes from S201 to S202 similar to the processes S101 to S102 of the first embodiment. The control unit 20 of the in-vehicle device 2 acquires (receives) the Ethernet packet from a plurality of in-vehicle ECUs 3 (Eth nodes) via a plurality of Ethernet communication units 231.

[0071] In this case, the control unit 20 of the in-vehicle device 2 may perform the following processing for each source in-vehicle ECU 3 (Eth node). The control unit 20 of the in-vehicle device 2 classifies or classifies the received Ethernet packets based on the source addresses (source IP address, source MAC address) included in the headers of the Ethernet packets transmitted from each of the plurality of in-vehicle ECUs 3 (Eth nodes), and performs the series of processing in this flowchart for Ethernet packets with the same source address. In this case, the control unit 20 of the in-vehicle device 2 may generate, for example, a plurality of subprocesses according to the number of source in-vehicle ECUs 3 (Eth nodes) of the Ethernet packets, and may use the plurality of subprocesses to execute processing for each source in-vehicle ECU 3 (Eth node) in parallel (parallel processing).

[0072] Each time the control unit 20 of the in-vehicle device 2 acquires (receives) an Ethernet packet, the control unit 20 associates the Ethernet packet with the reception time and stores the Ethernet packet in the storage unit 21. This allows the control unit 20 of the in-vehicle device 2 to grasp or manage chronological information, such as the order according to the reception time, for multiple Ethernet packets transmitted from the same source in-vehicle ECU 3 (Eth node). In other words, by referring to the storage unit 21, the control unit 20 of the in-vehicle device 2 can grasp the reception time, reception order, and reception count for multiple Ethernet packets received consecutively from the same source in-vehicle ECU 3 (Eth node). Furthermore, the control unit 20 of the in-vehicle device 2 may also store the transmission time (or the time of entry into a transmission queue) of the unpacked CAN message together with the CAN message in the storage unit 21.

[0073] The control unit 20 of the in-vehicle device 2 identifies a discard condition for the CAN message by referring to the relay setting table (S203). The control unit 20 of the in-vehicle device 2 identifies (derives) a discard condition (relay setting) for the CAN message by referring to the relay setting table stored in the storage unit 21 based on the source address (source node) of the acquired Ethernet packet and the message ID (received CAN ID) of the CAN message (unpacked CAN message) stored in the payload of the Ethernet packet.

[0074] 7 is an explanatory diagram illustrating an example of a relay setting table. Information defining discard conditions for CAN messages, i.e., criteria for determining whether to transmit or discard a message when performing thinning processing, is stored in, for example, a table format (relay setting table) in the storage unit 21 of the in-vehicle device 2. The relay setting table includes, as management items (fields), an item for a source node, an item for a received CAN ID, an item for the number of relay frequency counts, an item for a relay frequency time, an item for a stored value of a payload, and an item for discarding duplicate frames.

[0075] The received CAN ID field stores all the numerical values ​​used as the CAN ID (message ID) of the CAN message. The source node field may store an identifier such as a node name that uniquely identifies the in-vehicle ECU 3 (Eth node) that is the sender of the CAN message as an Ethernet packet, or a source address (source IP address, source MAC address). The type of CAN message is determined by the combination of the source node field and the received CAN ID field.

[0076] The relay frequency field stores a setting value for whether or not to perform thinning processing according to the number of times Ethernet packets are received for the corresponding CAN message type (combination of source node and receiving CAN ID). For example, the setting value is stored as 4 times, and in this case, a CAN message of the corresponding type (combination of source node and receiving CAN ID) is transmitted once out of every four times it is received.

[0077] The relay frequency time field stores a setting value for the type of corresponding CAN message (combination of source node and receiving CAN ID) that indicates whether or not to apply a process of not transmitting the next CAN message until a predetermined time (non-transmission period) has elapsed since the time the previous CAN message was transmitted (transmission time). The setting value is stored as, for example, 1 second, and in this case, the next CAN message is discarded without being transmitted until the 1 second set as the non-transmission period has elapsed since the time the previous CAN message was transmitted (or entered into the transmission queue).

[0078] The item of the stored value of the payload stores a setting value for whether or not to apply a process of not transmitting the current CAN message when the stored values ​​of the payload of the previously transmitted CAN message and the currently unpacked CAN message are the same for the corresponding CAN message type (combination of the source node and the received CAN ID). The setting value is defined, for example, as two values, "yes" or "no." If "yes," thinning out process based on the identity of the stored values ​​of the payload is applied, and if "no," thinning out process is not applied.

[0079] The item for discarding duplicate frames stores a setting value for whether or not to apply processing to not transmit CAN messages for frames with duplicate IDs (CAN messages with the same message ID) described in embodiment 1 for the corresponding CAN message type (combination of source node and received CAN ID). The setting value is defined, for example, as a binary value of yes or no; if yes, thinning processing is applied to frames with duplicate IDs, and if no, thinning processing is not applied.

[0080] In this way, the relay frequency count item, the relay frequency time item, the payload storage value item, and the duplicate frame discard item are items that define the discard conditions (relay settings). One or more discard conditions (relay settings) may be set for any CAN message type (combination of source node and receiving CAN ID). By applying all of the multiple discard conditions (relay settings) to a CAN message type (combination of source node and receiving CAN ID) for which multiple discard conditions (relay settings) are set, the relay frequency can be further reduced compared to when a single discard condition (relay setting) is set.

[0081] The control unit 20 of the in-vehicle device 2 executes relay processing for the CAN message according to the identified discard condition (S204). Based on the contents defined in the relay setting table, the control unit 20 of the in-vehicle device 2 executes relay processing specified according to the type of CAN message (combination of source node and message ID), i.e., transmission or discard according to the discard condition. In this embodiment, each of the discard conditions (relay settings) defined in the relay setting table will be described as follows. In this embodiment, three types of discard conditions (relay settings) will be described, and processing for each type may be executed as a subroutine of processing S204. When executing relay processing according to the type of CAN message (combination of source node and message ID), the control unit 20 of the in-vehicle device 2 may execute branch processing defined by, for example, a case statement.

[0082] 8 is a flowchart illustrating the process (relay frequency count) of the control unit 20 of the in-vehicle device 2. The control unit 20 of the in-vehicle device 2 executes thinning processing based on the number of receptions depending on the type of the unpacked CAN message (combination of the source node and the received CAN ID).

[0083] The control unit 20 of the in-vehicle device 2 acquires the current number of times an Ethernet packet has been received (K01). The control unit 20 of the in-vehicle device 2 updates the number of times an Ethernet packet has been received by incrementing (counting up) the number of times each time an Ethernet packet including a target CAN message is acquired (received), and stores the current number of times the Ethernet packet has been received in the storage unit 21. In this case, the control unit 20 of the in-vehicle device 2 may count (measure) the number of times an Ethernet packet including the CAN message has been received for each type of CAN message (a type determined by a combination of a sender and a message ID). The control unit 20 of the in-vehicle device 2 may store the number of times the Ethernet packet has been received counted for each type of CAN message in, for example, a relay setting table. This allows for efficient management of the current number of times each type of CAN message has been received.

[0084] The control unit 20 of the in-vehicle device 2 determines whether to transmit based on the number of times of reception (K02). The control unit 20 of the in-vehicle device 2 acquires the transmission frequency (relay frequency) indicating how many times a message is transmitted by referring to the relay setting table. The relay setting table defines whether to perform thinning processing according to the number of times a message is received for each type of CAN message (type determined by the combination of a sender and a message ID). For a type of CAN message for which thinning processing according to the number of times a message is received is not performed, the control unit 20 of the in-vehicle device 2 determines to transmit the message.

[0085] In the case of a type of CAN message that executes thinning processing according to the number of times of reception, the control unit 20 of the in-vehicle device 2 determines whether to transmit the message based on the current number of times of reception using a value (e.g., 4 times) stored in the relay frequency field. For example, the control unit 20 of the in-vehicle device 2 may determine to transmit the message if the remainder when dividing the current number of times of reception (n) by the value (frequency constant: k) stored in the relay frequency field is 1, and determine not to transmit the message if the remainder is other than 1. As a result, if the value (frequency constant: k) stored in the relay frequency field is 4 times, the CAN message is transmitted once every four times, and the other three CAN messages are discarded.

[0086] If it is determined that the CAN message should be transmitted (K02: YES), the control unit 20 of the in-vehicle device 2 transmits the CAN message to which the specified discard condition applies (K03). If it is determined that the CAN message should be transmitted based on the number of receptions, the control unit 20 of the in-vehicle device 2 transmits (relays) the CAN message to which the specified discard condition applies by referring to the relay setting table.

[0087] If it is determined that the CAN message should not be transmitted (K02: NO), the control unit 20 of the in-vehicle device 2 discards the CAN message to which the specified discard condition applies (K04). If it is determined that the CAN message should not be transmitted based on the number of receptions, the control unit 20 of the in-vehicle device 2 discards the CAN message to which the specified discard condition applies without transmitting (relaying) it by referring to the relay setting table. The control unit 20 of the in-vehicle device 2 may initialize the counted number of receptions to 0, for example, when the vehicle C is stopped or started.

[0088] 9 is a flowchart illustrating the process (relay frequency time) of the control unit 20 of the in-vehicle device 2. The control unit 20 of the in-vehicle device 2 executes a thinning process based on the elapsed time according to the type of the unpacked CAN message (the combination of the source node and the received CAN ID).

[0089] The control unit 20 of the in-vehicle device 2 acquires the elapsed time from the previous transmission point (J01). Every time the control unit 20 of the in-vehicle device 2 transmits an unpacked CAN message, the control unit 20 associates the transmission point with the message ID of the transmitted CAN message and stores them in the storage unit 21. The control unit 20 of the in-vehicle device 2 acquires the elapsed time from the previous transmission point to the current point for the CAN message of the type (combination of source node and received CAN ID) that is the target of this process, by referring to the storage unit 21.

[0090] The control unit 20 of the in-vehicle device 2 determines whether to transmit based on the elapsed time (J02). The control unit 20 of the in-vehicle device 2 acquires a non-transmission period indicating how much time has elapsed since the previous transmission or the time the message was added to the transmission queue before transmission is initiated, by referring to the relay setting table. The relay setting table defines, for each type of CAN message (a type determined by a combination of a sender and a message ID), whether to perform thinning processing according to the elapsed time. For a CAN message type that does not perform thinning processing according to the elapsed time, the control unit 20 of the in-vehicle device 2 determines to transmit.

[0091] For a type of CAN message that performs thinning processing according to elapsed time, the control unit 20 of the in-vehicle device 2 determines whether to transmit the message based on the elapsed time up to the present time using a value stored in the relay frequency time field (e.g., 1 second: non-transmission period). The control unit 20 of the in-vehicle device 2 may determine to transmit the message if the non-transmission period is 1 second and the elapsed time from the previous transmission to the present time exceeds 1 second, and may determine not to transmit the message if the non-transmission period does not exceed 1 second. This eliminates the need for the control unit 20 of the in-vehicle device 2 to transmit (relay) a CAN message that includes an Ethernet packet received during the non-transmission period.

[0092] If it is determined that the CAN message should be transmitted (J02: YES), the control unit 20 of the in-vehicle device 2 transmits the CAN message to which the specified discard condition applies (J03). If it is determined that the CAN message should be transmitted based on the elapsed time, the control unit 20 of the in-vehicle device 2 transmits (relays) the CAN message to which the specified discard condition applies by referring to the relay setting table.

[0093] If it is determined not to transmit (J02: NO), the control unit 20 of the in-vehicle device 2 discards the CAN message to which the specified discard condition applies (J04). If it is determined not to transmit based on the elapsed time, the control unit 20 of the in-vehicle device 2 discards the CAN message to which the specified discard condition applies without transmitting (relaying) it by referring to the relay setting table.

[0094] 10 is a flowchart illustrating the processing (stored values ​​of the payload) of the control unit 20 of the in-vehicle device 2. The control unit 20 of the in-vehicle device 2 executes thinning processing based on the stored values ​​of the payload according to the type of the unpacked CAN message (combination of the source node and the received CAN ID).

[0095] The control unit 20 of the in-vehicle device 2 extracts the stored value stored in the payload of the extracted CAN message (P01). Every time the control unit 20 of the in-vehicle device 2 transmits an unpacked CAN message, the control unit 20 associates the transmission time with the message ID of the transmitted CAN message and the stored value of the payload in the storage unit 21. The control unit 20 of the in-vehicle device 2 also extracts the stored value stored in the payload of the currently extracted (unpacked) CAN message and stores it in the storage unit 21.

[0096] The control unit 20 of the in-vehicle device 2 determines whether the stored value of the previously transmitted CAN message and the currently extracted stored value are the same (P02). By referring to the storage unit 21, the control unit 20 of the in-vehicle device 2 compares the stored values ​​of the payloads of the currently extracted CAN message and a CAN message of the same type (combination of the transmission source node and the received CAN ID) as the currently extracted CAN message, and determines whether these two stored values ​​are substantially the same.

[0097] If they are not identical (P02: NO), the control unit 20 of the in-vehicle device 2 transmits a CAN message to which the specified discard condition applies (P03). If they are not identical, that is, if the two compared stored values ​​are substantially different, the control unit 20 of the in-vehicle device 2 transmits (relays) a CAN message to which the specified discard condition applies by referring to the relay setting table, that is, the CAN message unpacked this time.

[0098] If the stored values ​​are identical (P02: YES), the control unit 20 of the in-vehicle device 2 discards the CAN message to which the specified discard condition applies (P04). If the compared two stored values ​​are substantially identical, the control unit 20 of the in-vehicle device 2 discards the CAN message to which the discard condition specified by referring to the relay setting table applies, i.e., the currently unpacked CAN message, without transmitting (relaying) it. When discarding a CAN message according to the identity of the stored values ​​of the payload, the control unit 20 of the in-vehicle device 2 may count the number of consecutive discards (discard count) and store it in the storage unit 21. If the number of discards exceeds or reaches a predetermined upper limit (discard upper limit), the control unit 20 of the in-vehicle device 2 may transmit the CAN message that has reached the discard upper limit.

[0099] 11 is an explanatory diagram illustrating functional blocks (parallel processing) of an in-vehicle device 2 according to a third embodiment. In this embodiment, the storage unit 21 of the in-vehicle device 2 includes a plurality of reception buffers predetermined according to the number of transmission sources. In the illustration of this embodiment, the storage unit 21 is provided with two reception buffers (an ECU-A reception buffer and an ECU-B reception buffer) corresponding to two in-vehicle ECUs 3 (Eth nodes: ECU-A and ECU-B) that are transmission sources of Ethernet packets.

[0100] When the control unit 20 of the in-vehicle device 2 receives an Ethernet packet from an in-vehicle ECU 3 (Eth node), the control unit 20 stores the received Ethernet packet in a receive buffer corresponding to the in-vehicle ECU 3 (Eth node). The control unit 20 of the in-vehicle device 2 uses the receive buffer as a work area to perform various processes in parallel, such as extracting (unpacking) CAN messages and executing thinning processes (count Cnt, time Cnt) applied by referencing a relay setting table. The control unit 20 of the in-vehicle device 2 has hardware resources such as multiple cores or multiple CPUs, and is configured to be able to handle parallel processes.

[0101] The control unit 20 of the in-vehicle device 2 parallelizes the thinning process including unpacking according to the number of in-vehicle ECUs 3 (Eth nodes) that are the senders, and sequentially transmits the thinned-out CAN messages. When sequentially transmitting the CAN messages, the control unit 20 of the in-vehicle device 2 may input the CAN messages into a transmission queue.

[0102] The embodiments disclosed herein are to be considered as illustrative in all respects and not restrictive. The scope of the present invention is defined by the claims, not by the above meaning, and is intended to include all modifications within the meaning and scope of the claims.

[0103] Multiple claims may be combined with each other regardless of the form of reference. The claims may contain multiple dependent claims that depend on multiple claims. Multiple dependent claims may be contained that depend on multiple dependent claims. If multiple dependent claims that depend on multiple dependent claims are not contained, this does not limit the number of multiple dependent claims that depend on multiple dependent claims.

[0104] C Vehicle S In-vehicle system 100 External server 1 Exterior communication device 11 Antenna 2 In-vehicle device 20 Control unit 21 Storage unit M Recording medium P Program (program product) 22 Input / output I / F 23 In-vehicle communication unit 231 Ethernet communication unit 232 CAN communication unit 3 In-vehicle ECU (Eth node, CAN node) 4 In-vehicle network 41 Communication line 411 Ethernet cable 412 CAN bus

Claims

1. An in-vehicle device mounted on a vehicle and connected to an in-vehicle network in which communication is performed using Ethernet and CAN, the in-vehicle device comprising a control unit that performs processing related to relaying data flowing through the in-vehicle network, the data including an Ethernet packet using the Ethernet and a CAN message using the CAN, the control unit acquiring one or more of the Ethernet packets transmitted from the same transmission source, extracting a plurality of the CAN messages included in the acquired one or more Ethernet packets, and when there are a plurality of CAN messages with the same message ID among the extracted plurality of CAN messages, transmitting some of the CAN messages with the same message ID and discarding other CAN messages. In-vehicle device.

2. When, in one or more of the acquired Ethernet packets, a single Ethernet packet includes a plurality of CAN messages with the same message ID, the control unit transmits the CAN message that is the last in the storage order in the Ethernet packet among the plurality of CAN messages with the same message ID, and discards other CAN messages. The in-vehicle device according to claim 1.

3. When there are CAN messages with the same message ID in each of the plurality of acquired Ethernet packets, the control unit transmits the CAN message included in any one of the plurality of Ethernet packets according to the number of receptions of the Ethernet packets, and discards the CAN messages included in other Ethernet packets. The in-vehicle device according to claim 1.

4. When an Ethernet packet is acquired before a predetermined non-transmission period elapses from the time when the CAN message included in the acquired Ethernet packet is transmitted, the control unit discards the CAN message included in the acquired Ethernet packet, and when an Ethernet packet is acquired after the non-transmission period has elapsed, the control unit transmits the CAN message included in the acquired Ethernet packet. The in-vehicle device according to claim 1.

5. The control unit refers to the stored values stored in the payloads of each of the CAN messages with the same message ID included in a plurality of the Ethernet packets acquired from the same source, transmits the CAN messages with different stored values from the stored value of the previously transmitted CAN message, and discards the CAN messages with the same stored value as the stored value of the previously transmitted CAN message. The in-vehicle device according to claim 1.

6. The control unit refers to the discard conditions of the CAN messages stored in the accessible storage area, and discriminates between the CAN messages to be transmitted and the CAN messages to be discarded according to the referred discard conditions. The in-vehicle device according to claim 1.

7. The control unit updates the discard conditions stored in the storage area by acquiring information regarding the discard conditions from an external server provided outside the vehicle. The in-vehicle device according to claim 6.

8. The device includes a storage unit including a plurality of reception buffers. The control unit acquires each of a plurality of Ethernet packets transmitted from a plurality of different sources using each of the plurality of reception buffers, and executes parallelization processing according to the number of sources by extracting a plurality of the CAN messages included in the Ethernet packets on the reception buffers. The in-vehicle device according to claim 1.

9. The device includes a plurality of CAN communication units for performing communication by CAN and a plurality of Ethernet communication units for performing communication by Ethernet. The control unit performs relay processing of CAN messages transmitted and received between the plurality of CAN communication units and relay processing of Ethernet packets transmitted and received between the plurality of Ethernet communication units. The in-vehicle device according to any one of claims 1 to 8.

10. The control unit determines whether the CAN message is included in the Ethernet packet based on the source address, destination address, port number, or information stored in the payload of the acquired Ethernet packet. When the CAN message is included in the Ethernet packet, the control unit performs processing related to transmission or discard for each of the plurality of CAN messages. When the CAN message is not included in the Ethernet packet, the control unit performs relay processing of the Ethernet packet based on predetermined routing information. The in-vehicle device according to claim 9.

11. A program for causing a computer connected to an in-vehicle network in which communication is performed using Ethernet and CAN to execute processing related to relaying data flowing through the in-vehicle network, where the data includes an Ethernet packet using the Ethernet and a CAN message using the CAN. The program causes the computer to acquire one or more Ethernet packets transmitted from the same source, extract a plurality of CAN messages included in the acquired one or more Ethernet packets, and when there are a plurality of CAN messages with the same message ID among the extracted plurality of CAN messages, transmit some of the CAN messages with the same message ID and discard the other CAN messages.

12. An information processing method for causing a computer connected to an in-vehicle network in which communication is performed using Ethernet and CAN to execute processing related to relaying data flowing through the in-vehicle network, where the data includes an Ethernet packet using the Ethernet and a CAN message using the CAN. The method includes acquiring one or more Ethernet packets transmitted from the same source, extracting a plurality of CAN messages included in the acquired one or more Ethernet packets, and when there are a plurality of CAN messages with the same message ID among the extracted plurality of CAN messages, transmitting some of the CAN messages with the same message ID and discarding the other CAN messages.

Images