CAN bus fault detection method and system

Abstract

The invention relates to the technical field of CAN bus detection, in particular to a CAN bus fault detection method and system. The method comprises the following steps: extracting a first signal feature set in transmission data of a CAN bus, extracting a first abnormal feature set from the first signal feature set, and determining a suspected fault reason of each abnormal feature in the first abnormal feature set; screening the suspected fault cause of each abnormal feature based on the fault feature mapping relationship to obtain the fault cause of each abnormal feature; determining a first fault index of a target fault reason based on the historical fault data, determining a second fault index of the target fault reason based on the fault reason of each abnormal feature, and calculating a fault index of the target fault reason based on the first fault index and the second fault index; and based on the fault index corresponding to each fault reason, formulating a fault removal strategy and sending the fault removal strategy to terminal equipment of a detector. According to the invention, the method can achieve the precise positioning of a CAN bus fault.

Description

Technical Field

[0001] This application relates to the field of CAN bus detection technology, and in particular to a CAN bus fault detection method and system. Background Technology

[0002] With the rapid development of automotive electronics, industrial automation, and other fields, the CAN bus has become a key technology for inter-device communication due to its high reliability and real-time performance. In these application scenarios, a CAN bus failure can lead to serious consequences such as vehicle control system malfunctions and industrial equipment downtime. Therefore, fault detection of the CAN bus is crucial.

[0003] Currently, common CAN bus fault detection technologies include voltage measurement based on the physical layer and error frame statistics based on the data link layer. Voltage measurement determines the presence of faults such as short circuits and open circuits by detecting the voltage values ​​on the CAN bus; error frame statistics locate faults by counting the number and type of error frames on the bus.

[0004] However, these methods often only detect a single type of fault and cannot accurately distinguish the specific cause of the fault, resulting in inaccurate fault location. Maintenance personnel need to spend a lot of time troubleshooting, which affects maintenance efficiency and system recovery speed. Summary of the Invention

[0005] To address the problem of inaccurate fault location in existing technologies for CAN buses, this application provides a CAN bus fault detection method and system.

[0006] Firstly, this application provides a CAN bus fault detection method, which adopts the following technical solution: A CAN bus fault detection method includes: Extract a first signal feature set from the transmitted data of the CAN bus, extract a first abnormal feature set from the first signal feature set, and determine the suspected fault cause of each abnormal feature in the first abnormal feature set. The fault feature mapping relationship is retrieved, and the suspected fault causes of each abnormal feature are screened based on the fault feature mapping relationship to obtain the fault cause of each abnormal feature; wherein, the fault feature mapping relationship includes the inevitable abnormal features and the probabilistic abnormal features caused by each fault cause. Take any fault cause as the target fault cause, determine the first fault index of the target fault cause based on historical fault data, determine the second fault index of the target fault cause based on the fault cause of each abnormal feature, and calculate the fault index of the target fault cause based on the first fault index and the second fault index. Based on the fault index corresponding to each fault cause, a fault resolution strategy is formulated and sent to the terminal device of the testing personnel.

[0007] By employing the above technical solution, signal feature sets of CAN bus transmission data are extracted, abnormal features are identified, and suspected fault causes are determined. Through multi-dimensional data collection and analysis, preliminary fault location is achieved. Next, fault causes are screened based on fault feature mapping relationships. Logical verification using certain and probabilistic abnormal features effectively eliminates false positives and improves the accuracy of fault cause identification. Then, a fault index is calculated by combining historical fault data with current abnormal features, balancing historical probability with real-time evidence to quantify the likelihood of a fault. Finally, a resolution strategy is formulated and sent based on the fault index, prioritizing high-probability faults to ensure the strategy's efficiency and relevance. The entire process is interconnected, significantly improving the accuracy, comprehensiveness, and maintenance efficiency of CAN bus fault detection, achieving precise fault location for CAN bus faults, and reducing manual troubleshooting costs and system downtime.

[0008] In a preferred embodiment, this application can be further configured such that the first signal feature set includes: message static features, dynamic behavior features, and correlation features; The step of extracting the first abnormal feature set from the first signal feature set includes: Identify rule anomalies that do not conform to preset rules from the static features and dynamic behavior features of the message; Identify logical anomalies that do not conform to preset logic from the associated features, and the rule anomalies and the logical anomalies constitute the first anomaly feature set.

[0009] By adopting the above technical solution, a first signal feature set containing message static features, dynamic behavior features and correlation features is extracted from the CAN bus transmission data. The bus communication status is fully covered through multi-dimensional data acquisition. Then, rule abnormal features that violate preset rules (such as illegal ID, DLC abnormality) are identified from the static and dynamic features, and illogical anomalies (such as timing errors, synchronization failure) are mined from the correlation features. Through rule and logic dual verification, potential fault signs of the protocol layer and communication logic layer are accurately captured.

