Abnormality detection method, device and equipment and readable storage medium

Abstract

The invention belongs to the technical field of automobile diagnosis, and discloses an anomaly detection method, device and equipment and a readable storage medium, and the method comprises the steps: obtaining a diagnosis communication message log corresponding to a target vehicle; classifying the diagnosis communication message log to obtain a diagnosis message log and an application message log; detecting the timeout position of the diagnosis message by using the time parameter of the diagnosis message log; detecting a loss position of the diagnosis message by utilizing the diagnosis message log and combining a response mechanism corresponding to the addressing category; detecting the period deviation of the application message by using the application message log; outputting abnormal information; wherein the abnormal information comprises an overtime position, a loss position and a periodic deviation. The timeout position, the loss position and the periodic deviation can be detected based on the diagnosis communication message log corresponding to the target vehicle.

Description

Technical Field

[0001] The present application relates to the field of automobile diagnosis technology, and in particular to an abnormality detection method, device, equipment and readable storage medium. Background Art

[0002] The upgrade, calibration, self-diagnosis and interaction of vehicle ECUs all rely on a large number of diagnostic communication messages, and the client implements a series of operations through diagnostic service commands.

[0003] Sending large quantities of diagnostic and application communication messages often results in message anomalies, such as loss, timeout, and cycle deviation. However, the large volume of diagnostic communication messages cannot accurately locate the above problems, resulting in the client not being able to find problems in time, and the accuracy of screening anomalies is low, which can easily lead to omissions and loopholes.

[0004] In summary, how to effectively solve the problem of message anomaly detection is a technical problem that technical personnel in this field urgently need to solve. Summary of the invention

[0005] The purpose of this application is to provide an anomaly detection method, device, equipment and readable storage medium, which can accurately detect the abnormal location of the message and further provide reliable reference information for the diagnostic terminal to discover the problem of the target vehicle.

[0006] In order to solve the above technical problems, this application provides the following technical solutions:

[0007] A message anomaly detection method, comprising:

[0008] Obtain the diagnostic communication message log corresponding to the target vehicle;

[0009] Classifying the diagnostic communication message log to obtain a diagnostic message log and an application message log;

[0010] Using the time parameter of the diagnostic message log, detecting the timeout position of the diagnostic message;

[0011] Utilizing the diagnostic message log and combining the response mechanism corresponding to the addressing category, detecting the loss location of the diagnostic message;

[0012] Utilizing the application message log, detecting a periodic deviation of the application message;

[0013] Output abnormal information; wherein the abnormal information includes the timeout position, the loss position and the period deviation.

[0014] Preferably, it also includes:

[0015] Obtain target application messages with periodic deviations;

[0016] Determining a count value of the target application message;

[0017] If the count value is 0 and does not match the count value of the target application message, it is determined that the target application message corresponds to a reset restart position.

[0018] Preferably, using the diagnostic message log in combination with a response mechanism corresponding to the addressing category to detect the lost location of the diagnostic message includes:

[0019] Determine the addressing category corresponding to the target diagnostic message by using the ID identifier of the diagnostic message log;

[0020] detecting, according to a response mechanism corresponding to the addressing category, whether the target diagnostic message is discarded;

[0021] If yes, the location of the target diagnosis message is the lost location.

[0022] Preferably, detecting whether the target diagnostic message is discarded according to a response mechanism corresponding to the addressing category includes:

[0023] If the addressing category is physical addressing, then when the response bit of the target diagnostic message is empty, it is determined that the target diagnostic message is discarded, and when the response bit of the target diagnostic message is not empty, it is determined that the target diagnostic message is not discarded;

[0024] If the addressing category is functional addressing, then when the response bit of the target diagnostic message is empty, it is determined that the target diagnostic message is discarded; and when there is at least one response bit in the target diagnostic message, it is determined that the target diagnostic message is not discarded.

[0025] Preferably, after obtaining the diagnostic communication message log corresponding to the target vehicle, the method further includes:

[0026] Reading fault code data from the diagnostic communication message log;

[0027] The fault code data is used to determine the fault type and fault status.

[0028] Preferably, using the application message log to detect the periodic deviation of the application message includes:

[0029] Using the application message log, determining the timestamp of each frame of the application message;

[0030] Calculate the message interval period using the timestamps of adjacent application messages;

[0031] The message interval period is compared with a normal period to determine application messages with period deviations.

[0032] Preferably, it also includes:

[0033] Using the application message log, obtain the count value of each frame of application message;

[0034] The count value is used to determine the frame loss position or the missed transmission position of the application message.

[0035] An abnormality detection device, comprising:

[0036] A log acquisition module is used to obtain the diagnostic communication message log corresponding to the target vehicle;

[0037] A log classification module, used to classify the diagnostic communication message log to obtain a diagnostic message log and an application message log;

[0038] A timeout detection module, used to detect the timeout position of the diagnostic message using the time parameter of the diagnostic message log;

[0039] A loss detection module, used to detect the loss position of the diagnostic message by using the diagnostic message log and combining the response mechanism corresponding to the addressing category;

[0040] A period detection module, used to detect the period deviation of the application message using the application message log;

[0041] The abnormality output module is used to output abnormality information; wherein the abnormality information includes the timeout position, the loss position and the period deviation.

[0042] An electronic device, comprising:

[0043] Memory for storing computer programs;

[0044] A processor is used to implement the steps of the above-mentioned abnormality detection method when executing the computer program.

[0045] A readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps of the above-mentioned abnormality detection method are implemented.

[0046] Apply the method provided in the embodiment of the present application to obtain the diagnostic communication message log corresponding to the target vehicle; classify the diagnostic communication message log to obtain the diagnostic message log and the application message log; use the time parameter of the diagnostic message log to detect the timeout position of the diagnostic message; use the diagnostic message log in combination with the response mechanism corresponding to the addressing category to detect the loss position of the diagnostic message; use the application message log to detect the periodic deviation of the application message; output abnormal information; wherein the abnormal information includes the timeout position, the loss position and the periodic deviation.

[0047] In the present application, after obtaining the diagnostic communication message log corresponding to the target vehicle, the diagnostic communication message log is first classified to determine the diagnostic message log and the application message log. For the time parameter of the diagnostic message log, the timeout position of the diagnostic message can be detected. Using the diagnostic message log and combining the response mechanism corresponding to the addressing category, the loss position of the diagnostic message can be detected. For the application message log, the periodic deviation of the application message can be detected. Finally, the abnormal information is output. The abnormal information is at least one of the detected timeout position, loss position and periodic deviation.

[0048] Accordingly, the embodiments of the present application also provide anomaly detection devices, equipment and readable storage media corresponding to the above-mentioned anomaly detection method, which have the above-mentioned technical effects and are not repeated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0049] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the related technologies, the drawings required for use in the embodiments or the related technical descriptions are briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0050] FIG1 is a flowchart of an implementation of an abnormality detection method in an embodiment of the present application;

[0051] FIG2 is a schematic diagram of the structure of an abnormality detection device in an embodiment of the present application;

[0052] FIG3 is a schematic diagram of the structure of an electronic device in an embodiment of the present application;

[0053] FIG4 is a schematic diagram of a specific structure of an electronic device in an embodiment of the present application;

[0054] FIG5 is a schematic diagram of a specific implementation of an abnormality detection method in an embodiment of the present application. DETAILED DESCRIPTION

[0055] In order to enable those skilled in the art to better understand the present application, the present application is further described in detail below in conjunction with the accompanying drawings and specific implementation methods. Obviously, the described embodiments are only part of the embodiments of the present application, rather than all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in the field without making creative work are within the scope of protection of the present application.

[0056] Please refer to FIG1 , which is a flow chart of an abnormality detection method in an embodiment of the present application, and the method includes the following steps:

[0057] S101. Obtain a diagnostic communication message log corresponding to a target vehicle.

[0058] The target vehicle may be any vehicle having an ECU (Electronic Control Unit).

[0059] The upgrade, calibration, self-diagnosis and interaction of the ECU in the target vehicle all rely on a large number of diagnostic communication messages. The diagnostic client implements a series of operations through diagnostic service commands and records the diagnostic communication message logs.

