Vehicle control system

Abstract

To quickly detect and defend against unauthorized communications from attackers to a vehicle control system while maintaining high responsiveness of vehicle control.SOLUTION: A vehicle control system is connected to a first control device group connected to a first communication network and a second control device group connected to a second communication network different from the first communication network, and includes a forwarding unit that forwards communication packets containing messages between communication networks including the first communication network and the second communication network, and a processing unit that processes communication packets that contain more than a predetermined number of messages among the communication packets received by the forwarding unit from the communication network. The forwarding unit forwards communication packets that contain the predetermined number or less of the messages. The processing unit performs processing to enable the forwarding unit to forward communication packets that contain more than the predetermined number of the messages.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present invention relates to a vehicle control system. [Background technology]

[0002] In recent years, research and development has been carried out to improve the safety of vehicle control. Patent Document 1 describes an unauthorized frame detection device that detects unauthorized frame transmissions in an in-vehicle network system that employs service-oriented communication and prevents the establishment of unauthorized communication. This device detects unauthorized frame transmissions based on the relationship between the ports that physically connect the server and client. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] International Publication No. 2021 / 002010 Summary of the Invention [Problem to be solved by the invention]

[0004] Incidentally, in technology relating to the safety of vehicle control, it is an issue to simultaneously achieve high defense against attacks on vehicle control and high responsiveness of vehicle control. In order to solve the above-mentioned problems, the present application aims to maintain high responsiveness of vehicle control while quickly detecting and defending against unauthorized communications from attackers against vehicle control systems, thereby further improving traffic safety and contributing to the development of sustainable transportation systems. [Means for solving the problem]

[0005] One aspect of the present invention is a vehicle control system mounted on a vehicle, the vehicle control system comprising: a forwarding unit connected to a first control device group connected to a first communication network and a second control device group connected to a second communication network different from the first communication network, the forwarding unit forwarding communication packets containing messages between communication networks including the first communication network and the second communication network; and a processing unit processing communication packets received by the forwarding unit from the communication network that contain more than a predetermined number of messages, the forwarding unit forwarding communication packets that contain the predetermined number or less of the messages, and the processing unit processing to enable the forwarding unit to forward communication packets that contain more than the predetermined number of the messages. [Effects of the Invention]

[0006] According to the present invention, a configuration for transferring communication packets between different communication networks can protect a vehicle control system from unauthorized communication from attackers while maintaining high responsiveness of vehicle control. [Brief explanation of the drawings]

[0007] [Figure 1] FIG. 1 is a diagram showing the configuration of a vehicle control system according to one embodiment of the present invention. [Figure 2] FIG. 2 is a diagram illustrating the configuration of the transfer determination unit. [Figure 3] FIG. 3 is a diagram illustrating an example of search conditions used by the transfer determination unit. [Figure 4] FIG. 4 is a diagram showing an example of the configuration of an Ethernet frame used in SOME / IP communication. [Figure 5] FIG. 5 is a diagram showing an example of the configuration of an Ethernet frame used in SOME / IP communication. [Figure 6] FIG. 6 is a flowchart showing the operation of the processing unit. DETAILED DESCRIPTION OF THE INVENTION

[0008] Hereinafter, an embodiment of the present invention will be described with reference to the drawings. [1. Vehicle control system configuration] FIG. 1 is a diagram showing the configuration of a vehicle control system 1 according to one embodiment of the present invention. The vehicle control system 1 is mounted on a vehicle 2 and controls the operation of the vehicle 2. The vehicle 2 may be any vehicle driven by an internal combustion engine and / or a motor. In this embodiment, the vehicle 2 is, for example, an electric vehicle driven by a drive motor (neither of which is shown) powered by an on-board battery.

[0009] The vehicle control system 1 includes a first control device group 3, a second control device group 4, a vehicle control unit 100, and a communication management device 8. In this embodiment, the first control device group 3 does not include a control device that communicates with the outside of the vehicle 2, but includes a control device that performs control within the vehicle 2. For example, the first control device group 3 includes a control device that performs control related to motion control of the vehicle 2. In this embodiment, the first control device group 3 includes, as control devices that perform control related to motion control of the vehicle 2, a drive ECU (Electronic Control Unit) 6a, a steering ECU 6b, a battery ECU 6c, and an ADAS (Advanced Driver-Assistance System)-ECU 6d.

[0010] The drive ECU 6a controls the operation of the drive motor that drives the vehicle 2, and the steering ECU 6b controls operations such as steering, deceleration, and acceleration of the vehicle 2 based on steering operations such as the steering wheel, brake, and accelerator of the vehicle 2. The battery ECU 6c detects the remaining charge of the on-board battery and controls the power supply operation to the drive motor. Furthermore, the ADAS-ECU 6d controls driver assistance operations such as cruising operation and lane keeping operation of the vehicle 2. Hereinafter, the drive ECU 6a, steering ECU 6b, battery ECU 6c, and ADAS-ECU 6d included in the first control device group 3 will be collectively referred to as ECU 6.

[0011] The second control device group 4 includes a control device that communicates with the outside of the vehicle 2. For example, the second control device group 4 includes a control device other than a control device that performs control related to motion control of the vehicle 2. In this embodiment, the second control device group 4 includes a TCU (Telematics Control Unit) 7a and an IVI (In-Vehicle Infotainment)-ECU 7b as control devices that communicate with the outside of the vehicle 2. The TCU 7a is a wireless communication device that communicates with devices outside the vehicle 2 directly or indirectly via an external communication network. The IVI-ECU 7b receives radio and television broadcast waves and / or GPS waves and displays images and videos to occupants of the vehicle 2 on an in-vehicle display device, speaker, etc. (neither of which are shown), and / or provides information such as route guidance.

[0012] The second control device group 4 also includes, for example, a DMC-ECU 7c that controls the operation of a DMC (Driver Monitoring Camera) (not shown) provided in the passenger compartment of the vehicle 2. Hereinafter, the TCU 7a, IVI-ECU 7b, and DMC-ECU 7c included in the second control device group 4 will also be collectively referred to as ECU 7.