[0010] In a preferred embodiment, this application can be further configured such that: the step of filtering the suspected fault causes of each abnormal feature based on the fault feature mapping relationship to obtain the fault cause of each abnormal feature includes: The suspected fault causes of each abnormal feature are divided into multiple fault groups according to the fault cause type. Each fault group contains a suspected fault cause and several abnormal features. Take any one of the multiple fault groups as the target fault group, and the suspected fault cause in the target fault group as the target suspected fault cause. Determine the target fault feature mapping relationship corresponding to the target suspected fault cause from the fault feature mapping relationship. The target fault group and the target fault feature mapping relationship are compared to determine whether all the abnormal features in the target fault group contain the necessary abnormal features in the target fault feature mapping relationship. If several abnormal features in the target fault group do not all contain the necessary abnormal features of the target fault feature mapping relationship, then the suspected fault cause is determined to be a non-fault cause, thereby obtaining the determination result of whether the suspected fault cause of each fault group is the non-fault cause. The cause of failure for each abnormal feature is obtained by removing all non-fault causes from the suspected causes of failure for each abnormal feature.

[0011] By adopting the above technical solution, for each group of suspected fault causes, the corresponding fault feature mapping relationship is retrieved, and logical verification is performed using the uniqueness of the necessary abnormal features. By comparing whether the abnormal features of the target fault group completely contain the necessary abnormal features, non-fault causes that do not meet the necessary conditions are accurately eliminated. This grouping screening and necessary feature verification mechanism can quickly eliminate irrelevant fault assumptions, narrow down the candidate range, avoid redundant investigation, and ensure that the finally determined fault cause has logical necessity.

[0012] In a preferred embodiment, this application can be further configured such that: the first fault index for determining the target fault cause based on historical fault data includes: Based on the historical fault data, the fault frequency of each fault cause is determined, and the fault causes are sorted from low to high according to the fault frequency to obtain a fault frequency list. Determine the position of the target fault cause in the fault frequency list, and calculate the first fault index based on the position.

[0013] By adopting the above technical solution, the frequency of occurrence of each fault cause is statistically analyzed based on historical fault data, and a fault frequency list is generated by sorting them accordingly; then, by determining the position of the target fault cause in the list, the first fault index is calculated, and the historical probability of fault occurrence is quantified into a comparable numerical indicator.

[0014] In a preferred embodiment, this application can be further configured such that: the second fault index for determining the target fault cause based on the fault cause of each abnormal feature includes: Based on the fault feature mapping relationship, determine the first number of probable abnormal features caused by the target fault cause; A second number of features that match the probabilistic abnormal features caused by the target fault are determined from the first set of abnormal features; The ratio of the second quantity to the first quantity is calculated as a second fault index for the target fault cause.

[0015] By adopting the above technical solution, the number of probabilistic abnormal features corresponding to the target fault cause is determined based on the fault feature mapping relationship, and the correlation range between the fault and potential abnormal phenomena is established. Then, probabilistic abnormal features that match the target fault cause are selected from the currently detected first abnormal feature set and counted. Finally, the second fault index is obtained by calculating the ratio of the two, which quantifies the degree of matching between the current abnormal phenomenon and the target fault cause. The probability relationship of the probabilistic abnormal features is fully utilized, which complements the first fault index guided by historical probability, thereby improving the comprehensiveness and accuracy of fault diagnosis.

[0016] In a preferred embodiment, this application can be further configured as follows: the step of formulating a fault resolution strategy based on the fault index corresponding to each fault cause and sending it to the terminal device of the testing personnel includes: Arrange the various causes of failure in descending order of the failure index to obtain a list of causes of failure. Starting from the first fault cause in the fault cause list, each fault cause is traversed sequentially until the necessary and possible abnormal features corresponding to the current fault cause and all previous fault causes can cover the first abnormal feature set. The system retrieves the current fault cause and the corresponding fault resolution methods for all previous fault causes, combines each fault resolution method into a first fault resolution strategy according to the order of the fault cause list, and sends the first fault resolution strategy to the terminal device of the testing personnel.

[0017] By adopting the above technical solution, the causes of failures are sorted from high to low according to their failure index, highlighting high-probability failures and achieving a scientific division of investigation priorities. By traversing the causes of failures, a set of key failures is selected based on feature coverage, ensuring that the strategy can comprehensively resolve the current anomaly. The corresponding resolution methods are retrieved and combined in sequence to generate an operable failure resolution strategy, which is then pushed to the testing personnel. Based on the data quantification results, blind attempts are avoided, high-probability failures are prioritized, and all anomalies are covered with the fewest operation steps, effectively improving the efficiency of failure repair, shortening system downtime, and reducing labor costs.

[0018] In a preferred embodiment, this application can be further configured such that, after sending the first fault-clearing strategy to the testing personnel's terminal device, the method further includes: When the signal indicating that the strategy has been executed is received from the inspector, the second signal feature set of the transmitted data of the CAN bus is extracted again, and the second abnormal feature set is extracted from the second signal feature set. The cause of failure for each abnormal feature in the second abnormal feature set is determined as the cause of failure to be resolved; The portion of the list following the current fault cause in the fault cause list will be used as the list to be resolved. Based on the cause of the fault to be resolved and the list of faults to be resolved, a second fault resolution strategy is formulated, and the second fault resolution strategy is sent to the terminal device of the testing personnel.

