Vehicle Diagnostic System

Abstract

To easily diagnose whether an abnormality occurring in a vehicle is caused by an attack or a simple failure.SOLUTION: A diagnostic server 1 is provided with a log acquisition unit 13 that acquires a history of a first log indicating whether or not an ECU 32 in a vehicle 3 has executed a predetermined process in response to a request signal requesting the ECU 32 to execute the predetermined process, and a communication determination unit 15 that, when the history includes a non-execution log indicating that the predetermined process has not been executed, determines the validity of a communication used for transmitting a request signal corresponding to the non-execution log.SELECTED DRAWING: Figure 2

Description

[Technical field]

[0001] The present invention relates to a vehicle diagnostic system, and more particularly to a diagnostic system for identifying the cause of an abnormality when an abnormality or a symptom thereof occurs in a vehicle device. [Background technology]

[0002] As the IoT revolution advances, with everything being connected to the Internet, the automotive industry is also moving toward IoT, with connected cars and self-driving cars, etc. However, while the IoT revolution in automobiles brings convenience, it also increases the risk of cyber attacks via the Internet.

[0003] Patent Documents 1 to 3 are cited as examples of technologies for detecting cyber attacks against vehicles. Patent Document 1 describes technology related to a vehicle diagnostic device that suppresses damage caused by hacking of vehicles, etc. Patent Document 2 describes technology for detecting suspicious behavior by an attacker from vehicle logs and detecting abnormal vehicles. Patent Document 3 describes technology related to analysis of vehicle logs transmitted from vehicles to an external server. [Prior art documents] [Patent documents]

[0004] [Patent Document 1] Patent Publication No. 2021-079855 [Patent Document 2] International Publication No. 2021 / 038870 [Patent Document 3] Republished Patent No. 2020 / 110414 Summary of the Invention [Problem to be solved by the invention]

[0005] When a vehicle is subject to a cyber attack, some kind of abnormality will naturally occur in some of the vehicle's equipment. However, in recent years, cyber attacks have become more sophisticated, and the owner of the vehicle in question is likely to assume that the abnormality is simply due to a malfunction. Owners who make this judgment are likely to take their vehicle to a repair shop or report the malfunction to the customer center, and the vehicle provider will need to deal with this.

[0006] However, if an abnormality occurring in a vehicle is treated as simply a malfunction, even though it is actually the result of a cyberattack, the owner will not be aware that the vehicle has been subjected to a cyberattack, and the risk of the vehicle being exposed to further attacks by the attacker will increase. Even if the abnormality is found to be the result of a cyberattack at a later inspection stage, it is likely that a long time has already passed since the abnormality occurred, and the vehicle may have already been subjected to further attacks by the attacker by the time it is discovered. Therefore, it is necessary to quickly determine whether an abnormality occurring in a vehicle is the result of a cyberattack.

[0007] In order to distinguish between a cyber attack and a simple malfunction, vehicle providers must, for example, set up a Product Security Incident Response Team (PSIRT) to handle safety management aimed at improving the security level of their products and services, provide user support in terms of security, and prepare to respond when incidents related to the products / services occur; however, this increases time and costs.

[0008] The technologies described in Patent Documents 1 to 3 also relate to diagnosing abnormalities that occur in a vehicle, such as hacking, but even these technologies cannot distinguish whether an abnormality that occurs in a vehicle is due to an attack or simply a malfunction.

[0009] The present invention has been made in consideration of the above-mentioned problems, and aims to easily diagnose whether an abnormality occurring in a vehicle or a symptom thereof is due to an attack or simply a malfunction, without spending a lot of time or cost. [Means for solving the problem]

[0010] In order to solve the above problems, the vehicle diagnosis system of the present invention has a log acquisition unit that acquires a history of a first log indicating whether or not an in-vehicle device has performed a specified process in response to a request signal requesting the device to perform the specified process, and a communication determination unit that, when the history includes a non-execution log indicating that the specified process was not performed, determines the validity of the communication used to transmit the request signal corresponding to the non-execution log. Effect of the Invention

