Vehicle fault diagnosis system, method, device, and medium

Abstract

The application provides a vehicle fault diagnosis system, method, device and medium, comprising: a traceability perception layer configured to obtain a working condition snapshot at a fault triggering time, bus message data in a preset time window and bottom layer logs of a target vehicle electronic control unit when an undefined fault code for a vehicle fault is read, and perform traceability analysis on the working condition snapshot, bus message data and bottom layer logs to obtain a traceability analysis result, the traceability analysis result comprising a working condition feature vector, a bus abnormal feature set and a bottom layer abnormal sequence of the vehicle electronic control unit; and a classification and judgment layer configured to judge a fault category corresponding to the undefined fault code according to the traceability analysis result to obtain a judgment result.

Description

Technical Field

[0001] This application relates to the field of vehicle fault diagnosis technology, and in particular to a vehicle fault diagnosis system, method, device and medium. Background Technology

[0002] Currently, vehicle fault diagnosis technology mainly relies on fault code (DTC) databases for matching and identification. However, in practical applications, this approach reveals the following significant shortcomings: 1. Strong reliance on static databases, resulting in a large diagnostic blind spot: Existing technologies can only identify standard-defined fault codes and cannot parse non-standard protocols or newly added undefined fault codes, leading to a large number of unknown or long-tail faults becoming diagnostic blind spots. 2. Coarse fault classification dimensions, resulting in high false positive and false negative rates: Current classifications are mostly limited to vehicle peripheral faults and vehicle faults, lacking in-depth analysis of fault mechanisms and failing to accurately distinguish between specific types such as false interference faults, genuine hardware damage, low-level logic errors, and system redundancy faults. 3. Insufficient depth of investigation and analysis, leading to the retention of hidden faults: The diagnostic process often stops at reading superficial fault codes, failing to pinpoint the root cause of the fault. 4. Limited fault handling strategies, leading to frequent recurrence of problems: Fault clearing methods are mostly simple memory resets or code clearing, lacking targeted in-depth repair strategies, resulting in frequent fault code recurrence. 5. Lack of closed-loop verification mechanism, no guarantee of repair effect: After the fault is handled, there is no automated re-inspection and status confirmation process, which makes it impossible to effectively verify whether the fault has been completely eliminated and makes it difficult to form a complete diagnostic closed loop.

[0003] Therefore, there is an urgent need for a technical solution that can accurately diagnose vehicle faults without relying on a fault code database. Summary of the Invention

[0004] To address the aforementioned problems, this application provides a vehicle fault diagnosis system, method, device, and medium.

[0005] Firstly, a vehicle fault diagnosis system is provided, comprising: a source tracing perception layer, configured to, upon reading an undefined fault code for a vehicle fault, acquire a snapshot of the operating conditions at the time of fault triggering, bus message data within a preset time window, and the underlying logs of the target vehicle electronic control unit, and perform source tracing analysis on the snapshot of the operating conditions, the bus message data, and the underlying logs to obtain source tracing analysis results, wherein the source tracing analysis results include an operating condition feature vector, a bus abnormality feature set, and an underlying abnormality sequence of the vehicle electronic control unit; and a classification and determination layer, configured to, based on the source tracing analysis results, determine the fault category corresponding to the undefined fault code to obtain a determination result.

[0006] Secondly, a vehicle fault diagnosis method is provided, including, when an undefined fault code for a vehicle fault is read, acquiring a snapshot of the operating conditions at the time of fault triggering, bus message data within a preset time window, and the underlying log of the target vehicle electronic control unit, and performing source tracing analysis on the snapshot of the operating conditions, bus message data, and underlying log to obtain source tracing analysis results, wherein the source tracing analysis results include operating condition feature vectors, bus abnormal feature sets, and underlying abnormal sequences of the vehicle electronic control unit; and determining the fault category corresponding to the undefined fault code based on the source tracing analysis results to obtain a determination result.

[0007] Thirdly, an electronic device is provided, including a processor, a memory, and a program stored in the memory and capable of running on the processor, wherein when the program is executed by the processor, it implements the steps of any of the vehicle fault diagnosis methods provided in the embodiments of this application.

[0008] A fourth aspect provides a computer-readable storage medium storing instructions that, when executed by a processor, implement the steps of any of the vehicle fault diagnosis methods provided in the embodiments of this application.

[0009] In summary, the vehicle fault diagnosis system, method, device, and medium provided in this application have the following beneficial effects: When an undefined fault code is read, the system directly obtains the vehicle's operating condition snapshot, bus message data, and underlying logs at the time the fault was triggered, and performs reverse deduction and tracing to obtain the fault determination result of the undefined fault code. This breaks the technical monopoly of the original manufacturer's protocol, enabling ordinary third-party diagnostic equipment or cloud platforms to also have the ability to deeply diagnose unknown faults, significantly reducing the threshold and cost of vehicle fault diagnosis. Simultaneously, through multi-dimensional data detection, it can effectively identify faults that conventional diagnostics cannot recognize, and extend the depth of fault location from the surface error to the physical and software root causes. Furthermore, this application extracts the operating condition snapshot, bus message data, and underlying logs into operating condition feature vectors, bus abnormality feature sets, and underlying abnormality sequences, respectively, and performs comprehensive judgment on the three major feature data. This enables feature dimensionality reduction and fusion, thereby effectively locking the specific reproducible scenario of the fault occurrence, accurately outputting the true fault category of the undefined fault code, and providing a diagnostic basis for subsequent one-time vehicle repair. Attached Figure Description

[0010] To more clearly illustrate the specific embodiments of this application or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0011] Figure 1 This invention provides a schematic diagram of the structure of a vehicle fault diagnosis system according to an embodiment of the present application. Figure 2 This diagram illustrates the structure of a source tracing perception layer provided in an embodiment of this application. Figure 3 This diagram illustrates the structure of a classification determination layer provided in an embodiment of this application. Figure 4 This invention provides a schematic diagram of the structure of a vehicle diagnostic fault system according to another embodiment of the present application. Figure 5 This diagram illustrates the structure of a scenario-based layered processing layer provided in an embodiment of this application. Figure 6 This illustration shows a schematic diagram of the structure of a fully closed-loop verification archiving layer provided in an embodiment of this application; Figure 7 This illustration shows a schematic flowchart of a vehicle fault diagnosis method provided in an embodiment of this application. Figure 8 A flowchart illustrating a vehicle fault diagnosis method provided in another embodiment of this application is shown. Figure 9 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0012] To make the above and other features and advantages of this application clearer, the application is further described below with reference to the accompanying drawings. It should be understood that the specific embodiments given herein are for the purpose of explanation to those skilled in the art, and are exemplary only, not restrictive.