[0013] In this embodiment, the first control device group 3 and the second control device group 4 include four and three control devices, respectively, but each group only needs to have at least one control device. Each of the ECU 6 and the ECU 7 includes a computer and performs predetermined control operations and communication with other in-vehicle devices.

[0014] In this embodiment, the ECU 6 and the ECU 7 perform SOME / IP communication (Service Oriented MiddleWarE Over IP) defined in AUTOSAR (AUTomotive Open System Architecture) in accordance with the Ethernet (registered trademark) communication standard, using IP packets that comply with the UDP (User Datagram Protocol) communication standard.

[0015] The ECU 6 of the first control device group 3 and the ECU 7 of the second control device group 4 are connected to a routing device 5 to respectively form a first communication network 9 and a second communication network 10. The first communication network 9 and the second communication network 10 are, for example, VLANs (Virtual Local Area Networks).

[0016] The vehicle control unit 100 includes a routing device 5 and a processing device 110 . The routing device 5 performs communication transfer between communication networks including the first communication network 9 and the second communication network 10, and communication transfer within each communication network, thereby enabling communication between each ECU including the ECU 6 and the ECU 7. The routing device 5 can be realized as, for example, an L3 switch. The routing device 5 is an example of a transfer unit of the present disclosure.

[0017] In this embodiment, in particular, the routing device 5 checks IP packets of communications carried out between the ECU 6 and the ECU 7, and discards IP packets used for unauthorized communications, thereby preventing the execution of unauthorized communications. A communication management device 8 is connected to the routing device 5. The communication management device 8 sets check conditions for IP packets for the routing device 5. The routing device 5 may be built into the communication management device 8.

[0018] The processing device 110 performs processing to reconstruct packets as described below for communications sent from the second control device group 4 to the first control device group 3. The processing device 110 has a function to hook communications from the second control device group 4 to the first control device group 3, and executes processing for communications that meet predetermined conditions. The processing device 110 is an example of a processing unit of the present disclosure.

[0019] The vehicle control unit 100 may include a communication management device 8. The processing device 110 and the communication management device 8 may be implemented in the same hardware, and the communication management device 8 may include the routing device 5.

[0020] [2. Overview of Ethernet® frames in SOME / IP communications] Here, an outline of the Ethernet frame in the SOME / IP communication handled by the vehicle control system 1 will be described.

[0021] Figures 4 and 5 show an example of an Ethernet frame in SOME / IP communication when performing SOME-IP-SD communication, with one Ethernet frame divided into Figures 4 and 5. The illustrated Ethernet frame consists of an 18-byte MAC header and an IP packet (after the IP header) that includes a message (SOME / IP message) specified in SOME / IP communication.

[0022] The MAC header includes the following fields: Destination Mac Address, Source Mac Address, TCI, Type, and EthType. The Destination Mac Address field indicates the MAC address of the destination device, and the Source Mac Address field indicates the MAC address of the source device. The TCI field is a VLAN identification value, and indicates either the first communication network 9 or the second communication network 10. The Type field and Eth Type field are well-known fields, so their explanation will be omitted.

[0023] The IP packet may include an IP header, a UDP header, and a SOME / IP header and a SOME / IP-SD header that are part of a SOME / IP message. The SOME / IP-SD header includes an Entries Array and an Options Array.

[0024] The IP header, UDP header, SOME / IP header, and SOME / IP-SD header are well known. In the following, in order to simplify the explanation and facilitate understanding, the fields that make up these headers will not be explained one by one, and only the parts related to the characteristic operations of the vehicle control system 1 according to this embodiment will be explained briefly.

[0025] The SourceAddress field of the IP header and the SourcePort field of the UDP header indicate the IP address (source address) and communication port number (source port number) of the device that sent this communication packet, respectively. The DestinationAddress field of the IP header and the DestinationPort field of the UTP header indicate the IP address (destination address) and communication port number (destination port number) of the device that received this communication packet, respectively. Here, the IP addresses are local IP addresses in the LAN (including VLANs) to which the corresponding devices are connected.

[0026] The source device can specify the IP address of a specific destination device in the DestinationAddress field and send the communication packet by unicast, or it can specify a predefined IP address (multicast address) that indicates a range of multiple destination devices and send the communication packet by multicast to those multiple destination devices.

[0027] In the case of SOME / IP-SD communication, the ServiceID field and MethodID field of the SOME / IP header store 0xFFFF and 0x8100, respectively, as special values ​​indicating that the communication is SOME / IP-SD.

[0028] The SOME / IP-SD header includes an EntriesArray field.

[0029] The SOME / IP communication standard defined by AUTOSAR allows various messages, such as FindService and OfferService messages, for multiple different services to be transmitted in a single IP packet. In other words, the Entries Array in the SOME / IP-SD header is permitted to contain multiple 16-byte units of information (specifically, information from the Type field to the Instance ID), each representing a single message. Hereinafter, the above 16-byte information portion per service will also be referred to as a service entry. In other words, the number of service entries contained in the Entries Array is arbitrary, and the Entries Array is variable-length information.

[0030] The Length of Entries Array field in the SOME / IP-SD header indicates the length of the bit string in which the service entries are stored, and is 0x10 (i.e., 16 bytes) when there is one service entry. In the example shown in Figures 4 and 5, five service entries are included, so the value of the Length of Entries Array field is 0x50 (i.e., 80 bytes). In this example, the SOME / IP-SD header contains five Entries Arrays corresponding to the five service entries, respectively. The Length of Entries Array field can be said to indicate the number of service entries, and is an example of a message count field in the present disclosure.

[0031] [3. Routing Device] The configuration and operation of the routing device 5 will now be described. Referring to FIG. 1, the routing device 5 includes, as functional elements (or functional units), a communication unit 20, a frame buffer 22, a switch unit 23, a route determination unit 24, a gate unit 25, a forwarding judgment unit 26, and a management unit 27. These functional elements may be realized by, for example, semiconductor devices included in the routing device 5. Such semiconductor devices may include a processor (computer), a dedicated LSI such as an ASIC, an FPGA, and / or a memory.

