Anomaly detection method, recording medium, and anomaly detection system

By setting up a detection unit in the vehicle network system and determining the associated output of the detection results, the problems of high cost and vulnerability to attack in the prior art are solved, and a more secure vehicle network system is achieved.

CN114450683BActive Publication Date: 2026-06-19PANASONIC INTELLECTUAL PROPERTY CORP OF AMERICA

Patent Information

Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
PANASONIC INTELLECTUAL PROPERTY CORP OF AMERICA
Filing Date
2020-12-11
Publication Date
2026-06-19

AI Technical Summary

Technical Problem

Existing technologies for detecting anomalies in vehicular network systems are costly and vulnerable to attack, and the detection function itself becomes a target for attack, resulting in insufficient security.

Method used

A detection unit is set up in the vehicle network system to determine whether the message meets the predetermined rules and store the detection result in the memory. It determines whether the detection result is received within a predetermined time, associates the determination result with the detection result and outputs it. It analyzes the result through an external device to determine whether it is a system abnormality or a detection unit abnormality.

Benefits of technology

A safer in-vehicle network system has been implemented, which can distinguish between system malfunctions and detection unit malfunctions, thereby improving overall security.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN114450683B_ABST
    Figure CN114450683B_ABST
Patent Text Reader

Abstract

An anomaly detection method is an anomaly detection method in an in-vehicle network system in which multiple ECUs are connected. At least one of the multiple ECUs has a detection unit that determines whether a received message meets a predetermined rule and sends the determined detection result to the network. The anomaly detection method includes the following processing: (i) receiving the detection result from the network and storing the received detection result in a memory; (ii) determining whether the detection result is received within a predetermined time and storing the determination result in a memory in association with the detection result; (iii) outputting a message containing the detection result associated with the determination result to the outside.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This disclosure relates to anomaly detection methods, recording media, and anomaly detection systems for detecting anomalies in vehicular network systems. Background Technology

[0002] In recent years, many devices called Electronic Control Units (ECUs) have been installed in automotive systems. The network connecting these ECUs is called the in-vehicle network. Many standards exist for in-vehicle networks. One of the most mainstream standards is CAN (Controller Area Network), as specified in ISO 11898-1. In CAN, the communication path consists of two buses, and the ECUs connected to these buses are called nodes. Each node connected to the bus sends and receives messages (messages) called frames. In CAN, there are no identifiers indicating the destination or source node; the sending node assigns an ID called a message ID to each frame before sending, and each receiving node only receives the predetermined message ID. Therefore, there is a threat: by connecting an ECU to the CAN bus, impersonating a legitimate ECU to send frames containing abnormal control commands, it is possible to abnormally (illegally) control the vehicle.

[0003] To address the aforementioned threat, a method for detecting abnormal messages has been proposed, which typically involves attaching a Message Authentication Code (MAC) to the data field in the CAN bus before transmission (Patent Document 1). Additionally, as a method for detecting abnormal messages without using an encryption key, a method for detecting abnormal message injection by observing the period between messages has been proposed (Patent Document 2).

[0004] Existing technical documents

[0005] Patent Document 1: Japanese Patent No. 5770602

[0006] Patent Document 2: Japanese Patent No. 5919205 Summary of the Invention

[0007] The problem that the invention aims to solve

[0008] However, in Patent Document 1, since abnormal message detection is achieved by having both parties maintain the encryption key, it is not only costly but also prone to failure if the key is leaked. Furthermore, Patent Document 2 suffers from the following problem: when detecting abnormal message injection solely through periodic observations, the detection function itself becomes a target for attack, rendering the detection function ineffective.

[0009] Therefore, in order to solve the above problems, this disclosure aims to provide anomaly detection methods for achieving a more secure in-vehicle network system.

[0010] Technical solutions for solving the problem

[0011] To achieve the above objectives, an anomaly detection method, as a technical solution of this disclosure, is an anomaly detection method in an in-vehicle network system in which multiple electronic control devices are connected. At least one of the multiple electronic control devices has a detection unit that determines whether a received message meets a predetermined rule, and sends the determined detection result to the network. The anomaly detection method includes the following processing: (i) receiving the detection result from the network and storing the received detection result in a memory; (ii) determining whether a detection result is received within a predetermined time, associating the determination result with the detection result, and storing it in the memory; (iii) outputting a message containing the detection result associated with the determination result to the outside.

[0012] Invention Effects

[0013] According to this disclosure, a more secure in-vehicle network system can be achieved. Attached Figure Description

[0014] Figure 1 This is a diagram illustrating an example of the overall configuration of the vehicle network system in Implementation Method 1.

[0015] Figure 2 This is a diagram illustrating an example of the configuration of the ECU in Embodiment 1.

[0016] Figure 3 This is a diagram illustrating an example of the detection rules in Implementation Method 1.

[0017] Figure 4 This is a diagram illustrating an example of the configuration of the GW-ECU in Embodiment 1.

[0018] Figure 5 This is a diagram illustrating an example of the format of the detection result status message in Implementation 1.

[0019] Figure 6 This is a diagram illustrating an example of the detection result management table in Implementation Method 1.

[0020] Figure 7 This is a diagram illustrating an example of the configuration of the communication ECU in Embodiment 1.

[0021] Figure 8 This is a diagram illustrating an example of the configuration of the server in Implementation Method 1.

[0022] Figure 9This is a diagram illustrating an example of the sequence related to communication of detection results in Implementation 1.

[0023] Figure 10 This is a diagram illustrating an example of the timing related to flag setting in Implementation 1.

[0024] Figure 11 This is a diagram illustrating an example of the configuration of the ECU in a variation of Embodiment 1.

[0025] Figure 12 This is a diagram illustrating an example of the overall configuration of the vehicle network system in Implementation Method 2.

[0026] Figure 13 This is a diagram illustrating an example of the detection rules in Implementation Method 2.

[0027] Figure 14 This is a diagram illustrating an example of the configuration of the GW-ECU in Embodiment 2.

[0028] Figure 15 This is a diagram illustrating an example of the format of the detection result status message in Implementation Method 2.

[0029] Figure 16 This is a diagram illustrating an example of a detection result management table in Implementation Method 2.

[0030] Figure 17 This is a diagram illustrating an example of the configuration of the communication ECU in Embodiment 2.

[0031] Figure 18 This is a diagram showing an example of the configuration of IVI in Embodiment 2.

[0032] Figure 19 This is a diagram illustrating an example of the timing related to communication of detection results in Implementation 2.

[0033] Figure 20 This is a diagram illustrating an example of the timing related to flag setting in Implementation Method 2.

[0034] Figure 21 This is a diagram illustrating an example of the format of the detection result status message in a variation of Embodiment 2, Example 1.

[0035] Figure 22 This is a diagram illustrating an example of the configuration of the GW-ECU in a variation of Embodiment 2.

[0036] Figure 23 This is a diagram illustrating an example of the configuration of the GW-ECU in Modification 3 of Embodiment 2.

[0037] Figure 24This is a diagram illustrating an example of the timing related to flag setting in a variation 3 of implementation method 2. Detailed Implementation

[0038] An anomaly detection method in one embodiment of this disclosure is an anomaly detection method in an in-vehicle network system in which multiple electronic control devices are connected. At least one of the multiple electronic control devices has a detection unit that determines whether a received message meets a predetermined rule and sends the determined detection result to the network. The anomaly detection method includes the following processing: (i) receiving the detection result from the network and storing the received detection result in a memory; (ii) determining whether a detection result is received within a predetermined time and storing the determination result in the memory in association with the detection result; (iii) outputting a message containing the detection result associated with the determination result to the outside.

[0039] While electronic control devices connected to in-vehicle network systems are equipped with detection units to detect anomalies within the system, there is a possibility that these units may malfunction due to attacks. The detection unit sends its findings to the network, but in cases of malfunction, it may fail to receive the results within a predetermined timeframe. In other words, if a result is not received within the predetermined time, there is a possibility that the detection unit itself has malfunctioned. Therefore, this disclosure associates a determination of whether a result was received within the predetermined timeframe with the actual detection result, and outputs a message containing this associated detection result to an external device. This allows external devices to analyze the associated detection result and appropriately distinguish whether the anomaly occurred within the in-vehicle network system or was caused by a malfunction in the detection unit itself. This ensures overall vehicle security and enables a more secure in-vehicle network system.