[0011] According to the present invention, it is possible to easily diagnose whether an abnormality occurring in a vehicle or a symptom thereof is due to an attack or simply a malfunction, without spending a great deal of time and cost as in the conventional method. Further features related to the present invention will become apparent from the description of the present specification and the accompanying drawings. Furthermore, the problems, configurations and effects other than those described above will become apparent from the following description of the embodiments. [Brief description of the drawings]

[0012] [Figure 1] This is an overview diagram showing the operations required of each department / organization during the maintenance phase of each phase related to automobile supply. [Diagram 2] 1 is a block diagram showing the configuration of a diagnosis server and a vehicle to which a vehicle diagnosis system according to the present invention is applied; [Diagram 3] 2A to 2C are diagrams for explaining the data structure of each piece of data handled in the present invention; [Figure 4] FIG. 11 is a sequence diagram showing the relationship between the processes performed by the diagnostic server, the vehicle, and an attacker. [Diagram 5] A list of the expected actions to be taken if a malfunction occurs in the ECU inside the vehicle. [Figure 6]A list of the processes that are expected to occur if an ECU inside a vehicle is attacked. [Figure 7] 11 is a flowchart showing a process performed by a log acquisition unit. [Figure 8] 3 is a flowchart showing a process performed by the vehicle diagnosis system in the first embodiment. [Figure 9] 10 is a flowchart showing a process performed by the vehicle diagnosis system in the second embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0013] Hereinafter, the embodiment will be described with reference to the drawings. Figure 1 is an overall overview diagram showing the operations required of each department / organization in the maintenance phase of each phase related to automobile supply.

[0014] When supplying automobiles to consumers, automobile suppliers usually carry out operations in the phases from design to maintenance as shown in Figure 1. Among these, in recent years, there has been a demand for diversification of customer support, especially in the maintenance phase.

[0015] Specifically, when an abnormality occurs in a vehicle owned by a customer, the customer first assumes that a breakdown has occurred and reports it to the customer center, as described above. After that, as shown in the figure, the customer center transmits various requests / information to the quality assurance department, development department, and supplier, and the product is repaired and the results of the investigation are responded to the customer.

[0016] In parallel with the above process, if any threat / vulnerability information or incident information (such as logs related to security events) is detected by external organizations such as dealers or repair shops, or by the Vehicle Security Operation Center (VSOC), which manages security during operation of the vehicle after it is shipped, this is reported to the PSIRT mentioned above, and the PSIRT then passes the information on to the quality assurance department, development department, and suppliers.

[0017] In this way, if a PSIRT is established from the perspective of ensuring security as mentioned above, when any abnormality or the possibility of an abnormality occurs in a vehicle, the first points of contact for receiving reports will be dispersed, which increases the amount of work required to distinguish between malfunctions and cyber attacks, leading to delays in responding to vehicle abnormalities.

[0018] The present invention has been made based on the above background. Figure 2 shows a schematic diagram of an application of the vehicle diagnosis system according to the present invention.

[0019] The vehicle diagnostic system according to the present invention is implemented, for example, on a diagnostic server 1 on a cloud. The diagnostic server 1 is connected to a vehicle 3 via a network 2. The vehicle diagnostic system is not limited to being implemented on a cloud, and may be installed in each vehicle as hardware having a CPU and memory.

[0020] The diagnostic server 1 has a communication unit 11, a request message generation unit 12, a log acquisition unit 13, a log processing unit 14, a communication determination unit 15, an abnormality identification unit 16, and a vehicle diagnosis history storage unit 17. The vehicle 3 has a communication unit 31 and a plurality of ECUs 32. The ECUs 32 are devices related to various control systems capable of self-diagnosis.

[0021] The communication unit 11 of the diagnostic server 1 transmits a request message to each ECU 32 of the vehicle 3 and receives a response message from each ECU 32. The request message generation unit 12 generates this request message. The log acquisition unit 13 records the information received from the vehicle 3 as a log.

[0022] Here, the request message, the response message, and the contents of the log acquired by the log acquisition unit 13 will be described with reference to Fig. 3. First, the request message is a command signal for requesting each ECU 32 of the vehicle 3 to execute a predetermined process such as self-diagnosis, and includes a one-byte identification number (SID) indicating the outline of the requested process as shown in Fig. 3(a). Optionally, the request message includes a one-byte identification number (Sub function) indicating the details of the requested process, a one- to two-byte ID number (Data ID) indicating the target of the requested process, and data (Data) other than the above that is necessary for executing the process.