[0013] In the following description, numerous specific details are set forth to provide a thorough understanding of this application. However, it will be apparent to those skilled in the art that the specific details are not required to practice this application. In other instances, well-known steps or operations have not been described in detail to avoid obscuring this application.

[0014] Before elaborating on the specific structure of the vehicle fault diagnosis system provided in this application, the core technical concept of this application will be summarized first.

[0015] In response to the current vehicle fault diagnosis's heavy reliance on traditional fault databases (or diagnostic protocol libraries), which leads to the predicament of being unable to parse undefined fault codes reported by diagnostic equipment and resulting in blind repairs, the applicant established the core technical concept of "breaking away from external database dependence and inferring the true root cause of the fault by deeply mining the vehicle's underlying native data."

[0016] Based on this technical concept, this application proposes a technical solution for troubleshooting and repairing undefined fault codes in vehicles, encompassing "three-dimensional passive tracing, multi-layered refined classification, scenario-based layered handling, and full closed-loop verification." This solution aims to address the shortcomings of existing technologies, such as the inability to trace the source of undefined fault codes, repeated fault reproduction, excessive repairs, and missed detection of latent faults. Ultimately, it achieves accurate location and complete eradication of unknown faults, ensuring long-term stable vehicle operation.

[0017] One embodiment of this application provides a vehicle fault diagnosis system that communicates with the vehicle and exchanges data.

[0018] In one embodiment of this application, the vehicle fault diagnosis system can be installed in a diagnostic device or independently of the diagnostic device, such as on a cloud server or a local computer. When the vehicle fault diagnosis system is installed independently of the diagnostic device, it communicates with the vehicle through the diagnostic device.

[0019] Figure 1 This application provides a schematic diagram of the structure of a vehicle fault diagnosis system according to an embodiment of the present application. Figure 1 As shown, the vehicle fault diagnosis system 10 may include a source tracing perception layer 11 and a classification and determination layer 12.

[0020] In one embodiment of this application, the source tracing perception layer 11 is configured to, when reading an undefined fault code for a vehicle fault, acquire a snapshot of the operating condition at the time of the fault trigger, bus message data within a preset time window, and the underlying log of the target vehicle electronic control unit, and perform source tracing analysis on the snapshot of the operating condition, bus message data, and underlying log to obtain the source tracing analysis results.

[0021] In one embodiment of this application, the undefined fault code refers to a fault code obtained by diagnosing the vehicle's operating status, and this fault code is not a predefined fault code. The predefined fault code is determined based on a labeled fault code dictionary, a publicly available definition library, and a manufacturer's protocol library.

[0022] One embodiment of this application relates to a snapshot of operating conditions, which is a set of parameters of the vehicle's multi-dimensional operating state automatically captured and frozen by the vehicle's electronic control unit at the moment when no fault code is defined. This snapshot of operating conditions can accurately reflect the real physical environment in which the fault occurs.

[0023] The snapshot data for this operating condition includes, but is not limited to, at least one of the following: vehicle driving status parameters (such as vehicle speed, motor speed, accelerator pedal opening, braking status, gear information, etc.); status parameters of the three-electric system (such as the voltage, current, SOC, and temperature distribution of the power battery, the insulation status of the high-voltage system, and the temperature and torque status of the load, drive motor, and controller, etc.); and status parameters of the thermal management system (such as coolant temperature, air conditioning system pressure, compressor speed, etc.).

[0024] One embodiment of this application relates to a target vehicle electronic control unit that can be any one or more electronic control units in a vehicle, such as VCU and / or ECU.

[0025] In one embodiment of this application, the bus message data refers to the set of communication data frames actually transmitted in the vehicle network within a preset time window. The preset time window is a continuous time period consisting of a first preset duration preceding the trigger time of an undefined fault code and a second preset duration preceding it. Optionally, the first and second preset durations are 10 seconds.

[0026] The bus message data includes, but is not limited to, message identifier, raw data field, message transmission period, high-precision timestamp, and underlying link status information (such as frame loss count, error frame count, check error flag, etc.).

[0027] The underlying log in one embodiment of this application refers to the set of operating status data directly generated by the vehicle electronic control unit during operation and stored in the non-volatile memory (such as an encrypted Flash partition) inside the controller.

[0028] The underlying log may include, but is not limited to, sensor underlying sampling data, hardware and peripheral status data, and internal fault de-jitter data.

[0029] One embodiment of this application involves source tracing analysis results including operating condition feature vectors, bus anomaly feature sets, and the underlying anomaly sequence of the vehicle's electronic control unit.

[0030] In some embodiments of this application, Figure 2 This illustration shows a schematic diagram of the structure of a source tracing perception layer provided in an embodiment of this application, as shown below. Figure 2 As shown, the source tracing perception layer 11 includes a working condition acquisition unit 111, a bus message parsing unit 112, and a bottom-level log reading unit 113.

[0031] In one embodiment of this application, the operating condition acquisition unit 111 is configured to acquire an operating condition snapshot at the time of fault triggering when an undefined fault code is read, extract feature parameters from the operating condition snapshot, and add a timestamp to the extracted feature parameters to form an operating condition feature vector.

[0032] Specifically, when the vehicle fault diagnosis system identifies an undefined fault code for a vehicle fault, the operating condition acquisition unit 111 automatically sends a reading command to the vehicle electronic control unit to obtain a snapshot of the operating condition that is synchronously fixed at the moment of fault triggering corresponding to the undefined fault code. The operating condition feature parameters, which include five standard native fields such as engine speed, vehicle speed, coolant temperature, low voltage, and vehicle load at the moment of fault triggering, are extracted from the operating condition snapshot. A unified high-precision timestamp is automatically added to the operating condition feature parameters to generate an operating condition feature vector.

[0033] In this way, by extracting features from the operating condition snapshots, the operating condition acquisition unit can construct an operating condition feature vector that characterizes the vehicle's physical boundary conditions at the moment the fault occurs, thus identifying specific fault-specific recurrence scenarios (e.g., cold start scenarios, idling scenarios, or high-temperature and high-load scenarios), providing key environmental features for subsequent classification and judgment layers. Furthermore, in subsequent analysis, this can be used to filter out abnormal messages and logs that only occur under this specific operating condition, effectively filtering out random and occasional invalid data and narrowing the scope of abnormal data filtering.