[0040] Alternatively, in (i), detection results can be received periodically from the network and stored in the memory each time; in (ii), if no detection result is received within the predetermined time, the determination result can be associated with the last received detection result and stored in the memory.

[0041] The testing department periodically sends the determined test results to the network. However, in cases where the testing department itself malfunctions, it may sometimes fail to receive the test results from the network within the scheduled time. Therefore, in this solution, when a test result is not received within the scheduled time, the determination result is associated with the last received test result, and a message containing the associated determination result is output to an external device on the vehicle. Thus, external devices can analyze the test result associated with the determination result to appropriately distinguish whether the malfunction occurred within the vehicle network system or within the testing department itself.

[0042] Alternatively, in (i), the received detection result may also be associated with the time of receipt and stored. In (ii), if no detection result is received within the predetermined time, it may be determined whether the last received detection result is the latest detection result based on the time associated with the last received detection result. If the last received detection result is not the latest detection result, the determination result may be associated with the last received detection result and stored in the memory.

[0043] For example, based on the time the detection result is received, it can be determined whether the detection result is the latest. If a detection result is not received within the predetermined time, and the last received detection result is not the latest, there is a possibility that the detection unit itself has malfunctioned; therefore, the determination result is associated with the last received detection result. On the other hand, even if a detection result is not received within the predetermined time, if the last received detection result is the latest, the current situation is considered normal, and the determination result is not associated with the last received detection result. Furthermore, if no detection result is received after further time has passed, and the last received detection result is no longer the latest, the determination result will be associated with the last received detection result.

[0044] Alternatively, in step (ii), if a detection result is received within the predetermined time, and the detection result indicates an anomaly, a message containing the detection result may be output to the outside.

[0045] Therefore, even if a detection result is received within a predetermined time, and that detection result indicates an anomaly, a message containing the anomaly can be output to the outside. This allows external devices to analyze the anomaly.

[0046] Alternatively, the at least one electronic control device may be at least two electronic control devices. In (ii), for each of the at least two electronic control devices, it is determined whether a detection result is received within the predetermined time. If there is an electronic control device among the at least two electronic control devices that does not receive a detection result within the predetermined time, the determination result is associated with the detection result of that electronic control device and stored in the memory.

[0047] Thus, detection units for detecting anomalies in the vehicle network system can be installed in at least two electronic control devices connected to the vehicle network system.

[0048] Alternatively, the message output to the outside in (iii) may include the detection result of each of the at least two electronic control devices and the determination result associated with the detection result of each of the at least two electronic control devices.

[0049] Accordingly, the detection results of each of at least two electronic control devices and the judgment results associated with those detection results are summarized into a single message, thereby reducing the amount of communication.

[0050] Alternatively, the anomaly detection method may further include: determining the state of the vehicle in the vehicle network system, wherein in (ii), based on the state of the vehicle, it is determined whether to associate the determination result with the detection result.

[0051] Depending on the vehicle's state, there may be situations where the judgment result and the detection result are not associated. Therefore, as in this solution, by determining whether to associate the judgment result with the detection result based on the vehicle's state, appropriate information corresponding to the vehicle's state can be output.

[0052] Alternatively, the network can be an in-vehicle network through which the multiple electronic control devices send and receive messages.

[0053] Thus, the network that sends the test results from the testing department can also be an in-vehicle network where multiple electronic control devices send and receive messages.

[0054] Alternatively, the network may be a network within the at least one electronic control device.

[0055] Thus, the network that sends the test results from the testing department can also be the network within the electronic control device.

[0056] Alternatively, the detection unit may use CAN (Controller Area Network) messages, Ethernet messages, or system logs of the electronic control device as received messages to determine whether they meet the predetermined rules.

[0057] Based on this, anomalies in CAN messages, Ethernet messages, or system logs of electronic control devices can be determined.

[0058] In one embodiment of this disclosure, the recording medium is a computer-readable recording medium storing a program for causing a computer to execute the above-described anomaly detection method.

[0059] Accordingly, a recording medium can be provided that stores programs that enable a more secure in-vehicle network system.

[0060] An anomaly detection system in one embodiment of this disclosure is an anomaly detection system in an in-vehicle network system in which multiple electronic control devices are connected. At least one of the multiple electronic control devices has a detection unit that determines whether a received message meets a predetermined rule and sends the determined detection result to the network. The anomaly detection system includes: a memory that stores the detection results received from the network; a detection result management unit that determines whether a detection result is received within a predetermined time and stores the determination result in the memory in association with the detection result; and a communication unit that outputs a message containing the detection result associated with the determination result to the outside.

[0061] Therefore, an anomaly detection system can be provided to enable a more secure in-vehicle network system.

[0062] Hereinafter, with reference to the accompanying drawings, the anomaly handling method involved in the embodiments of this disclosure will be described. Furthermore, the embodiments described below represent preferred specific examples of this disclosure. That is to say, the numerical values, shapes, materials, constituent elements, configurations and connection forms of constituent elements, steps, and order of steps shown in the following embodiments are examples of this disclosure and are not intended to limit this disclosure. This disclosure is based on the description in the claims. Therefore, the constituent elements in the following embodiments that are not described in the independent claims representing the highest concept of this disclosure are not essential to achieving the subject matter of this disclosure, but are described as constituent elements of a more preferred manner.

[0063] (Implementation Method 1)

[0064] [1. System Structure]

[0065] Hereinafter, as embodiment 1 of this disclosure, the vehicle network system 1000 will be described with reference to the accompanying drawings.

[0066] [1.1 Overall Composition of the Vehicle Network System 1000]

[0067] Figure 1 This is a diagram illustrating an example of the overall configuration of the vehicle network system 1000 in Embodiment 1.

[0068] The vehicle network system 1000 consists of a vehicle 1001 and a server 1400 that operates by connecting to the vehicle 1001 via a network. In the vehicle network system 1000, multiple electronic control devices (hereinafter referred to as ECUs) that send and receive messages via various vehicle networks are connected to each other.

[0069] The vehicle 1001 is configured to include: ECUs 1100a, 1100b and 1100c connected via various vehicle networks; a brake (brake) 1011, a steering wheel 1012 and an accelerator (throttle) 1013 controlled by each ECU; a GW-ECU 1200 that relays the connections of each of the ECUs 1100a to 1100c; and a communication ECU 1300 that communicates with the GW-ECU 1200 via the vehicle network.

[0070] ECUs 1100a to 1100c communicate with each other via an in-vehicle network to control the vehicle. The in-vehicle network may use, for example, CAN.

[0071] The GW-ECU1200 communicates with other ECUs via the vehicle network and is responsible for transmitting (forwarding) data.

[0072] The communication ECU 1300 communicates with the server 1400 to send and receive messages between the server 1400 and other ECUs in the vehicle 1001.

[0073] Server 1400 remotely implements monitoring to ensure the security of vehicle 1001.

[0074] The vehicle network system 1000 includes an anomaly detection system. This anomaly detection system, designed to achieve a safer vehicle network system, includes a memory, a detection result management unit, and a communication unit. In Embodiment 1, the anomaly detection system is implemented by the GW-ECU 1200. By centralizing the functions for achieving a safer vehicle network system in a specific device (here, the GW-ECU 1200), the load on the vehicle's network can be reduced. Alternatively, these functions can be distributed among multiple devices within the vehicle, which reduces the load on each device and contributes to overall cost reduction.

[0075] At least one of the multiple ECUs in the vehicle network system 1000 has a detection unit. In Embodiment 1, ECU 1100a will be described as at least one ECU.

[0076] [1.2 ECU1100a Configuration Diagram]

[0077] Figure 2 This diagram illustrates an example of the configuration of ECU 1100a in Embodiment 1. ECU 1100a is composed of a communication unit 1101, a message conversion unit 1102, a detection unit 1103, and a detection rule holding unit 1104. Furthermore, ECUs 1100b and 1100c have the same configuration as ECU 1100a, therefore, their descriptions are omitted here.

[0078] The communication unit 1101 communicates with various sensors or other ECUs via the vehicle network. The communication unit 1101 notifies the message conversion unit 1102 of received messages or sensor values. Additionally, the communication unit 1101 sends messages notified by the message conversion unit 1102 or the detection unit 1103 to other ECUs or various sensors.