[0032] The communication unit 20 is a transceiver that performs communication in accordance with the Ethernet standard. For example, the communication unit 20 may be configured with a so-called PHY (PHYsical layer) circuit chip. The communication unit 20 has a plurality of input / output ports 21 (referring to each of the plurality of rectangles within the dashed rectangle indicated by reference numeral 21 in FIG. 1 ), and performs communication with the ECU 6 and ECU 7 connected to these input / output ports 21.

[0033] The frame buffer 22 is a memory for temporarily storing Ethernet frames received by the communication unit 20 from the ECU 6 and the ECU 7. The frame buffer 22 sequentially outputs the temporarily stored Ethernet frames to a gate unit 25, which will be described later.

[0034] The switch unit 23 performs communication transfer between the input / output ports 21 of the communication unit 20 to which the ECU 6 or ECU 7 is connected, in accordance with information from the route determination unit 24, according to conventional technology. In this embodiment, the switch unit 23 particularly performs communication transfer for Ethernet frames that are received at one of the input / output ports 21 of the communication unit 20 and temporarily stored in the frame buffer 22, and that are input to the switch unit 23 via the gate unit 25.

[0035] For each Ethernet frame sent from the frame buffer 22 via the gate unit 25, the route determination unit 24 refers to a routing table (not shown) according to conventional technology to determine the input / output port 21 to which the IP packet included in the Ethernet frame should be forwarded. For each IP packet, the route determination unit 24 notifies the switch unit 23 of information specifying the input / output port 21 to which the IP packet should be forwarded.

[0036] The gate unit 25, in accordance with an instruction from the transfer decision unit 26, outputs the Ethernet frame sent from the frame buffer 22 to the switch unit 23 and the route decision unit 24, or discards it.

[0037] The management unit 27 acquires search conditions (described later) used in the transfer decision unit from the communication management device 8, for example, when the routing device 5 is started up, and sets the search conditions in the transfer decision unit .

[0038] The forwarding decision unit 26 determines whether or not to allow forwarding between communication networks each of the communication packets (in this embodiment, IP packets; the same applies hereinafter) contained in the Ethernet frame received by the routing device 5. In other words, the forwarding decision unit 26 checks the Ethernet frames containing IP packets transmitted and received between the ECU 6 and the ECU 7. The forwarding decision unit 26 instructs the gate unit 25 to discard any Ethernet frame containing an inappropriate IP packet. As a result, any IP packet determined by the forwarding decision unit 26 to be an inappropriate IP packet is discarded without being forwarded.

[0039] In this embodiment, the transfer decision unit 26 is configured, for example, with a TCAM (Ternary Content Addressable Memory). By specifying a plurality of specific bit strings (arrays of bit values) as search conditions, the TCAM uses hardware processing to quickly search for a bit string that matches the bit string specified as the search condition from among the bit strings input to the TCAM (input bit strings). When the TCAM finds a bit string that matches a bit string indicated by one of the search conditions in the input bit string, it outputs, as search results, information identifying the search condition that led to the match (for example, an identification number of the search condition), information about the found bit string, etc.

[0040] In particular, TCAM can use three values, "1" and "0" plus "X (Don't Care)," as the value of each bit in the bit string that is the search condition. For example, if "001XX000" is specified as the search condition, the search will be determined to be a hit if the input bit string contains any of "00100000," "00110000," "00101000," or "00111000."

[0041] The TCAM has a memory (hereinafter referred to as a condition storage memory) for storing the bit strings of the search conditions. The storage area of ​​the condition storage memory is usually divided into partitions of a predetermined size (for example, a predetermined number of bytes). These partitions are called TCAM entries here. Search conditions are set in TCAM entry units (for example, one condition for two entries, or one condition for three entries, etc.).

[0042] For example, in this embodiment, the size of a TCAM entry in the transfer determination unit 26 is 48 bytes, and a storage area for 512 TCAM entries is reserved in the condition storage memory. However, these numerical values ​​are merely examples, and the size and number of reserved TCAM entries in the condition storage memory can be designed arbitrarily based on the size and number of search conditions required, within the range of the size of the storage area that can be reserved for the condition storage memory.

[0043] 2 is a functional block diagram showing the operation of the forwarding decision unit 26. The forwarding decision unit 26 includes a condition storage memory 261 that stores search conditions, and a search circuit 262. The search circuit 262 obtains the leading portion of each received Ethernet frame from the frame buffer 22 as an input bit string. The search circuit 262 searches the input bit string for a bit pattern indicated by each search condition stored in the condition storage memory 261. The leading portion is, for example, 144 bytes including 106 bytes from the beginning of the Ethernet frame to the end of the first SOME / IP-SD header.

[0044] The search circuit 262 then outputs the search result (i.e., whether or not a search hit occurs) indicating whether a bit pattern indicated by any of the search conditions is found in the input bit string as a transfer permission command or a transfer prohibition command for the Ethernet frame. In other words, the search result of the search circuit 262 corresponds to the determination result of whether or not the IP packet is appropriate.

[0045] 3 is a diagram showing an example of search conditions for Ethernet frames set in the forwarding decision unit 26, and will be explained using SOME / IP-SD communication as an example. In this embodiment, the contents of each field shown below, including the value of the Length of Entries Array field, are specified in the search conditions. Note that the symbols in the bit string parts shown below are the symbols for each bit string part shown in FIG. 3. Bit string 281: Source Address of the IP header (IP address of the source ECU) Bit string section 282: Destination Address of the IP header (IP address of the destination ECU) Bit string part 283: SourcePort of UDP header (communication port number of the sending ECU) Bit string part 284: DestinationPort of UDP header (communication port number of destination ECU) Bit string 285: Service ID of the SOME / IP header (fixed value 0xFFFF indicating SOME / IP-SD communication) Bit string 286: MessageType of SOME / IP header (fixed value 0x02) Bit string 287: Length of Entries Array of SOME / IP-SD header (fixed value 0x10) Bit string 288: Service ID in the Entries Array of the SOME / IP-SD header (service ID of the service exchanged between ECUs)