[0023] Each ECU 32 in the vehicle 3 attempts to execute processing in response to receiving the request message, and generates and transmits a response message as a result to the diagnostic server 1. If the ECU 32 is able to execute the requested processing, the response message is a positive response message as shown in Fig. 3(b), and if the ECU 32 is unable to execute the requested processing, the response message is a negative response message as shown in Fig. 3(c).

[0024] The positive response message includes the SID and the results of the requested processing, etc. Specifically, it includes [Sub function] which repeats the requested processing details as is, [Data ID] which repeats the requested data ID as is, and [Data] which indicates the data obtained as a result of the processing.

[0025] A negative response message contains an identification number (SID: fixed at 0x7F) indicating that it is a negative response, the SIDRQ of the process that could not be performed, and a negative response code (NRC) which is a code number indicating the reason why the process could not be performed. The NRC is a one-byte code defined in ISO 14229-1, and includes not only codes indicating cases where the process could not be performed simply such as a timeout, but also security-related error codes such as multiple authentication failures and certificate verification failures.

[0026] The above request and response messages are sent and received using UDS (Unified Diagnostic Services) communication. UDS is a new diagnostic communication specification framework that is compliant with ISO14229 and is a major improvement over KWP based on practical use experience. It is a communication protocol with streamlined specifications and a greatly expanded scope of standardization. In recent years, it has been used particularly in the field of vehicle diagnosis, and is implemented as a session layer on the lower layer CAN.

[0027] The log acquisition unit 13 acquires information about the response message as a first log indicating whether each ECU of the vehicle 3 has been able to execute the requested process. A request message may be generated multiple times for one ECU 32 or may be generated for multiple ECUs 32. Therefore, the log acquisition unit 13 acquires and stores the information together with a time stamp as a history of the first log. This history also includes information about the contents of the UDS communication used when accessing each ECU 32. The process performed by the log acquisition unit 13 is shown in the flowchart of FIG. 7. In step 701, a request message is transmitted to the ECU 32, and in step 702, a response message is received from the ECU 32, and in step 703, the response message is recorded in the log acquisition unit 13 as log information.

[0028] The log acquisition unit 13 can also acquire and store, as a second log, a diagnosis trouble code (DTC) that is generated when some abnormality occurs in the ECU 32 and indicates the type of the abnormality. The DTC is a 3-byte code that indicates an abnormal state of the vehicle and is defined in ISO 15031-6. The DTC has a data structure as shown in FIG. 3(d).

[0029] DTC codes have standardized parameter fields and OEM-defined parameter fields, the latter of which can be used independently by OEMs. In DTCs, a 1-byte status flag (FTB: Failure Type Byte) indicates the status of the corresponding DTC code (whether it is a confirmed failure or an unconfirmed failure, etc.).

[0030] In addition, the DTC may also include DTC snapshot data, which records the ECU control data at the time the DTC occurred, and DTC extended data, which records the frequency of the malfunction and the odometer value at the time the malfunction first occurred, in order to identify the cause of the abnormality.

[0031] The log acquisition unit 13 acquires information about DTCs generated in one ECU and / or multiple ECUs as the history of the second log together with a time stamp, similar to the first log, and stores the information in the log acquisition unit 13.

[0032] The logs acquired and stored by the log acquisition unit 13 are processed by the log processing unit 14. The log processing unit 14 refers to the timestamps of the above logs, extracts and rearranges them in chronological order, and generates log chronological data.

[0033] When the first log contains a non-execution log indicating that any ECU 32 was unable to execute a predetermined process, i.e., when the first log contains an NRC, the communication determination unit 15 determines the validity of the UDS communication used to transmit a request signal that requests execution of a process corresponding to the negative response message containing the NRC. The method of this determination will be described later.

[0034] When there is UDS communication that is determined by the communication determination unit 15 to be unauthorized use, the abnormality identification unit 16 identifies the cause.