[0079] The message conversion unit 1102 converts sensor values ​​received from various sensors via the communication unit 1101 into a format based on the vehicle network, and then sends them to other ECUs via the communication unit 1101. Additionally, the message conversion unit 1102 converts communication messages received from the communication unit 1101 into sensor values ​​or setting information, and then sends this information to various sensors via the communication unit 1101. Furthermore, the message conversion unit 1102 notifies the detection unit 1103 of the received sensor values ​​or messages.

[0080] The detection unit 1103 determines whether a received message meets a predetermined rule. Specifically, the detection unit 1103 uses the detection rules maintained by the detection rule holding unit 1104 to determine the received message. The detection unit 1103 sends the determined detection result (in other words, the detection result representing the result of the determination by the detection unit 1103) to the network (specifically, periodically). In Embodiment 1, this network is an in-vehicle network in which multiple ECUs transmit and receive messages.

[0081] The detection rule holding unit 1104 holds the detection rules used by the detection unit 1103. Figure 3 This is an example of a detection rule.

[0082] [An example of a detection rule in section 1.3]

[0083] Figure 3 This is a diagram illustrating an example of the detection rules in Implementation Method 1. Figure 3The detection rules shown include rules for detecting anomalies in messages from the vehicle network. Specifically, the detection rules include a rule number (No.), the category of the data being judged, the ID of the data being judged, the content of the data with that ID, and a judgment rule (predetermined rule). For example, if the data contained in the received message is outside the range of the judgment rule, the detection result is NG (Not Good); if the data contained in the received message is within the range of the judgment rule, the detection result is OK (Good). For example, the detection unit 1103 of ECU 1100a determines whether a message received from the brake 1011 meets the predetermined rule. If the value of the data (brake pedal position) of ID1 contained in the message is outside the range of 0 to 100, the detection unit 1103 determines it as NG as a detection result and sends the determination result to the vehicle network.

[0084] [Structure diagram of 1.4GW-ECU1200]

[0085] Figure 4 This diagram illustrates an example of the configuration of the GW-ECU1200 in Embodiment 1. As described above, in Embodiment 1, the GW-ECU1200 is an example of an anomaly detection system. The GW-ECU1200 consists of a communication unit 1201, a detection result management unit 1202, a detection result holding unit 1203, and a transmission processing unit 1204.

[0086] The communication unit 1201 communicates with other ECUs via the vehicle network and notifies the detection result management unit 1202 and the transmission processing unit 1204 of received messages. Additionally, the communication unit 1201 sends the messages notified by the detection result management unit 1202 and the transmission processing unit 1204 to other ECUs.

[0087] The test result management unit 1202 obtains the test results based on the received message related to the test results notified by the communication unit 1201, and saves (stores) the test results along with surrounding information to the test result storage unit 1203. In addition, the test result management unit 1202 determines the test result status of each ECU (e.g., ECU 1100a) from the stored content of the test result storage unit 1203, and sends the test result status message to the communication ECU 1300 via the communication unit 1201. Figure 5 An example of a message format representing a test result status message. Details will be described later. The test result management unit 1202 determines whether a test result has been received within a predetermined time and stores the determination result in the test result storage unit 1203, associating the determination result with the test result. The message containing the test result associated with the determination result is called a test result status message.

[0088] The detection result holding unit 1203 is an example of a memory that stores detection results received from the network. The detection result holding unit 1203 stores and holds detection result data received from the detection result management unit 1202. Furthermore, the detection result holding unit 1203 notifies the detection result data based on a read instruction from the detection result management unit 1202. Figure 6 This refers to an example of specific content to be retained.

[0089] The transmission processing unit 1204 performs message transmission processing within the vehicle 1001 according to predetermined rules. In this embodiment, the received messages are transmitted to all other ECUs.

[0090] [1.5 An example of the format of a detection result status message]

[0091] Figure 5 This is a diagram illustrating an example of the format of the detection result status message in Implementation 1. The payload consists of a detection result header D1101, a detection unit ID D1102, a flag D1103, and a detection result payload D1104.

[0092] The detection result header D1101 is a region used to store the category and quantity values ​​of the data that follows. By placing a predetermined number at the beginning, it serves to convey the content of the detection result to the receiver while simultaneously presenting the subsequent data as a message indicating the status of the detection result.

[0093] The detection unit ID D1102 stores a number used to identify the detection unit 1103 in ECUs 1100a, 1100b, and 1100c. In other words, each detection unit 1103 in ECUs 1100a, 1100b, and 1100c is associated with a different detection unit ID, and based on the detection unit ID D1102, it is possible to determine which ECU's detection unit 1103 determined the received detection result.

[0094] Flag D1103 indicates whether the detection result from detection unit 1103, as determined by detection unit ID D1102, has been received normally. In other words, flag D1103 is an example of a determination result indicating whether the detection result was received within a predetermined time. The determination of whether the detection result was received normally can be based on whether the detection result was received within the predetermined time. A determination result in flag D1103 indicating that if the detection result was not received within the predetermined time, there is a possibility that detection unit 1103 has entered a state of not sending detection results periodically, or that detection unit 1103 itself has malfunctioned.

[0095] The detection result payload D1104 is an example of a detection result determined by the detection unit 1103. The detection result status message stored in the detection result holding unit 1203 contains a determination result associated with the detection result.

[0096] [1.6 An example of a test result management table]

[0097] Figure 6 This diagram illustrates an example of the detection result management table in Implementation Method 1. The detection result management table is maintained by the detection result holding unit 1203. The detection result management table consists of the detection unit ID, object data, final detection result, and the final detection result reception time.

[0098] The detection unit ID is a number used to identify the detection unit installed in each ECU. For example, the detection unit with detection unit ID "1" can be identified as detection unit 1103 installed in ECU 1100a, the detection unit with detection unit ID "2" can be identified as detection unit 1103 installed in ECU 1100b, and the detection unit with detection unit ID "3" can be identified as detection unit 1103 installed in ECU 1100c.

[0099] The term "object data" refers to the type of data on which the stored detection results were obtained. For example, the detection results in the detection unit 1103 of each of ECUs 1100a to 1100c represent results obtained by detecting CAN messages.

[0100] The so-called final test result refers to the last test result received from the test results periodically received by the testing department 1103.

[0101] The final detection result reception time refers to the time when the last received detection result is received. In the detection result holding unit 1203, the received detection result is stored in association with the reception time.

[0102] [1.7 Schematic diagram of the communication ECU1300]

[0103] Figure 7 This diagram illustrates an example of the configuration of the communication ECU 1300 in Embodiment 1. The communication ECU 1300 consists of an in-vehicle communication unit 1301, a conversion unit 1302, and an external communication unit 1303.

[0104] The in-vehicle communication unit 1301 notifies the conversion unit 1302 of messages received from other ECUs within the vehicle 1001. Additionally, the in-vehicle communication unit 1301 sends messages notified by the conversion unit 1302 to other ECUs within the vehicle 1001.

[0105] The conversion unit 1302 converts the data to be transmitted in the message received via the in-vehicle communication unit 1301 into a predetermined format and sends it to the external communication unit 1303. Additionally, the conversion unit 1302 converts the data to be transmitted in the message received via the external communication unit 1303 into a predetermined format and sends it to the in-vehicle communication unit 1301.

[0106] The external communication unit 1303 notifies the conversion unit 1302 of the message received from the server 1400. In addition, the external communication unit 1303 sends the message notified by the conversion unit 1302 to the server 1400.

[0107] [Diagram of Server 1.8 1400]

[0108] Figure 8 This diagram illustrates the configuration of server 1400 in Embodiment 1. Server 1400 consists of a communication unit 1401 and a vehicle management unit 1402.

[0109] The communications unit 1401 communicates with the vehicle 1001 and notifies the vehicle management unit 1402 of the received message. Additionally, it sends the content notified by the vehicle management unit 1402 to the vehicle 1001.

[0110] The vehicle management unit 1402 communicates with the vehicle 1001 via the communication unit 1401, and manages whether the detection unit in the vehicle 1001 used for detecting anomalies is working properly based on the message received from the vehicle 1001 containing the detection result associated with the judgment result.

[0111] [1.9 An example of communication timing for detection results]