[0046] The bit string fields 281 and 282 are set with the IP addresses of the legitimate ECU6 or ECU7 that can be the source and destination, respectively. The bit string fields 283 and 284 are set with the communication port numbers of the legitimate ECU6 or ECU7 that can be the source and destination, respectively. The bit string field 285 is set with a fixed value of 0xFFFF indicating SOME / IP-SD communication. The bit string field 286 is set with a fixed value of 0x02 for a SOME / IP-ID message. The bit string field 287 is set with a fixed value of 0x10 that specifies the length of the Entries Array, which is a variable-length portion. The bit string field 288 is set with a service ID indicating the legitimate service exchanged between the ECU6 and ECU7.

[0047] In addition, for example, a value "X (Don't Care)" is set in fields other than the above fields defined by the search conditions.

[0048] In this embodiment, a plurality of search conditions are set in the transfer decision unit 26 as a whitelist indicating regular conditions, similar to the search conditions shown in FIG.

[0049] In this embodiment, as described above, the Length of Entries Array (fixed value 0x10) in the SOME / IP-SD header is always checked, so at least the first 74 bytes of the Ethernet frame must be included in the search criteria. Therefore, the number of TCAM entries used in the search criteria is 2 or 3 (i.e., a search criteria of 96 bytes or 144 bytes overall).

[0050] The bit string portions 281, 282, 283, 284, 285, 286, 287, and / or 288 corresponding to the designated fields may also contain the value "X." For example, if the service IDs to be set in the bit string portion 288 have a characteristic common portion in binary or hexadecimal notation and there is no need to check portions other than the common portion, the bit value of the bit position corresponding to the portion other than the common portion may be set to "X." This reduces the number of search conditions, reduces the processing load on the forwarding determination unit 26, and improves the processing speed.

[0051] 3 are merely examples, and the search conditions set in the forwarding determination unit 26 may be set according to the design of the ECUs 6 and 7. For example, the value of the Type field in the Entries Array of the SOME / IP-SD header may be included in the search conditions. In this case, in the SOME / IP communication standard, the interpretation of the message type indicated by the Type field may differ depending on the value of the TTL field in the Entries Array (whether it is 0 or not). For this reason, the value of the TTL field may be included in the search conditions in addition to the value of the Type field. For example, a value of 0x01 in the Type field indicates that the SOME / IP message is an OfferService message if the TTL field value is not 0, but indicates that the SOME / IP message is a StopOfferService message if the TTL field value is 0.

[0052] As described above, when the ECU 6 or ECU 7 performs SOME / IP-SD communication conforming to the SOME / IP communication standard, the number of service entries included in the Entries Array can be any number. That is, the number of service entries included in the Entries Array is arbitrary, and the Entries Array is variable-length information.

[0053] Since an IP packet can contain any number of service entries, the size of the IP packet may exceed the maximum of three entries (maximum of 144 bytes) that the TCAM used in the routing device 5 can handle, or the upper limit on the number of entries (maximum of 512) may be exceeded because it is necessary to set TCAM entries in the condition storage memory 261 for the number of permutations of the number of service entries.

[0054] In the future, it is expected that the number of services will increase, such as the addition of functions to ECUs involved in SOME / IP-SD communication, such as ECU 7. Furthermore, in addition to the ECU shown in Figure 1 as ECU 7, ECUs with many other functions will be installed in vehicle 2, and the number of services using SOME / IP-SD communication is also expected to increase.

[0055] As such, with the increase in services that use SOME / IP-SD communication, there are limitations to appropriately determining whether an IP packet is a legitimate packet using TCAM processing alone, which led the inventors to propose the present disclosure.

[0056] Furthermore, if a TCAM with a sufficiently large storage capacity is used to address the issue of increasing IP packet size, there is a concern that the cost of the routing device 5 will increase. The present inventors have come to propose the vehicle control system 1 of the present disclosure in order to increase the flexibility in adopting TCAM. That is, in the present disclosure, the number of service entries included in IP packets processed by the TCAM is set to a predetermined number or less, thereby increasing the flexibility in adopting TCAM and realizing a configuration that enables the transfer of IP packets with more than the predetermined number of service entries.

[0057] In the vehicle control system 1 of this embodiment, the number of service entries to be included in the SOME / IP-SD header of SOME / IP communication is set to a predetermined number or less in the forwarding determination unit 26. Specifically, for each Ethernet frame received via the communication unit 20 and temporarily stored in the frame buffer 22, the forwarding determination unit 26 determines whether a predetermined value is set in the Length of Entries Array field of the SOME / IP-SD header, which serves as the bit length field.

[0058] That is, the transfer decision unit 26 includes a check of the value of the Length of Entries Array field of the SOME / IP-SD header in the search conditions set for the TCAM entry. In the SOME / IP communication standard, the Length of Entries Array field indicates the length of the bit string in which the service entry is stored, and if there is one service entry, the length is 0x10 (i.e., 16 bytes). The transfer decision unit 26 permits transfer from the ECU 7 to the ECU 6 on the condition that a predetermined value (0x10) is set in the Length of Entries Array field.

[0059] As a result, the forwarding decision unit 26 only needs to determine the validity of the IP packet within a range of 106 bytes from the beginning of the Ethernet frame to the end of the first SOME / IP-SD header (first 106 bytes). As described above, in this embodiment, the TCAM entry of the TCAM constituting the forwarding decision unit 26 is 48 bytes, so that for the first 106 bytes, a search condition can be set using a maximum of three entries (48 bytes / entry x 3 entries = 144 bytes).

[0060] In other words, by using a maximum of three TCAM entries (144 bytes) depending on the position range in the first 106 bytes of one or more fields you want to set in the search conditions, you can determine the validity of the Ethernet frame (and therefore the validity of the IP packets contained in that Ethernet).

[0061] In this way, the transfer determination unit 26 permits the transfer of the received communication packet on the condition that a predetermined value is set in the bit length field that specifies the bit length of the variable-length portion of the received communication packet. If a predetermined value is not set in the bit length field that specifies the bit length of the variable-length portion of the received communication packet, processing is performed by the processing device 110, which will be described later. This fixes the bit length of the variable-length portion of the communication packet, preventing it from exceeding the capacity of the TCAM storage area and ensuring reliable processing of the communication packet. Furthermore, this facilitates detection of fraudulent communication packets and reduces the time required for the fraud detection process. Therefore, the vehicle control system 1 can easily detect and protect against fraudulent communications while maintaining high vehicle control responsiveness.

