On-vehicle device, program, and information processing method
Patent Information
- Authority / Receiving Office
- JP · JP
- Patent Type
- Applications
- Current Assignee / Owner
- AUTONETWORKS TECH LTD
- Filing Date
- 2023-12-25
- Publication Date
- 2026-06-09
AI Technical Summary
Existing in-vehicle devices fail to efficiently process multiple CAN messages included in Ethernet packets, leading to inefficiencies and potential communication overload when connected to networks using both Ethernet and CAN protocols.
An in-vehicle device with a control unit that acquires Ethernet packets, extracts CAN messages, and selectively transmits or discards messages with the same ID, employing methods such as prioritizing the latest message, managing reception counts, and using discard conditions to optimize communication.
This approach enhances communication efficiency by reducing redundant message transmission, managing communication load, and ensuring quality by selectively transmitting only necessary CAN messages.
Smart Images

Figure 00000000_0000_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to an in-vehicle device, a program, and an information processing method.
Background Art
[0002] Vehicles are equipped with an in-vehicle ECU (Electronic Control Unit) for controlling in-vehicle devices such as a power train system for engine control and a body system for air conditioner control. The in-vehicle ECU includes an arithmetic processing unit such as an MPU, a rewritable non-volatile storage unit such as a RAM, and a communication unit for communicating with other in-vehicle ECUs, and controls the in-vehicle devices by reading and executing a control program stored in the storage unit. Furthermore, a relay device having a wireless communication function is mounted on the vehicle (see, for example, Patent Document 1).
Prior Art Documents
Patent Documents
[0003]
Patent Document 1
Summary of the Invention
Problems to be Solved by the Invention
[0004] However, when the relay device of Patent Document 1 is connected to an in-vehicle network in which communication is performed using Ethernet and CAN, there is a problem that no consideration is given to processing such as transmission or discard of a plurality of CAN messages included in the acquired Ethernet packet.
[0005] An object of the present invention is to provide an in-vehicle device or the like that can efficiently perform processing such as transmission or discard on a plurality of CAN messages included in an acquired Ethernet packet when connected to an in-vehicle network in which communication is performed using Ethernet and CAN.
Means for Solving the Problems
[0006] An in-vehicle device according to one aspect of the present disclosure is an in-vehicle device 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 through the in-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 the CAN messages included in the acquired one or more Ethernet packets, and if there are a plurality of CAN messages with the same message ID among the extracted plurality of CAN messages, transmits some of the CAN messages with the same message ID and discards the other CAN messages.
Effects of the Invention
[0007] According to one aspect of the present disclosure, when connected to an in-vehicle network in which communication is performed using Ethernet and CAN, it is possible to provide an in-vehicle device or the like that efficiently performs processing such as transmission or discard on a plurality of CAN messages included in the acquired Ethernet packet.
Brief Description of the Drawings
[0008]
Figure 1
Figure 2
Figure 3
Figure 4
Figure 5
Figure 6
Figure 7
Figure 8
Figure 9
Figure 10
Figure 11
Mode for Carrying Out the Invention
[0009] [Description of Embodiments of the Present Disclosure] First, the embodiments of the present disclosure will be listed and described. Also, at least a part of the embodiments described below may be arbitrarily combined.
[0010] (1) An in-vehicle device according to an aspect of the present disclosure is 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 includes a control unit that performs processing related to relaying data flowing through the in-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 source, extracts 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, transmits some of the CAN messages with the same message ID and discards the other CAN messages.
[0011] In this aspect, the in-vehicle device is mounted on a vehicle and connected to an in-vehicle network in which communication is performed using Ethernet and CAN. The in-vehicle network includes an Ethernet segment in which communication is performed using a protocol such as TCP / IP via an Ethernet cable, and a CAN segment in which communication is performed using a protocol such as CAN (Controller Area Network) or CANFD (CAN with Flexible Data Rate) via a CAN bus. One or more in-vehicle ECUs (Eth nodes) that perform Ethernet communication are connected to the Ethernet segment (Ethernet network). One or more in-vehicle ECUs (CAN nodes) are connected to the CAN segment (CAN network). The in-vehicle device is communicably connected to these in-vehicle ECUs (Eth nodes) and in-vehicle ECUs (CAN nodes) via the in-vehicle network. The control unit of the in-vehicle device functions as an in-vehicle relay device by performing protocol conversion between in-vehicle ECUs with different communication protocols, and relaying the data transmitted from the in-vehicle ECU (Eth node) connected to Ethernet to the in-vehicle ECU (CAN node) connected to CAN. When the control unit of the in-vehicle device acquires an Ethernet packet from the in-vehicle ECU (Eth node) connected to Ethernet, it extracts a plurality of CAN messages included in the payload area of the Ethernet packet, thereby splitting (unpacking process) a plurality of CAN messages from a single Ethernet packet. That is, a plurality of CAN messages are packed in the Ethernet packet, and the packing form (pattern) may be, for example, in a form (pattern) compliant with AUTOSAR (registered trademark). The CAN header format packed in the Ethernet packet may be, for example, the Long Header (Full Header) format or the 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 in the order of the CANID area (4 bytes) at the head, the DLC area (4 bytes), and the payload area.The control unit of the in-vehicle device acquires one or more Ethernet packets transmitted from the same source, that is, 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 source of the Ethernet packet based on the source IP address (source address) included in the header of the Ethernet packet. When the control unit of the in-vehicle device acquires a plurality of Ethernet packets from the same in-vehicle ECU, these plurality of Ethernet packets may be acquired continuously in time series. The control unit of the in-vehicle device may group CAN messages for each message ID included in the header of the CAN message among a plurality of CAN messages extracted from one or more Ethernet packets acquired from the same in-vehicle ECU. As a result, one or more CAN message groups are 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 and discards the other CAN messages without transmitting them in a plurality of CAN messages (each CAN message group) with the same message ID. Therefore, in a plurality of CAN messages extracted (unpacked) from one or more Ethernet packets from the same source, if there are CAN messages with duplicate message IDs among these plurality of CAN messages, for example, only one CAN message is transmitted (relayed by protocol conversion) among the plurality of CAN messages with duplicate message IDs, and the other CAN messages are discarded without being transmitted (relayed). As a result, it becomes possible to efficiently perform processes such as transmission or discard on the plurality of CAN messages included in the acquired Ethernet packets, and it is possible to suppress the excessive retention of CAN messages in the in-vehicle device when performing protocol conversion and relay processing from Ethernet packets to CAN messages.Particularly, between Ethernet and CAN or CAN-FD, the throughput (communication bandwidth) is significantly different. That is, CAN etc. has a lower transfer speed than Ethernet. However, by suitably thinning out all CAN messages extracted (unpacked) from Ethernet packets and transmitting (relaying) only some of the CAN messages, efficient relaying processing can be performed while ensuring communication quality.
[0012] (2) In the in-vehicle device according to one aspect of the present disclosure, when a single Ethernet packet contains a plurality of CAN messages with the same message ID among the acquired one or more Ethernet packets, the control unit transmits the CAN message with the last storage order in the Ethernet packet among the plurality of 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 in-vehicle ECU (Eth node) may contain a plurality of CAN messages with the same message ID. At this time, the control unit of the in-vehicle device transmits at least the CAN message with the last storage order in the Ethernet packet, that is, the latest CAN message, among the plurality of CAN messages (CAN message group with the same message ID) including the same message ID, and discards other CAN messages. When the in-vehicle ECU (Eth node) stores (packs) a plurality of CAN messages in the payload area of a single Ethernet packet, it stores them from the front (front byte) of the payload area in the order in which the CAN messages were received (in the order of the oldest reception time). Therefore, the latest CAN message, that is, the CAN message with the latest reception time, is stored at the end of the payload area. Accordingly, when a plurality of CAN messages with the same message ID are stored in a single Ethernet packet, the control unit of the in-vehicle device can transmit the latest CAN message by transmitting (relaying) the CAN message at the end in the payload area. Note that the in-vehicle ECU (Eth node) may add (associate) a timestamp indicating the time point or time when the CAN message was received when storing (packing) the CAN message in the Ethernet packet. In this case, the control unit of the in-vehicle device may transmit the latest CAN message according to the timestamp attached to the unpacked individual CAN messages.
[0014] (3) In the in-vehicle device according to an aspect of the present disclosure, 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 messages 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 the other Ethernet packets.
[0015] In this aspect, when the control unit of the in-vehicle device acquires (receives) Ethernet packets containing CAN messages with the same message ID from the same in-vehicle ECU (Eth node) multiple times, each time the acquisition (each time of reception), the reception count is increased (counted up), and the reception count is associated with the ECU name of the in-vehicle ECU (Eth node) as the transmission source and the message ID, and stored in the storage unit of the in-vehicle device. Thereby, the control unit of the in-vehicle device can store or manage the reception count of the Ethernet packet containing the CAN message in the combination of the in-vehicle ECU (Eth node) that is the transmission source of the Ethernet packet and the message ID of the CAN message included in the Ethernet packet. The control unit transmits the CAN message at a predetermined frequency for each CAN message in the combination of these transmission sources and message IDs. For example, among the four receptions of the Ethernet packet containing the CAN message, the control unit transmits the CAN message at a predetermined frequency such as once. That is, when the remainder when the reception count (n) of the Ethernet packet containing the CAN message with the same message ID, which is transmitted from the same in-vehicle ECU (Eth node), is divided by a predetermined frequency constant (k) is 1, the unpacked CAN message may be transmitted, and when it is other than 1, the unpacked CAN message may be discarded.
[0016] (4) In the in-vehicle device according to one aspect of the present disclosure, when the control unit acquires an Ethernet packet before a predetermined non-transmission period elapses from the time when the CAN message included in the acquired Ethernet packet is transmitted, the CAN message included in the acquired Ethernet packet is discarded, and when the control unit acquires an Ethernet packet after the non-transmission period has elapsed, the CAN message included in the acquired Ethernet packet is transmitted.
[0017] In this aspect, the control unit of the in-vehicle device, starting from the transmission time point of the unpacked CAN message, until a predetermined non-transmission period elapses, even if an Ethernet packet including the CAN message at the transmission time point and a CAN message with the same message ID and the same transmission source is received, the CAN message included in the received Ethernet packet is discarded without being transmitted. Then, after the non-transmission period has elapsed, when the control unit of the in-vehicle device receives an Ethernet packet including the previous transmitted CAN message and a CAN message with the same message ID and the same transmission source, the CAN message included in the received Ethernet packet is unpacked and transmitted. In this way, when relaying the same type of CAN messages, that is, CAN messages with the same message ID and the same in-vehicle ECU (Eth node) as the transmission source, a non-transmission period is defined for each type of the CAN message, and the transmission process of the CAN message is not performed during the non-transmission period, so that it is possible to suppress the communication load from becoming excessive, ensure the communication quality, and perform efficient relay processing. The starting point of the non-transmission period is not limited to the transmission time point of the CAN message, and it may be the time point when the CAN message is stored (input) in the transmission queue used when transmitting the CAN message (queue input time point). By using such a transmission queue, it is possible to suppress the occurrence of resource competition in the CAN communication unit (such as a CAN transceiver) when, for example, a plurality of CAN messages are transmitted at once.
[0018] (5) In the 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 included in each of the plurality of Ethernet packets acquired from the same transmission source, transmits the CAN message with a stored value different from the stored value of the previously transmitted CAN message, and discards the 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 source (in-vehicle ECU) multiple times, each of the multiple continuously acquired Ethernet packets contains CAN messages with the same message ID (the same type of CAN message). When the control unit of the in-vehicle device determines that, in the same type of CAN messages continuously acquired from the same source (in-vehicle ECU), more precisely, in the multiple Ethernet packets containing the same type of CAN message, the stored value of the payload of the CAN message transmitted (relayed) last time is substantially the same as the stored value of the payload of the CAN message extracted (unpacked) this time, the CAN message extracted this time is discarded without being transmitted (relayed). When the stored value of the payload of the CAN message transmitted (relayed) last time is substantially different from the stored value of the payload of the CAN message extracted (unpacked) this time, the CAN message extracted this time is transmitted (relayed). As a result, even when Ethernet packets containing CAN messages with the same message ID (the same type of CAN message) are received multiple times continuously from the same source (in-vehicle ECU), it is possible to eliminate the need for transmitting (relaying) CAN messages with stored values substantially the same as the stored value of the payload of the CAN message transmitted (relayed) last time (thinning out), suppress the communication load from becoming excessive, ensure communication quality, and perform efficient relay processing. That is, by unpacking multiple Ethernet packets transmitted from the same source (in-vehicle ECU), even when there are multiple same-type CAN messages consecutive in time series, if the stored values of the payloads in these multiple CAN messages are substantially the same, only the CAN message extracted (unpacked) from the Ethernet packet acquired first can be transmitted (relayed). Therefore, when there are multiple same-type CAN messages consecutive in time series, if there is no change in the stored values of the payloads of these CAN messages, it is possible to avoid transmitting (relaying) the same CAN message with the same stored value repeatedly, ensure communication quality, and perform efficient relay processing.When the control unit of the in-vehicle device performs processing related to discarding CAN messages according to the identity of the stored value of the payload in this way, it counts the number of times of discarding (the number of discard times), and when the number of discard times exceeds or reaches a predetermined upper limit value (the discard upper limit value), it may be configured to transmit the CAN message that has reached the discard upper limit value. By unpacking the Ethernet packet in this way, when there are a plurality of the same type of CAN messages continuous in time series, since there is no change in the stored value of the payload of these CAN messages (substantially the same stored value continues), if the discarding of the CAN messages is continued, there is a concern that it may affect the processing of the in-vehicle ECU (CAN node) at the transmission destination of the CAN message. On the other hand, even when substantially the same stored value continues, by transmitting the CAN message when the discard upper limit value is reached, it is possible to prevent the CAN message from being discarded beyond the discard upper limit value, and it is possible to ensure communication quality and perform efficient relay processing.
[0020] (6) In the in-vehicle device according to one aspect of the present disclosure, the control unit refers to the discard condition of the CAN message stored in the accessible storage area, and discriminates between the CAN message to be transmitted and the CAN message to be discarded according to the referred discard condition.
[0021] In this aspect, in a storage unit of an in-vehicle device or a storage area accessible from a control unit of the in-vehicle device, information defining discard conditions for CAN messages is stored, for example, in a table format (relay setting table). In the relay setting table, for example, for each type of CAN message (each type defined by a combination of a transmission source and a CAN message), discard conditions (relay settings) corresponding to the type of the corresponding CAN message are stored. The discard conditions (relay settings) may include, for example, conditions such as a relay frequency according to the number of reception times, a non-transmission period from the previous transmission time, discard of duplicate frames (CAN messages with the same message ID) included in the same Ethernet packet, or discard based on the identity of stored values in the payload. The control unit of the in-vehicle device can efficiently grasp any discard condition (relay setting) corresponding to each of the CAN messages or a combination of a plurality of discard conditions with respect to the CAN messages extracted (unpacked) from the acquired Ethernet packet by referring to the relay setting table.
[0022] (7) In the in-vehicle device according to one aspect of the present disclosure, 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.
[0023] In this aspect, the in-vehicle device is communicably connected to an external server provided outside the vehicle. When the in-vehicle device acquires campaign information indicating the distribution of an update program from the external server, the in-vehicle device acquires the update program and functions as a control device that performs reprogramming processing related to the transmission and activation of the update program for in-vehicle ECUs that require program updates. When the in-vehicle device acquires campaign information or the like from the external server in this way, the in-vehicle device acquires information regarding discard conditions (relay setting table) from the external server as necessary. The in-vehicle device updates the discard conditions (relay setting table) stored in the storage unit using the information regarding the discard conditions (relay setting table) from the external server. In this way, as part of the reprocessing such as acquiring the update program to be applied to the in-vehicle ECU or the like, the in-vehicle device can flexibly respond to, for example, design changes or variation deployment for the in-vehicle system by also acquiring and updating the discard conditions (relay setting table), and can improve the usability according to the types and functions of the in-vehicle ECUs to be mounted on the vehicle.
[0024] (8) In the in-vehicle device according to one aspect of the present disclosure, the in-vehicle 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 transmission sources using each of the plurality of reception buffers, and extracts a plurality of the CAN messages included in the Ethernet packet on the reception buffer, thereby executing parallelization processing according to the number of transmission sources.
[0025] In this aspect, the storage unit of the in-vehicle device includes a plurality of reception buffers determined in advance according to the number of transmission sources. That is, in the storage unit, areas corresponding to these reception buffers are secured. The number of the reception buffers is two or more, and may be the same as the number of in-vehicle ECUs (Eth nodes) that are transmission sources of Ethernet packets. In this case, reception buffers may be provided corresponding to each of the in-vehicle ECUs (Eth nodes) that are transmission sources of Ethernet packets. When the control unit of the in-vehicle device sequentially acquires Ethernet packets from a plurality of in-vehicle ECUs (Eth nodes), it stores the individual Ethernet packets in different reception buffers, and on these reception buffers, it parallelizes and executes the process of extracting (unpacking) CAN messages from the individual Ethernet packets (executes parallelization processing). At this time, the control unit has hardware resources such as multi-core or multi-CPU, for example, and is configured to be capable of handling parallelization processing, and the number of cores or CPUs may be equal to or more than the number of reception buffers. The control unit of the in-vehicle device may store (input) the CAN messages extracted (unpacked) by such parallelization processing in the transmission queue in the order of extraction. The transmission queue may be configured as a software functional unit by the control unit executing a queuing program, or may be configured as a hardware functional unit implemented by an FPGA or ASIC included in a CAN communication unit such as a CAN controller. By using a plurality of reception buffers in this way and executing the unpacking in a plurality of Ethernet packets by parallelization processing, the control unit of the in-vehicle device can shorten the lead time (elapsed time) required for processing each Ethernet packet, and can reduce the transmission waiting time in the transmission (relay) of CAN messages.
[0026] (9) In an in-vehicle device according to an aspect of the present disclosure, the in-vehicle device includes a plurality of CAN communication units for performing communication via CAN, and a plurality of Ethernet communication units for performing communication via Ethernet. The control unit performs relay processing of CAN messages transmitted and received between the plurality of CAN communication units, and performs 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 performs relay processing of CAN messages transmitted and received between the plurality of CAN communication units and functions as a CAN relay unit. Further, the control unit of the in-vehicle device performs relay processing of 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, and also functions 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. By implementing in the in-vehicle device a function of relaying data of each protocol and also performing protocol conversion in an in-vehicle network where different protocols (CAN, Ethernet (TCP / IP)) coexist, the processing related to relay can be aggregated in the in-vehicle device, and the number of devices mounted on the vehicle can be reduced.
[0028] In an in-vehicle device according to one aspect of the present disclosure, 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, processing related to transmission or discard is performed for each of the plurality of CAN messages. When the CAN message is not included in the Ethernet packet, relay processing of the Ethernet packet is performed based on predetermined routing information.
[0029] In this aspect, the control unit of the in-vehicle device determines whether the acquired Ethernet packet contains (packs) a plurality of CAN messages (unpacking frame determination) 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. The storage unit of the in-vehicle device stores setting information or a parameter sheet for defining an Ethernet packet that packs a plurality of CAN messages by means of a port number or the like, and the control unit of the in-vehicle device can perform the determination by referring to the parameter sheet or the like. Alternatively, the control unit of the in-vehicle device may determine whether a plurality of CAN messages are stored (packed) in the payload by referring to the information stored in the payload of the acquired Ethernet packet. When the control unit of the in-vehicle device determines that a plurality of CAN messages are included (packed) in the Ethernet packet, for example, according to the discard conditions (relay setting table), a series of processes related to protocol conversion and relay (unpacking process, etc.) are performed by transmitting or discarding each of the plurality of CAN messages. When the control unit of the in-vehicle device determines that a plurality of CAN messages are not included (packed) in the Ethernet packet, the relay process of the Ethernet packet is performed based on the predetermined routing information without performing the process related to protocol conversion (unpacking process, etc.) on the Ethernet packet. The relay process of the Ethernet packet based on the routing information is not limited to the relay process from the Ethernet communication unit that received the Ethernet packet to another Ethernet communication unit. For example, when it is determined that relay is not required according to the routing information, the process of discarding the received Ethernet packet is also included. Thus, even when the control unit of the in-vehicle device receives a large number of Ethernet packets, the processing load can be reduced because a series of processes related to protocol conversion (unpacking process, etc.) are performed only on the Ethernet packets that pack CAN messages.
[0030] (11) A program according to an aspect of the present disclosure is a program that causes 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. The data includes an Ethernet packet using the Ethernet and a CAN message using the CAN. The program acquires one or more of the Ethernet packets transmitted from the same source, extracts a plurality of the CAN messages included in the acquired one or more of the Ethernet packets, and when there are a plurality of CAN messages with the same message ID among the extracted plurality of CAN messages, the program causes the computer to execute a process of transmitting some of the CAN messages with the same message ID and discarding the other CAN messages.
[0031] In this aspect, it is possible to provide a program that causes a computer, when connected to an in-vehicle network in which communication is performed using Ethernet and CAN, to function as an in-vehicle device that efficiently performs processing such as transmission or discard on a plurality of CAN messages included in the acquired Ethernet packets.
[0032] (12) An information processing method according to an 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 execute processing related to relaying data flowing through the in-vehicle network. The data includes an Ethernet packet using the Ethernet and a CAN message using the CAN. The information processing method acquires one or more of the Ethernet packets transmitted from the same source, extracts a plurality of the CAN messages included in the acquired one or more of the Ethernet packets, and when there are a plurality of CAN messages with the same message ID among the extracted plurality of CAN messages, the information processing method causes the computer to execute a process of transmitting some of the CAN messages with the same message ID and discarding the other CAN messages.
[0033] In this aspect, when a computer is connected to an in-vehicle network where communication is performed using Ethernet and CAN, it is possible to provide an information processing method that causes the computer to function as an in-vehicle device that efficiently processes a plurality of CAN messages included in acquired Ethernet packets, such as transmission or discard.
[0034] [Details of Embodiments of the Present Disclosure] The present disclosure will be specifically described based on the drawings showing its embodiments. The in-vehicle device 2 according to the embodiment 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 shown by the claims, and is intended to include all modifications within the meaning and scope equivalent to the claims.
[0035] (Embodiment 1) Hereinafter, embodiments 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 the in-vehicle device 2. The in-vehicle system S includes 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 communicably connected to each of the plurality of in-vehicle ECUs 3 via the in-vehicle network 4. The in-vehicle device 2 relays communication between the plurality of in-vehicle ECUs 3 mounted on the vehicle. Further, the in-vehicle device 2 may communicate with an external server 100 connected to an external network via an out-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 switched telephone network. Information regarding an update program to be applied to the in-vehicle ECU 3 or a relay setting table described later may be stored in the storage unit of the external server 100.
[0037] The in-vehicle network 4 is composed of a plurality of communication lines 41 including an Ethernet cable 411 or a CAN bus 412. That is, the in-vehicle network 4 includes an Ethernet segment where communication using, for example, the TCP / IP protocol is performed via the Ethernet cable 411, and a CAN segment where communication using, for example, the CAN (Controller Area Network) or CANFD (CAN with Flexible Data Rate) protocol is performed via the CAN bus 412.
[0038] One or more in-vehicle ECUs 3 (Eth nodes) that perform Ethernet communication are connected to the Ethernet segment (Ethernet network). One or more in-vehicle ECUs 3 (CAN nodes) that perform CAN communication are connected to the 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 a plurality of in-vehicle ECUs 3 (Eth nodes) connected to the Ethernet segment. Further, 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 a plurality of in-vehicle ECUs 3 (CAN nodes) connected to the CAN segment. Furthermore, the in-vehicle device 2 functions as a protocol conversion unit (CAN-Eth relay unit) that performs protocol conversion and relaying between in-vehicle ECUs 3 (between Eth nodes and CAN nodes) with different communication protocols between CAN and Ethernet. In this way, the control unit 20 of the in-vehicle device 2 functions as an Ethernet relay unit, a CAN relay unit, and a protocol conversion unit by executing a program stored in the storage unit 21. These Ethernet relay unit, CAN relay unit, and protocol conversion unit correspond to software functional units by executing a relay application (GW application) included in the program.
[0040] In addition, in the functions performed by the Ethernet relay unit and the CAN relay unit, for example, with regard to processing related to the data link layer, it may be executed not by software processing by the control unit 20 but 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. In the present embodiment, the Ethernet relay unit, the CAN relay unit, and the protocol conversion unit are configured to be mounted on the in-vehicle device 2 configured as a single device, but the present invention is not limited to this. Each of the Ethernet relay unit, the CAN relay unit, and the protocol conversion unit may be mounted on a separate in-vehicle device 2, and the in-vehicle devices 2 implementing these respective functional units may be communicably connected. In this case, centering on the in-vehicle device 2 implementing the protocol conversion unit, each of 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 be connected to the in-vehicle device 2 implementing the protocol conversion unit.
[0041] The vehicle external communication device 1 includes a vehicle external communication unit (not shown) and an input / output I / F for communicating with the in-vehicle device 2. The vehicle external communication unit is a communication device for performing wireless communication using a protocol of mobile communication such as 4G, LTE (Long Term Evolution), 5G, WiFi, etc., and transmits and receives data to and from the external server 100 via an antenna 11 connected to the vehicle external communication unit. Communication between the vehicle external communication device 1 and the external server 100 is performed via an external network such as a public line network or the Internet, for example. The input / output I / F is a communication interface for performing serial communication with the in-vehicle device 2, for example. The vehicle external 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 the present embodiment, the vehicle external communication device 1 is a separate device from the in-vehicle device 2, and these devices are communicably connected by the input / output I / F or the like, but the present invention is not limited to this. The vehicle external communication device 1 may be incorporated in the in-vehicle device 2 as a constituent part 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 function of power distribution in addition to the relay function of data communication, or an integrated ECU having a relay function and integrally controlling the entire vehicle C. The in-vehicle device 2 may be configured as a functional part of a body ECU that controls all body system actuators. The in-vehicle device 2 is configured to acquire an update program received by the out-vehicle communication device 1 from the external server 100 by wireless communication from the out-vehicle communication device 1, 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), an MPU (Micro Processing Unit), etc., and performs various control processes, arithmetic processes, etc. by reading and executing a program P and data pre-stored in the storage unit 21.
[0044] The storage unit 21 is composed of 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 a program P and data to be referred to during processing in advance. The program P stored in the storage unit 21 may store the 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. A relay setting table, etc., which will be described later, is stored in the storage unit 21.
[0045] The storage unit 21 stores relay route information (routing table) used for performing relay processing for communication between in-vehicle ECUs 3 or for communication between an in-vehicle ECU 3 and an 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 (CAN ID) included in a CAN message and a relay destination (I / O port number of the CAN communication unit 232) associated with the CAN ID. 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 an IP packet and a relay destination (physical port number of the Ethernet communication unit 231) associated with the destination address.
[0046] The input / output I / F 22 is a communication interface for serial communication, for example, similar to the input / output I / F of the vehicle external communication device 1. The in-vehicle device 2 is connected to the vehicle external communication device 1 via the input / output I / F 22. The connection between the in-vehicle device 2 and the vehicle external communication device 1 may be made 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) using a communication protocol such as CAN (Control Area Network), CAN-FD (CAN with Flexible Data Rate), or Ethernet (Ethernet / Registered Trademark). The control unit 20 communicates with in-vehicle devices such as an 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 corresponding to TCP / IP packets transmitted via an Ethernet cable 411 such as 100BASE-T1 or 1000BASE-T1.
[0049] The CAN communication unit 232 complies with the communication protocol of CAN or CAN-FD, corresponds to the CAN messages transmitted on the CAN bus 412, receives the waveform due to the potential difference of the differential voltage on the CAN bus 412 composed of two wires on the high side and the low side, and decodes the received waveform into a signal represented by a bit string of 1 and 0, which is a CAN transceiver or a CAN-FD transceiver. Alternatively, the 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 each communication line 41 (Ethernet cable 411, CAN bus 412) constituting the in-vehicle network 4, that is, each bus. By providing a plurality of in-vehicle communication units 23 in this way, the in-vehicle network 4 can be divided into a plurality of segments, and the in-vehicle ECU 3 can 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 in the same manner as the in-vehicle device 2. The storage unit is composed of 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 the program or data of the in-vehicle ECU 3. The in-vehicle communication unit includes an Ethernet communication unit or a CAN communication unit in the same manner as 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 that performs Ethernet communication and a CAN node that performs CAN communication.
[0052] FIG. 3 is an explanatory diagram illustrating data (frame format) flowing through in - vehicle network 4. The data flowing through in - vehicle network 4 includes Ethernet packets (Eth frames) using Ethernet and CAN messages (CAN frames) using CAN. In in - vehicle network 4, Ethernet packets are transmitted and received in an Ethernet segment (Ethernet network) constituted by Ethernet cable 411. In in - vehicle network 4, CAN messages are transmitted and received in a CAN segment (CAN network) constituted by CAN bus 412.
[0053] The frame format of an Ethernet packet is defined by a communication standard such as IEEE802.3, etc., and includes areas such as a header, a payload, and FCS (Frame Check Sequence). The header area (header part) is subdivided by the communication standard, and various header information such as the source address and destination address in the IP address and MAC address, and port numbers (UDP port number or TCP port number) are stored. An Ethernet packet packing a plurality of CAN messages stores these plurality of CAN messages in the payload area. In the payload area of an Ethernet packet that does not pack a plurality of CAN messages, that is, an Ethernet packet transmitted and received between in - vehicle ECUs 3 (Eth nodes) connected to Ethernet cable 411, content data corresponding to the use of the Ethernet packet is stored.
[0054] The frame format of a CAN message is defined by a communication standard such as ISO11898 - 3, etc., and includes areas such as a header (header part) and a payload. The header area is subdivided by the communication standard and includes a CANID area and a DLC area. A message ID (CANID) is stored in the CANID area. The data length of the CAN message is stored in the DLC area.
[0055] FIG. 4 is a flowchart illustrating the processing (duplicate frames) of the control unit 20 of the in-vehicle device 2. The control unit 20 of the in-vehicle device 2 constantly performs the following processing, for example, when the vehicle C is in the start state (IG switch is on) or the stop 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) configured by an Ethernet cable 411. The control unit 20 of the in-vehicle device 2 acquires (receives) the data flowing through the in-vehicle network 4 (Ethernet network) and transmitted from the in-vehicle ECU 3 operating as an Eth node via the Ethernet communication unit 231.
[0057] The control unit 20 of the in-vehicle device 2 extracts a plurality of 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 executes an unpacking process on the packed CAN messages by extracting the plurality of CAN messages stored in the payload area of the Ethernet packet. The control unit 20 of the in-vehicle device 2 stores each of the extracted (unpacked) plurality of 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 the plurality of CAN messages (frames) stored (packed) in the Ethernet packet, each CAN message is assigned (stored in the header) a message ID. In the message IDs of each of these plurality of CAN messages, it is assumed that there are a plurality of CAN messages with the same message ID (CAN messages with duplicate message IDs). That is, the plurality of CAN messages stored in a single Ethernet packet are classified into one or more CAN message groups according to the identity of the message ID.
[0059] The control unit 20 of the in-vehicle device 2 may classify or group a plurality of CAN messages with the same message ID as a CAN message group. The control unit 20 of the in-vehicle device 2 executes the following processing for each of one or more CAN message groups classified (grouped) in this way, so that only the latest CAN message is transmitted and other CAN messages are discarded in each of the CAN message groups, that is, a thinning process of CAN messages may be executed.
[0060] The control unit 20 of the in-vehicle device 2 identifies the CAN message with the latest value among a plurality of CAN messages with overlapping message IDs (S104). The control unit 20 of the in-vehicle device 2 identifies the CAN message having the latest value (stored in the payload) among these plurality of CAN messages in a plurality of CAN messages with overlapping message IDs, that is, a CAN message group formed according to the identity of the message IDs.
[0061] FIG. 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) the CAN message and identifies frames with overlapping IDs (CAN messages with the same message ID). In the illustration of the present embodiment, among the CAN messages (frames) stored (packed) in the Ethernet packet, four CAN messages (frames A, B, C, D) are CAN messages (frames) with overlapping message IDs, that is, CAN messages (CAN message group) with the same message ID.
[0062] In a plurality of CAN messages (frames) with duplicate message IDs, that is, a plurality of CAN messages (frames) containing the same message ID, the CAN message (frame) in which the latest value is stored in the payload is stored at the end (the last part) in the payload of the Ethernet packet. Or, in the case of an Ethernet packet in which the CAN message storing the latest value is stored at the head (the foremost part), the control unit 20 of the in-vehicle device 2 may specify the CAN message stored at the head (the foremost part) as the CAN message with the latest value. Or, when the in-vehicle ECU 3 (Eth node) stores (packs) the CAN message into the Ethernet packet and packs it by attaching (associating) a time stamp indicating the time point or time when the CAN message was received or generated, the control unit 20 of the in-vehicle device 2 may specify the CAN message with the latest value according to the time stamp attached to the unpacked individual CAN messages. The control unit 20 of the in-vehicle device 2 may specify the CAN message with the latest value based on the storage order of the CAN messages defined in advance according to the type of the Ethernet packet, such as the port number or the source address of the Ethernet packet.
[0063] The control unit 20 of the in-vehicle device 2 holds only the CAN message (frame) with the latest value and discards (erases from the storage unit 21) other CAN messages. The control unit 20 of the in-vehicle device 2 may reconstruct the data stored in the payload of the Ethernet packet including the CAN message as a preprocess before transmitting the CAN message with the latest value.
[0064] In the illustration in this embodiment, four CAN messages (Frames A, B, C, D) are frames with overlapping IDs (CAN messages with the same message ID), and for other CAN messages, the message IDs are individually different (not frames with overlapping IDs). At this time, the control unit 20 of the in-vehicle device 2 stores the CAN message (Frame D), which is the latest value, at the position of the CAN message (Frame A) located at the forefront (beginning) among the CAN messages (Frames A, B, C) to be thinned out in the payload of the Ethernet packet, thereby reconstructing the data stored in the payload of the Ethernet packet. That is, the control unit 20 of the in-vehicle device 2 may move the CAN message (Frame D), which is the latest value, to the storage position of the CAN message (Frame A) located at the forefront (beginning) in the payload of the Ethernet packet, and perform a relaying process from the forefront (beginning) of the payload. At that time, the control unit 20 of the in-vehicle device 2 can shorten the data length (frame length) of the payload of the Ethernet packet by deleting the CAN messages (Frames A, B, C) to be thinned out, thereby improving the communication efficiency.
[0065] When the control unit 20 of the in-vehicle device 2 reconstructs 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 area of frame D in the payload of the Ethernet packet may be shifted (expanded) to the right (towards the end side) so that the CAN message (frame D) can be stored. If the length of the CAN message (frame A) is larger than the length of the CAN message (frame D) (A > D), the area of frame D in the payload of the Ethernet packet may be shrunk towards the head side by packing the remaining part when the CAN message (frame D) is stored. In this way, even when the data lengths of the CAN message to be relayed and the CAN message to be discarded (thinned out) because it is not the latest value are different, by changing the storage area in the payload of the Ethernet packet, the difference in the data lengths can be efficiently handled.
[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 CAN message with the latest value among a plurality of CAN messages with duplicate message IDs via the Ethernet communication unit 231. Thereby, only the CAN message with the latest value can be transmitted among a plurality of CAN messages stored (packed) in a single Ethernet packet and having duplicate message IDs (identical message IDs). 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) 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 other CAN messages other than the CAN message with the latest value among a plurality of CAN messages with duplicate message IDs (S106). As described above, in a plurality of CAN messages stored (packed) in a single Ethernet packet and having duplicate message IDs (identical message IDs), CAN messages other than the latest value are discarded without being transmitted (relayed). The control unit 20 of the in-vehicle device 2 may determine whether or not 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, the CAN message to be transmitted (relayed) is only the CAN message with the latest value, but it is not limited thereto. For example, in a plurality of CAN messages with duplicate message IDs, the oldest CAN message may be discarded, that is, targeted for thinning, and other CAN messages may be transmitted (relayed). The storage unit 21 of the in-vehicle device 2 stores setting information regarding the thinning degree of CAN messages corresponding to each message ID, and the control unit 20 of the in-vehicle device 2 may determine the CAN message to be targeted for thinning corresponding to each individual message ID based on the setting information regarding the thinning degree.
[0069] (Embodiment 2) FIG. 6 is a flowchart illustrating the processing (relay setting table) of the control unit 20 of the in-vehicle device 2 according to Embodiment 2. The control unit 20 of the in-vehicle device 2 constantly performs the following processing, for example, when the vehicle C is in the start state (IG switch is on) or the stop 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 the 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 in the same manner as the processes from S101 to S102 in Embodiment 1. The control unit 20 of the in-vehicle device 2 acquires (receives) Ethernet packets from a plurality of in-vehicle ECUs 3 (Eth nodes) via a plurality of Ethernet communication units 231.
[0071] At this time, the control unit 20 of the in-vehicle device 2 may perform the following processes for each in-vehicle ECU 3 (Eth node) that is the transmission source. Based on the source address (source IP address, source MAC address) included in the header of the Ethernet packets transmitted from each of these plurality of in-vehicle ECUs 3 (Eth nodes), the control unit 20 of the in-vehicle device 2 classifies or categorizes the received plurality of Ethernet packets, and executes a series of processes in this flowchart for the Ethernet packets with the same source address. At that time, the control unit 20 of the in-vehicle device 2 may generate, for example, a plurality of sub-processes according to the number of in-vehicle ECUs 3 (Eth nodes) that are the source of the Ethernet packets, and by using the plurality of sub-processes, execute the processes for each of the in-vehicle ECUs 3 (Eth nodes) that are the source in parallel (parallel processing).
[0072] Each time the control unit 20 of the in-vehicle device 2 acquires (receives) an Ethernet packet, it associates the reception time point and stores the Ethernet packet in the storage unit 21. As a result, the control unit 20 of the in-vehicle device 2 can grasp or manage chronological matters such as the order according to the reception time point for a plurality of Ethernet packets transmitted from the in-vehicle ECU 3 (Eth node) of the same transmission source. That is, the control unit 20 of the in-vehicle device 2 can grasp the reception time point, reception order, and reception count in a plurality of continuously received Ethernet packets from the in-vehicle ECU 3 (Eth node) of the same transmission source by referring to the storage unit 21. Further, the control unit 20 of the in-vehicle device 2 may also store the transmission time point (or the input time point to the transmission queue) of the unpacked CAN message in the storage unit 21 together with the CAN message.
[0073] The control unit 20 of the in-vehicle device 2 specifies the discard condition for the CAN message by referring to the relay setting table (S203). The control unit 20 of the in-vehicle device 2 refers to the relay setting table stored in the storage unit 21 based on the transmission source address (transmission source node) of the acquired Ethernet packet and the message ID (received CAN ID) of the CAN message stored in the payload of the Ethernet packet (unpacked CAN message) to specify (derive) the discard condition (relay setting) for the CAN message.
[0074] FIG. 7 is an explanatory diagram illustrating a relay setting table. In the storage unit 21 of the in-vehicle device 2, information defining the discard condition of the CAN message, that is, the determination criterion for transmission or discard in performing the thinning process, is stored in, for example, a table format (relay setting table). The relay setting table includes, as management items (fields), an item for the transmission source node, an item for the received CAN ID, an item for the relay frequency count, an item for the relay frequency time, an item for the stored value of the payload, and an item for duplicate frame discard.
[0075] In the item of the received CAN ID, all the numerical values used as the CAN ID (message ID) of the CAN message are stored. In the item of the source node, an identifier such as a node name that uniquely identifies the in-vehicle ECU 3 (Eth node), which is the source of the Ethernet packet for the CAN message, or a source address (source IP address, source MAC address) may be stored. The type of the CAN message is determined by the combination of the item of the source node and the item of the received CAN ID.
[0076] In the item of the relay frequency count, a setting value for whether to perform decimation processing according to the number of received Ethernet packets is stored for the corresponding type of CAN message (combination of the source node and the received CAN ID). The setting value is stored as, for example, 4 times. In this case, among the 4 received times, the CAN message of the corresponding type (combination of the source node and the received CAN ID) is transmitted at a frequency of 1 time.
[0077] In the item of the relay frequency time, a setting value for whether to apply a process of not transmitting the next CAN message until a predetermined time (non-transmission period) has elapsed since the time when the previous CAN message was transmitted (transmission time) is stored for the corresponding type of CAN message (combination of the source node and the received CAN ID). The setting value is stored as, for example, 1 second. In this case, until 1 second set as the non-transmission period has elapsed since the transmission time (or the time of input to the transmission queue) of the previous CAN message, a process of discarding without transmitting the next CAN message is performed.
[0078] In the item of the stored value of the payload, for the type of the corresponding CAN message (combination of the transmission source node and the reception CAN ID), when the stored values of the payloads of the previously transmitted CAN message and the currently unpacked CAN message are the same, a setting value is stored as to whether or not to apply the process of not transmitting the current CAN message. The setting value is defined, for example, by two values of "yes" or "no". When it is "yes", thinning processing based on the identity of the stored value of the payload is applied, and when it is "no", the thinning processing is not applied.
[0079] In the item of duplicate frame discard, for the type of the corresponding CAN message (combination of the transmission source node and the reception CAN ID), for the frame with duplicate IDs (CAN message with the same message ID) described in Embodiment 1, a setting value is stored as to whether or not to apply the process of not transmitting the CAN message. The setting value is defined, for example, by two values of "yes" or "no". When it is "yes", thinning processing for the frame with duplicate IDs is applied, and when it is "no", the thinning processing is not applied.
[0080] As described above, the items of the relay frequency count, the relay frequency time, the stored value of the payload, and the duplicate frame discard are matters for determining the discard conditions (relay settings). For any type of CAN message (combination of the transmission source node and the reception CAN ID), one or more discard conditions (relay settings) may be set. For the type of CAN message (combination of the transmission source node and the reception CAN ID) for which a plurality of discard conditions (relay settings) are set, by applying all of the set plurality of discard conditions, the relay frequency can be further reduced as compared with the case of setting a single discard condition (relay setting).
[0081] The control unit 20 of the in-vehicle device 2 executes relay processing for CAN messages according to the specified discard conditions (S204). The control unit 20 of the in-vehicle device 2 performs relay processing specified according to the type of CAN message (combination of the transmission source node and the message ID), that is, transmission or discard according to the discard conditions, based on the content defined in the relay setting table. In the present embodiment, each of the discard conditions (relay settings) defined in the relay setting table will be described as follows. The present embodiment describes three modes as discard conditions (relay settings), and the processing in each mode may be executed as a subroutine of processing S204. The control unit 20 of the in-vehicle device 2 may perform, for example, branch processing defined in a case statement or the like when performing relay processing according to the type of CAN message (combination of the transmission source node and the message ID).
[0082] FIG. 8 is a flowchart illustrating the processing (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 reception count according to the type of the unpacked CAN message (combination of the transmission source node and the received CAN ID).
[0083] The control unit 20 of the in-vehicle device 2 acquires the reception count of the Ethernet packet at the current time (K01). Each time the control unit 20 of the in-vehicle device 2 acquires (receives) an Ethernet packet containing the target CAN message, it updates by increasing (counting up) the reception count, and stores the reception count of the Ethernet packet at the current time in the storage unit 21. At this time, the control unit 20 of the in-vehicle device 2 may count (measure) the reception count of the Ethernet packet containing the CAN message for each type of CAN message (type according to the combination of the transmission source and the message ID). The control unit 20 of the in-vehicle device 2 may store the reception count counted for each type of CAN message, for example, in the relay setting table. Thereby, the reception count for each type of CAN message at the current time can be efficiently managed.
[0084] The control unit 20 of the in-vehicle device 2 determines whether to transmit based on the number of receptions (K02). The control unit 20 of the in-vehicle device 2 obtains the transmission frequency (relay frequency), that is, how many times to transmit once, by referring to the relay setting table. In the relay setting table, for each type of CAN message (type based on the combination of the transmission source and the message ID), it is defined whether to perform decimation processing according to the number of receptions. In the case of a type of CAN message for which decimation processing according to the number of receptions is not performed, the control unit 20 of the in-vehicle device 2 determines to transmit.
[0085] In the case of a type of CAN message for which decimation processing according to the number of receptions is performed, the control unit 20 of the in-vehicle device 2 determines whether to transmit based on the current number of receptions using the value (for example, 4 times) stored in the item of the relay frequency number. For example, when the remainder is 1 when the current number of receptions (n) of the control unit 20 of the in-vehicle device 2 is divided by the value (frequency constant: k) stored in the item of the relay frequency number, it may be determined to transmit, and in other cases where the remainder is not 1, it may be determined not to transmit. Thereby, when the value (frequency constant: k) stored in the item of the relay frequency number is 4 times, the CAN message is transmitted at a frequency of once every 4 times, and the other three CAN messages are discarded.
[0086] When it is determined to transmit (K02: YES), the control unit 20 of the in-vehicle device 2 transmits the CAN message to which the specified discard condition is applied (K03). When it is determined to transmit based on the number of receptions, the control unit 20 of the in-vehicle device 2 transmits (relays) the CAN message to which the discard condition specified by referring to the relay setting table is applied.
[0087] When it is determined not to transmit (K02: NO), the control unit 20 of the in-vehicle device 2 discards the CAN message to which the specified discard condition applies (K04). When it is determined not to transmit based on the number of reception times, the control unit 20 of the in-vehicle device 2 discards, without transmitting (relaying), the CAN message to which the discard condition specified by referring to the relay setting table applies. The control unit 20 of the in-vehicle device 2 may initialize the counted number of reception times to 0 or the like, for example, at the timing of stopping or starting the vehicle C.
[0088] FIG. 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 thinning processing based on the elapsed time according to the type of the unpacked CAN message (combination of the transmission 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 time (J01). Each time the control unit 20 of the in-vehicle device 2 transmits the unpacked CAN message, the control unit 20 associates the transmission time 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 time to the current time in the CAN message of the type (combination of the transmission source node and the 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 or not based on the elapsed time (J02). The control unit 20 of the in-vehicle device 2 acquires the non-transmission period indicating how much time has elapsed from the previous transmission time or the time of input to the transmission queue until transmission by referring to the relay setting table. In the relay setting table, for each type of CAN message (type based on the combination of the transmission source and the message ID), it is defined whether to execute thinning processing according to the elapsed time. In the case of a type of CAN message for which thinning processing according to the elapsed time is not executed, the control unit 20 of the in-vehicle device 2 determines to transmit.
[0091] In the case of the type of CAN message that performs thinning processing according to the elapsed time, the control unit 20 of the in-vehicle device 2 determines whether to transmit based on the elapsed time up to the current time using the value stored in the item of the relay frequency time (for example, 1 second: non-transmission period). The control unit 20 of the in-vehicle device 2 may determine to transmit when the non-transmission period is 1 second and the elapsed time from the previous transmission time to the current time exceeds 1 second, and may determine not to transmit when it does not exceed 1 second. Thereby, the control unit 20 of the in-vehicle device 2 can eliminate the need to transmit (relay) the CAN message included in the Ethernet packet received during the non-transmission period.
[0092] When it is determined to transmit (J02: YES), the control unit 20 of the in-vehicle device 2 transmits the CAN message to which the specified discard condition is applied (J03). When it is determined to transmit based on the elapsed time, the control unit 20 of the in-vehicle device 2 transmits (relays) the CAN message to which the discard condition specified by referring to the relay setting table is applied.
[0093] When 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 is applied (J04). When 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 discard condition specified by referring to the relay setting table is applied without transmitting (relaying).
[0094] FIG. 10 is a flowchart illustrating the processing (payload stored value) 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 value of the payload according to the type of the unpacked CAN message (combination of the transmission 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). Each time the control unit 20 of the in-vehicle device 2 transmits an unpacked CAN message, it associates the transmission time point with the message ID of the transmitted CAN message and the stored value of the payload, and stores them 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 is the same as the currently extracted stored value (P02). The control unit 20 of the in-vehicle device 2 refers to the storage unit 21 to compare the stored values of the payloads of these CAN messages in the currently extracted CAN message and CAN messages of the same type (the combination of the transmission source node and the received CAN ID) as this CAN message, and determines whether these two stored values are substantially the same.
[0097] If they are not the same (P02: NO), the control unit 20 of the in-vehicle device 2 transmits the CAN message to which the specified discard condition applies (P03). If they are not the same, that is, if the two compared stored values are substantially different, the control unit 20 of the in-vehicle device 2 transmits (relays) the CAN message to which the discard condition specified by referring to the relay setting table applies, that is, the currently unpacked CAN message.
[0098] If they are the same (P02: YES), the control unit 20 of the in-vehicle device 2 discards the CAN message to which the specified discard condition is applied (P04). When the two stored values being compared are substantially the same, the control unit 20 of the in-vehicle device 2 refers to the relay setting table and discards the CAN message to which the specified discard condition is applied, that is, the CAN message unpacked this time, without transmitting (relaying) it. The control unit 20 of the in-vehicle device 2 may count the number of consecutive discards (number of discard times) when discarding the CAN message according to the identity of the stored value of the payload in this way, and store it in the storage unit 21. When the number of discard times exceeds or reaches the specified upper limit value (discard upper limit value), the control unit 20 of the in-vehicle device 2 may transmit the CAN message that has reached the discard upper limit value.
[0099] (Embodiment 3) FIG. 11 is an explanatory diagram illustrating a functional block (parallel processing) of the in-vehicle device 2 according to Embodiment 3. In the present embodiment, the storage unit 21 of the in-vehicle device 2 includes a plurality of reception buffers determined in advance according to the number of transmission sources. In the illustration in the present embodiment, two reception buffers (reception buffer for ECU-A, reception buffer for ECU-B) corresponding to two in-vehicle ECUs 3 (Eth node: ECU-A, ECU-B) that are transmission sources of Ethernet packets are provided in the storage unit 21.
[0100] When the control unit 20 of the in-vehicle device 2 receives an Ethernet packet from the in-vehicle ECU 3 (Eth node), it stores the received Ethernet packet in the reception buffer corresponding to each of the in-vehicle ECUs 3 (Eth node). The control unit 20 of the in-vehicle device 2 uses the reception buffer as a work area and performs various processes such as extraction (unpacking) of CAN messages and execution of thinning processes (number of times Cnt, time Cnt) applied by referring to the relay setting table in parallel. The control unit 20 of the in-vehicle device 2 has hardware resources such as a multi-core or multi-CPU, for example, and is configured to be capable of parallel processing.
[0101] The control unit 20 of the in-vehicle device 2 parallelizes the thinning process including unpacking and the like according to the number of in-vehicle ECUs 3 (Eth nodes) that are the transmission sources, and sequentially transmits the CAN messages subjected to the thinning process. 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] All the embodiments disclosed this time should be considered as illustrative in all respects and not restrictive. The scope of the present invention is shown not by the above meaning but by the claims, and it is intended that all modifications within the meaning and scope equivalent to the claims are included.
[0103] Regarding the plurality of claims described in the claims, they can be combined with each other regardless of the citation format. In the claims, multiple dependent claims subordinate to a plurality of claims may be described. Multiple dependent claims subordinate to multiple dependent claims may be described. Even when multiple dependent claims subordinate to multiple dependent claims are not described, this does not limit the description of multiple dependent claims subordinate to multiple dependent claims.
Explanation of Reference Signs
[0104] C Vehicle S In-vehicle System 100 External Server 1 Vehicle External 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, comprising a control unit that performs processing related to relaying data flowing through the in-vehicle network, wherein the data includes Ethernet packets using the Ethernet and CAN messages using the CAN, and the control unit: acquires one or more of the Ethernet packets transmitted from the same source, extracts 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, transmits some of the CAN messages with the same message ID and discards the 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 whose storage order in the Ethernet packet is the last among the plurality of CAN messages with the same message ID, and discards the other CAN messages The in-vehicle device according to claim 1.
3. When each of the acquired plurality of Ethernet packets includes a CAN message with the same message ID, 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 the other Ethernet packets The in-vehicle device according to claim 1.
4. The control unit: 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, discards the CAN message included in the acquired Ethernet packet, and when an Ethernet packet is acquired after the non-transmission period has elapsed, 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 the respective CAN messages with the same message ID included in each of the plurality of Ethernet packets acquired from the same source, Store the CAN message values sent last time, and send CAN messages with different stored values, Discard CAN messages with the same stored values as the CAN message values sent last time The in-vehicle device according to claim 1.
6. The control unit Refer to the deletion conditions of the CAN messages stored in the accessible storage area, Discriminate between the CAN messages to be sent and the CAN messages to be discarded according to the referred deletion conditions The in-vehicle device according to claim 1.
7. The control unit updates the deletion conditions stored in the storage area by obtaining information regarding the deletion conditions from an external server provided outside the vehicle. The in-vehicle device according to claim 6.
8. Comprises a storage unit including a plurality of reception buffers, The control unit Obtains each of a plurality of Ethernet packets transmitted from a plurality of different transmission sources using each of the plurality of reception buffers, Performs parallelization processing according to the number of transmission sources by extracting a plurality of the CAN messages included in the Ethernet packet on the reception buffer The in-vehicle device according to claim 1.
9. A plurality of CAN communication units for performing communication by the CAN, and A plurality of Ethernet communication units for performing communication by the Ethernet, The control unit Performs relay processing of CAN messages transmitted and received between a plurality of the CAN communication units, Performs relay processing of Ethernet packets transmitted and received between a plurality of the 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 transmission source address, destination address, port number, or information stored in the payload of the obtained Ethernet packet, When the CAN message is included in the Ethernet packet, perform processing related to transmission or deletion for each of the plurality of CAN messages, When the CAN message is not included in the Ethernet packet, perform relay processing of the Ethernet packet based on predetermined routing information The in-vehicle device according to claim 9.
11. A program that causes a computer connected to an in-vehicle network where communication is performed using Ethernet and CAN to execute processing related to relaying data flowing through the in-vehicle network, wherein the data includes Ethernet packets using the Ethernet and CAN messages using the CAN, obtains one or more of the Ethernet packets transmitted from the same source, extracts a plurality of the CAN messages included in the obtained 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, transmits some of the CAN messages with the same message ID and discards the other CAN messages to execute the processing.
12. An information processing method that causes a computer connected to an in-vehicle network where communication is performed using Ethernet and CAN to execute processing related to relaying data flowing through the in-vehicle network, wherein the data includes Ethernet packets using the Ethernet and CAN messages using the CAN, obtains one or more of the Ethernet packets transmitted from the same source, extracts a plurality of the CAN messages included in the obtained 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, transmits some of the CAN messages with the same message ID and discards the other CAN messages to execute the processing.