[0035] The vehicle diagnosis history storage unit 17 stores the history of vehicle diagnoses that have been performed in the past for each vehicle 3. This history is used by the communication determination unit 15 to determine the validity of the UDS communication. In addition, this history can be obtained in real time from dealers, repair shops, and suppliers.

[0036] Next, an example of an event (failure, attack) that may occur among the diagnostic server according to this embodiment, the in-vehicle ECU, and an attacker will be described with reference to FIG.

[0037] As mentioned above, cyber attacks on vehicles have become a problem in recent years, and attackers often use the above-mentioned UDS communication when launching cyber attacks on vehicles. This is because UDS communication, by its very nature of diagnosing the functions of each ECU, can be said to have administrator authority, and attackers can use this communication to launch direct attacks on each ECU.

[0038] 4, first, when a failure occurs in the ECU 32 in step 401, a DTC code is issued and recorded in the ECU (step 402). This DTC is not automatically erased and can therefore be acquired later as a log.

[0039] Next, suppose that an attacker uses UDS communication for some reason to launch a cyber attack on the ECU 32 (step 403). This attack is not necessarily successful. This is because when the ECU 32 detects an access through UDS communication, it performs challenge-and-response authentication, and as a result, the hash values ​​may not match, and the attacker's subsequent access may be rejected. In this case, the above-mentioned NRC is generated and transmitted to the attacker as a negative response message (steps 404, 405). Information about the generated NRC and the UDS communication used illegally by the attacker is also recorded in the ECU 32.

[0040] After that, it is assumed that the diagnostic server 1 transmits a request message to the ECU 32 by using normal UDS communication (step 406). It is further assumed that for some reason, the ECU does not process this request message and generates an NRC (step 407). Then, a negative response message including this NRC is transmitted to the diagnostic server 1 (step 408). The diagnostic server 1 records the above series of information as log information (step 409).

[0041] In Figure 4, a series of flows has been described in which possible events include a failure in ECU 32, an attack by an attacker being sustained but the attack fails and an NRC is generated, and an NRC is generated in response to a request message from diagnostic server 1.

[0042] All of the above-mentioned possible events are shown in Figures 5 and 6. Figure 5 shows a case where a failure occurs in the ECU 32, and Figure 6 shows a case where the ECU 32 is attacked by an attacker.

[0043] Figure 5(a) corresponds to steps 401 and 402 in Figure 4, and although not shown, is an example in which a positive response message is returned to the request message after that. Figure 5(b) shows a case in which steps 401 and 402 in Figure 4 occur consecutively. This is the case, for example, when a failure occurs in the central ECU, the failure spreads to the zone ECUs as well.

[0044] Fig. 5(c) shows a case where the flow of steps 401, 402, 406, 407, and 408 in Fig. 4 has been completed. In this way, when a failure occurs in the ECU 32 and an NRC response is generated, it is assumed that the UDS communication being used is normal.

[0045] Next, the case where an attack is made by an attacker will be explained with reference to Fig. 6. First, Fig. 6(a) shows the case where an attacker launches an attack without using UDS communication (for example, physically). In this case, no record is made of the use of UDS, and if an abnormality occurs in the ECU, a DTC is issued and recorded.

[0046] Fig. 6(b) is a case corresponding to steps 403, 404, and 405 in Fig. 4. Fig. 6(c) is a case where an abnormality occurs in the ECU after that and a DTC is recorded in the ECU. This may be the case, for example, where an attack by an attacker continues for a long time, and initially access is denied and an NRC is generated, but then the attack succeeds for some reason.

[0047] Figure 6(d) shows a case where an attack by an attacker is successful, an abnormality occurs in the ECU and a DTC is recorded, and then an NRC is issued because it is determined that the UDS is being used illegally. For example, an attacker first attacks the car navigation system in the vehicle, and if this is successful, a DTC is recorded in the car navigation system. After that, the attacker attacks the central gateway via the car navigation system, but fails. Figures 6(e) and (f) show cases where the above patterns are combined.

[0048] As can be seen from Figure 6, when an attack by an attacker occurs, an NRC response occurs when unauthorized UDS communication is used. Therefore, by utilizing this, when an abnormality occurs in an ECU, it becomes possible to determine whether the cause of the abnormality is due to a failure or an attack. Note that when there is no NRC response (Figures 5(a), (b), and Figure 6(a) and parts of Figures 6(e) and (f)), the conventional method is used to determine whether the abnormality is due to a failure or an attack.