[0060] In this embodiment, the diagnostic communication message log can be a log recorded after the ECU and the diagnostic client communicate under any requirement. The diagnostic communication message can be recorded locally in real time, or can be pulled from the diagnostic client through communication with the diagnostic client, or can be read from a storage medium.

[0061] S102: Classify the diagnostic communication message log to obtain a diagnostic message log and an application message log.

[0062] The diagnostic communication message log can record the timestamp (Time), channel (Chn), CANID (CAN (Controller Area Network) bus, ID is identifier), event type (EventType), type (Dir), data length (Date Length), data encoding (Date ASCII) and data (Data) of each frame message.

[0063] Based on the configuration parameters and DBC (Database CAN), the diagnostic communication message log can be classified to obtain the diagnostic message log and the application message log.

[0064] For example: diagnostic communication messages are divided into application messages and diagnostic messages. Except for messages with identifiers 0x793 (diagnostic physical addressing request CANID (one-to-one)), 0x7DF (diagnostic function addressing request CANID (one-to-many)) and 0x79B (diagnostic response CANID), which are diagnostic messages, the remaining identifiers correspond to application messages. Therefore, based on CANID, the diagnostic communication message log can be divided into diagnostic message log and application message log.

[0065] S103: Detect the timeout position of the diagnostic message using the time parameter of the diagnostic message log.

[0066] As shown in Table 1 below:

[0067] Table 1 is a schematic table of time parameters

[0068]

[0069] Among them, P2Server: the timer performance requirement value between the ECU receiving the request message and sending the response message. The ECU must ensure that a single-frame response message or the first frame message of a multi-frame response message is completed within P2Server, usually 50ms (milliseconds).

[0070] P2*Server: Indicates the enhanced timer performance requirement value from the time the ECU sends a negative response message with NRC of 0x78 to the start of sending the next response message, usually 5000 ms.

[0071] S3Server: Only used for non-default sessions, specifically when the system switches the original default session to non-default session mode through the function addressing detector. If the server does not receive any diagnostic request message within the S3Server time, it exits the non-default session mode and returns to the default session mode. Usually 5000 ms.

[0072] P2Client: The timeout setting when the client waits for the response from the server after successfully sending a diagnostic request message.

[0073] P2*Client: Enhanced timeout setting when the client waits for the server to send a response after receiving a diagnostic negative response NRC of 0x78.

[0074] S3Client: To maintain a non-default session automation connection, the interval between two TesterPresent request messages is usually 4000ms.

[0075] Based on the time parameters shown in Table 1, that is, using the time parameters of the diagnostic message log in combination with the timestamp of the specific diagnostic message, the timeout position of the diagnostic message can be detected, which will not be described one by one here.

[0076] S104: Detect the loss position of the diagnostic message by using the diagnostic message log and combining the response mechanism corresponding to the addressing category.

[0077] In a specific implementation of the present application, the diagnostic message log is used in combination with a response mechanism corresponding to the addressing category to detect the loss position of the diagnostic message, including:

[0078] Step 1: Use the ID of the diagnostic message log to determine the addressing category corresponding to the target diagnostic message;

[0079] Step 2: Detect whether the target diagnostic message is discarded according to the response mechanism corresponding to the addressing class;

[0080] Step 3: If yes, the location of the target diagnostic message is the lost location.

[0081] Among them, step 2, detecting whether the target diagnostic message is discarded according to the response mechanism corresponding to the addressing category, includes:

[0082] Case 1: If the addressing category is physical addressing, then when the response bit of the target diagnostic message is empty, it is determined that the target diagnostic message is discarded, and when the response bit of the target diagnostic message is not empty, it is determined that the target diagnostic message is not discarded;

[0083] Case 2: If the addressing category is functional addressing, when the response bit of the target diagnostic message is empty, it is determined that the target diagnostic message is discarded, and when there is at least one response bit in the target diagnostic message, it is determined that the target diagnostic message is not discarded.

[0084] For ease of description, the above steps are combined for explanation below.

[0085] Please refer to Table 2:

[0086] Table 2 is a schematic diagram of the diagnostic message

[0087]