[0112] Figure 9 This is a diagram illustrating an example of the timing related to the communication of detection results in Implementation Method 1. Furthermore, Figure 9 This is also a timing diagram illustrating an example of the anomaly detection method in Implementation Method 1. Figure 9 The image shows an example of the timing sequence in which ECU1100a notifies GW-ECU1200 of the detection results and transmits the results obtained from the judgment in GW-ECU1200 to communication ECU1300.

[0113] (S1101) GW-ECU1200 waits to receive the detection result from ECU1100a within a predetermined time. ECU1100a sends the detection result (specifically, a message containing the detection result) to the network, GW-ECU1200 receives the detection result from the network, and stores the received detection result in a predetermined location (e.g., detection result holding unit 1203). Specifically, ECU1100a periodically sends the detection result to the network, GW-ECU1200 periodically receives the detection result from the network, and stores the received detection result in the detection result holding unit 1203 each time. In addition, ECUs1100b and 1100c also send detection results in the same manner as ECU1100a, and GW-ECU1200 also receives detection results from ECUs1100b and 1100c, but here we will focus on ECU1100a for explanation.

[0114] (S1102) GW-ECU1200 determines whether a detection result has been received within a predetermined time (e.g., within a predetermined time from the last received detection result). If no detection result is received within the predetermined time, GW-ECU1200 proceeds to S1103; if a detection result is received, it proceeds to S1104. The predetermined time is not particularly limited and can be determined, for example, based on the reception interval of detection results periodically received from the normal ECU1100a.

[0115] (S1103) The GW-ECU1200 performs processing for setting flags for messages. Details of the processing are provided using... Figure 10 To illustrate.

[0116] (S1104) When the GW-ECU1200 receives the detection result within a predetermined time, it determines whether the received detection result contains an NG result. If the result does not contain an NG result, it proceeds to S1101, and if the result does contain an NG result, it proceeds to S1105.

[0117] (S1105) GW-ECU1200 determines the status of ECU1100a that sent the detection results according to a pre-determined algorithm. In this embodiment, even if only one NG result is received, it is determined that ECU1100a has been attacked. Conversely, if an OK result is received, it is determined that the ECU is normal.

[0118] (S1106) The GW-ECU1200 sends the judgment result of S1105 to the communication ECU1300. For example, if the GW-ECU1200 receives a detection result within a predetermined time and the detection result indicates an anomaly, it outputs a message containing the detection result to the outside (server 1400). In addition, the GW-ECU1200 outputs the detection result associated with the judgment result indicating whether the detection result was received within the predetermined time to the outside via the communication ECU1300.

[0119] (S1107) GW-ECU1200 completes a series of processes and returns to S1101.

[0120] [1.10 An example of flag processing timing]

[0121] Figure 10 This is a diagram illustrating an example of the timing related to flag setting in Implementation 1. Figure 10 This is an example of the timing sequence for setting a flag when the GW-ECU1200 fails to receive a detection result from the ECU1100a within a predetermined time.

[0122] (S1201) The GW-ECU1200 obtains information about the last received detection result. Specifically, if the GW-ECU1200 does not receive a detection result within a predetermined time, it obtains the moment when the last received detection result was received.

[0123] (S1202) The GW-ECU1200 determines whether it has successfully received the latest detection result. Specifically, if the GW-ECU1200 has not received a detection result within a predetermined time, it determines whether the last received detection result is the latest detection result based on the time associated with the last received detection result. If the last received detection result is not the latest detection result, that is, if the final detection result is old information, it proceeds to S1203.

[0124] (S1203) GW-ECU1200 sets a message for notifying ECU1100a of its status. Figure 5 The flag area of ​​the detection result status message shown. Specifically, the GW-ECU 1200 stores a determination result indicating that no detection result was received within a predetermined time in the detection result holding unit 1203, associating it with the last received detection result. In other words, a determination result indicating the possibility that the detection unit 1103 of ECU 1100a itself has malfunctioned is stored in association with the last received detection result. Furthermore, a message containing this detection result is output to the outside of the vehicle 1001 and parsed.

[0125] (Effects of Implementation Method 1)

[0126] In the vehicle network system 1000 shown in Embodiment 1, a device (e.g., server 1400) outside the vehicle 1001 can appropriately distinguish whether an abnormality has occurred within the vehicle network system 1000 or whether the detection unit 1103 itself has malfunctioned, thus ensuring the overall safety of the vehicle 1001.

[0127] (A variation of Implementation Method 1)

[0128] In the vehicle network system 1000 shown in Embodiment 1, an example is described where the GW-ECU 1200, which is different from the ECU 1100a having the detection unit 1103, has a detection result management unit 1202. However, it is also possible for the ECU having the detection unit to maintain the detection result management unit. Furthermore, for the same drawings as in Embodiment 1, the description is omitted, so only the ECU 11100a, which is different from the ECU 1100a, will be described here.

[0129] In a variation of Embodiment 1, ECU 11100a will be described as at least one ECU having a detection unit. In this variation of Embodiment 1, the anomaly detection system is implemented by ECU 11100a.

[0130] [1.11 ECU11100a Configuration Diagram]

[0131] Figure 11 This diagram illustrates an example of the configuration of ECU 11100a in a variation of Embodiment 1. ECU 11100a is composed of a communication unit 1101, a message conversion unit 1102, a detection unit 11103, a detection rule holding unit 1104, a detection result management unit 11105, and a detection result holding unit 11106. Furthermore, ECUs 11100b and 11100c (not shown), which correspond to ECUs 1100b and 1100c in Embodiment 1, have the same configuration as ECU 11100a, therefore, their description is omitted here.

[0132] The detection unit 11103 determines whether a received message meets a predetermined rule. Specifically, the detection unit 11103 uses the detection rules maintained by the detection rule holding unit 1104 to determine the received message. The detection unit 11103 sends the determined detection result (specifically, periodically) to the network to notify the detection result management unit 11105. In a variation of Embodiment 1, this network is the network within the ECU 11100a, specifically the bus within the ECU 11100a that connects the detection unit 11103 and the detection result management unit 11105.

[0133] The test result management unit 11105 saves the test results notified by the test unit 11103, along with surrounding information, to the test result storage unit 11106. Furthermore, the test result management unit 11105 determines the test result status of the test unit 11103 from the stored content in the test result storage unit 11106, and sends a test result status message to the communication ECU 1300 via the communication unit 1101. An example of the message format for the test result status message is... Figure 5 The functions shown are the same, so the description is omitted. Furthermore, the other functions of the detection result management unit 11105 are the same as those of the detection result management unit 1202 in Embodiment 1, so the description is omitted.

[0134] The test result retention unit 11106 stores and retains the test result data received from the test result management unit 11105. Furthermore, it notifies the user of the test result data based on a read instruction from the test result management unit 11105. An example of the specific content to be retained is... Figure 6 The same applies as shown, therefore the explanation is omitted.

[0135] (Effects of variations of Implementation Method 1)

[0136] In the vehicle network system shown in the modified embodiment 1, each of the ECUs 11100a to 11100c has a detection result management unit 11105, which determines whether its own detection unit 11103 has malfunctioned. Therefore, even if malfunctions occur simultaneously in multiple locations of the vehicle network (specifically, two or more of the ECUs 11100a to 11100c), an external device can appropriately distinguish whether the malfunction occurred within the vehicle network system or in the detection unit 11103 itself, ensuring the overall safety of the vehicle. Furthermore, since the determination is performed within the ECU, which is close to the actual source of the malfunction within the vehicle, early intervention is possible. Additionally, by having a detection unit 11103 and a detection result management unit 11105 in a single ECU, the network load within the vehicle can be reduced.

[0137] (Implementation Method 2)

[0138] In the vehicle network system 1000 shown in Embodiment 1, such as Figure 5 The illustration shows an example where a detection result status message contains only the detection result of the detection unit 1103 of a specific ECU. In Embodiment 2, an example where a detection result status message contains the detection results of multiple detection units will be described with reference to the accompanying drawings. Furthermore, descriptions of the same drawings as in Embodiment 1 are omitted.

[0139] [2. System Structure]

[0140] Here, as Embodiment 2 of this disclosure, the vehicle network system 2000 will be described with reference to the accompanying drawings. Furthermore, for configurations identical to those in Embodiment 1, descriptions will be omitted with the same reference numerals.