[0049] The above-mentioned method of distinguishing between a failure and an attack when an NRC response is received will be described with reference to the flowchart of FIG. 8. First, in step 801, the log processing unit 14 rearranges the log information acquired by the log acquisition unit 13 in chronological order to generate log time series data. In step 802, the log processing unit 14 deletes the NRC log based on normal UDS communication from the log time series data. Normal UDS communication can be determined by referring to the history of vehicle diagnosis stored in the vehicle diagnosis history storage unit 17 of the diagnostic server 1. That is, since the history of vehicle diagnosis records diagnostic information performed by a person with legitimate authority such as a dealer, a repair shop, and a supplier up to that point in time, it is possible to determine whether the UDS communication is legitimate by, for example, comparing the timestamp when the NRC was generated with the timestamp included in the diagnostic information. Applying this to FIG. 4, the NRC generated in step 407 is deleted for the request message transmitted from the diagnostic server 1 using normal UDS communication. In this way, the log processing unit 14 generates modified log time series data.

[0050] The correction log time series data is sent to the communication determination unit 15. In step 803, the communication determination unit 15 determines whether an NRC log still exists in the correction log time series data (step 803). If an NRC log no longer exists, the process ends. If an NRC log exists, the anomaly identification unit 16 proceeds to step 804 and identifies the source of the NRC (source of the attack). In application to FIG. 4, the correction log time series data contains the NRC log generated in step 404 in response to the cyber attack by the attacker that illegally uses the UDS communication in step 403, and therefore the communication determination unit 15 can determine that the UDS communication in step 403 is illegal. Then, in step 805, the anomaly identification unit 16 records anomaly information related to the illegal use of the UDS communication.

[0051] In this way, in this embodiment, when an ECU in a vehicle generates an NRC, the fault and attack are isolated by simply judging the validity of the use of UDS communication corresponding to the NRC. Therefore, it becomes possible to easily and quickly identify the cause of the anomaly without sending products with actual anomalies to each department for analysis or conducting an investigation by PSIRT, as in the past.

[0052] In the above example, only the first log related to the NRC is used, but if the second log related to the DTC is used, the processing flow will be as shown in Fig. 9. The processing shown in Fig. 9 performs the processing shown in steps 901 to 904 in addition to the processing shown in Fig. 8.

[0053] When it is determined in step 803 that the NRC log exists in the correction log time series data, the log acquisition unit 13 acquires the second log related to the above-mentioned DTC (step 901). Then, the log is transmitted to the communication determination unit 15, which determines whether or not there has been a false detection of UDS communication (step 902). For example, one cause of issuing a DTC is that a diagnostic program (a program that uses UDS communication) implemented in the ECU is started due to an ECU failure, and UDS communication is performed. Although this use of UDS communication is not an unauthorized use of UDS communication by an attacker, it is not recorded in the vehicle diagnosis history, and therefore may be regarded as an unauthorized use of UDS communication.

[0054] Therefore, the contents indicated by the DTC are verified, and the NRC corresponding to the UDS communication that was determined to be an unauthorized use of UDS communication but was determined not to be unauthorized use by an attacker is deleted (step 903). After that, in step 904, it is determined again whether or not an NRC log exists, and if it does exist, the process proceeds to step 804 to identify the source of the NRC (source of the attack). The same applies if it is determined in step 902 that there is no erroneous detection of communication.

[0055] In this way, by taking into consideration the second log related to the DTC in addition to the first log related to the NRC, it is possible to more accurately distinguish between failures and attacks.

[0056] In this embodiment, an example in which the NRC is acquired as the first log has been described, but a PRC (Positive Response Code), which indicates that the ECU has normally executed the process, can also be acquired as the first log. However, it should be noted that the PRC is issued more frequently than the NRC, and therefore is usually stored in a volatile manner, and that the high frequency of issuance increases the possibility of false detection.