[0088] For physically addressed requests: one diagnostic message request corresponds to one diagnostic message response, unless the disable positive response bit is set. For example, 02 3e 00 requires a response of 02 7e 00, but if the disable positive response bit is set, 02 3e 80 does not require a response.

[0089] Functionally addressed requests are one-to-many and will have at least one response unless the Disable Positive Response bit is set.

[0090] Therefore, when determining the lost position, it can be based on whether the response bit is set after the diagnostic message request, that is, whether the response message is received if it is not prohibited. Specifically, in the case of no prohibited response, if the request is a physical addressing request, then its response message is one, and if the request is a functional addressing, then corresponding to the functional addressing, its response should be at least one.

[0091] That is to say, if it is clear based on the diagnostic message log that a physical addressing request message has been sent, then the corresponding response bit should have a record log corresponding to the response message. If not, it indicates that the request message is lost; if it is clear based on the diagnostic message log that a functional addressing request message has been sent, then the corresponding response bit should have at least one record log corresponding to the response message. If not, it indicates that the request message is lost.

[0092] For example, in a diagnostic message log, the following logs are recorded in sequence:

[0093] At time a, a log with ID 0X79B was recorded;

[0094] At time b, a log with ID 0X7DF was recorded;

[0095] At time c, a log with ID 0X793 was recorded;

[0096] At time d, a log with ID 0X79B was recorded;

[0097] At time e, a log with ID 0X793 was recorded;

[0098] It can be seen that there is no corresponding response message record for the function request recorded at time b, which clearly shows that the request message recorded at time b is lost; correspondingly, the physical addressing request recorded at time c received a response message at time d. In other words, based on the corresponding response of the addressing, it can be determined that the function addressing request issued at time b is lost, and thus the location where the diagnostic message is lost is determined to be time b.

[0099] S105: Detect the periodic deviation of the application message by using the application message log.

[0100] Based on the application message log, the message interval can be calculated for the log record of each frame of the application message. Then, according to the DBC cycle, it is determined whether the cycle deviation is within the normal deviation range (generally 5%-10% deviation), so as to determine whether there is a timeout, that is, whether there is a cycle deviation.

[0101] For example, according to DBC, the application message period of CANID 1B0 is 20ms (0.020s). Therefore, based on the difference between the timestamps of adjacent application messages, the time interval of the application messages can be known, and the period deviation of the application messages can be detected by comparing the time interval with the application message period.

[0102] In a specific implementation of the present application, using the application message log to detect the periodic deviation of the application message includes:

[0103] Use the application message log to determine the timestamp of each frame of the application message;

[0104] Calculate the message interval period using the timestamps of adjacent application messages;

[0105] Compare the message interval period with the normal period to identify application messages with period deviations.

[0106] For ease of description, the above steps are combined for explanation below.

[0107] For example: All 1B0 messages can be extracted, and by subtracting the timestamp of the previous frame application message from the timestamp of the next frame application message, it is calculated whether the average time interval between each frame is 20ms±2ms (10% deviation). If so, it is determined that the period deviation is normal. If not, the application message that detects the period deviation is determined.

[0108] In a specific implementation of the present application, it also includes:

[0109] Obtain target application messages with periodic deviations;

[0110] Determine a count value of a target application message;

[0111] If the count value is 0 and does not match the count value of the target application message, the target application message is determined to correspond to a reset restart position.

[0112] For ease of description, the above steps are combined for explanation below.

[0113] For each frame of application message log records, check the RC stacking order, and locate the place where frame loss or missed transmission occurs based on the discontinuous count values ​​or incorrect first and last values ​​corresponding to the counter.

[0114] For application messages with period timeout, and the superposition order of RC is wrong (interrupt starts from 0), the reset and restart position is determined.

[0115] For example: Rollingcounter (RC, counter) will be recorded in the data of CAN message. The data in the log record will record the Rolling Counter (count value of the rolling counter), which is mainly used for the sequential sending and receiving of messages, and the count will cycle from 0 to 15. That is, each time a CAN message is sent, the Rollingcounter count increases by 1, and after accumulating to 15, it becomes 0 and continues to cycle.