[0019] By adopting the above technical solution, after executing the first fault resolution strategy, a new round of detection is triggered by receiving the execution completion signal, the signal characteristics of the bus data are re-extracted and anomalies are identified, ensuring that unresolved potential faults can be discovered in a timely manner; the fault causes of new anomalies are combined with the unverified parts of the original fault list, which not only continues the previous diagnostic results, but also includes newly discovered fault clues; on this basis, a second fault resolution strategy is formulated and sent to realize dynamic iteration of fault investigation, avoid omissions in one-time diagnosis, and ensure that CAN bus faults are thoroughly and efficiently resolved.

[0020] Secondly, this application provides a CAN bus fault system, which adopts the following technical solution: A CAN bus fault detection system includes: a fault detector and an electronic device, wherein the fault detector includes a data acquisition module and a display module; The data acquisition module is used to acquire the transmission data of the CAN bus and send it to the electronic device, as well as to receive external trigger signals; The display module is used to receive the fault cause analyzed by the electronic device, and to display the waveform and voltage value of the external trigger signal; The electronic device is used to perform the CAN bus fault detection method as described in any of the first aspects.

[0021] In a preferred embodiment, the electronic device may be further configured to include: At least one processor; Memory; At least one application, wherein the at least one application is stored in memory and configured to be executed by at least one processor, the at least one application being configured to: execute the CAN bus fault detection method as described in any of the first aspects.

[0022] In summary, this application includes the following beneficial technical effects: This application extracts the signal feature set of CAN bus transmission data, identifies abnormal features, and determines suspected fault causes. Through multi-dimensional data collection and analysis, it achieves preliminary fault location. Next, it filters fault causes based on fault feature mapping relationships, effectively eliminating false positives and improving the accuracy of fault cause identification using logical verification of certain and probabilistic abnormal features. Then, it calculates a fault index by combining historical fault data with current abnormal features, balancing historical probability with real-time evidence to quantify the likelihood of the fault. Finally, it formulates and sends a resolution strategy based on the fault index, prioritizing high-probability faults to ensure the strategy's efficiency and relevance. The entire process is interconnected, significantly improving the accuracy, comprehensiveness, and maintenance efficiency of CAN bus fault detection, achieving precise fault location for CAN bus, and reducing manual troubleshooting costs and system downtime. Attached Figure Description

[0023] Figure 1 This is a flowchart illustrating a CAN bus fault detection method provided in an embodiment of this application; Figure 2 This is a schematic diagram of the structure of a CAN bus fault detection system provided in an embodiment of this application; Figure 3 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0024] The following is in conjunction with the appendix Figure 1 - Appendix Figure 3 This application will be described in further detail.

[0025] This specific embodiment is merely an explanation of this application and is not intended to limit it. After reading this specification, those skilled in the art can make modifications to this embodiment without contributing any inventive step, but such modifications are protected by patent law as long as they fall within the scope of the claims of this application.

[0026] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0027] Furthermore, the term "and / or" in this article is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. Additionally, the character " / " in this article, unless otherwise specified, generally indicates that the preceding and following related objects have an "or" relationship.

[0028] It should be noted that, in the optional embodiments of this application, the data related to object information, when applied to specific products or technologies, requires the permission or consent of the object. Furthermore, the collection, use, and processing of this data must comply with the relevant laws, regulations, and standards of the relevant countries and regions. In other words, if the embodiments of this application involve data related to an object, it must be obtained with the object's authorization and consent, the authorization and consent of relevant departments, and in accordance with the relevant laws, regulations, and standards of the country and region. If the embodiments involve personal information, the acquisition of all personal information requires the individual's consent. If sensitive information is involved, the separate consent of the information subject is required. The embodiments also need to be implemented with the object's authorization and consent.

[0029] This application provides a CAN bus fault detection method, such as... Figure 1 As shown, the method provided in this application embodiment is executed by an electronic device, which can be a server or a terminal device. The server can be an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing cloud computing services. The terminal device can be a smartphone, tablet, laptop, desktop computer, etc., but is not limited to these. The terminal device and the server can be directly or indirectly connected via wired or wireless communication. This application embodiment does not impose any limitations on this connection. The method includes steps S101-S104, wherein: S101. Extract the first signal feature set from the transmitted data of the CAN bus, extract the first abnormal feature set from the first signal feature set, and determine the suspected fault cause of each abnormal feature in the first abnormal feature set.

[0030] Specifically, the fault detector is equipped with a CAN transceiver, which can capture the transmitted data on the CAN bus and store it as time-series data. The first signal feature set includes message static features, dynamic behavior features, and correlation features. Each feature in the first signal feature set is compared with preset rules, and features that do not conform to the corresponding preset rules are identified as abnormal features. All abnormal features constitute the first abnormal feature set.

[0031] A fault feature mapping relationship is pre-constructed, including the fault causes corresponding to abnormal features. For any abnormal feature, there can be one or more corresponding fault causes. For any fault cause, there can also be one or more abnormal features that it can lead to. Features that each fault cause can necessarily lead to an abnormality are designated as necessary abnormal features, and features that may lead to an abnormality are designated as probabilistic abnormal features. For example, for the fault cause of bus short circuit, the necessary abnormal feature can be "dominant bit timeout", and the probabilistic abnormal features can be "voltage abnormality" or "ACK error".