[0141] [2.1 Overall Structure of the Vehicle Network System 2000]

[0142] Figure 12 This diagram illustrates an example of the overall configuration of the vehicle network system 2000 in Embodiment 2. In the vehicle network system 2000, multiple ECUs that transmit and receive messages via various vehicle networks are connected to each other.

[0143] The vehicle network system 2000 consists of a vehicle 2001 and a server 1400 that operates by connecting to the vehicle 2001 via a network.

[0144] The vehicle 2001 is configured to include: ECUs 1100a, 1100b, and 1100c connected via various in-vehicle networks; a brake 1011, a steering wheel 1012, and an accelerator 1013 controlled by each ECU; a GW-ECU 2200 that relays the connection between ECUs 1100a to 1100c; a communication ECU 2300 that communicates with the GW-ECU 2200 via the in-vehicle network; and an IVI (In-Vehicle Infotainment system) 2500 that has a screen capable of displaying information to the driver.

[0145] The GW-ECU2200 communicates with other ECUs via the vehicle network and is responsible for processing the transmitted data.

[0146] The communication ECU2300 communicates with the server 1400 to send and receive messages between the server 1400 and other ECUs in the vehicle 2001.

[0147] The IVI2500 is an ECU that communicates with other ECUs via the GW-ECU2200 and displays information from within the vehicle 2001 to the driver. The IVI2500 connects to the GW-ECU2200, for example, via Ethernet.

[0148] The vehicle network system 2000 includes an anomaly detection system. This anomaly detection system, designed to enhance the security of the vehicle network system, comprises a memory, a detection result management unit, and a communication unit. In embodiment 2, the anomaly detection system is implemented by the GW-ECU 2200.

[0149] At least two of the multiple ECUs in the vehicle network system 2000 each have a detection unit. In Embodiment 2, ECUs 1100a to 1100c, communication ECU 2300, and IVI 2500 will be described as at least two ECUs.

[0150] [An example of a detection rule in section 2.2]

[0151] Figure 13 This is a diagram illustrating an example of the detection rules in Implementation Method 2. Figure 13 The detection rules shown include rules for detecting anomalies in messages from the vehicular network. Specifically, the detection rules include a rule number (No.), the category of the data being judged, the ID of the data being judged, the content of the data with that ID, and the judgment rule (predefined rule). For example, if the data contained in the received message or log is outside the scope of the judgment rule, the detection result is an error (NG); if the data contained in the received message or log is within the scope of the judgment rule, the detection result is normal (OK).

[0152] For example, the detection unit 1103 of ECU1100a determines whether a predetermined rule is met based on the message obtained from the brake 1011. If the value of the ID1 data (brake pedal position) contained in the message is outside the range of 0 to 100, the detection unit 1103 of ECU1100a determines it as NG as a detection result and sends the determination result to the vehicle network.

[0153] For example, the detection unit 1103 of ECU1100b determines whether a predetermined rule is met based on the message received from the steering wheel 1012. If the value of the ID2 data (steering wheel angle) contained in the message is outside the range of -540 to 540, the detection unit 1103 of ECU1100b determines it as NG as a detection result and sends the determination result to the vehicle network.

[0154] For example, the detection unit 1103 of ECU 1100c determines whether a predetermined rule is met based on the message received from accelerator 1013. If the value of the ID3 data (accelerator opening) contained in the message is outside the range of 0 to 100, the detection unit 1103 of ECU 1100c determines it as NG as a detection result and sends the determination result to the vehicle network.

[0155] For example, the detection unit 2503 of the IVI2500 (see below) Figure 18For Ether messages, it is determined whether they meet predetermined rules. If the value of the ID1 data (transmission frequency per unit time) contained in the message is 100 or higher, the detection unit 2503 determines it as NG as a detection result and sends the determination result to the vehicle network.

[0156] For example, the detection unit 2304 of the communication ECU 2300 (see below) Figure 17 The system log is checked to determine whether it meets predetermined rules. If the value of ID1 data (communication error frequency) in the system log is 100 or higher, the detection unit 2304 determines it as NG as a detection result and sends the determination result to the vehicle network.

[0157] [Structure diagram of 2.3GW-ECU2200]

[0158] Figure 14 This diagram illustrates an example of the configuration of the GW-ECU2200 in Embodiment 2. As described above, in Embodiment 2, the GW-ECU2200 is an example of an anomaly detection system. The GW-ECU2200 consists of a communication unit 1201, a detection result management unit 2202, a detection result holding unit 2203, and a transmission processing unit 1204.

[0159] The test result management unit 2202 obtains the test results based on the received message related to the test results notified by the communication unit 1201, and saves them along with surrounding information to the test result storage unit 2203. In addition, the test result management unit 2202 determines the test result status of each ECU (e.g., ECUs 1100a to 1100c, communication ECU 2300, and IVI 2500) from the stored content of the test result storage unit 2203, and sends the test result status message to the communication ECU 2300 via the communication unit 1201. Figure 15 An example of a message format for representing a test result status message. Details will be described later. The test result management unit 2202 determines whether a test result has been received within a predetermined time for each of the ECUs 1100a to 1100c, the communication ECU 2300, and the IVI 2500. If any of the ECUs 1100a to 1100c, the communication ECU 2300, and the IVI 2500 has not received a test result within the predetermined time, the determination result is associated with the test result for that ECU and stored in the test result holding unit 2203.

[0160] The detection result holding unit 2203 is an example of a memory that stores detection results received from the network. The detection result holding unit 2203 stores and holds detection result data received from the detection result management unit 2202. Furthermore, the detection result holding unit 2203 notifies the user of the detection result data based on a read instruction from the detection result management unit 2202. Figure 16 This refers to an example of specific content to be retained.

[0161] [Example of the format for a detection result status message in section 2.4]

[0162] Figure 15 This diagram illustrates an example of the format of the detection result status message in Embodiment 2. The payload consists of a detection result header D1101, a detection unit ID D1102, a flag D1103, and a detection result payload D1104. The structure is the same as in Embodiment 1, so the description is omitted. However, as shown in this diagram, flags for multiple detection units can also be placed in a single message. In other words, in Embodiment 2, the detection result status message includes the detection results of each of the ECUs 1100a-1100c, the communication ECU 2300, and the IVI 2500, as well as flags (judgment results) associated with the detection results of each of the ECUs 1100a-1100c, the communication ECU 2300, and the IVI 2500.

[0163] [Example of a test result management table (2.5)]

[0164] Figure 16 This diagram illustrates an example of the detection result management table in Embodiment 2. The detection result management table is maintained by the detection result holding unit 2203. The detection result management table consists of the detection unit ID, object data, final detection result, and the final detection result reception time. For structures identical to those in Embodiment 1, further explanation is omitted.

[0165] For example, the detection unit with detection unit ID "4" can be identified as detection unit 2503 installed in IVI2500, and the detection unit with detection unit ID "5" can be identified as detection unit 2304 installed in communication ECU2300.

[0166] For example, the detection result in the detection unit 2503 of the IVI2500 represents the result obtained by detecting Ether messages, and the detection result in the detection unit 2304 of the communication ECU2300 represents the result obtained by detecting system logs.

[0167] [2.6 Component diagram of the communication ECU2300]

[0168] Figure 17This diagram illustrates an example of the configuration of the communication ECU 2300 in Embodiment 2. The communication ECU 2300 consists of an in-vehicle communication unit 2301, a conversion unit 1302, an external communication unit 2303, a detection unit 2304, and a detection rule holding unit 2305.

[0169] The in-vehicle communication unit 2301 notifies the conversion unit 1302 of messages received from other ECUs within the vehicle 2001. Additionally, the in-vehicle communication unit 2301 sends messages notified by the conversion unit 1302 and the detection unit 2304 to other ECUs within the vehicle 2001.

[0170] The external communication unit 2303 notifies the conversion unit 1302 of the message received from the server 1400. Additionally, the external communication unit 2303 sends the message notified by the conversion unit 1302 to the server 1400. Furthermore, the external communication unit 2303 notifies the detection unit 2304 of the system logs related to the communication.