[0116] Generally, after the ECU is started, the RC of the application message starts counting from 0, so the reset and restart location can be located by superimposing the periodic interval timeout and the sudden RC interruption from 0. Since the problem is too serious, the ECU is generally restarted, so clarifying the reset and restart location is of great reference value for subsequent analysis of ECU problems.

[0117] In a specific implementation of the present application, it also includes:

[0118] Use the application message log to obtain the count value of each frame of application message;

[0119] The count value is used to determine the frame loss position or missed transmission position of the application message.

[0120] According to the RC principle, if the log record of the target application message shows that the counter is discontinuous or the first and last values ​​are incorrect, it can be detected whether there is frame loss or missed frame transmission.

[0121] S106. Output abnormal information.

[0122] The abnormal information includes the detected timeout position, loss position and cycle deviation.

[0123] After detecting at least one of the timeout position, lost position and periodic deviation, it is output as abnormal information for subsequent problem location and analysis.

[0124] In a specific implementation of the present application, after obtaining the diagnostic communication message log corresponding to the target vehicle, the method further includes:

[0125] Read fault code data from the diagnostic communication message log;

[0126] Use the fault code data to determine the fault type and fault status.

[0127] For ease of description, the above steps are combined for explanation below.

[0128] The DTC partial message (i.e. fault code data) can be read through service 19 (i.e. the service for reading DTC related information); according to the logic of the UDS protocol (iso14229), the fault code (DTC) and the current fault status can be extracted. Then, based on the extracted fault code data, the major fault types can be parsed (the specific fault name can also be parsed).

[0129] Specifically, the highest two bits of the highest byte of the DTC (3 bytes in total), indicating which system (general fault type) the DTC belongs to, are shown in Table 3:

[0130] Table 3 is the correspondence table between DTC and fault type

[0131]

[0132] Then, based on the proposed fault status code (1 byte), it is reported whether the fault is present tense or historical past tense. The DTC status mask parameter includes 8 DTC status bits, which correspond to 8 specific fault states.

[0133] Apply the method provided in the embodiment of the present application to obtain the diagnostic communication message log corresponding to the target vehicle; classify the diagnostic communication message log to obtain a diagnostic message log and an application message log; use the time parameter of the diagnostic message log to detect the timeout position of the diagnostic message; use the diagnostic message log in combination with the response mechanism corresponding to the addressing category to detect the loss position of the diagnostic message; use the application message log to detect the periodic deviation of the application message; output abnormal information; wherein the abnormal information includes at least one of the timeout position, the loss position and the periodic deviation.

[0134] In the present application, after obtaining the diagnostic communication message log corresponding to the target vehicle, the diagnostic communication message log is first classified to determine the diagnostic message log and the application message log. For the time parameter of the diagnostic message log, the timeout position of the diagnostic message can be detected. Using the diagnostic message log and combining the response mechanism corresponding to the addressing category, the loss position of the diagnostic message can be detected. For the application message log, the periodic deviation of the application message can be detected. Finally, the abnormal information is output. The abnormal information is at least one of the detected timeout position, loss position and periodic deviation.

[0135] Corresponding to the above method embodiment, the embodiment of the present application further provides an abnormality detection device, and the abnormality detection device described below and the abnormality detection method described above can refer to each other.

[0136] As shown in FIG2 , the device includes the following modules:

[0137] The log acquisition module 101 is used to acquire the diagnostic communication message log corresponding to the target vehicle;

[0138] The log classification module 102 is used to classify the diagnostic communication message log to obtain the diagnostic message log and the application message log;

[0139] A timeout detection module 103, used to detect the timeout position of the diagnostic message using the time parameter of the diagnostic message log;

[0140] The loss detection module 104 is used to detect the loss position of the diagnostic message by using the diagnostic message log and combining the response mechanism corresponding to the addressing category;

[0141] The period detection module 105 is used to detect the period deviation of the application message by using the application message log;

[0142] The abnormality output module 106 is used to output abnormality information; wherein the abnormality information includes timeout position, loss position and cycle deviation.