[0032] After determining the first set of abnormal features, the fault cause corresponding to each set of abnormal features in the fault feature mapping relationship is determined as the suspected fault cause.

[0033] S102. Retrieve the fault feature mapping relationship, and based on the fault feature mapping relationship, filter the suspected fault causes of each abnormal feature to obtain the fault cause of each abnormal feature; wherein, the fault feature mapping relationship includes the inevitable abnormal features and the probabilistic abnormal features caused by each fault cause.

[0034] Specifically, based on the fault feature mapping relationship, several suspected fault causes corresponding to each abnormal feature are determined, and each abnormal feature and its corresponding suspected fault cause are combined into a correspondence. For example, if the suspected fault causes corresponding to abnormal feature A include fault cause A, fault cause B, and fault cause C, then abnormal feature A and fault cause A are combined into one correspondence, abnormal feature A and fault cause B are combined into one correspondence, and abnormal feature A and fault cause C are combined into one correspondence, resulting in three correspondences. For each abnormal feature in the first abnormal feature set, several correspondences are determined following the above steps.

[0035] All correspondences obtained from the first abnormal feature set are divided into multiple fault groups according to the fault cause type. Specifically, assume that the first abnormal feature set yields N correspondences, involving fault causes A, B, and C. The number of correspondences corresponding to fault cause A is m, the number of correspondences corresponding to fault cause B is n, and the number of correspondences corresponding to fault cause C is p, where m + n + p = N. Then, the m correspondences corresponding to fault cause A are divided into one fault group, the n correspondences corresponding to fault cause B are divided into one fault group, and the p correspondences corresponding to fault cause C are divided into one fault group, resulting in 3 fault groups. Each fault group contains one suspected fault cause and several abnormal features.

[0036] Furthermore, any one of the multiple fault groups is designated as the target fault group, and the suspected fault causes within the target fault group are designated as target suspected fault causes. The target fault feature mapping relationship corresponding to the target suspected fault cause is determined from the fault feature mapping relationship. It is then determined whether all abnormal features in the target fault group contain the necessary abnormal features in the target fault feature mapping relationship. If not, the target suspected fault cause is determined to be a non-fault cause, thus obtaining the determination result for whether the suspected fault cause of each fault group is a non-fault cause. All non-fault causes are removed from the suspected fault causes of each abnormal feature to obtain the fault cause of each abnormal feature.

[0037] S103. Take any fault cause as the target fault cause, determine the first fault index of the target fault cause based on historical fault data, determine the second fault index of the target fault cause based on the fault cause of each abnormal feature, and calculate the fault index of the target fault cause based on the first fault index and the second fault index.

[0038] Specifically, the failure frequency of each failure cause is determined based on historical failure data, and then the first failure index of the target failure cause is calculated based on the failure frequency. The higher the first failure index, the higher the failure frequency.

[0039] Based on the fault feature mapping relationship, determine the first number of possible abnormal features caused by the target fault cause, determine the second number of features that match the possible abnormal features caused by the target fault cause from the first abnormal feature set, calculate the ratio of the second number to the first number as the second fault index of the target fault cause, and the second fault index represents the current abnormal feature matching degree.

[0040] Then, the first fault index and the second fault index are weighted and summed to obtain the fault index of the target fault cause.

[0041] S104. Based on the fault index corresponding to each fault cause, formulate a fault resolution strategy and send it to the terminal device of the testing personnel.

[0042] Specifically, the causes of each fault are arranged in descending order of fault index to obtain a fault cause list. The fault cause list is then sent to the terminal device of the testing personnel so that the testing personnel can troubleshoot the faults according to the fault cause list.

[0043] This embodiment extracts the signal feature set of CAN bus transmission data, identifies abnormal features, and determines suspected fault causes. Through multi-dimensional data collection and analysis, it achieves preliminary fault location. Next, it filters fault causes based on fault feature mapping relationships, effectively eliminating false positives and improving the accuracy of fault cause identification using logical verification of certain and probabilistic abnormal features. Then, it calculates a fault index by combining historical fault data with current abnormal features, balancing historical probability with real-time evidence to quantify the likelihood of a fault. Finally, it formulates and sends a resolution strategy based on the fault index, prioritizing high-probability faults to ensure the strategy's efficiency and relevance. The entire process is interconnected, significantly improving the accuracy, comprehensiveness, and maintenance efficiency of CAN bus fault detection, achieving precise fault location for CAN bus, and reducing manual troubleshooting costs and system downtime.

[0044] In one possible implementation of this application, the first signal feature set includes: message static features, dynamic behavior features, and association features; Extract the first abnormal feature set from the first signal feature set, including: Identify rule-abnormal features that do not conform to preset rules from the static and dynamic behavior features of messages; Identify logical anomalies that do not conform to the preset logic from the associated features. The rule anomalies and logical anomalies constitute the first set of anomalies.

[0045] In this embodiment, static message characteristics refer to features in the message content that are fixed or change periodically, such as CANID, data length code, and data field format. Dynamic behavioral characteristics refer to the message's behavioral characteristics in the time dimension, such as transmission frequency, interval time, and response delay. Association characteristics refer to the logical relationship characteristics between multiple messages, such as timing dependency, message sequence, and synchronization. Preset rules and preset logic are pre-defined, and each preset rule or preset logic corresponds to a feature. Rule abnormal features indicate features that violate the predefined rules (such as ID range, data format, etc.), and logic abnormal features indicate features that do not conform to the preset logical relationship (such as timing errors, broken dependency relationships, etc.).