[0062] In this embodiment, in addition to the value of the Length of Entries Array field, the forwarding decision unit 26 checks whether the contents of predetermined fields, including the source address, source port number, destination address, destination port number, and the Service ID and Message Type fields of the SOME / IP header of the IP packet, are correct. This makes it possible to confirm that the communication is from a correct party and is related to a correct service, thereby more reliably detecting unauthorized communication from an attacker.

[0063] If the contents of these fields are correct, forwarding decision unit 26 permits gate unit 25 to forward the Ethernet frame containing that IP packet, and if the contents are incorrect, it prohibits the forwarding of the Ethernet frame containing that IP packet. Gate unit 25 outputs Ethernet frames that have been permitted for forwarding by forwarding decision unit 26 to switch unit 23, and discards Ethernet frames that have been prohibited for forwarding.

[0064] This determines whether the IP packet is legitimate, i.e., whether it is a packet carrying a SOME / IP-SD communication message related to a legitimate service from a legitimate ECU, and prevents the communication of fraudulent IP packets (i.e., fraudulent communication).

[0065] The transfer decision unit 26 can be configured to determine whether to transfer an IP packet from the ECU 7 to the ECU 6, and also to determine whether to transfer an IP packet received from the ECU 7 to the processing device 110. Specifically, if a predetermined value is not set in a bit length field that specifies the bit length of the variable-length part of a communication packet received from the ECU 7, the transfer decision unit 26 determines to transfer the packet to the processing device 110 so that the processing device 110 can execute processing.

[0066] As an example, consider a configuration in which the transfer determination unit 26 has a condition for transferring a frame from the ECU 7 to the ECU 6 and a condition for transferring a frame from the ECU 7 to the processing device 110. In this configuration, for example, the determination conditions (search conditions) set in the transfer determination unit 26 are managed by assigning numbers as shown below. The transfer determination unit 26 performs a match determination on the determination conditions in order from the smallest number to determine whether or not the frame satisfies the determination conditions. (Condition 1):IP,PORT,ServiceID,LengthofEntriesArray (Condition 2):IP,PORT,ServiceID

[0067] In this example, the forwarding decision unit 26 performs a match determination for the received Ethernet frame with condition 1, and performs a match determination for the frame that does not meet condition 1 with condition 2. For example, when a frame whose Length of Entries Array field has a value of 0x10 is received, the forwarding decision unit 26 determines that the frame meets condition 1. In this case, the forwarding decision unit 26 determines to forward the frame to the ECU 6 in accordance with the determination based on condition 1. On the other hand, when a frame whose Length of Entries Array field has a value other than 0x10 is received, the forwarding decision unit 26 determines that the frame does not meet condition 1 and performs a match determination for condition 2. Then, when the frame meets condition 2, the forwarding decision unit 26 determines to forward the frame to the processing device 110.

[0068] This example can also be said to be a configuration in which the forwarding judgment unit 26 has condition 1 for judging whether to forward the Ethernet frame received from ECU 7 to ECU 6, and condition 2 for judging whether to forward the Ethernet frame received from ECU 7 to the processing device 110. Furthermore, when the forwarding judgment unit 26 forwards an Ethernet frame received from the ECU 6 to the ECU 7, the forwarding judgment unit 26 may have a plurality of judgment conditions that are managed by assigning numbers as described above, and may make a judgment by applying these plurality of judgment conditions in order.

[0069] The function of the forwarding determination unit 26 to determine an IP packet based on the value of the Length of Entries Array field may be configured to be executed only in one direction for Ethernet frames transferred between the ECU 6 and the ECU 7. The ECU 6 included in the first control device group 3 does not include a control device that communicates with the outside of the vehicle 2, so there is little concern about unauthorized access to the vehicle control system 1. For this reason, the forwarding determination unit 26 may be configured to execute the determination based on the value of the Length of Entries Array field only for Ethernet frames transferred from ECU 7 to ECU 6, and not to apply it to Ethernet frames transferred from ECU 6 to ECU 7. In this case, communication from the first communication network 9 to the second communication network 10 can be transferred at a higher speed.

[0070] [4.Communication management device] The communication management device 8 is, for example, a computer equipped with a processor such as a CPU. The communication management device 8 sets search conditions for the forwarding determination unit 26 by executing a program using the processor. The communication management device 8 is equipped with a nonvolatile storage device such as a ROM, and stores the search conditions to be set in the forwarding determination unit 26.

[0071] The communication management device 8 may include a communication device that communicates with a server device or the like external to the vehicle 2. The communication management device 8 receives a list of search conditions to be set in the forwarding determination unit 26, for example, from the server device, and stores the list as a search condition list. In response to a request from the routing device 5 (for example, the management unit 27), the communication management device 8 transmits the search condition list to the routing device 5. As described above, the management unit 27 of the routing device 5 transmits the request to the communication management device 8, for example, when the routing device 5 is started up, receives the transmitted search condition list, and sets it in the forwarding determination unit 26. This allows the forwarding determination unit 26 to appropriately set search conditions for determining whether an IP packet is a valid IP packet.

[0072] [5. Processing equipment] 1, the processing device 110 includes a frame processing unit 111. The processing device 110 is a computer including a processor such as a CPU and a storage device that stores programs executed by the processor and data processed by the processor. The frame processing unit 111 is a functional unit realized when the processor of the processing device 110 executes a program.

[0073] The processing device 110 has a function of hooking Ethernet frames received by the routing device 5 from the ECU 6 or ECU 7, or in other words, a function of receiving Ethernet frames that the routing device 5 transfers to the processing device 110. While FIG. 1 shows a configuration in which the processing device 110 acquires Ethernet frames sent from the frame buffer 22 to the gate unit 25, the connection between the processing device 110 and the routing device 5 in FIG. 1 is one example. Any configuration may be used as long as, among the Ethernet frames received by the communication unit 20, frames that are for SOME / IP-SD communication and have more than one service entry are sent to the processing device 110, and frames processed by the processing device 110 are sent again to the communication unit 20.