[0143] Using the device provided in the embodiment of the present application, the diagnostic communication message log corresponding to the target vehicle is obtained; the diagnostic communication message log is classified to obtain a diagnostic message log and an application message log; the time parameter of the diagnostic message log is used to detect the timeout position of the diagnostic message; the diagnostic message log is used in combination with the response mechanism corresponding to the addressing category to detect the loss position of the diagnostic message; the application message log is used to detect the periodic deviation of the application message; and abnormal information is output; wherein the abnormal information includes the timeout position, the loss position and the periodic deviation.

[0144] In the present application, after obtaining the diagnostic communication message log corresponding to the target vehicle, the diagnostic communication message log is first classified to determine the diagnostic message log and the application message log. For the time parameter of the diagnostic message log, the timeout position of the diagnostic message can be detected. Using the diagnostic message log and combining the response mechanism corresponding to the addressing category, the loss position of the diagnostic message can be detected. For the application message log, the periodic deviation of the application message can be detected. Finally, the abnormal information is output. The abnormal information is at least one of the detected timeout position, loss position and periodic deviation.

[0145] In a specific implementation of the present application, it also includes:

[0146] The reset and restart detection is used to obtain a target application message with a period deviation; determine a count value of the target application message; if the count value is 0 and does not match the count value of the target application message, determine a reset and restart position corresponding to the target application message.

[0147] In a specific implementation of the present application, the loss detection module is specifically used to use the ID identifier of the diagnostic message log to determine the addressing category corresponding to the target diagnostic message; according to the response mechanism corresponding to the addressing category, detect whether the target diagnostic message is discarded; if so, the location of the target diagnostic message is the lost location.

[0148] In a specific implementation of the present application, the loss detection module is specifically used to determine that the target diagnostic message is discarded if the addressing category is physical addressing and that the target diagnostic message is not discarded if the response bit of the target diagnostic message is empty;

[0149] If the addressing category is functional addressing, when the response bit of the target diagnostic message is empty, it is determined that the target diagnostic message is discarded, and when there is at least one response bit in the target diagnostic message, it is determined that the target diagnostic message is not discarded.

[0150] In a specific implementation of the present application, it also includes:

[0151] The fault detection module is used to read the fault code data from the diagnostic communication message log after obtaining the diagnostic communication message log corresponding to the target vehicle; and determine the fault type and fault status using the fault code data.

[0152] In a specific implementation of the present application, the period detection module is specifically used to use the application message log to determine the timestamp of each frame of the application message; use the timestamps of adjacent application messages to calculate the message interval period; compare the message interval period with the normal period to determine the application message with the period deviation.

[0153] In a specific implementation of the present application, it also includes:

[0154] Frame loss / missing detection is used to obtain the count value of each frame of application message by using the application message log; and determine the frame loss position or missing position of the application message by using the count value.

[0155] To facilitate those skilled in the art to better understand and implement the anomaly detection method and device provided in the embodiments of the present application, the anomaly detection method and device are described in detail below with reference to a specific scenario as an example.

[0156] As can be seen from the above, the anomaly detection method provided in the embodiment of the present application can provide a log to detect the loss and timeout of diagnostic messages, which is used for anomalies such as periodic deviation of messages.

[0157] In the actual implementation process, the specific implementation steps may be referred to FIG. 5 , including:

[0158] S1. Obtain the first diagnostic communication message log and import the log into the anomaly detection device;

[0159] S2. Parse the logs and filter out the diagnostic message logs and application message logs according to the configuration parameters and DBC;

[0160] S3, locate and extract abnormal messages (including: 1. diagnose message abnormalities and locate the positions of negative feedback, timeout, and loss; 2. apply message abnormalities and calculate cycle deviations; 3. if there is a DTC fault code, extract the current fault type);

[0161] S4. Generate reports based on different abnormal results according to preset logic.

[0162] The abnormality detection of the diagnostic message log specifically includes the following steps:

[0163] S201, obtaining a diagnostic message log;

[0164] S202, based on the screened diagnostic message log, according to the UDS protocol (ISO14229) logic, first locate the location of the negative response;

[0165] S203, locating the timeout position of the remaining diagnostic message data according to the time parameter;

[0166] S204. Distinguish physical addressing and functional addressing, and locate the lost position according to the response mechanism.

[0167] The following steps are specifically included for anomaly detection of application message logs:

[0168] S301, obtaining application message log;

[0169] S302, based on the filtered application message log, according to the DBC cycle, first extract the CANID corresponding to the abnormal cycle;

[0170] Specifically, for each frame of application message, the message interval is calculated; according to the DBC cycle, it is determined whether the cycle deviation is within the normal deviation range (generally 5%-10% deviation) and whether there is a timeout, so as to extract the CANID of the abnormal cycle.

[0171] S303, based on the filtered target data, for each frame of application message, check the RC superposition order, and locate the place where the frame is lost or missed according to the discontinuity of the counter or the wrong first and last values;

[0172] S304: There is an application message with a period timeout, and the superposition order of RC is wrong (interrupt starts from 0), so as to determine the reset and restart position.

[0173] For fault identification with fault code log, the following steps are specifically included:

[0174] S401, obtain 19 service to read DTC part message;

[0175] S402, get 19 service (service for reading DTC related information) to read some DTC messages; extract the fault code (DTC) and current fault status according to the UDS protocol (iso14229) logic;

[0176] S403, parsing out the major fault types (or the specific fault names) according to the extracted fault code data;

[0177] S404. According to the proposed fault status code (1 byte), report whether the fault is in present continuous tense or historical past tense.

[0178] The device can come with a unified configuration parameter template, which can standardize the different requirements of different OEMs into a consistent format; because the device logic is universal and widely used, it can take into account all the factors involved, accurately and cover a wide range of issues. The frequency of interaction between the client and the ECU often results in a large number of data logs, and manual analysis often makes it difficult to locate specific problems. The device greatly solves the omission of bad problems, quickly locates problems, and avoids subsequent ECU repairs. For other departments that are not familiar with diagnosis, in actual matching test applications, they can also analyze problems on site without having to transfer to lower-level personnel, which can greatly reduce time and improve efficiency.

[0179] Corresponding to the above method embodiment, an embodiment of the present application further provides an electronic device, and the electronic device described below and the abnormality detection method described above can refer to each other.

[0180] As shown in FIG3 , the electronic device includes:

[0181] A memory 332, for storing computer programs;

[0182] The processor 322 is used to implement the steps of the abnormality detection method of the above method embodiment when executing the computer program.

[0183] Specifically, please refer to FIG. 4, which is a schematic diagram of the specific structure of an electronic device provided in this embodiment. The electronic device may have relatively large differences due to different configurations or performances, and may include one or more processors (central processing units, CPU) (for example, one or more processors) and a memory 332, and the memory 332 stores one or more computer programs 342 or data 344. Among them, the memory 332 can be a temporary storage or a permanent storage. The program stored in the memory 332 may include one or more modules (not shown in the figure), and each module may include a series of instruction operations in the data processing device. Furthermore, the processor 322 can be configured to communicate with the memory 332 to execute a series of instruction operations in the memory 332 on the electronic device 301.

[0184] The electronic device 301 may further include one or more power supplies 326 , one or more wired or wireless network interfaces 350 , one or more input and output interfaces 358 , and / or one or more operating systems 341 .

[0185] The steps in the abnormality detection method described above can be implemented by the structure of an electronic device.

[0186] Corresponding to the above method embodiment, the embodiment of the present application further provides a readable storage medium. The readable storage medium described below and the anomaly detection method described above can refer to each other.

[0187] A readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps of the abnormality detection method of the above method embodiment are implemented.

[0188] The readable storage medium may specifically be a U disk, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk, or other readable storage medium that can store program codes.

[0189] In this specification, each embodiment is described in a progressive manner, and each embodiment focuses on the differences from other embodiments. The same or similar parts between the embodiments can be referred to each other. For the device disclosed in the embodiment, since it corresponds to the method disclosed in the embodiment, the description is relatively simple, and the relevant parts can be referred to the method part.

[0190] Those skilled in the art may further appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented with electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the composition and steps of each example have been generally described in terms of function in the above description. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art may use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

[0191] The steps of the method or algorithm described in conjunction with the embodiments disclosed herein may be implemented directly using hardware, a software module executed by a processor, or a combination of the two. The software module may be placed in a random access memory (RAM), a memory, a read-only memory (ROM), an electrically programmable ROM, an electrically erasable programmable ROM, a register, a hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art.