[0171] The detection unit 2304 determines whether the received message (specifically, a system log related to communication) meets predetermined rules. Specifically, the detection unit 2304 uses the detection rules maintained by the detection rule holding unit 2305 to thoroughly examine the communication-related system log notified by the external communication unit 2303, and periodically sends the status of whether no communication errors have occurred to the network via the in-vehicle communication unit 2301, notifying the GW-ECU 2200. In Embodiment 2, this network is an in-vehicle network where multiple ECUs transmit and receive messages.

[0172] The detection rule holding unit 2305 holds the detection rule used by the detection unit 2304. Since it has already... Figure 13 An example of the detection rules is illustrated in the document, so the explanation is omitted here.

[0173] [2.7 IVI2500 Configuration Diagram]

[0174] Figure 18 This diagram illustrates an example of the configuration of the IVI2500 in Embodiment 2. The IVI2500 consists of a communication unit 2501, a display unit 2502, a detection unit 2503, and a detection rule holding unit 2505.

[0175] The communication unit 2501 communicates with other ECUs via the vehicle network. The communication unit 2501 notifies the display unit 2502 and the detection unit 2503 of received messages. Additionally, the communication unit 2501 sends messages notified by the detection unit 2503 to the GW-ECU 2200.

[0176] Display unit 2502 displays the content received via communication unit 2501. Additionally, display unit 2502 notifies other ECUs of the driver's actions via communication unit 2501.

[0177] The detection unit 2503 determines whether the received message meets predetermined rules. Specifically, the detection unit 2503 detects anomalies in the communication towards the vehicle according to the detection rules maintained by the detection rule holding unit 2505, and periodically sends the detection result to the network via the communication unit 2501 to notify the GW-ECU 2200. In Embodiment 2, this network is an in-vehicle network in which multiple ECUs send and receive messages.

[0178] The detection rule holding unit 2505 holds the detection rule used by the detection unit 2503. Since it has already... Figure 13 An example of the detection rules is illustrated in the document, so the explanation is omitted here.

[0179] [2.8 An example of communication timing for detection results]

[0180] Figure 19 This is a diagram illustrating an example of the timing related to the communication of detection results in Implementation Method 2. Furthermore, Figure 19 This is also a timing diagram illustrating an example of the anomaly detection method in Implementation Method 2. Figure 19 The diagram illustrates an example of the timing sequence in which ECUs 1100a-1100c, communication ECU 2300, and IVI 2500 notify GW-ECU 2200 of the detection results and transmit the results obtained from the determination performed in GW-ECU 2200 to communication ECU 2300. Furthermore, for processing steps identical to those in Embodiment 1, the same numbering is applied, and descriptions are omitted.

[0181] (S2101) The GW-ECU2200 waits within a predetermined time to receive test results from ECUs 1100a to 1100c, the communication ECU 2300, and the IVI 2500. ECUs 1100a to 1100c, the communication ECU 2300, and the IVI 2500 periodically send the test results to the network, and the GW-ECU2200 periodically receives the test results from the network, storing each received test result in a predetermined location (e.g., the test result storage unit 2203).

[0182] (S2102) For each of ECUs 1100a to 1100c, communication ECU 2300, and IVI 2500, GW-ECU 2200 determines whether a detection result has been received within a predetermined time (e.g., within a predetermined time from the last received detection result). In other words, GW-ECU 2200 determines whether there is a detection unit that has not received a detection result within the predetermined time. If there is a detection unit (ECU with that detection unit) that has not received a detection result within the predetermined time, GW-ECU 2200 proceeds to S2103; if detection results have been received from all ECUs within the predetermined time, it proceeds to S2104. The predetermined time is not particularly limited, and can be determined, for example, based on the reception interval of detection results periodically received from the normal ECUs 1100a to 1100c, communication ECU 2300, and IVI 2500. Furthermore, the predetermined time can be determined for each ECU, or it can be a time that varies depending on the ECU.

[0183] (S2103) The GW-ECU2200 performs processing for setting flags for messages. Details of the processing are available using... Figure 20 To illustrate.

[0184] (S2104) When the GW-ECU2200 receives detection results from all ECUs within a predetermined time, it determines whether the received detection results include NG results. If the NG results are not included, it proceeds to S2101; if the NG results are included, it proceeds to S2105.

[0185] (S2105) The GW-ECU2200 determines the status of all ECUs that have sent detection results according to a pre-determined algorithm. In this embodiment, even if only one NG result is received, the ECU is determined to be under attack. Conversely, if an OK result is received, the ECU is determined to be normal.

[0186] [2.9 An example of flag processing timing]

[0187] Figure 20 This is a diagram illustrating an example of the timing related to flag setting in Implementation Method 2. Figure 20 This is an example of the timing sequence for setting a flag when the GW-ECU2200 fails to receive a detection result within a predetermined time. Furthermore, for processing steps identical to those in Embodiment 1, the same numbers are added, and descriptions are omitted.

[0188] (S2204) The GW-ECU2200 begins repeated processing of S1201 to S1203 according to the number of ECUs targeted. Specifically, if there is an ECU among ECUs 1100a to 1100c, communication ECU 2300, and IVI 2500 that has not received a detection result within a predetermined time, the GW-ECU2200 stores the determination result in the detection result for that ECU in the detection result holding unit 2203. More specifically, if there is an ECU among ECUs 1100a to 1100c, communication ECU 2300, and IVI 2500 that has not received a detection result within a predetermined time, and the last detection result received for that ECU is not the latest detection result, the GW-ECU2200 stores the determination result in the detection result for that ECU in the detection result holding unit 2203.

[0189] (S2205)GW-ECU2200 performs repeated processing on the number of ECUs that are targeted, and then ends the processing.

[0190] (Effects of Implementation Method 2)

[0191] The vehicle network system 2000 shown in Embodiment 2 can be appropriately distinguished by a device outside the vehicle 2001 whether the abnormality occurred within the vehicle network system 2000 or the abnormality was detected by the detection unit itself, thus ensuring the overall safety of the vehicle 2001. Furthermore, as... Figure 15 As shown, since multiple detection results are aggregated into one message, there is no need to send each detection result to the vehicle 2001 in separate messages, thus reducing the amount of communication.

[0192] (Modification 1 of Implementation Method 2)

[0193] In the vehicle network system 2000 shown in Embodiment 2, such as Figure 15 The illustration shows an example of generating test results (test result payload D1104) for each ECU with a detection unit, but it is also possible to determine the overall test results for the vehicle. Furthermore, for the same figures as in Embodiment 2, descriptions are omitted; therefore, only the format of the test result status message will be described here.

[0194] [2.10 Example of the format of a detection result status message]

[0195] Figure 21This is a diagram illustrating an example of the format of the detection result status message in Modification 1 of Embodiment 2. The payload consists of a detection result header D1101, a detection unit ID D1102, a flag D1103, and a detection result payload D2104. The final detection result payload D2104 stores the result obtained by synthesizing all detection results. For example, the synthesized judgment result can also be stored: Figure 13 If all the testing rules specified in the standard are met, it is judged as OK; if even one rule is not met, it is judged as NG.

[0196] (Effect of variation 1 of implementation method 2)

[0197] The vehicle network system shown in Modification 1 of Embodiment 2 can be appropriately distinguished by an external device from an anomaly occurring within the vehicle network system itself, or from an anomaly detected by the detection unit itself, thus ensuring the overall safety of the vehicle. Furthermore, as... Figure 21 As shown, since multiple detection results are aggregated into a single message for transmission, there is no need to send each detection result as a separate message outside the vehicle, thus reducing communication volume. Furthermore, by combining the detection results from individual detection units into a single judgment result, communication volume can be further reduced.

[0198] (Modification 2 of Implementation Method 2)

[0199] In the vehicle network system 2000 shown in Embodiment 2, each ECU is described as having a detection unit. However, the GW-ECU may have functions equivalent to the detection units of each ECU. Furthermore, the description of the GW-ECU 22200, which is different from the GW-ECU 2200, is omitted here, as the same figures as in Embodiment 2 are used.

[0200] [Structure diagram of 2.11GW-ECU22200]

[0201] Figure 22 This diagram illustrates an example of the configuration of GW-ECU22200 in Modification 2 of Embodiment 2. In Modification 2 of Embodiment 2, GW-ECU22200 is also an example of an anomaly detection system. GW-ECU22200 comprises a communication unit 22201, a detection result management unit 22202, a detection result holding unit 2203, a transmission processing unit 1204, a CAN detection unit 22205, a detection rule holding unit 22206, an Ether detection unit 22207, and a detection rule holding unit 22208.