[0074] The processing device 110 processes the transferred Ethernet frame using the frame processing unit 111. The frame processing unit 111 detects Ethernet frames in which the number of service entries exceeds one. For example, the frame processing unit 111 refers to the value of the Length of Entries Array in the SOME / IP-SD header of the Ethernet frame, and processes any Ethernet frame in which the value is greater than a predetermined value (0x10) when the service entry is one. Here, the frame processing unit 111 may be configured to detect that the transferred Ethernet frame is an Ethernet frame for SOME / IP-SD communication and in which the number of service entries exceeds one.

[0075] Frame processing unit 111 generates multiple Ethernet frames based on the Ethernet frame determined to be the target of processing. Specifically, frame processing unit 111 generates multiple Ethernet frames, each containing one service entry, from an Ethernet frame containing multiple service entries. The service entry included in the Ethernet frame generated by frame processing unit 111 is the service entry obtained from the target Ethernet frame of processing. In other words, frame processing unit 111 converts the Ethernet frame containing multiple service entries into an Ethernet frame containing a single service entry that can be forwarded by routing device 5.

[0076] Frame processing unit 111 sends the processed Ethernet frame to communication unit 20. The Ethernet frame sent by frame processing unit 111 is received by routing device 5 and stored in frame buffer 22, just like a frame sent by ECU 6 or ECU 7 to routing device 5. This Ethernet frame contains one service entry, and is therefore forwarded by routing device 5 after undergoing the above-mentioned determination. An Ethernet frame with one service entry is not forwarded to frame processing unit 111, so there is no concern that processing of the same Ethernet frame will loop in frame processing unit 111.

[0077] By performing the above-described process, the number of service entries included in an Ethernet frame forwarded by the routing device 5 to the ECU 6 or ECU 7 is limited to one. This enables high-speed communication forwarding. If multiple service entries exist and the above-described process is not performed, vehicle control using that Ethernet frame becomes impossible. In this embodiment, an Ethernet frame including multiple service entries is converted into an Ethernet frame including a single service entry. This enables forwarding of an Ethernet frame including multiple service entries without impairing the high-speed processing of the routing device 5.

[0078] Furthermore, the frame processing unit 111 sets values ​​in each field of the MAC header in the process of generating an Ethernet frame. The Ethernet frame that the processing unit 110 acquires from the routing device 5 may be in the form of an IP packet that does not include a MAC header, depending on the layer processed in the routing device 5. When the processing unit 110 acquires a frame from a configuration in which the routing device 5 processes the network layer (IP layer), the MAC header is missing from the acquired frame. To deal with these cases, the frame processing unit 111 acquires the IP packet of the Ethernet frame to be processed and generates multiple IP packets from multiple service entries included in this IP packet. Then, it creates a MAC header for the generated IP packet. That is, the frame processing unit 111 sets values ​​in each field of the Destination MAC Address, Source MAC Address, TCI, Type, and Eth Type.

[0079] When setting the MAC addresses of the destination and source devices, the frame processing unit 111 refers to an ARP (Address Resolution Protocol) table 113. The ARP table 113 is information that the processing unit 110 holds in advance, and associates IP addresses with MAC addresses. The frame processing unit 111 obtains the MAC addresses from the ARP table 113 based on the IP addresses of the destination and source devices, and generates a MAC header. This ensures reliable transfer of Ethernet frames, regardless of which layer of the routing device 5 the processing unit 110 hooks the frame from.

[0080] 6 is a flowchart showing the operation of the processing device 110. Steps S1 to S8 in FIG.

[0081] The processing device 110 refers to an Ethernet frame obtainable from the routing device 5 and determines whether the frame is a UDP communication frame (step S1). In this embodiment, the Ethernet frames that the processing device 110 targets for conversion processing are limited to UDP communication frames. When transmitting large data such as video content via UDP communication, it is likely that Ethernet frames containing multiple service entries will be sent and received. Therefore, targeting UDP communication has the advantage of enabling more efficient communication transfer.

[0082] If it is not an Ethernet frame for UDP communication (step S1: NO), the processing device 110 ends this process and acquires the next communication. On the other hand, if the referenced Ethernet frame is a frame for UDP communication (step S1: YES), the processing device 110 acquires this frame and determines whether the acquired frame satisfies the filtering conditions (step S3).

[0083] The filtering condition in step S3 is a condition that is predefined for the frame to be processed by the processing device 110. For example, the filtering condition is that the number of service entries included in the frame exceeds one.

[0084] The filtering condition may also include a condition that the frame is a SOME / IP-SD communication frame. The filtering condition may also include a condition that the destination IP address (Destination Address) in the IP header is a multicast address. The filtering condition may also include a condition that the source IP address (Source Address) in the IP header indicates a specific ECU. The filtering condition may also include a condition that the destination port number (Destination Port) in the UTP header is a specific port number. The specific ECU is, for example, an ECU that performs functions related to information processing, such as an ECU in an IVI system. The specific port number is, for example, an SD common port prepared for SD communication. These filtering conditions prevent frame conversion processing from being performed on unnecessary frames, enabling more efficient processing by the processing device 110.

[0085] If the acquired frame does not meet the filtering conditions (step S3: NO), the processing device 110 ends this process and acquires the next communication. On the other hand, if the acquired frame satisfies the filtering conditions (step S3: YES), the processing device 110 divides the entries of this frame (step S4). Specifically, the processing device 110 sets the number of service entries by referencing the Length of Entries Array field. The processing device 110 acquires the Entries Array fields included in the Ethernet frame one by one and temporarily stores each Entries Array field individually. Here, the processing device 110 stores the correspondence between the value of the Index 1st Options field of each Entries Array and the value of the Length field of the Options Array.

[0086] The processor 110 selects one unprocessed service entry from the service entries divided in step S4 (step S5), and generates an Ethernet frame including the selected service entry (step S6).