[0192] Finally, it should be noted that, in this article, relationships such as first and second, etc. are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms include, include or any other variations are intended to cover non-exclusive inclusion, so that a process, method, article or device that includes a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device.

[0193] Specific examples are used herein to illustrate the principles and implementation methods of the present application. The description of the above embodiments is only used to help understand the method and core idea of ​​the present application. At the same time, for those skilled in the art, according to the idea of ​​the present application, there will be changes in the specific implementation methods and application scope. In summary, the content of this specification should not be understood as a limitation on the present application.

Claims

1. An anomaly detection method, characterized in that: include: Obtain the diagnostic communication message log corresponding to the target vehicle; Classifying the diagnostic communication message log to obtain a diagnostic message log and an application message log; Using the time parameter of the diagnostic message log, detecting the timeout position of the diagnostic message; Utilizing the diagnostic message log and combining the response mechanism corresponding to the addressing category, detecting the loss location of the diagnostic message; Utilizing the application message log, detecting a periodic deviation of the application message; Output abnormal information; wherein the abnormal information includes the timeout position, the loss position and the period deviation.

2. The method according to claim 1, characterized in that Also includes: Obtain target application messages with periodic deviations; Determining a count value of the target application message; If the count value is 0 and does not match the count value of the target application message, it is determined that the target application message corresponds to a reset restart position.

3. The method according to claim 1, characterized in that Utilizing the diagnostic message log and combining the response mechanism corresponding to the addressing category to detect the loss position of the diagnostic message includes: Determine the addressing category corresponding to the target diagnostic message by using the ID identifier of the diagnostic message log; detecting, according to a response mechanism corresponding to the addressing category, whether the target diagnostic message is discarded; If yes, the location of the target diagnosis message is the lost location.

4. The method according to claim 3, characterized in that Detecting whether the target diagnostic message is discarded according to a response mechanism corresponding to the addressing category includes: If the addressing category is physical addressing, then when the response bit of the target diagnostic message is empty, it is determined that the target diagnostic message is discarded, and when the response bit of the target diagnostic message is not empty, it is determined that the target diagnostic message is not discarded; If the addressing category is functional addressing, then when the response bit of the target diagnostic message is empty, it is determined that the target diagnostic message is discarded; and when there is at least one response bit in the target diagnostic message, it is determined that the target diagnostic message is not discarded.

5. The method according to claim 1, characterized in that: After obtaining the diagnostic communication message log corresponding to the target vehicle, it also includes: Reading fault code data from the diagnostic communication message log; The fault code data is used to determine the fault type and fault status.

6. The method according to claim 1, characterized in that Utilizing the application message log, detecting the periodic deviation of the application message includes: Using the application message log, determining the timestamp of each frame of the application message; Calculate the message interval period using the timestamps of adjacent application messages; The message interval period is compared with a normal period to determine application messages with period deviations.

7. The method according to any one of claims 1 to 6, characterized in that: Also includes: Using the application message log, obtain the count value of each frame of application message; The count value is used to determine the frame loss position or the missed transmission position of the application message.

8. An abnormality detection device, characterized in that: include: A log acquisition module is used to obtain the diagnostic communication message log corresponding to the target vehicle; A log classification module, used to classify the diagnostic communication message log to obtain a diagnostic message log and an application message log; A timeout detection module, used to detect the timeout position of the diagnostic message using the time parameter of the diagnostic message log; A loss detection module, used to detect the loss position of the diagnostic message by using the diagnostic message log and combining the response mechanism corresponding to the addressing category; A period detection module, used to detect the period deviation of the application message using the application message log; An abnormality output module is used to output abnormality information; wherein the abnormality information includes the timeout position, the loss position and the period deviation.

9. An electronic device, characterized in that: include: Memory for storing computer programs; A processor, configured to implement the steps of the anomaly detection method according to any one of claims 1 to 7 when executing the computer program.

10. A readable storage medium, characterized in that: The readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps of the abnormality detection method according to any one of claims 1 to 7 are implemented.

Images