[0034] The bus message parsing unit 112 is configured to acquire bus message data within a preset time window when an undefined fault code is read, and to perform abnormal feature analysis on the bus message data to obtain a bus abnormal feature set.

[0035] Specifically, when the vehicle fault diagnosis system identifies an undefined fault code, the bus message parsing unit 112 automatically opens a message recording window at the millisecond level (10 seconds) before and after the fault to completely capture the bus message data on the vehicle network. This bus message data includes, but is not limited to, bus frame ID, raw data bits, message period, lost / erroneous frame count, and timing offset marker.

[0036] The bus message parsing unit 112 directly performs statistics on the underlying physical state and automatically extracts three types of communication anomaly features, such as periodic signal jump features, transmission interruption features, and continuous interference features, forming a bus anomaly feature set.

[0037] Thus, the bus message parsing unit 112 acquires bus message data before and after the fault is triggered, and extracts features from the bus message data to obtain a bus anomaly feature set that can truly reflect the abnormal state of the vehicle network. This bus anomaly feature set is the core basis for subsequent judgment of faults such as line damage, poor grounding, and external electromagnetic interference.

[0038] The underlying log reading unit 113 is configured to obtain the underlying log of the target vehicle electronic control unit when an undefined fault code is read, and to perform data feature extraction and feature recognition on the underlying log to obtain the underlying abnormal sequence.

[0039] Specifically, the underlying log reading unit 113 directly reads the underlying log stored in the encrypted underlying storage partition of the target vehicle's electronic control unit through the original factory private diagnostic ID, and obtains data such as internal fault counters, long-term sensor sampling curves, factory calibration reference values, data offset records, and program verification error markers from the underlying log. It then performs feature extraction and identification on these data to obtain implicit features such as continuous sensor numerical drift, calibration reference offset, and cumulative hardware attenuation, forming an underlying abnormal sequence.

[0040] Thus, by extracting and recognizing data features from the underlying logs, the underlying log reading unit 113 can obtain a sequence of underlying anomalies that can be used to accurately locate the root causes of hardware and software faults within the electronic control system.

[0041] In one embodiment of this application, the classification and determination layer 12 is configured to determine the fault category corresponding to the undefined fault code based on the source tracing analysis results, and obtain the determination result.

[0042] One embodiment of this application relates to a diagnostic conclusion generated for an undefined fault code. This determination result includes one of the following: device adaptation faults, bus communication faults, low-level implicit faults, intermittent redundancy faults, and composite faults.

[0043] In one embodiment of this application, the classification and determination layer 200 is used to first identify false faults (such as device adaptation faults), then determine single true faults (such as intermittent redundancy faults, bus communication faults, or underlying latent faults), and finally identify composite faults. Among them, intermittent redundancy faults are instantaneous one-time interference faults, bus communication faults are external persistent true faults, and underlying latent faults are internal hardware or calibration true faults.

[0044] In one embodiment of this application, the classification and determination layer 12 is configured to perform hierarchical correlation deduction on the source tracing analysis results, thereby determining the fault category corresponding to the undefined fault code and obtaining the determination result.

[0045] For example, classification and judgment layer 12 performs time-series alignment of the operating condition feature vector, the bus anomaly feature set, and the underlying anomaly sequence of the vehicle's electronic control unit. After alignment, the first step is to use the operating condition feature vector to pinpoint the physical environment that triggered the fault, using this physical environment as a priori condition to narrow down the range of fault data. The second step is to match the bus anomaly feature set with the anomaly features to determine whether the external communication triggers persist. The third step is to combine the underlying anomaly sequence to determine whether the vehicle's electronic control unit has long-term hardware and / or calibration deviations. In this way, after completing the three-layer data hierarchical association and deduction, an anomaly data set is obtained, and then the fault type matching the anomaly data set is determined according to the fault judgment priority.

[0046] When an abnormal data set is found to have a single type of abnormal characteristic, it is determined that a single type of fault has occurred; when an abnormal data set has at least two types of abnormal characteristics (such as bus abnormal characteristics and underlying abnormal characteristics), it is determined that a composite fault has occurred.

[0047] In one embodiment of this application, the fault determination priority from high to low is as follows: device adaptation faults, intermittent redundancy faults, bus communication faults, and underlying implicit faults.

[0048] In some embodiments of this application, Figure 3 This invention provides a schematic diagram of the structure of a classification determination layer according to an embodiment of the present application. Figure 3 As shown, the classification and judgment layer 12 includes: a device adaptation fault judgment unit 121, a bus communication fault judgment unit 122, a bottom-level implicit fault judgment unit 123, an occasional redundancy fault judgment unit 124, and a composite fault judgment unit 125.

[0049] Among them, the equipment adaptation fault determination unit 121 is configured to identify and diagnose false faults caused by incompatibility between the equipment database and version.

[0050] The bus communication fault determination unit 122 is configured to identify real faults such as wire harness damage, pin oxidation, grounding connection failure, and signal interference.

[0051] The underlying implicit fault determination unit 123 is configured to identify real faults such as hardware aging, performance degradation, data drift, program logic deviation, and calibration parameter offset.

[0052] The intermittent redundancy fault determination unit 124 is configured to identify one-time redundancy faults caused by voltage fluctuations, battery depletion, aftermarket interference, and momentary power instability.

[0053] The composite fault judgment unit 125 is configured to identify composite faults.

[0054] In one embodiment of this application, the device adaptation fault determination unit 121 is configured to determine whether the source tracing analysis result meets the device adaptation fault determination condition; if the source tracing analysis result meets the device adaptation fault determination condition, obtain the fault detection result after switching the third-party diagnostic device to the original diagnostic device, and if the fault detection result indicates that the undefined fault code has been eliminated, determine that the fault type corresponding to the undefined fault code is a device adaptation fault.

[0055] One embodiment of this application involves equipment adaptation fault determination conditions that may include operating condition feature vectors, bus anomaly feature sets, and the absence of anomalies in the underlying anomaly sequence of the vehicle's electronic control unit. For example, the bus anomaly feature set indicates no periodic frame drops or timing offsets throughout the process; the underlying anomaly sequence indicates no long-term data drift or calibration offset records; and the operating condition feature vector indicates no fixed abnormal operating condition patterns.