[0202] The communication unit 22201 communicates with other ECUs via the vehicle network and notifies the CAN detection unit 22205, Ether detection unit 22207, and transmission processing unit 1204 of received messages. Additionally, the communication unit 22201 sends messages from the detection result management unit 22202 and transmission processing unit 1204 to other ECUs.

[0203] The test result management unit 22202 saves the test results and surrounding information notified by the CAN test unit 22205 and Ether test unit 22207 to the test result storage unit 2203. Furthermore, the test result management unit 22202 determines the test result status of each ECU from the stored content in the test result storage unit 2203 and sends a test result status message to the communication ECU 2300 via the communication unit 22201. An example of the message format for the test result status message is... Figure 15 The functions shown are the same, so the description is omitted. Furthermore, the other functions of the detection result management unit 22202 are the same as those in Embodiment 2, so the description is omitted.

[0204] The CAN detection unit 22205 is an example of a detection unit that determines whether a received message meets predetermined rules. It is equivalent to the detection unit 1103 in the ECUs 1100a to 1100c in Embodiment 2. The CAN detection unit 22205 uses the detection rules maintained by the detection rule holding unit 22206 to determine the received CAN message. The CAN detection unit 22205 sends the determined detection result (specifically, periodically) to the network and notifies the detection result management unit 22202. In the second variation of Embodiment 2, this network is the network within the GW-ECU 22200, specifically a bus within the GW-ECU 22200 that connects the CAN detection unit 22205 and the detection result management unit 22202.

[0205] The detection rule holding unit 22206 holds the detection rule used by the CAN detection unit 22205. Since it has already... Figure 13 An example of the detection rules is illustrated in the document, so the explanation is omitted here.

[0206] Ether detection unit 22207 is an example of a detection unit that determines whether a received message meets predetermined rules. It is equivalent to the detection unit 2503 in IVI 2500 in Embodiment 2. Ether detection unit 22207 uses the detection rules maintained by detection rule holding unit 22208 to determine the received Ether message. Ether detection unit 22207 sends (specifically, periodically) the determined detection result to the network and notifies detection result management unit 22202. In variation 2 of Embodiment 2, this network is the network within GW-ECU 22200, specifically a bus within GW-ECU 22200 connecting Ether detection unit 22207 and detection result management unit 22202.

[0207] The detection rule holding unit 22208 holds the detection rule used by the Ether detection unit 22207. Since it has already... Figure 13 An example of the detection rules is illustrated in the document, so the explanation is omitted here.

[0208] (Effect of variation 2 of implementation method 2)

[0209] In the vehicle network system shown in Variation 2 of Embodiment 2, an external device can appropriately distinguish whether an anomaly has occurred within the vehicle network system or whether the anomaly detected by the detection unit itself has malfunctioned, thus ensuring the overall safety of the vehicle. Furthermore, by having a detection unit and a detection result management unit 22202 in a single GW-ECU 22200, the network load within the vehicle can be reduced.

[0210] (Modification 3 of Implementation Method 2)

[0211] In the vehicle network system 2000 shown in Embodiment 2, an example of processing independent of the state of the vehicle 2001 is described. However, it is also possible for the detection result management unit to change the processing according to the state of the vehicle. Furthermore, for the same drawings as in Embodiment 2, the description is omitted. Here, the GW-ECU 32200, which is different from the GW-ECU 2200, and the flag processing timing will be described.

[0212] [Structure diagram of 2.12GW-ECU32200]

[0213] Figure 23 This diagram illustrates an example of the configuration of the GW-ECU32200 in Variation 3 of Embodiment 2. In Variation 3 of Embodiment 2, the GW-ECU32200 is an example of an anomaly detection system. The GW-ECU32200 consists of a communication unit 1201, a detection result management unit 32202, a detection result holding unit 2203, a transmission processing unit 1204, and a vehicle status management unit 32201.

[0214] The test result management unit 32202 obtains the test results based on the received message related to the test results notified by the communication unit 1201, and saves it along with surrounding information to the test result storage unit 2203. Furthermore, based on the stored content in the test result storage unit 2203 and the vehicle status notified by the vehicle status management unit 32201, the test result management unit 32202 determines the test result status of each ECU and sends a test result status message to the communication ECU 2300 via the communication unit 1201. An example of the message format for the test result status message is... Figure 15 The same applies as shown, therefore the explanation is omitted.

[0215] The vehicle status management unit 32201 determines the status of the vehicle in the vehicle network system and notifies the detection result management unit 32202 of the determined vehicle status. For example, the vehicle status management unit 32201 determines whether the vehicle is in motion or stationary.

[0216] [2.13 An example of flag processing timing]

[0217] Figure 24 This is a diagram illustrating an example of the timing related to flag setting in a variation 3 of implementation method 2. Figure 24 This describes an example of the timing of the process by which the GW-ECU32200 sets a flag based on the vehicle's status when an ECU fails to receive a detection result within a predetermined time. Furthermore, for processing steps identical to those in Embodiments 1 and 2, the same numbers are added, and descriptions are omitted.

[0218] (S32202) GW-ECU32200 determines whether the latest detection result has been successfully received, and if the last received detection result is not the latest detection result, that is, if the final detection result is old information, it proceeds to S32206.

[0219] (S32206) GW-ECU32200 determines the vehicle's status. Specifically, GW-ECU32200 determines whether the vehicle is in motion. If the vehicle is in motion, proceed to S1203.

[0220] Thus, in variation 3 of implementation 2, the GW-ECU32200 determines whether to associate the determination result with the detection result based on the vehicle's state.

[0221] (Effect of variation 3 of implementation method 2)

[0222] In order to determine whether to associate the determination result with the detection result, the vehicle's state is used in combination, as a result of the vehicle's state. This enables the determination of loss in the event of an anomaly and ensures the overall safety of the vehicle.

[0223] (Other variations)

[0224] Furthermore, although this disclosure has been described based on the above embodiments and modifications, this disclosure is not limited to the above embodiments and modifications. The following situations are also included in this disclosure.

[0225] (1) The above embodiments illustrate the use of Ethernet and CAN protocols as vehicle networks, but are not limited to these. For example, CAN-FD (CAN with Flexible Data Rate), LIN (Local Interconnect Network), MOST (Media Oriented Systems Transport), etc., can also be used as vehicle networks. Alternatively, a vehicle network can be a network structure composed of these networks as subnets.

[0226] (2) In the above embodiments, several combinations of anomaly detection methods based on the detection unit and the detection result management unit have been described, but are not limited to these. There are instances where physically separate ECUs maintain the detection unit and the detection result management unit, and instances where the same ECU maintains both. Furthermore, there may be one or more detection units and detection result management units, or there may be one detection unit with multiple detection result management units, or multiple detection units with one detection result management unit. Moreover, multiple detection result management units of one ECU or multiple highly correlated ECUs can work together to share flag information (judgment results) and attach it to the detection result status message. That is, if a detection result status message sent by a certain ECU is flagged by the detection result management unit of that ECU, other detection result management units of that ECU or other detection result management units of highly correlated ECUs can also set the same flag as the detection result management unit of that ECU.

[0227] (3) In the above embodiments, an example was described in which the same ECU (specifically GW-ECU22200) has only CAN and Ether detection units, but it is not limited to this, and does not exclude any combination including system log detection units.

[0228] (4) In the above embodiments, an example of determining the driving state as the vehicle's state was described. However, it can be set that the driving state is determined by a specific ECU and other ECUs obtain the driving state from the specific ECU via the vehicle network, or it can be set that each ECU determines the driving state independently. In addition, the vehicle's state can also be determined in addition to states such as driving, parking, or valances, such as accessories being on (ON), ignition switch being on (ON), low-speed driving, or high-speed driving.

[0229] (5) In the above embodiment, an example of setting a flag for each detection unit was described, but it is not limited to this. A flag can also be set for multiple detection units. Alternatively, it can be implemented using a specific message code instead of a flag.

[0230] (6) In the above embodiments, an example of specifying the communication error frequency as a detection rule using system logs has been described, but it is not limited to this, and does not exclude any detection unit that uses the logs output by the system. For example, as a detection rule, rules related to port scan results from external sources or failure results of secure boot checking integrity during system boot can also be used.