[0087] In step S6, the processing device 110 generates a SOME / IP-SD header containing one service entry by adding an OptionsArray field and the like to the selected service entry according to the correspondence between the value of the Index 1st Options field and the value of the Length field of the Options Array. Furthermore, the processing device 110 generates an IP packet by adding the same IP header, UDP header, and SOME / IP header as the original frame to the generated SOME / IP-SD header. Here, the processing device 110 changes the value of the Length of Entries Array field of the SOME / IP-SD header to a predetermined value (0x10) corresponding to one service entry. The processing device 110 obtains the source MAC address by referencing the ARP table 113 based on the source IP address in the IP header. The processing device 110 also sets the destination MAC address to a multicast address. The processing device 110 generates a MAC header containing the source MAC address obtained from the ARP table 113 and the set destination MAC address, and adds the MAC header to the IP packet to generate an Ethernet frame. The Ethernet frame generated by the series of processes in step S6 has the same format as the Ethernet frame that the routing device 5 receives from the ECU 6 or ECU 7.

[0088] The processor 110 determines whether the processing of steps S5 to S6 has been completed for all service entries divided in step S4 (step S7). If there are any unprocessed entries (step S7: NO), the processor 110 returns to step S5 and processes the unprocessed entries.

[0089] If the process of generating Ethernet frames has been completed for all service entries (step S7: YES), the processing device 110 retransmits the Ethernet frame generated in step S6 (step S8). Retransmission is a process in which the processing device 110 sends the Ethernet frame to the communication unit 20 while disguising it as a frame transmitted from the ECU 6 or ECU 7. In step S8, the processing device 110 transmits all of the multiple frames generated from one Ethernet frame at once.

[0090] The processing device 110 may perform the process of FIG. 6 only for Ethernet frames transmitted from the ECU 7 to the ECU 6. In other words, Ethernet frames transmitted from the ECU 6 to the ECU 7 are not forwarded to the processing device 110. For example, the vehicle control system 1 may be configured such that the vehicle control unit 100 is included in the ECU 7. In this case, the routing device 5 determines whether to forward the Ethernet frame transmitted from the ECU 7 to the ECU 6 based on a search condition that includes a condition that the number of service entries is equal to or less than a predetermined number. The processing device 110 then hooks the Ethernet frame transmitted from the ECU 7 to the ECU 6 and processes the SOME / IP-SD communication Ethernet frame whose number of service entries exceeds a certain constant. In this configuration, the routing device 5 may be configured not to limit the number of service entries for SOME / IP-SD communication transmitted from the ECU 6 to the ECU 7, and may also forward frames containing multiple service entries. In this case, reliable fraud detection processing can be performed for SOME / IP-SD communication from the ECU 7, which includes a control device that communicates with the outside of the vehicle 2, to the ECU 6. Furthermore, communication packets sent from ECU 6, which does not include a control device that performs communication with the outside of vehicle 2, to ECU 7 can be transferred without service entry restrictions, thereby making SOME / IP-SD communication even more efficient.

[0091] 6. Other Embodiments In the above embodiment, the processing device 110 may acquire not only UDP communications but also all communications processed by the routing device 5 in step S2 (FIG. 6). That is, the processing in step S1 may be omitted.

[0092] In the above embodiment, the condition under which the transfer decision unit 26 permits transfer from the ECU 7 to the ECU 6 is that a predetermined value (0x10) is set in the Length of Entries Array field. Also, an example has been described in which the transfer decision unit 26 permits transfer on the condition that a predetermined value is set in the bit length field that specifies the bit length of the variable-length portion of the received communication packet. These conditions are merely examples, and the transfer decision unit 26 may permit transfer under other conditions. Furthermore, the transfer decision unit 26 may determine whether to permit transfer by combining multiple conditions, including other conditions.

[0093] The function of gate unit 25 may be included in switch unit 23 or frame buffer 22. In these cases, switch unit 23 or frame buffer 22 can be configured to forward or discard Ethernet frames including IP packets in accordance with instructions from forwarding determination unit 26.

[0094] The route determination unit 24 can be configured with a TCAM according to conventional techniques. The forwarding decision unit 26 and the route determination unit 24 may be configured with one TCAM.

[0095] In addition, although the transfer decision unit 26 is configured with a TCAM (ternary content addressable memory) in the above-described embodiment, it may be configured with a microprocessor or the like that performs similar processing. In this case, however, the processing speed of the transfer decision unit 26 may be slower than when a TCAM is used.

[0096] The present invention is not limited to the configurations of the above-described embodiments, and can be implemented in various forms without departing from the spirit of the present invention.

[0097] 7. Configurations Supported by the Above Embodiments The above-described embodiment supports the following configurations.

[0098] (Configuration 1) A vehicle control system mounted on a vehicle, the vehicle control system comprising: a forwarding unit connected to a first control device group connected to a first communication network and a second control device group connected to a second communication network different from the first communication network, the forwarding unit forwarding communication packets containing messages between communication networks including the first communication network and the second communication network; and a processing unit processing communication packets received by the forwarding unit from the communication network that contain more than a predetermined number of messages, the forwarding unit forwarding communication packets containing the predetermined number or less of the messages, and the processing unit processing to enable the forwarding unit to forward communication packets containing more than the predetermined number of the messages. According to the vehicle control system of configuration 1, by forwarding communication packets with a limit on the number of messages included in the communication packets, it becomes easier to detect fraud in the forwarded communication packets and the time required for the fraud detection process is also reduced. Furthermore, by enabling the processing unit to forward communication packets that exceed the limit on the number of messages, necessary communication packets can be forwarded without being discarded. Therefore, according to the vehicle control system of configuration 1, it is possible to easily detect and protect against fraudulent communications while maintaining high responsiveness of vehicle control.

[0099] (Configuration 2) The vehicle control system described in Configuration 1, wherein the processing unit generates a plurality of communication packets including messages equal to or less than the predetermined number based on communication packets including messages exceeding the predetermined number, and causes the forwarding unit to forward the generated communication packets. According to the vehicle control system of configuration 2, by converting communication packets that exceed the message number limit into communication packets that comply with the limit, necessary communication packets can be forwarded without being discarded, thereby achieving both detection and prevention of unauthorized communication and responsiveness of vehicle control.