[0056] Thus, the equipment adaptation fault determination unit 121 can determine that the fault corresponding to the undefined fault code is a false equipment fault (i.e., equipment adaptation fault) caused by the lack of coding interpretation in the database of the third-party diagnostic equipment, and that the vehicle itself has no fault, by identifying the operating condition feature vector, bus abnormal feature set and underlying abnormal sequence as having no abnormalities, and by determining that the undefined fault code disappears after being replaced with the original diagnostic equipment.

[0057] In one embodiment of this application, the bus communication fault determination unit 122 is configured to determine whether the source analysis result meets the bus communication fault determination conditions; if the source analysis result meets the bus communication fault determination conditions, the fault type corresponding to the undefined fault code is determined to be a bus communication fault.

[0058] One embodiment of this application involves bus communication fault determination conditions that may include operating condition feature vectors indicating specific operating conditions corresponding to bus communication faults, bus abnormality feature sets indicating the presence of communication abnormalities, and underlying abnormal sequences indicating the presence of communication error markers. For example, the bus abnormality feature set indicates the presence of stable frame drops, frame errors, and continuous signal interference; the operating condition feature vector indicates the occurrence of high communication load operating conditions such as idling and low load; and the underlying abnormal sequence indicates the absence of long-term hardware attenuation records, with only synchronous recording of communication error markers.

[0059] Thus, by using the bus feature set as the primary judgment basis and the operating condition feature vector and the underlying abnormal sequence as auxiliary judgment basis, the bus communication fault determination unit can determine that the fault corresponding to the undefined fault code is a true bus fault (i.e., a bus communication fault) caused by a persistent abnormality in the external communication link.

[0060] In one embodiment of this application, the underlying implicit fault determination unit 123 is configured to determine whether the source analysis result meets the underlying implicit fault determination condition; if the source analysis result meets the underlying implicit fault determination condition, the fault type corresponding to the undefined fault code is determined to be an underlying implicit fault.

[0061] The fault determination criteria for bus communication can include operating condition feature vectors indicating specific operating conditions corresponding to underlying latent faults, bus abnormal feature sets indicating normal communication, and underlying abnormal sequences indicating the presence of abnormal characteristics. For example, underlying abnormal sequences indicate continuous sensor sampling drift, factory calibration deviation, and multiple verification anomalies; operating condition feature vectors indicate high and low temperatures or all driving conditions; and bus abnormal feature sets indicate stable bus message timing and no continuous communication interference.

[0062] Thus, the underlying hidden fault determination unit uses the underlying abnormal sequence as the main judgment basis and the operating condition feature vector and bus abnormal feature set as auxiliary judgment basis to determine that the fault corresponding to the undefined fault code is a true underlying fault (i.e., underlying hidden fault) caused by permanent deterioration deviation in the internal hardware and / or calibration of the vehicle electronic control unit.

[0063] In one embodiment of this application, the intermittent redundancy fault determination unit 124 is configured to determine whether the source analysis result meets the intermittent redundancy fault determination condition; if the source analysis result meets the intermittent redundancy fault determination condition, the fault type corresponding to the undefined fault code is determined to be an intermittent redundancy fault.

[0064] One embodiment of this application relates to the intermittent redundancy fault determination conditions, which may include a bus anomaly feature set indicating a momentary single fluctuation, a working condition feature vector indicating a momentary working condition of power-on or cold start voltage mutation, and a low-level anomaly sequence indicating a single anomaly. For example, the bus anomaly feature set indicates only a momentary single fluctuation without periodic interference; the low-level anomaly sequence records only a single temporary voltage anomaly without long-term drift; and the working condition feature vector indicates a working condition of power-on or cold start voltage mutation.

[0065] In this way, the intermittent redundancy fault determination unit can determine that the fault corresponding to the undefined fault code can be a one-time redundant fault generated by instantaneous power supply or external equipment interference (i.e., intermittent redundant fault), without any potential for continuous fault.

[0066] In one embodiment of this application, the composite fault judgment unit 125 is configured to determine whether the source analysis result satisfies at least two of the following fault judgment conditions: equipment adaptation fault judgment condition, bus communication fault judgment condition, underlying implicit fault judgment condition, and occasional redundancy fault judgment condition; when the source analysis result satisfies the at least two fault judgment conditions, the fault type corresponding to the undefined fault code is determined to be a composite fault.

[0067] In one embodiment of this application, the composite fault judgment unit 125 is further configured to judge whether the source analysis result meets the judgment conditions for equipment adaptation type fault, occasional redundancy type fault, bus communication type fault and underlying implicit type fault according to the fault judgment priority.

[0068] In another embodiment of this application, the composite fault determination unit 125 is configured to determine the fault type corresponding to the undefined fault code as a composite fault when the output results of the device adaptation fault determination unit 121, the bus communication fault determination unit 122, the underlying implicit fault determination unit 123, and the occasional redundancy fault determination unit 124 indicate that at least two types of faults have occurred.

[0069] In one embodiment of this application, the classification and determination layer 12 is configured to sequentially call the device adaptation type fault determination unit 121, the occasional redundancy type fault determination unit 124, the bus communication type fault determination unit 122, the underlying implicit type fault determination unit 123, and the composite type fault determination unit 125 according to the fault determination priority to determine the source analysis results.

[0070] In some embodiments of this application, Figure 4 This illustration shows a structural schematic diagram of a vehicle diagnostic fault system provided in another embodiment of this application. Figure 2 Based on the above, the vehicle fault diagnosis system 10 also includes a scenario-based layered processing layer 13.

[0071] The scenario-based hierarchical processing layer 13 is configured to generate a scenario repair scheme corresponding to the fault category based on the determination result.

[0072] In one embodiment of this application, Figure 5 This illustration shows a schematic diagram of the structure of a scenario-based layered processing layer provided in an embodiment of this application, as shown below. Figure 5 As shown, the scenario-based layered processing layer 13 includes a device adaptation and handling unit 131, a bus fault repair unit 132, a bottom layer repair unit 133, and a redundancy optimization unit 134.

[0073] The device adaptation handling unit 131 is configured to generate a first scenario repair solution for device adaptation-related faults. The first scenario repair solution may include, but is not limited to, prompting for device upgrade and diagnostics, and calibrating device adaptation parameters.