[0057] According to the embodiment of the present invention described above, the following advantageous effects are obtained. (1) A vehicle diagnosis system according to the present invention includes a log acquisition unit that acquires a history of a first log indicating whether or not an in-vehicle device has performed a specified process in response to a request signal requesting the device to perform the specified process, and a communication determination unit that, when the history includes a non-execution log indicating that the specified process was not performed, determines the validity of the communication used to transmit the request signal corresponding to the non-execution log.

[0058] With the above configuration, it is possible to easily diagnose whether an abnormality occurring in a vehicle is due to an attack or simply a malfunction, without spending a lot of time or cost.

[0059] (2) The system further includes a log processing unit that extracts the history in chronological order to generate log time-series data, and a vehicle diagnosis history storage unit that stores the history of vehicle diagnoses performed on the vehicle, and the communication determination unit compares the log time-series data with the vehicle diagnosis history, and when a record corresponding to the non-execution log exists in the vehicle diagnosis history, determines that the communication corresponding to the non-execution log is valid. Since the vehicle diagnosis history can be easily collected, the validity of the UDS communication can be determined without requiring complicated processing.

[0060] (3) The log processing unit generates modified log time series data by deleting a first log corresponding to a communication determined to be valid by the communication determination unit from the log time series data, and the communication determination unit determines that the communication corresponding to the non-execution log is unauthorized when the modified log time series data further includes a non-execution log. Since only the first log corresponding to the communication determined to be valid by the communication determination unit is deleted, it becomes possible to generate and manage modified log time series data that is easy to handle and highly reliable while keeping the data volume smaller than that of the original log time series data, without deleting the first log based on the unauthorized communication.

[0061] (4) The log acquisition unit further acquires a history of a second log that is generated when an abnormality occurs in the device and indicates the type of the abnormality, and the communication determination unit, when a non-execution log is further included in the correction log time-series data, re-determines the validity of the communication corresponding to the non-execution log based on the second log. In this way, by taking into account the second log related to the DTC in addition to the first log related to the NRC, the validity of the UDS communication can be determined with higher accuracy.

[0062] The present invention is not limited to the above-described embodiments, and various modifications are possible. For example, the above-described embodiments have been described in detail to clearly explain the present invention, and the present invention is not necessarily limited to an embodiment having all of the configurations described. It is also possible to replace a part of the configuration of one embodiment with the configuration of another embodiment. It is also possible to add the configuration of another embodiment to the configuration of one embodiment. It is also possible to delete a part of the configuration of each embodiment, or to add or replace another configuration. [Explanation of symbols]

[0063] 1 diagnostic server (vehicle diagnostic system), 3 vehicle, 13 log acquisition unit, 14 log processing unit, 15 communication determination unit, 17 vehicle diagnostic history storage unit

Claims

1. a log acquisition unit that acquires a history of a first log indicating whether or not a device in a vehicle has performed a predetermined process in response to a request signal that requests the device to perform the predetermined process; a communication determination unit that, when a non-execution log indicating that the predetermined process was not executed is included in the history, determines the validity of the communication used to transmit the request signal corresponding to the non-execution log. A vehicle diagnostic system comprising:

2. 2. The vehicle diagnosis system according to claim 1, a log processing unit that extracts the history in a chronological order to generate log time-series data; A vehicle diagnosis history storage unit that stores a history of vehicle diagnoses performed on the vehicle, the communication determination unit compares the log time series data with the vehicle diagnosis history, and when a record corresponding to the non-execution log exists in the vehicle diagnosis history, determines that the communication corresponding to the non-execution log is valid. A vehicle diagnostic system comprising:

3. 3. A vehicle diagnosis system according to claim 2, the log processing unit deletes, from the log time-series data, the first log corresponding to the communication determined to be valid by the communication determination unit to generate corrected log time-series data; When the non-execution log is further included in the correction log time series data, the communication determination unit determines that the communication corresponding to the non-execution log is unauthorized. A vehicle diagnostic system comprising:

4. 4. A vehicle diagnosis system according to claim 3, The log acquisition unit further acquires a history of a second log that is generated when an abnormality occurs in the device and indicates a type of the abnormality; When the non-execution log is further included in the correction log time series data, the communication determination unit re-determines the validity of the communication corresponding to the non-execution log based on the second log. A vehicle diagnostic system comprising:

Images