[0046] This embodiment extracts a first signal feature set from the CAN bus transmission data, which includes message static features, dynamic behavior features, and correlation features. It comprehensively covers the bus communication status through multi-dimensional data acquisition. Then, it identifies rule-abnormal features that violate preset rules (such as illegal IDs and DLC abnormalities) from the static and dynamic features, and mines illogical anomalies (such as timing errors and synchronization failures) from the correlation features. Through dual verification of rules and logic, it accurately captures potential fault signs in the protocol layer and communication logic layer.

[0047] One possible implementation of this application embodiment involves filtering the suspected fault causes of each abnormal feature based on a fault feature mapping relationship to obtain the fault cause of each abnormal feature, including: Each abnormal feature is divided into multiple fault groups according to the fault cause type. Each fault group contains a suspected fault cause and several abnormal features. Take any one of the multiple fault groups as the target fault group, and the suspected fault causes in the target fault group as the target suspected fault causes. Determine the target fault feature mapping relationship corresponding to the target suspected fault cause from the fault feature mapping relationship. Compare the target fault group and the target fault feature mapping relationship to determine whether all the abnormal features in the target fault group contain the necessary abnormal features in the target fault feature mapping relationship. If several abnormal features in the target fault group do not all contain the necessary abnormal features of the target fault feature mapping relationship, then the suspected fault cause of the target is determined to be a non-fault cause, thereby obtaining the determination result of whether the suspected fault cause of each fault group is a non-fault cause. By eliminating all non-fault causes from the suspected fault causes of each abnormal feature, the fault cause of each abnormal feature is obtained.

[0048] For example, the target fault group includes: fault cause A (the suspected fault cause) and several corresponding abnormal features (including: abnormal feature A, abnormal feature B, abnormal feature C, and abnormal feature D). The target fault feature mapping relationship is as follows: the necessary abnormal features corresponding to fault cause A include: abnormal feature A, abnormal feature B, and abnormal feature E; the possible abnormal features include: abnormal feature C and abnormal feature D. Comparing the target fault group and the target fault feature mapping relationship, if several abnormal features (A, B, C, D) in the target fault group do not all contain the necessary abnormal features (A, B, E) in the target fault feature mapping relationship, then "fault cause A" is determined to be a non-fault cause.

[0049] Certain anomaly characteristics are features that will definitely appear when a certain cause of a fault occurs, possessing determinism. By comparing the abnormal characteristics in the target fault group with the certain anomaly characteristics, suspected fault causes that do not meet the criteria can be quickly eliminated. This is because if the certain anomaly characteristics of a suspected fault cause do not appear in the actual anomaly, then that cause cannot be the real fault cause, greatly narrowing the scope of fault investigation.

[0050] This embodiment retrieves the corresponding fault feature mapping relationship for each group of suspected fault causes and performs logical verification using the uniqueness of inevitable abnormal features. By comparing whether the abnormal features of the target fault group completely contain the inevitable abnormal features, non-fault causes that do not meet the necessary conditions are accurately eliminated. This grouping and screening mechanism, along with the inevitable feature verification mechanism, can quickly eliminate irrelevant fault assumptions, narrow down the candidate range, avoid redundant investigations, and ensure that the finally determined fault cause has logical inevitability.

[0051] One possible implementation of this application embodiment involves determining a first fault index based on historical fault data to identify the cause of a target fault, including: Based on historical fault data, the fault frequency of each fault cause is determined, and the fault causes are sorted from low to high according to their fault frequency to obtain a fault frequency list. Determine the position of the target fault cause in the fault frequency list, and calculate the first fault index based on the position.

[0052] In this embodiment, historical fault data refers to historical data over a period of time, and the frequency of each fault cause in the historical fault data is counted. For example, "node hardware failure" appears 20 times, and "electromagnetic interference" appears 15 times. The fault frequency of each fault cause is calculated by dividing the frequency of a particular fault cause by the total number of faults.

[0053] This embodiment calculates the frequency of occurrence of each fault cause based on historical fault data and generates a fault frequency list accordingly; then, by determining the position of the target fault cause in the list, a first fault index is calculated, quantifying the historical probability of fault occurrence into a comparable numerical indicator.

[0054] One possible implementation of this application embodiment involves determining a second fault index for the target fault cause based on the fault cause of each abnormal feature, including: The first number of probable abnormal features caused by the target fault is determined based on the fault feature mapping relationship. A second number of features that match the probabilistic abnormal features caused by the target fault are determined from the first set of abnormal features; The ratio of the second quantity to the first quantity is calculated as the second failure index for the target failure cause.

[0055] For example, if the target fault cause is "electromagnetic interference", the possible abnormal features caused by the target fault cause in the fault feature mapping relationship include: data CRC error, message period fluctuation, and ACK error, then the first quantity is 3.