[0074] Specifically, the equipment adaptation handling unit 131 is configured to perform fault masking or ignoring operations when the fault type is determined to be an equipment adaptation fault, and output a prompt message that "there are no hardware or electronic control defects in the vehicle body, and it is recommended to upgrade the diagnostic equipment protocol library or calibrate the equipment adaptation parameters" to avoid ineffective repairs.

[0075] The bus fault repair unit 132 is configured to generate a second scenario repair solution for bus communication faults. The second scenario repair solution may include, but is not limited to, solutions to eliminate communication interference, such as replacing the damaged wire harness, repairing the shielding layer, and tightening the grounding point.

[0076] Specifically, the device adaptation and handling unit 131 is configured to output repair instructions for the physical link (such as checking for wire harness damage, grinding oxidized grounding contacts, and removing external interference sources) when the fault type is determined to be a bus communication fault. After receiving the repair confirmation and after a preset resting time, the unit re-collects bus messages to verify whether the communication timing and signal transmission have returned to stability.

[0077] The underlying repair unit 133 is configured to generate a third-scenario repair solution for underlying latent faults. The third-scenario repair solution may include, but is not limited to, replacing attenuation hardware, resetting the underlying calibration, and correcting data drift, etc., to eradicate latent anomalies.

[0078] Specifically, the underlying repair unit 133 is configured to output a replacement guide for the performance degradation sensor when the fault category is determined to be an underlying latent fault, and automatically send a command to the vehicle electronic control unit to reset the underlying factory calibration parameters or correct the sampling drift deviation, thereby eliminating the fault from the root cause of the software and hardware.

[0079] The redundancy optimization unit 134 is configured to generate a fourth scenario repair scheme for intermittent redundancy faults. The fourth scenario repair scheme may include, but is not limited to, optimizing the power supply circuit, removing unauthorized modifications, and clearing redundant fault records.

[0080] Specifically, the redundancy optimization unit 134 is configured to output a prompt message to optimize the power supply circuit or remove unauthorized modifications when the fault category is determined to be an intermittent redundancy fault, and to automatically clear the redundant fault record.

[0081] In actual vehicle operation, an undefined fault code is often not formed by a single fault, but rather by the superposition of multiple faults. Therefore, to efficiently and thoroughly resolve complex faults, in one embodiment of this application, the scenario-based hierarchical processing layer is configured to further generate a scenario repair scheme corresponding to the complex fault based on the fault processing priority when the fault corresponding to the undefined fault code is a complex fault. The scenario repair scheme corresponding to the complex fault is a scheme with strict time-series dependencies.

[0082] One embodiment of this application involves a fault handling priority setting based on a hierarchical progressive logic of "external first, internal second, easy first, difficult third". That is, external causes such as external devices, buses, and power supply are dealt with first, and then hidden faults are dealt with to achieve root cause repair.

[0083] Meanwhile, the applicant's prioritization of fault handling is based on the fact that equipment compatibility faults diagnose defects in the equipment itself, rather than actual physical defects in the vehicle. Prioritizing the identification and handling of such faults can immediately eliminate false errors caused by protocol incompatibility, avoid repair personnel blindly disassembling vehicle parts, and significantly reduce the misdiagnosis rate; repairing bus communication faults can ensure the reliability of data transmission, thus not affecting subsequent internal logic repairs.

[0084] Therefore, the priority of fault handling, from high to low, is as follows: equipment adaptation faults, bus communication faults, underlying hidden faults, and occasional redundancy faults.

[0085] In the above embodiments, the use of fault handling priority to handle compound faults can achieve the following beneficial effects: (1) Eliminate the superimposed damage of external interference to the bottom layer of the electronic control: continuous bus signal interference will aggravate the sensor sampling offset. Repairing the communication link first can avoid repeated interference to the hardware and greatly reduce the probability of secondary data drift recurrence after maintenance; (2) Control maintenance costs and eliminate over-maintenance: line and grounding rectification is a low-cost external inspection. There is no need to replace high-priced parts such as sensors in advance, avoiding blind replacement of parts and waste of resources; (3) Accurately distinguish the primary and secondary root causes of faults: after eliminating external interference, it is possible to intuitively judge whether the data drift is a temporary deviation induced by interference or permanent hardware degradation, and prevent misjudgment of component failure; (4) The step-by-step handling of compound faults can quickly locate the unresolved items, greatly reduce the time for re-inspection and investigation, and improve the one-time cure rate.

[0086] In some embodiments of this application, such as Figure 4 As shown, the vehicle fault diagnosis system also includes a fully closed-loop verification and archiving layer 14.

[0087] The closed-loop verification archiving layer is configured to perform three-level verification on the vehicle after it has been repaired according to the scenario repair plan, in order to confirm whether the undefined fault code has been reproduced.

[0088] One embodiment of this application involves a three-level verification process, including static verification, dynamic verification, and long-term verification. Static verification can refer to verifying whether undefined fault codes are triggered when the vehicle is stationary.

[0089] Dynamic verification can refer to verifying whether undefined fault codes are triggered when a vehicle is continuously driven and covers all operating conditions.

[0090] Long-term verification refers to continuously monitoring the vehicle's operating parameters, bus communication status, and the underlying logs of the vehicle's electronic control unit to verify whether any undefined fault codes are triggered within the detection period.

[0091] Thus, by configuring a three-level closed-loop verification mechanism in the fully closed-loop verification archiving layer, and having this three-level closed-loop verification mechanism triggered sequentially after the scenario repair plan is executed, it can be ensured that the output scenario repair plan of the scenario-based layered processing layer can completely eradicate the fault and prevent false repairs or short-term recurrence of the fault.

[0092] The closed-loop verification archiving layer is also configured to form a standard technical solution from the entire process data after Level 3 verification is passed. The entire process data may include, but is not limited to, undefined fault codes, operating condition snapshots, bus message data, underlying logs, source tracing analysis results, judgment results, scenario repair solutions, and Level 3 verification data.

[0093] In one embodiment of this application, Figure 6 This illustration shows a structural diagram of a fully closed-loop verification archiving layer 14 provided in an embodiment of this application, as shown below. Figure 6 As shown, the closed-loop verification archiving layer 14 includes a static re-inspection unit 141, a full-condition road test unit 142, a long-term monitoring unit 143, and a fault closed-loop archiving unit 144.