[0100] (Configuration 3) The vehicle control system according to configuration 2, wherein the processing unit processes communication packets that comply with the UDP communication standard among the communication packets received by the forwarding unit. The vehicle control system of configuration 3 can detect and protect against unauthorized communications while improving the responsiveness of vehicle control, targeting communication packets of UDP communication, which tend to be used for transferring large amounts of data. In addition, by limiting the types of communication packets to be processed, the efficiency of processing can be improved.

[0101] (Configuration 4) A vehicle control system as described in Configuration 3, wherein the communication packet received by the forwarding unit includes a message number field indicating the number of messages, and the processing unit acquires each message from a communication packet that includes more than the predetermined number of messages, and generates a communication packet including each of the acquired multiple messages. According to the vehicle control system of configuration 4, by making communication packets that comply with the limit without dropping any messages contained in the communication packets in which the number of messages exceeds the limit, it is possible to detect and prevent unauthorized communication while also achieving responsiveness in vehicle control.

[0102] (Configuration 5) A vehicle control system as described in Configuration 3, wherein the communication packet received by the forwarding unit includes a MAC header and an IP header, and the forwarding unit performs processing to forward the communication packet based on the source address in the IP header, and the processing unit acquires the communication packet received by the forwarding unit from the communication network, acquires a MAC address corresponding to the source address in the IP header of the acquired communication packet by referring to a predetermined table, and generates a communication packet to which a MAC header including the acquired MAC address is attached. According to the vehicle control system of configuration 5, the processing unit can acquire and process communication packets from the layer where the forwarding unit processes IP packets excluding the MAC header. This allows communication packets to be processed without increasing the load on the forwarding unit, thereby achieving even greater efficiency.

[0103] (Configuration 6) The vehicle control system described in Configuration 4, wherein the processing unit performs processing to change the message number field of a communication packet generated from a communication packet containing messages exceeding the predetermined number to less than the predetermined number, and then forwards the packet using the forwarding unit. According to the vehicle control system of configuration 6, the communication packet processed by the processing unit can be reliably transferred by the transfer unit.

[0104] (Configuration 7) A vehicle control system as described in Configuration 6, wherein the processing unit, after completing processing of the message number fields of multiple communication packets generated from communication packets containing more than the predetermined number of messages, causes the processing-completed multiple communication packets to be forwarded by the forwarding unit. According to the vehicle control system of configuration 7, messages contained in a communication packet in which the number of messages exceeds the limit can be processed by the transfer unit without causing a large time difference.

[0105] (Configuration 8) A vehicle control system according to any one of configurations 1 to 7, wherein the forwarding unit determines whether to allow forwarding of each communication packet received from the communication network that contains the predetermined number of messages or less, and forwards the communication packets that are allowed to be forwarded. According to the vehicle control system of configuration 8, detection and protection against unauthorized communications can be realized by detecting unauthorized communications packets to be transferred. [Explanation of symbols]

[0106] 1...vehicle control system, 2...vehicle, 3...first control device group, 4...second control device group, 5...routing device (transfer unit), 6, 7...ECU, 6a...drive ECU, 6b...steering ECU, 6c...battery ECU, 6d...ADAS-ECU, 7a...TCU, 7b...IVI-ECU, 7c...DMC-ECU, 8...communication management device, 9...first communication network, 10...second communication network, 20...communication unit, 21...input / output port, 22...frame buffer, 23...switch unit, 24...route determination unit, 25...gate unit, 26...transfer judgment unit, 261...condition storage memory, 262...search circuit, 27...management unit, 100...vehicle control unit, 110...processing device (processing unit), 111...frame processing unit, 113...ARP table 113, 281, 282, 283, 284, 285, 286...bit string unit.

Claims

1. A vehicle control system mounted on a vehicle, a forwarding unit connected to a first control device group connected to a first communication network and a second control device group connected to a second communication network different from the first communication network, and configured to forward communication packets including messages between communication networks including the first communication network and the second communication network; a processing unit that processes communication packets that include more than a predetermined number of messages among the communication packets received by the forwarding unit from the communication network, the forwarding unit forwards communication packets including the predetermined number or less of the messages; The processing unit performs processing to enable the forwarding unit to forward communication packets containing more than a predetermined number of the messages.

2. 2. The vehicle control system according to claim 1, wherein the processing unit generates a plurality of communication packets including messages equal to or less than the predetermined number based on a communication packet including messages exceeding the predetermined number, and causes the forwarding unit to forward the generated communication packets.

3. The vehicle control system according to claim 2 , wherein the processing unit processes communication packets that comply with the User Datagram Protocol (UDP) communication standard, among the communication packets received by the forwarding unit.

4. The communication packet received by the forwarding unit includes a message number field indicating the number of messages, The vehicle control system according to claim 3 , wherein the processing unit acquires each message from a communication packet including more than the predetermined number of messages, and generates a communication packet including each of the acquired messages.

5. The communication packet received by the transfer unit includes a MAC (Media Access Control) header and an IP (Internet Protocol) header, the forwarding unit performs a process of forwarding a communication packet based on a source address in an IP header, The processing unit The transfer unit acquires a communication packet received from the communication network, The MAC address corresponding to the source address in the IP header of the acquired communication packet is acquired by referring to a predetermined table. The vehicle control system according to claim 3, wherein a communication packet is generated to which a MAC header including the acquired MAC address is added.

6. 5. The vehicle control system according to claim 4, wherein the processing unit performs processing to change a message number field of a communication packet generated from a communication packet including more than the predetermined number of messages to a value equal to or less than the predetermined number, and then causes the communication packet to be forwarded by the forwarding unit.

7. 7. The vehicle control system according to claim 6, wherein the processing unit, after completing processing of the message number fields of the plurality of communication packets generated from the communication packet including the message exceeding the predetermined number, causes the transfer unit to transfer the plurality of processed communication packets.

8. 2. The vehicle control system according to claim 1, wherein the forwarding unit determines whether to permit forwarding of each communication packet received from the communication network that includes the predetermined number of messages or less, and forwards the communication packets that are permitted to be forwarded.

Images