[0231] (7) In the above embodiments, examples of using the value of the payload or the transmission frequency, etc., as anomaly detection methods in CAN or Ethernet communication messages have been described, but this is not a limitation and does not exclude the use of any detection means of in-vehicle communication messages. For example, the period or the change in the payload, etc., may also be used.

[0232] (8) Specifically, each device in the above embodiments is a computer system composed of a microprocessor, ROM, RAM, hard disk unit, display unit, keyboard, and mouse. A computer program is recorded in the RAM or hard disk unit. The microprocessor operates according to the computer program, thereby enabling each device to perform its function. This computer program is composed of multiple command codes representing instructions for the computer, combined to achieve a predetermined function.

[0233] (9) In each of the devices described in the above embodiments, some or all of the constituent elements may be constituted by a single system LSI (Large Scale Integration). A system LSI is a multifunctional LSI manufactured by integrating multiple constituent parts onto a single chip. Specifically, it is a computer system comprising a microprocessor, ROM, RAM, etc. The RAM stores the computer program. The microprocessor operates according to the computer program, thereby enabling the system LSI to perform its functions.

[0234] Furthermore, each component constituting the above-mentioned devices can be individually chipped, or it can be chipped in a manner that includes some or all of them.

[0235] Furthermore, although referred to here as a system LSI, it can also be called an IC, LSI, super LSI, or ultra-large LSI, depending on the level of integration. Additionally, the method of integrated circuitization is not limited to LSI; it can also be implemented using dedicated circuits or general-purpose processors. Alternatively, after LSI manufacturing, programmable FPGAs (Field Programmable Gate Arrays) or reconfigurable processors that can reconfigure the connections and / or settings of the internal circuitry of the LSI can be utilized.

[0236] Furthermore, with the development of semiconductor technology or the emergence of other derived technologies, if an integrated circuit technology emerges that can replace LSI, it can certainly be used for the integration of functional blocks. As a possibility, applications such as biotechnology are also possible.

[0237] (10) Some or all of the constituent elements of the above-described devices may also be composed of IC cards or individual modules that can be mounted and detached from the devices. The IC card or the module is a computer system composed of a microprocessor, ROM, RAM, etc. The IC card or the module may also include the aforementioned multi-functional LSI. The microprocessor operates according to a computer program, thereby enabling the IC card or the module to perform its functions. The IC card or the module may also be tamper-proof.

[0238] (11) This disclosure may also be the anomaly detection method shown above. In addition, this disclosure may also be a computer program that implements the anomaly detection method, or a digital signal formed by a computer program.

[0239] Alternatively, this disclosure can also record computer programs or digital signals on computer-readable non-transitory recording media such as floppy disks, hard disks, CD-ROMs, MOs, DVDs, DVD-ROMs, DVD-RAMs, BDs (Blu-ray Discs), or semiconductor memories. Furthermore, this disclosure can also contain digital signals recorded on these recording media.

[0240] In addition, this disclosure can also transmit computer programs or digital signals via electrical communication lines, wireless or wired communication lines, networks such as the Internet, or data broadcasting.

[0241] Alternatively, this disclosure may also be a computer system having a microprocessor and a memory, wherein the memory stores a computer program and the microprocessor operates according to the computer program.

[0242] Alternatively, the program or digital signal can be transferred by recording it on a recording medium or by transferring it via a network, thereby implementing it through a separate computer system.

[0243] (12) The above embodiments and the above variations can also be combined separately.

[0244] Industrial availability

[0245] This disclosure can be applied, for example, to in-vehicle network systems.

[0246] Label Explanation

[0247] 1000, 2000: In-vehicle network system

[0248] 1001, 2001: Vehicles

[0249] 1100a, 1100b, 1100c, 11100a, 11100b, 11100c: ECU

[0250] 1011: Brake

[0251] 1012: Steering Wheel

[0252] 1013: Accelerator

[0253] 1101, 1201, 1401, 2501, 22201: Ministry of Communications

[0254] 1102: Message Conversion Department

[0255] 1103, 11103, 2304, 2503: Testing Department

[0256] 1104, 2305, 2505, 22206, 22208: Inspection Rule Maintenance Department

[0257] 1200, 2200, 22200, 32200: GW-ECU

[0258] 1202, 11105, 2202, 22202, 32202: Test Result Management Department

[0259] 1203, 11106, 2203: Test Result Preservation Department

[0260] 1204: Transmission Processing Department

[0261] 1300, 2300: Communication ECU

[0262] 1301, 2301: In-vehicle communication department

[0263] 1302: Conversion Unit

[0264] 1303, 2303: External Communication Department

[0265] 1400: Server

[0266] 1402: Vehicle Management Department

[0267] 2500: IVI

[0268] 2502: Display Unit

[0269] 22205: CAN Detection Department

[0270] 22207: Ether Testing Department

[0271] 32201: Vehicle Status Management Department

[0272] D1101: Detection result header

[0273] D1102: Testing Department ID

[0274] D1103: Mark

[0275] D1104, D2104: Effective payload of test results

Claims

1. An anomaly detection method, which is an anomaly detection method in an in-vehicle network system in which multiple electronic control devices are connected. At least one of the plurality of electronic control devices has a detection unit that determines whether the received message meets a predetermined rule, and sends the detection result to the network. The anomaly detection method includes the following processing: (i) Receive detection results from the network and store the received detection results in a memory; (ii) Determine whether a detection result is received within a predetermined time, and associate the determination result with the detection result and store it in the memory; (iii) Output a message containing the detection result associated with the judgment result to the outside world. In (i), the received detection results are also stored in association with the time of receipt. In (ii), if no detection result is received within the predetermined time, it is determined whether the last received detection result is the latest detection result based on the time associated with the last received detection result. If the last received detection result is not the latest detection result, the determination result is associated with the last received detection result and stored in the memory.

2. The anomaly detection method according to claim 1, In (i), detection results are received periodically from the network, and each received detection result is stored in the memory.

3. The anomaly detection method according to claim 1, In (ii), when a detection result is received within the predetermined time, if the detection result indicates an anomaly, a message containing the detection result is output to the outside.

4. The anomaly detection method according to claim 1, The at least one electronic control device may be at least two electronic control devices. In (ii), Each of the at least two electronic control devices determines whether a detection result has been received within the predetermined time period. If one of the at least two electronic control devices fails to receive a detection result within the predetermined time, the determination result is associated with the detection result for that electronic control device and stored in the memory.

5. The anomaly detection method according to claim 4, The message output to the outside in (iii) includes the detection result of each of the at least two electronic control devices and the determination result associated with the detection result of each of the at least two electronic control devices.

6. The anomaly detection method according to claim 1, The anomaly detection method further includes: Determine the status of the vehicle in the in-vehicle network system. In step (ii), it is determined whether to associate the determination result with the detection result based on the state of the vehicle.

7. The anomaly detection method according to claim 1, The network is an in-vehicle network through which the multiple electronic control devices send and receive messages.

8. The anomaly detection method according to claim 1, The network is a network within the at least one electronic control device.

9. The anomaly detection method according to any one of claims 1 to 8, The detection unit uses the controller domain network (CAN) messages, Ethernet messages, or system logs of the electronic control device as received messages to determine whether they meet the predetermined rules.

10. A computer-readable recording medium storing a program for causing a computer to execute the anomaly detection method according to any one of claims 1 to 9.

11. A computer program product comprising a computer program for causing a computer to perform the anomaly detection method according to any one of claims 1 to 9.

12. An anomaly detection system, which is an anomaly detection system in an in-vehicle network system in which multiple electronic control devices are connected. At least one of the plurality of electronic control devices has a detection unit that determines whether the received message meets a predetermined rule, and sends the detection result to the network. The anomaly detection system has the following features: A memory that stores the detection results received from the network; The test result management department determines whether the test result has been received within a predetermined time, and stores the determination result in the memory in association with the test result. as well as The communications department outputs a message containing the detection result associated with the aforementioned determination result to the outside world. The memory also stores the received detection results in association with the time of receipt. If no test result is received within the predetermined time, the test result management unit determines whether the last received test result is the latest test result based on the time associated with the last received test result. If the last received test result is not the latest test result, the determination result is associated with the last received test result and stored in the memory.