[0094] The static re-inspection unit 141 is configured to perform static verification on the vehicle after the scenario repair plan is executed.

[0095] Specifically, the static self-test unit 141 is configured to send a static self-test command to the vehicle after executing the scenario repair plan, so that the vehicle enters a dormant state for static testing. After static testing for a first preset duration (e.g., 30 minutes), it enters the power-on self-test process, obtains the self-test results, and determines whether the vehicle has passed the static verification based on the self-test results. The passing criteria for static verification include confirming that the vehicle has no undefined faults, no historical fault records, and that the static data streams of each electronic control system are normal and without abnormal fluctuations.

[0096] The full-condition road test unit 142 is configured to perform dynamic verification on the vehicle after the static verification is passed.

[0097] Specifically, the full-condition road test unit 142 is configured to generate a dynamic road test task after the vehicle passes static verification, so that the vehicle drives continuously for a second preset time (e.g., no less than 30 minutes), and forcibly covers preset full-condition scenarios (e.g., idling, acceleration, constant speed, deceleration, start-stop, high and low temperature scenarios) during the driving process, obtain dynamic road test results, and determine whether the vehicle has passed dynamic verification based on the dynamic road test results. The passing criteria for dynamic verification include confirming that the vehicle is driving stably, without vibration or abnormal noise, without fault alarms, and without fault code triggering.

[0098] The long-term monitoring unit 143 is configured to perform long-term verification on the vehicle after the dynamic verification is passed.

[0099] Specifically, the long-term monitoring unit 143 is configured to activate a long-term monitoring mode after the dynamic verification is passed, and to perform long-term monitoring of the vehicle for a third preset duration (e.g., no less than 72 seconds), collecting vehicle operating parameters, bus communication status, and low-level logs of the vehicle's electronic control unit, etc., and determining whether the vehicle has passed the long-term verification based on the collected data. The passing criteria for long-term verification include no fault reproduction and no abnormal data drift.

[0100] The fault closed-loop archiving unit 144 is configured to organize and archive undefined fault codes, operating condition snapshots, bus message data, underlying logs, source analysis results, judgment results, scenario repair solutions, and level 3 verification data after passing level 3 verification, forming a technical file corresponding to the undefined fault codes.

[0101] In the above embodiments, by forming a technical file corresponding to the undefined fault code, the root cause of the undefined fault code can be traced, and a closed loop of the entire fault diagnosis and repair chain can be completed.

[0102] In one embodiment of this application, when the composite fault is determined to be a bus communication fault and a low-level hidden fault, the scenario repair scheme generated by the scenario-based layered processing layer 13 is to prioritize the processing of bus communication faults, then process the low-level hidden faults, then clear the redundant records of the fault counter inside the ECU, clear the composite fault superposition mark, and finally verify.

[0103] Specifically, the scenario-based layered processing layer triggers the bus fault repair unit 132 to output a second scenario solution. After the second scenario solution is executed, i.e., after repairing damaged circuits, polishing oxidized grounding contacts, and eliminating external signal interference sources, and completing bus rectification, it verifies whether communication has returned to normal. After successful verification, the bottom-level repair unit 133 is triggered to output a third scenario repair solution. After the third scenario solution is executed, i.e., after replacing the performance degradation sensor, resetting the bottom-level factory calibration parameters, and correcting sampling drift deviation, redundant records in the ECU's internal fault counter are cleared, and composite fault superposition markers are removed. Finally, after the scenario repair solution is completed, static verification, dynamic verification, and long-term verification are conducted to confirm whether the causes of both types of faults have been completely eliminated and whether the faults no longer recur.

[0104] In another aspect, this application provides a vehicle fault diagnosis method, which is applied to the vehicle fault diagnosis system provided in any embodiment of this application. Figure 7 This application provides a schematic flowchart of a vehicle fault diagnosis method according to an embodiment of the present application. Figure 7 As shown, the vehicle fault diagnosis method may include the following steps.

[0105] S71, when reading an undefined fault code for a vehicle fault, obtains the operating condition snapshot at the time of fault triggering, the bus message data within a preset time window, and the underlying log of the target vehicle electronic control unit, and performs source tracing analysis on the operating condition snapshot, bus message data, and underlying log to obtain the source tracing analysis results.

[0106] S72, based on the source analysis results, determine the fault category corresponding to the undefined fault code and obtain the determination result.

[0107] To gain a deeper understanding of the vehicle fault diagnosis method of this application, another embodiment of this application provides a vehicle fault diagnosis method. Figure 8 This document illustrates a flowchart of a vehicle fault diagnosis method according to another embodiment of this application, as shown below. Figure 8 As shown, the vehicle fault diagnosis method includes the following steps.

[0108] S81, retrieve the vehicle fault list and find undefined fault codes.

[0109] The vehicle fault list can be obtained from the vehicle via the OBD port of the vehicle diagnostic equipment. Undefined fault codes may include, but are not limited to, fault codes without DTC definitions, unrecorded fault codes, valid codes, and hexadecimal unknown codes.

[0110] S82: Obtain the diagnostic results after replacing the diagnostic equipment from a third-party diagnostic equipment with the original diagnostic equipment. If the fault disappears, proceed to S83. If the fault recurs, proceed to S84.

[0111] S83 indicates a false fault related to equipment compatibility. Upgrading the diagnostic equipment will suffice; no vehicle repair is required.

[0112] S84 confirms the fault is a genuine fault, then execute S85.

[0113] S85 mandates the preservation of three types of raw data.

[0114] The three types of raw data include a snapshot of the operating conditions at the time of fault triggering, bus message data within a preset time window, and the underlying logs of the vehicle's electronic control unit.

[0115] In one embodiment of this application, the operating condition snapshot may include, but is not limited to, key parameters such as low-voltage power supply voltage, engine / motor speed, vehicle speed, vehicle load, and operating temperature at the moment of fault triggering.

[0116] Bus message data may include, but is not limited to, complete message frame IDs before and after a fault, data bits, communication timing, lost / erroneous frame records, signal interference characteristics, etc.

[0117] The underlying logs can include non-public data such as ECU hidden operation logs, internal fault counters, data verification anomaly records, underlying parameter drift, and hidden fault markers.

[0118] S86 uses a built-in tracing algorithm to trace the source of three types of raw data and obtain the tracing results, thereby enabling reverse reasoning of the cause of the fault.