[0056] Iterate through the first set of abnormal features (i.e., the set of all currently detected abnormal features). For each abnormal feature in the first set, compare it one by one with the probable abnormal features of the target fault cause to determine whether there is a match. Count the number of all matching abnormal features as the second quantity. Assuming the second quantity is 2, the second fault index of the target fault cause is 2 / 3.

[0057] Probable anomalies are characteristics that may appear when a certain cause of a fault occurs. Although they are not certain, they reflect the probabilistic relationship between the fault and the anomaly. By statistically analyzing the number of anomalies that match the probable characteristics of the target fault cause among the actually detected anomalies, the correlation between the current anomaly and the fault cause can be quantified. The first fault index reflects the historical fault frequency and focuses on probability statistics; the second fault index focuses on the degree of matching between the current anomaly and the fault cause and focuses on real-time evidence. Combining the two can balance historical experience and current reality, providing a more reliable basis for fault diagnosis.

[0058] This embodiment clarifies the number of probabilistic abnormal features corresponding to the target fault cause based on the fault feature mapping relationship, and establishes the association range between the fault and potential abnormal phenomena. Then, it filters out and counts the probabilistic abnormal features that match the target fault cause from the currently detected first abnormal feature set. Finally, it obtains the second fault index by calculating the ratio of the two, quantifies the matching degree between the current abnormal phenomenon and the target fault cause, makes full use of the probabilistic relationship of the probabilistic abnormal features, complements the first fault index guided by historical probability, and improves the comprehensiveness and accuracy of fault diagnosis.

[0059] One possible implementation of this application embodiment involves formulating a fault resolution strategy based on the fault index corresponding to each fault cause and sending it to the terminal device of the testing personnel, including: Arrange the various causes of failure in descending order of failure index to obtain a list of causes of failure. Starting from the first fault cause in the fault cause list, traverse each fault cause in turn until the necessary and possible abnormal features corresponding to the current fault cause and all previous fault causes can cover the first abnormal feature set. Retrieve the current fault cause and the corresponding fault resolution methods for all previous fault causes, combine the various fault resolution methods in the order of the fault cause list into a first fault resolution strategy, and send the first fault resolution strategy to the terminal device of the testing personnel.

[0060] In this embodiment, an empty set is initialized to record the covered anomaly features. Starting from the first fault cause in the fault cause list, its corresponding necessary and probable anomaly features are obtained from the fault feature mapping relationship. The obtained anomaly features are merged with the recorded covered anomaly features, and it is determined whether the merged set can completely cover the first anomaly feature set (all anomaly features in the first anomaly feature set can be found in the merged set). If it cannot completely cover the first fault cause, the next fault cause is traversed, and the above operation is repeated; if it can completely cover the first fault cause, the traversal stops.

[0061] Determine the current fault cause and all previously traversed fault causes when traversal stops. Retrieve the fault resolution method corresponding to each determined fault cause from a pre-established fault resolution method database. For example, the resolution method corresponding to "node hardware damage" is "replace node hardware," and the resolution method corresponding to "electromagnetic interference" is "install shielding device." Combine the fault resolution methods corresponding to each fault cause in the order they appear in the fault cause list to form the first fault resolution strategy. For example, the first fault resolution strategy is: "1. Replace node hardware; 2. Install shielding device."

[0062] This embodiment sorts the causes of faults from high to low according to their fault index, highlighting high-probability faults and achieving a scientific division of troubleshooting priorities. By traversing the causes of faults, a set of key faults is selected based on feature coverage, ensuring that the strategy can comprehensively resolve the current anomaly. The corresponding resolution methods are retrieved and combined in sequence to generate an operable fault resolution strategy, which is then pushed to the testing personnel. Based on the data quantification results, blind attempts are avoided, high-probability faults are prioritized, and all anomalies are covered with the fewest operation steps, effectively improving fault repair efficiency, shortening system downtime, and reducing labor costs.

[0063] In one possible implementation of this application embodiment, after sending the first fault resolution strategy to the testing personnel's terminal device, the method further includes: When the signal indicating that the strategy has been executed is received from the inspector, the second signal feature set of the CAN bus transmission data is extracted again, and the second abnormal feature set is extracted from the second signal feature set. The cause of failure for each abnormal feature in the second set of abnormal features is determined as the cause of failure to be resolved. The part of the list following the current fault cause in the fault cause list will be used as the list to be resolved; Based on the causes of the faults to be resolved and the list of faults to be resolved, a second fault resolution strategy is formulated and sent to the terminal device of the testing personnel.

[0064] In this embodiment, after the testing personnel complete the execution of the first fault resolution strategy, they send a strategy execution completion signal to the system through the terminal device. This signal must contain key information such as task identifier and execution result status to facilitate system identification and processing. The data acquisition module is activated to capture the CAN bus transmission data in real time. Following the same method as extracting the first signal feature set, message static features, dynamic behavior features, and correlation features are extracted from the acquired transmission data to form a second signal feature set. Based on preset rules and logic, the second signal feature set is analyzed and processed. Rule-abnormal features that do not conform to the preset rules are identified from the message static features and dynamic behavior features, and logical abnormal features that do not conform to the preset logic are identified from the correlation features. These rule-abnormal features and logical abnormal features together constitute the second abnormal feature set.