[0119] Specifically, tracing the source of operating condition snapshots can include analyzing the operating condition characteristics at the time of fault triggering, identifying the specific triggering scenario of the fault (such as power-on initialization, low load idling, high load acceleration, high and low temperature environments, etc.), narrowing the tracing scope, and clarifying the correlation between the fault and the operating condition.

[0120] Tracing the source of bus message data can include parsing message timing anomalies, data bit offsets, frequency of frame loss / errors, detecting grounding status and pin contact conditions, and accurately locating the cause of bus communication link anomalies.

[0121] Tracing the underlying logs can include reading non-public ECU logs and counter data to identify hidden anomalies such as sensor sampling drift, actuator response delay, hardware performance degradation, underlying calibration parameter offset, and program logic deviation, and to trace the root cause of underlying faults that have not been publicly filed by the manufacturer.

[0122] S87, based on the source tracing results, automatically determines the fault type corresponding to the undefined fault code.

[0123] The fault types can include, but are not limited to, device adaptation faults, bus communication faults, low-level hidden faults, intermittent redundancy faults, and compound faults.

[0124] In one embodiment of this application, a device adaptation fault refers to a false fault caused by outdated diagnostic device database version, incomplete adaptation of private protocols, or insufficient device compatibility, even though the vehicle's electronic control system has no substantial abnormalities.

[0125] Bus communication faults refer to genuine communication faults caused by wire harness damage, pin oxidation and pin loss, loose grounding, or external signal interference.

[0126] Hidden faults at the underlying level refer to genuine electronic control faults caused by factors such as aging of sensor or actuator hardware, performance degradation, drift of sampling data, deviation of ECU program logic, and offset of underlying calibration parameters.

[0127] Intermittent redundancy faults refer to one-time redundant pseudo-faults that do not pose a continuous safety hazard and are triggered by fluctuations in the vehicle's low-voltage power supply, battery depletion, interference from aftermarket modified equipment, or sudden changes in operating conditions.

[0128] S88 generates a corresponding scene repair solution based on the judgment result.

[0129] For example, for equipment compatibility faults, a scenario repair solution is generated that includes updating the private protocol package of the diagnostic equipment without disassembling the vehicle or replacing parts; for bus communication faults, a scenario repair solution is generated that includes repairing damaged wiring harnesses, grinding and tightening grounding points, and treating oxidized pins to completely eliminate communication interference causes; for underlying hidden faults, a scenario repair solution is generated that includes replacing degraded sensors / actuators, resetting the ECU's underlying sampling calibration parameters, correcting data drift deviations, and eradicating underlying electronic control hidden dangers; for intermittent redundant faults, a scenario repair solution is generated that optimizes the vehicle's low-voltage power supply circuit, removes illegally modified interfering equipment, and clears redundant fault records from the ECU to prevent repeated false triggering of faults; for complex faults, a scenario repair solution is generated that includes layered and progressive logical processing to achieve root cause repair.

[0130] After executing the scenario repair plan, S89 enters the closed-loop verification process and performs level three verification. This ensures that there is no risk of the fault recurring.

[0131] After passing Level 3 verification, S810 performs data archiving.

[0132] S81, after failing the level 3 verification, re-execute S85.

[0133] In some of the above embodiments, compared with existing vehicle fault diagnosis technologies, this application can achieve the following beneficial effects: First, it eliminates the reliance on fault code dictionaries. This application does not require standard fault code dictionaries, publicly available definition libraries, or manufacturer protocol libraries, nor does it require upgrading diagnostic equipment. It can trace faults back to their source using only the vehicle's native low-level data. This breaks through the traditional technical bottleneck of "repair is only possible with defined fault codes, and diagnosis is impossible without defined fault codes," achieving passive and precise location of unknown non-standard faults.

[0134] Second, it accurately identifies non-standard, proprietary, and interference-related faults, covering blind spots of traditional technologies. Compared to traditional diagnostics, which can only identify international standard fault codes and cannot handle vehicle manufacturer proprietary codes, bus interference codes, and ECU low-level hidden codes, this application can directly parse freeze frames, bus messages, and ECU low-level logs, and can identify non-standard, proprietary, interference, and hidden faults that traditional technologies cannot fully cover, greatly expanding the diagnostic scope.

[0135] Third, the fault classification is detailed, avoiding misdiagnosis, omission, and over-repair. This application provides four fault classifications, which can accurately distinguish between equipment adaptation faults, bus communication faults, ECU low-level hidden faults, intermittent redundancy faults, and compound faults. Compared with the traditional simple "equipment / vehicle" dichotomy, the diagnostic accuracy is higher, the qualitative assessment is more accurate, and the repair is more targeted, reducing mis-repair, omission, and over-repair from the root cause.

[0136] Fourth, it can accurately locate underlying hidden faults and achieve root cause cure. Through in-depth analysis of bus messages and ECU underlying logs, it can directly trace the root cause to underlying factors such as wiring harness, shielding, grounding, sensor drift, calibration offset, and logic abnormalities. Through a closed-loop verification of static re-inspection, dynamic road test, and 72-hour long-term monitoring, it ensures that the fault is cured once and stabilized in the long term, completely solving the shortcomings of traditional diagnosis that only looks at the surface fault codes, hidden faults remain and recur repeatedly, and only treats the symptoms but not the root cause.

[0137] It should be understood that the specific features, operations, and details described herein with respect to the methods of this application can also be similarly applied to the apparatus and system of this application, or vice versa. Furthermore, each step of the methods of this application described above can be performed by a corresponding component or unit of the apparatus or system of this application.

[0138] It should be understood that the various modules / units of the device of this application can be implemented wholly or partially through software, hardware, firmware, or a combination thereof. Each module / unit can be embedded in the processor of the electronic device in hardware or firmware form or independent of the processor, or it can be stored in the memory of the electronic device in software form for the processor to call to execute the operation of each module / unit. Each module / unit can be implemented as an independent component or module, or two or more modules / units can be implemented as a single component or module.

[0139] In another aspect, this application provides an electronic device. Figure 9 This application provides a schematic diagram of the structure of an electronic device according to an embodiment of the present application. Figure 9 As shown, the electronic device 90 includes a processor 91, a memory 91, and a program stored in the memory and capable of running on the processor. When the program is executed by the processor, it implements the steps of the vehicle fault diagnosis method provided in any of the above embodiments.