[0065] For each anomalous feature in the second set of anomalous features, determine the corresponding fault cause and fault index using the process described above. Locate the position of the current fault cause in the fault cause list when formulating the first fault resolution strategy. Extract the portion of the list following that position as the to-be-resolved list, which contains fault causes that have not yet been verified or processed.

[0066] For example, if the list of fault causes is: "Fault Cause A", "Fault Cause B", "Fault Cause C", "Fault Cause D", when formulating the first fault resolution strategy, the process stops when the feature coverage condition is met when "Fault Cause B" is encountered. Then the list to be resolved is: "Fault Cause C" "Fault Cause D".

[0067] Combining the causes of the faults to be resolved and the list of faults to be resolved, first merge the causes of the faults to be resolved with the causes of the faults in the list of faults to be resolved (add the fault indices of the causes of the faults to be resolved and the same faults in the list of faults to be resolved to obtain the new fault index), and then reorder the merged faults according to the fault index.

[0068] Starting from the sorted list of fault causes, the system iterates sequentially until the necessary and probabilistic anomalies corresponding to the current fault cause and all previous fault causes cover the second set of anomalies. The system then retrieves the fault resolution methods corresponding to the current fault cause and all previous fault causes, combining them according to the order of the fault cause list to form the second fault resolution strategy. Finally, using the same communication method and process as sending the first fault resolution strategy, the second fault resolution strategy is sent to the testing personnel's terminal device, and the system awaits feedback from the testing personnel.

[0069] After executing the first fault resolution strategy, this embodiment triggers a new round of detection by receiving the execution completion signal, re-extracts the signal characteristics of the bus data and identifies anomalies, ensuring that unresolved potential faults can be discovered in a timely manner; the fault causes of new anomalies are combined with the unverified parts of the original fault list, which not only continues the previous diagnostic results but also incorporates newly discovered fault clues; on this basis, a second fault resolution strategy is formulated and sent to realize dynamic iteration of fault investigation, avoid omissions in one-time diagnosis, and ensure that CAN bus faults are thoroughly and efficiently resolved.

[0070] This application provides a CAN bus fault detection system, see [link to relevant documentation]. Figure 2 The system includes: a fault detector and electronic equipment. The fault detector includes a data acquisition module and a display module. The data acquisition module is used to acquire the data transmitted on the CAN bus and send it to electronic devices, as well as to receive external trigger signals; The display module is used to receive the fault causes analyzed by the electronic device, and to display the waveform and voltage value of the external trigger signal; An electronic device for performing a CAN bus fault detection method provided in this embodiment.

[0071] This application provides an electronic device, such as... Figure 3 As shown, Figure 3 The illustrated electronic device 300 includes a processor 301 and a memory 303. The processor 301 and the memory 303 are connected, for example, via a bus 302. Optionally, the electronic device 300 may also include a transceiver 304. It should be noted that in practical applications, the transceiver 304 is not limited to one type, and the structure of this electronic device 300 does not constitute a limitation on the embodiments of this application.

[0072] Processor 301 may be a CPU (Central Processing Unit), a general-purpose processor, a DSP (Digital Signal Processor), an ASIC (Application Specific Integrated Circuit), an FPGA (Field Programmable Gate Array), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. It can implement or execute the various exemplary logic blocks, modules, and circuits described in conjunction with the disclosure of this application. Processor 301 may also be a combination that implements computational functions, such as including one or more microprocessor combinations, a combination of a DSP and a microprocessor, etc.

[0073] Bus 302 may include a pathway for transmitting information between the aforementioned components. Bus 302 may be a PCI (Peripheral Component Interconnect) bus or an EISA (Extended Industry Standard Architecture) bus, etc. Bus 302 can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 3 The symbol is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0074] The memory 303 may be a ROM (Read Only Memory) or other type of static storage device capable of storing static information and instructions, RAM (Random Access Memory) or other type of dynamic storage device capable of storing information and instructions, or an EEPROM (Electrically Erasable Programmable Read Only Memory), CD-ROM (Compact Disc Read Only Memory) or other optical disc storage, optical disc storage (including compressed optical discs, laser discs, optical discs, digital universal optical discs, Blu-ray discs, etc.), magnetic disk storage media or other magnetic storage devices, or any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer, but not limited thereto.

[0075] The memory 303 stores the application code that executes the solution of this application, and its execution is controlled by the processor 301. The processor 301 executes the application code stored in the memory 303 to implement the content shown in the aforementioned CAN bus fault detection method embodiment.

[0076] Figure 3 The electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0077] This application provides a computer-readable storage medium storing a computer program that, when run on a computer, enables the computer to execute the contents shown in the aforementioned CAN bus fault detection method embodiment.

[0078] It should be understood that although the steps in the flowcharts of the accompanying figures are shown sequentially as indicated by the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the accompanying figures may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times, and their execution order is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the sub-steps or stages of other steps.

[0079] This application provides a computer program product, including a computer program that, when executed by a processor, implements the content shown in the aforementioned CAN bus fault detection method embodiment.