[0140] In one embodiment, the electronic device 90 may include a processor, memory, network interface, communication interface, etc., connected via a system bus. The processor of the electronic device 90 can be used to provide necessary computing, processing, and / or control capabilities. The memory of the electronic device 90 may include non-volatile storage media and internal memory. The non-volatile storage media may store operating systems, computer programs, etc. The internal memory can provide an environment for the operation of the operating system and computer programs in the non-volatile storage media. The network interface and communication interface of the electronic device 90 can be used to connect and communicate with external devices via a network.

[0141] This application also provides a computer-readable storage medium storing instructions, wherein when executed by a processor, the instructions implement the steps of the vehicle fault diagnosis method provided in any of the above embodiments.

[0142] Those skilled in the art will understand that the method steps of this application can be performed by a computer program instructing related hardware, such as electronic devices or processors. The computer program can be stored in a non-transitory computer-readable storage medium, and its execution causes the steps of this application to be performed. Depending on the context, any reference herein to memory, storage, or other media may include non-volatile or volatile memory. Examples of non-volatile memory include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), flash memory, magnetic tape, floppy disk, magneto-optical data storage device, optical data storage device, hard disk, solid-state drive, etc. Examples of volatile memory include random access memory (RAM), external cache memory, etc.

[0143] The technical features described above can be combined arbitrarily. Although not all possible combinations of these technical features are described, any combination of these technical features should be considered to be covered by this specification, provided that such combination does not contain contradictions.

[0144] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

Claims

1. A vehicle fault diagnosis system, characterized in that, include: The source tracing perception layer is configured to, upon reading an undefined fault code for a vehicle malfunction, acquire a snapshot of the operating conditions at the time of the fault trigger, bus message data within a preset time window, and the underlying logs of the target vehicle electronic control unit; and perform source tracing analysis on the snapshot of the operating conditions, the bus message data, and the underlying logs to obtain source tracing analysis results; the source tracing analysis results include operating condition feature vectors, bus abnormal feature sets, and underlying abnormal sequences of the vehicle electronic control unit; The classification and determination layer is configured to determine the fault category corresponding to the undefined fault code based on the source tracing analysis results, and obtain the determination result.

2. The system according to claim 1, characterized in that, The source tracing perception layer includes: The freeze frame operating condition acquisition unit is configured to acquire an operating condition snapshot at the time of fault triggering when the undefined fault code is read, extract feature parameters from the operating condition snapshot, and add a timestamp to the extracted feature parameters to form an operating condition feature vector. The bus message parsing unit is configured to, when the undefined fault code is read, acquire bus message data within a preset time window, and perform abnormal feature analysis on the bus message data to obtain the bus abnormal feature set; The underlying log reading unit is configured to, when reading the undefined fault code, obtain the underlying log of the target vehicle electronic control unit, perform data feature extraction and feature recognition on the underlying log, and obtain the underlying abnormal sequence.

3. The system according to claim 1, characterized in that, The classification determination layer includes: The device compatibility fault determination unit is configured to determine whether the source analysis result meets the device compatibility fault determination conditions; if the source analysis result meets the device compatibility fault determination conditions, it obtains the fault detection result after switching the third-party diagnostic device to the original diagnostic device, and if the fault detection result indicates that the undefined fault code has been eliminated, it determines that the fault type corresponding to the undefined fault code is a device compatibility fault. The bus communication fault determination unit is configured to determine whether the source analysis result meets the bus communication fault determination conditions; if the source analysis result meets the bus communication fault determination conditions, the fault type corresponding to the undefined fault code is determined to be a bus communication fault. The underlying implicit fault determination unit is configured to determine whether the source analysis result meets the underlying implicit fault determination condition; if the source analysis result meets the underlying implicit fault determination condition, the fault type corresponding to the undefined fault code is determined to be an underlying implicit fault. An intermittent redundancy fault determination unit is configured to determine whether the source analysis result meets the intermittent redundancy fault determination conditions; if the source analysis result meets the intermittent redundancy fault determination conditions, the fault type corresponding to the undefined fault code is determined to be an intermittent redundancy fault. The composite fault judgment unit is configured to determine whether the source analysis result satisfies at least two of the following fault judgment conditions: equipment adaptation fault judgment condition, bus communication fault judgment condition, underlying implicit fault judgment condition, and intermittent redundancy fault judgment condition; when the source analysis result satisfies the at least two fault judgment conditions, the fault type corresponding to the undefined fault code is determined to be a composite fault.

4. The system according to claim 1, characterized in that, Also includes: The scenario-based layered processing layer is configured to generate a scenario repair solution corresponding to the fault category based on the determination result.

5. The system according to claim 4, characterized in that, The scenario-based hierarchical processing layer is also configured to generate a scenario repair plan corresponding to the composite fault based on the fault processing priority when the fault corresponding to the undefined fault code is a composite fault.

6. The system according to claim 5, characterized in that... The fault handling priorities, from highest to lowest, are: device adaptation faults, bus communication faults, underlying hidden faults, and occasional redundancy faults.

7. The system according to any one of claims 4-6, characterized in that, Also includes: The closed-loop verification archiving layer is configured to perform three-level verification on the vehicle after it has been repaired according to the scenario repair plan, in order to confirm whether the undefined fault code has been reproduced. The three-level verification includes static verification, dynamic verification and long-term verification.

8. A vehicle fault diagnosis method, characterized in that, Applied to the vehicle fault diagnosis system as described in any one of claims 1-7, the vehicle fault diagnosis method includes: When an undefined fault code for a vehicle malfunction is read, a snapshot of the operating conditions at the time of the fault trigger, bus message data within a preset time window, and the underlying log of the target vehicle electronic control unit are obtained. The operating condition snapshot, the bus message data, and the underlying log are then subjected to source tracing analysis to obtain the source tracing analysis results. The source tracing analysis results include operating condition feature vectors, bus abnormal feature sets, and the underlying abnormal sequence of the vehicle electronic control unit. Based on the source tracing analysis results, the fault category corresponding to the undefined fault code is determined, and the determination result is obtained.

9. An electronic device, characterized in that, It includes a processor, a memory, and a program stored in the memory and executable on the processor, wherein the program, when executed by the processor, implements the steps of the vehicle fault diagnosis method as described in claim 8.

10. A computer-readable storage medium, characterized in that, Instructions are stored on the computer-readable storage medium, which, when executed by a processor, implement the steps of the vehicle fault diagnosis method as described in claim 8.

Images