[0080] The above are only some embodiments of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A CAN bus fault detection method, characterized in that, include: Extract a first signal feature set from the transmitted data of the CAN bus, extract a first abnormal feature set from the first signal feature set, and determine the suspected fault cause of each abnormal feature in the first abnormal feature set. The fault feature mapping relationship is retrieved, and the suspected fault causes of each abnormal feature are screened based on the fault feature mapping relationship to obtain the fault cause of each abnormal feature; wherein, the fault feature mapping relationship includes the inevitable abnormal features and the probabilistic abnormal features caused by each fault cause. Take any fault cause as the target fault cause, determine the first fault index of the target fault cause based on historical fault data, determine the second fault index of the target fault cause based on the fault cause of each abnormal feature, and calculate the fault index of the target fault cause based on the first fault index and the second fault index. Based on the fault index corresponding to each fault cause, a fault resolution strategy is formulated and sent to the terminal device of the testing personnel.

2. The CAN bus fault detection method according to claim 1, characterized in that, The first signal feature set includes: message static features, dynamic behavior features, and correlation features; The step of extracting the first abnormal feature set from the first signal feature set includes: Identify rule anomalies that do not conform to preset rules from the static features and dynamic behavior features of the message; Identify logical anomalies that do not conform to preset logic from the associated features, and the rule anomalies and the logical anomalies constitute the first anomaly feature set.

3. The CAN bus fault detection method according to claim 1, characterized in that, The step of filtering the suspected fault causes of each abnormal feature based on the fault feature mapping relationship to obtain the fault cause of each abnormal feature includes: The suspected fault causes of each abnormal feature are divided into multiple fault groups according to the fault cause type. Each fault group contains a suspected fault cause and several abnormal features. Take any one of the multiple fault groups as the target fault group, and the suspected fault cause in the target fault group as the target suspected fault cause. Determine the target fault feature mapping relationship corresponding to the target suspected fault cause from the fault feature mapping relationship. The target fault group and the target fault feature mapping relationship are compared to determine whether all the abnormal features in the target fault group contain the necessary abnormal features in the target fault feature mapping relationship. If several abnormal features in the target fault group do not all contain the necessary abnormal features of the target fault feature mapping relationship, then the suspected fault cause is determined to be a non-fault cause, thereby obtaining the determination result of whether the suspected fault cause of each fault group is the non-fault cause. The cause of failure for each abnormal feature is obtained by removing all non-fault causes from the suspected causes of failure for each abnormal feature.

4. The CAN bus fault detection method according to claim 1, characterized in that, The first fault index, which determines the cause of the target fault based on historical fault data, includes: Based on the historical fault data, the fault frequency of each fault cause is determined, and the fault causes are sorted from low to high according to the fault frequency to obtain a fault frequency list. Determine the position of the target fault cause in the fault frequency list, and calculate the first fault index based on the position.

5. The CAN bus fault detection method according to claim 1, characterized in that, The second fault index for determining the target fault cause based on the fault cause of each abnormal feature includes: Based on the fault feature mapping relationship, determine the first number of probable abnormal features caused by the target fault cause; A second number of features that match the probabilistic abnormal features caused by the target fault are determined from the first set of abnormal features; The ratio of the second quantity to the first quantity is calculated as a second fault index for the target fault cause.

6. The CAN bus fault detection method according to claim 1, characterized in that, The process of formulating a fault resolution strategy based on the fault index corresponding to each fault cause and sending it to the terminal device of the testing personnel includes: Arrange the various causes of failure in descending order of the failure index to obtain a list of causes of failure. Starting from the first fault cause in the fault cause list, each fault cause is traversed sequentially until the necessary and possible abnormal features corresponding to the current fault cause and all previous fault causes can cover the first abnormal feature set. The system retrieves the current fault cause and the corresponding fault resolution methods for all previous fault causes, combines each fault resolution method into a first fault resolution strategy according to the order of the fault cause list, and sends the first fault resolution strategy to the terminal device of the testing personnel.

7. The CAN bus fault detection method according to claim 6, characterized in that, After sending the first fault resolution strategy to the testing personnel's terminal device, the method further includes: When the signal indicating that the strategy has been executed is received from the inspector, the second signal feature set of the transmitted data of the CAN bus is extracted again, and the second abnormal feature set is extracted from the second signal feature set. The cause of failure for each abnormal feature in the second abnormal feature set is determined as the cause of failure to be resolved; The portion of the list following the current fault cause in the fault cause list will be used as the list to be resolved. Based on the cause of the fault to be resolved and the list of faults to be resolved, a second fault resolution strategy is formulated, and the second fault resolution strategy is sent to the terminal device of the testing personnel.

8. A CAN bus fault detection system, characterized in that, include: A fault detector and electronic equipment, wherein the fault detector includes a data acquisition module and a display module; The data acquisition module is used to acquire the transmission data of the CAN bus and send it to the electronic device, as well as to receive external trigger signals; The display module is used to receive the fault cause analyzed by the electronic device, and to display the waveform and voltage value of the external trigger signal; The electronic device is used to perform the CAN bus fault detection method according to any one of claims 1-7.

9. The CAN bus fault detection system according to claim 8, characterized in that, The electronic device includes: At least one processor; Memory; At least one application, wherein the at least one application is stored in memory and configured to be executed by at least one processor, said at least one application being configured to: perform the CAN bus fault detection method according to any one of claims 1-7.

Images