Vehicle diagnosis method and device, medium and vehicle

Abstract

The invention provides a vehicle diagnosis method and device, a medium and a vehicle. The method comprises the steps of obtaining multiple diagnosis items of the vehicle; determining an initial diagnosis sequence of the vehicle according to a first association relationship among the plurality of diagnosis items; the initial diagnosis sequence comprises a plurality of diagnosis items and a diagnosis sequence corresponding to each diagnosis item in the plurality of diagnosis items, and the first association relationship is determined according to a predefined dependency relationship among the vehicle parts; inputting the plurality of diagnosis items into a reinforcement learning model, and learning a second association relationship among the plurality of diagnosis items through the reinforcement learning model to obtain an association degree among the plurality of diagnosis items; adjusting the initial diagnosis sequence according to the correlation degree to obtain a target diagnosis sequence of the vehicle; the target diagnosis sequence comprises at least part of diagnosis items in the plurality of diagnosis items and a diagnosis sequence corresponding to each diagnosis item in the at least part of diagnosis items; and using the target diagnosis sequence to diagnose the vehicle. According to the embodiment of the invention, the vehicle diagnosis efficiency can be improved.

Description

Technical Field

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

[0002] In the automotive repair field, traditional vehicle fault diagnosis relies heavily on manual operation. Technicians typically begin with visual and auditory inspections, then use specialized tools to read fault codes, and finally combine their own experience with the vehicle manual to analyze the fault. This manual diagnostic method demands extremely high levels of experience and skill from the technician. When encountering complex or rare faults, technicians often need to invest a significant amount of time in repeated troubleshooting, constantly trying and refining their diagnostic approach. This can easily lead to prolonged diagnostic cycles and low vehicle diagnostic efficiency. Summary of the Invention

[0003] This application provides a vehicle diagnostic method, equipment, medium, and vehicle that can improve the efficiency of vehicle diagnostics.

[0004] In a first aspect, embodiments of this application provide a vehicle diagnostic method, the method comprising:

[0005] Obtain multiple diagnostic items for the vehicle;

[0006] The initial diagnostic sequence of the vehicle is determined based on the first association between multiple diagnostic items. The initial diagnostic sequence includes multiple diagnostic items and the diagnostic order corresponding to each diagnostic item. The first association is determined based on the predefined dependency relationship between vehicle components.

[0007] Multiple diagnostic items are input into a reinforcement learning model, and the reinforcement learning model learns the second association relationship between the multiple diagnostic items to obtain the association degree between the multiple diagnostic items.

[0008] The initial diagnostic sequence is adjusted based on the correlation to obtain the target diagnostic sequence for the vehicle; the target diagnostic sequence includes at least some of the diagnostic items from a plurality of diagnostic items, and the diagnostic order corresponding to each of the at least some diagnostic items.

[0009] The vehicle is diagnosed using a target diagnostic sequence.

[0010] Secondly, this application provides a vehicle diagnostic device, the device comprising:

[0011] The acquisition module is used to acquire multiple diagnostic items for the vehicle;

[0012] A first determining module is configured to determine an initial diagnostic sequence for the vehicle based on a first association relationship among the plurality of diagnostic items; the initial diagnostic sequence includes the plurality of diagnostic items and the diagnostic order corresponding to each of the plurality of diagnostic items, and the first association relationship is determined based on a predefined dependency relationship between vehicle components;

[0013] The second determining module is used to input the plurality of diagnostic items into a reinforcement learning model, learn the second correlation relationship between the plurality of diagnostic items through the reinforcement learning model, and obtain the correlation degree between the plurality of diagnostic items.

[0014] The third determining module is used to adjust the initial diagnostic sequence according to the correlation degree to obtain the target diagnostic sequence of the vehicle; the target diagnostic sequence includes at least some of the multiple diagnostic items, and the diagnostic order corresponding to each of the at least some diagnostic items;

[0015] A diagnostic module is used to diagnose the vehicle using the target diagnostic sequence.

[0016] Thirdly, embodiments of this application provide an electronic device, which includes: a processor and a memory storing computer program instructions;

[0017] When the processor executes computer program instructions, it implements the vehicle diagnostic method as described in any of the embodiments of the first aspect.

[0018] Fourthly, embodiments of this application provide a computer storage medium storing computer program instructions, which, when executed by a processor, implement the vehicle diagnostic method as described in any of the embodiments of the first aspect.

[0019] Fifthly, embodiments of this application provide a computer program product in which instructions, when executed by a processor of an electronic device, cause the electronic device to perform a vehicle diagnostic method as described in any of the embodiments of the first aspect above.

[0020] Sixthly, embodiments of this application also provide a vehicle, which includes at least one of the following:

[0021] Such as electronic devices in the third aspect;

[0022] Such as the computer-readable storage medium in the fourth aspect.

[0023] This application provides a vehicle diagnostic method, device, medium, and vehicle. Multiple diagnostic items of the vehicle are acquired, and an initial diagnostic sequence for these items is determined based on the dependencies between different vehicle components. This application introduces a reinforcement learning model to learn deep second-level relationships between diagnostic items, obtaining the correlation degree between each item. Based on these correlation degrees, the initial diagnostic sequence is adjusted and optimized to generate a more efficient target diagnostic sequence. This data-driven diagnostic sequence optimization method effectively avoids the repeated attempts and error corrections that may occur in traditional manual diagnostics due to insufficient technician experience or when facing complex faults. Through intelligent task optimization and sequence adjustment, this application significantly shortens the diagnostic cycle and improves the efficiency of vehicle diagnostics. Attached Figure Description

[0024] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0025] Figure 1 This is one of the schematic flowcharts of the vehicle diagnostic method provided in the embodiments of this application;

[0026] Figure 2 This is a second schematic flowchart of the vehicle diagnostic method provided in the embodiments of this application;

[0027] Figure 3 This is the third flowchart illustrating the vehicle diagnostic method provided in the embodiments of this application;

[0028] Figure 4 This is the fourth flowchart illustrating the vehicle diagnostic method provided in the embodiments of this application;

[0029] Figure 5 This is the fifth flowchart illustrating the vehicle diagnostic method provided in the embodiments of this application;

[0030] Figure 6 This is a schematic diagram of the structure of a vehicle diagnostic device provided in an embodiment of this application;

[0031] Figure 7 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0032] To better understand the above-mentioned objectives, features, and advantages of this disclosure, the solutions disclosed herein will be further described below. It should be noted that, unless otherwise specified, the embodiments and features described herein can be combined with each other.

[0033] Numerous specific details are set forth in the following description in order to provide a full understanding of this disclosure, but this disclosure may also be implemented in other ways different from those described herein; obviously, the embodiments in the specification are only some, and not all, of the embodiments of this disclosure.

[0034] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the term "comprising" or any other variations thereof is intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes the element.

[0035] In the field of vehicle diagnostics, while remote vehicle diagnostics (RVDC) and external diagnostic tools provide effective tools for after-sales maintenance, vehicle diagnostic tools (VDT) stand out due to their unique advantages. VDTs can utilize the vehicle's onboard screen to perform functions such as vehicle status queries, fault cause analysis, software reloading, and calibration. They not only quickly screen and calibrate simple problems, but also lower the barrier to entry through visual, guided tools, significantly improving maintenance efficiency.

[0036] However, current on-board diagnostic systems still face many challenges in practical applications. Fragmentation of diagnostic protocols is widespread. Traditional second-generation on-board diagnostic (OBD-II) systems can only support basic diagnostic functions and are difficult to adapt to the dedicated diagnostic protocols of advanced driver assistance systems (ADAS) and new electronic control units (ECUs) such as smart cockpits.

[0037] Furthermore, the cloud-based collaboration capabilities of on-board diagnostic systems are weak. Diagnostic results and software version data often rely on manual synchronization, failing to achieve bidirectional real-time interaction between the vehicle and the cloud, typically employing a one-way data transmission method. User interaction efficiency also needs improvement, requiring technicians to frequently switch between personal computer (PC) tools and the vehicle's interface during operation. Regarding version management, ECU software baseline version deviation detection exhibits lag and lacks an intelligent warning mechanism.

[0038] Traditional after-sales diagnostics rely on external PC devices connected to the OBD interface using dedicated hardware, making autonomous vehicle-side diagnostics impossible. Current ECU software version verification requires manual comparison of the Vehicle Identification Number (VIN) with a cloud database, resulting in a high false positive rate. Furthermore, existing vehicle diagnostic applications (APPs) use fixed communication protocols, failing to dynamically adapt to different vehicle model protocol extensions. While existing technologies have achieved universal parsing of Diagnostic Trouble Codes (DTCs), issues remain regarding the execution of multi-protocol diagnostic sequences; they primarily focus on automated testing, neglecting cloud synchronization of diagnostic results and user interaction optimization; and their data recording mechanisms are simplistic, failing to meet the demands of integrated vehicle-cloud scenarios.

[0039] To address the problems existing in related technologies, embodiments of this application provide a vehicle diagnostic method, device, medium, and vehicle.

[0040] The vehicle diagnostic method provided in the embodiments of this application will be described below. Figure 1 As shown, the method specifically includes the following steps:

[0041] S100 retrieves multiple diagnostic items for the vehicle.

[0042] Optionally, in this embodiment of the application, in the field of vehicle diagnostics, a diagnostic item refers to a specific diagnostic task or test content set for various systems, components, or functions of a vehicle, and is the basic unit constituting a diagnostic sequence. A diagnostic item can be the reading and analysis of data from a sensor (such as signal detection of an engine coolant temperature sensor), the testing of an actuator function (such as throttle valve actuator opening verification), or the verification of specific system parameters (such as pressure sensor calibration of an anti-lock braking system), etc. Each diagnostic item has its own clear detection target, execution conditions, and judgment criteria. For example, diagnostic items for an onboard camera may include specific operations such as image sharpness detection, focus calibration, and distortion rate analysis. This collection of diagnostic items covers the testing needs of vehicles from powertrain systems and chassis control to body electronics and intelligent driving, and is the basic unit for implementing vehicle fault location and performance evaluation.

[0043] Optionally, in one feasible implementation of this application, the VIN and hardware / software version information of each ECU are first read to query the preset mapping relationship between the vehicle model, ECU, and diagnostic protocol, and the appropriate diagnostic protocol stack (such as Unified Diagnostic Services (UDS)) is dynamically loaded. Then, diagnostic requests are sent to each ECU through the unified interface of the protocol abstraction layer, such as reading real-time sensor data, calling actuator function tests, and obtaining fault code storage information. At the same time, the system divides the diagnostic scope based on the vehicle's functional domains (such as powertrain, chassis, smart cockpit, etc.) and automatically selects the items to be tested based on predefined fault detection rules, such as engine speed sensor signal verification and camera image distortion rate analysis. In addition, vehicle operating environment parameters (such as vehicle speed, oil temperature, battery voltage, etc.) are collected simultaneously, ultimately forming a multi-dimensional diagnostic item set covering hardware status, software parameters, and functional tests, providing a data foundation for the construction of subsequent diagnostic sequences.

[0044] S200, determine the initial diagnostic sequence of the vehicle based on the first association relationship between the plurality of diagnostic items; the initial diagnostic sequence includes the plurality of diagnostic items and the diagnostic order corresponding to each of the plurality of diagnostic items, and the first association relationship is determined based on the predefined dependency relationship between vehicle components.

[0045] Optionally, in this embodiment, the first association refers to the logical connection between diagnostic items constructed based on predefined rules, which is essentially a mapping of the vehicle's physical structure and functional dependencies in the diagnostic process. The establishment of this first association is based on the hardware connections, signal transmissions, or functional dependencies between vehicle components. For example, fault diagnosis of the engine control unit must take precedence over fuel injector testing because the fuel injector's operating state depends on the ECU's command output. This association can be pre-stored in the system in the form of a tree structure or a directed acyclic graph, explicitly defining the constraint condition that "A must be executed before B" between diagnostic items, ensuring that the diagnostic process conforms to the physical working principles of the vehicle system.

[0046] The initial diagnostic sequence is a set of diagnostic task execution sequences generated based on the first association relationship, containing all vehicle diagnostic items and their corresponding order. It uses predefined component dependencies as its logical foundation, organizing scattered diagnostic items into a time-constrained process chain. This order ensures that the execution conditions of subsequent diagnostic items are met by preceding tasks. The key features of this initial diagnostic sequence are that it covers all preset diagnostic items and strictly adheres to component dependency rules, much like a digital mapping of a traditional diagnostic process, providing a baseline framework for subsequent sequence optimization through reinforcement learning.

[0047] The dependencies between vehicle components refer to the subordinate constraints between various hardware or functional modules in terms of physical connection, signal transmission, and functional implementation. These dependencies form the underlying basis for establishing the primary relationships. Such dependencies may manifest as direct connections at the hardware level (e.g., communication between the throttle body and the engine ECU via wiring harness) or as logical dependencies at the functional level (e.g., the shifting logic of an automatic transmission relies on real-time data from wheel speed sensors). For example, image data from an onboard camera is the input basis for an automatic parking system, forming a dependency chain of "camera → parking system." These dependencies are abstracted into constraints in the diagnostic logic through vehicle engineering design documents, electrical topology diagrams, and other materials, ensuring that the diagnostic process aligns with the actual working principles of the vehicle.

[0048] Optionally, in one feasible implementation of this application, firstly, the system extracts a component dependency model related to the current diagnostic scenario from the knowledge base. This model is stored in the form of a directed acyclic graph, where nodes represent diagnostic items and edges represent dependencies. Subsequently, the system maps the diagnostic items obtained in S100 to this dependency graph, generating an initial association matrix. The matrix elements represent the dependency strength between diagnostic items, with values ​​derived from preset rules (e.g., 1 for hard dependencies and 0.5 for soft dependencies). For example, there is a hard dependency between engine ECU firmware version checking and fuel injector drive testing, while tire pressure monitoring and air conditioning system diagnosis have no direct dependency.

[0049] Next, a topological sorting algorithm is used to process the association matrix, generating multiple feasible sequences that satisfy the dependency constraints. During the sorting process, the system prioritizes processing nodes with an in-degree of 0 (i.e., diagnostic items without prior dependencies) and dynamically updates the dependency state of the remaining nodes.

[0050] Finally, the generated initial diagnostic sequence is output as a task list, including the diagnostic item ID, execution order, preconditions, and expected execution time. For example, the sequence might be: 1. Read engine fault codes → 2. Detect oxygen sensor signal → 3. Verify throttle position → 4. Test ignition coil performance. This sequence satisfies component dependencies, providing a structured input foundation for subsequent reinforcement learning.

[0051] S300, the multiple diagnostic items are input into the reinforcement learning model, and the reinforcement learning model learns the second correlation between the multiple diagnostic items to obtain the correlation degree between the multiple diagnostic items.

[0052] Optionally, in this embodiment, the reinforcement learning model is a data-driven machine learning algorithm used to uncover implicit second-order correlations between diagnostic items. The reinforcement learning model takes historical diagnostic data as input and discovers statistical dependencies between diagnostic items through unsupervised learning. For example, the model can learn from a large number of maintenance records that when "engine vibration" and "abnormal oxygen sensor voltage" occur simultaneously, the probability of "low catalytic converter efficiency" increases significantly. This correlation cannot be directly expressed through predefined component dependencies (first-order correlations) but is quantified through the state-action-reward mechanism of reinforcement learning. The output of the reinforcement learning model is a correlation matrix between diagnostic items, providing a data foundation for subsequent sequence adjustments.

[0053] The second association is a statistical dependency between diagnostic items mined from historical maintenance data by the reinforcement learning model, complementing the first association based on physical structure. For example, the first association stipulates that "ECU communication must be checked before the actuator can be tested," while the second association might reveal that "the probability of thermostat failure increases by 80% when the coolant temperature sensor fails." This probabilistic association cannot be expressed through predefined rules. The core difference between the second and first associations is that the second association can continuously evolve with the accumulation of new data, adapting to vehicle model iterations and changes in fault modes; the second association can identify associations under specific fault scenarios (such as the enhanced correlation between battery performance and the starting system in low-temperature environments).

[0054] The correlation degree is a quantitative expression of the second correlation relationship, reflecting the degree of mutual influence between diagnostic items, and can be represented by a value in the range [0,1]. For example, a correlation degree of 0.8 indicates that the result of diagnostic item A has a strong influence on the execution of diagnostic item B, while 0.2 indicates a weak correlation. This index is calculated through the value function of the reinforcement learning model, taking into account the co-occurrence probability of faults (such as the co-occurrence frequency of ABS wheel speed sensor faults and ESP system faults) and temporal dependence (the optimal execution interval between diagnostic items (such as some faults needing to be exposed only after a specific operation)).

[0055] Unlike the fixed dependency strength in the first type of correlation, the correlation degree is dynamically adjusted based on the vehicle's real-time status (such as mileage and ambient temperature). For example, in high-temperature environments, the correlation between the air conditioning compressor diagnostics and the cooling fan diagnostics will significantly increase. This dynamically quantified correlation degree allows the system to adjust the diagnostic sequence in real time during execution, achieving more accurate fault location.

[0056] Optionally, in one feasible implementation of this application, a reinforcement learning model architecture is first constructed. Each diagnostic item in the initial diagnostic sequence is abstracted as a node in a graph, and the node features include diagnostic item type (such as sensor detection, actuator testing), historical failure rate, execution time, etc. The edge weights are initialized to the dependency strength in the first association relationship, forming an initial association graph.

[0057] During the model training phase, a training set is constructed using historical diagnostic data. Each training data point includes: vehicle state characteristics (such as vehicle model, mileage, and environmental parameters), the sequence of diagnostic items executed, and the final fault location result. A policy gradient algorithm is used to optimize the model parameters, and the reward function is defined as: the improvement in correct diagnostic rate minus a weighted value of the total diagnostic time. For example, if executing a diagnostic item earlier significantly improves the accuracy of subsequent fault location, a positive reward is given; if redundant testing occurs due to improper ordering, a negative reward is given.

[0058] In the state-space design, each state represents the set of currently executed diagnostic items and their results. The action space is the set of diagnostic items that have not yet been executed. The model learns the optimal strategy through trial and error, i.e., the next diagnostic item to choose given the current state. For example, when engine vibration is detected, the model learns that prioritizing checking the ignition system is faster than directly checking the fuel system, thus establishing a strong correlation between these two diagnostic items. To enhance the model's generalization ability, a transfer learning mechanism is introduced. For different vehicle models or diagnostic scenarios, the model's basic graph structure and parameters are retained, with only the layers relevant to specific scenarios being fine-tuned. For example, new energy vehicles share most of the diagnostic item association patterns with gasoline vehicles, but diagnostic items related to the battery management system are optimized separately.

[0059] The final correlation matrix not only includes direct dependencies between diagnostic items but also captures indirect associations. This data-driven correlation analysis can uncover implicit relationships that are difficult to define manually, thus providing a more accurate basis for subsequent sequence adjustment.

[0060] S400, the initial diagnostic sequence is adjusted according to the correlation to obtain the target diagnostic sequence of the vehicle; the target diagnostic sequence includes at least some of the multiple diagnostic items, and the diagnostic order corresponding to each of the at least some diagnostic items.

[0061] Optionally, in this embodiment, the target diagnostic sequence is a dynamic diagnostic scheme optimized by reinforcement learning, aiming to balance diagnostic accuracy and efficiency. Compared with the initial diagnostic sequence, the target diagnostic sequence removes diagnostic items with low relevance to the current fault based on the correlation degree (second correlation relationship) of the diagnostic items. For example, if reinforcement learning finds that the correlation degree between "abnormal air conditioning vent temperature" and "engine vibration" is only 0.1, then when dealing with engine faults, the air conditioning diagnosis is removed from the sequence; the target diagnostic sequence breaks through fixed dependencies and reorders based on data-driven correlation degree. For example, the traditional initial sequence requires checking the intake system before testing the ignition system, but reinforcement learning finds that reverse execution can shorten the diagnosis time by 30% in a specific fault scenario, so the target sequence will prioritize the ignition system diagnosis;

[0062] The target diagnostic sequence breaks away from the mechanical nature of the initial sequence through reinforcement learning, realizing the transformation from "rule-driven" to "data intelligence-driven", which significantly improves the efficiency of fault location while ensuring diagnostic accuracy.

[0063] Optionally, in one feasible implementation of this application, firstly, the diagnostic sequence is encoded as a chromosome, with each gene representing a diagnostic item and the gene position indicating the execution order, ensuring that each sequence in the initial population satisfies the dependency constraints of the first association relationship. Then, 100 candidate sequences are generated from the initial diagnostic sequence as the initial population through random swapping, insertion, or deletion operations.

[0064] The fitness function is designed by comprehensively considering three core metrics: diagnostic efficiency, execution cost, and fault coverage. Diagnostic efficiency is calculated using a correlation matrix; the higher the correlation between adjacent diagnostic items, the greater the information gain. Execution cost is the reciprocal of the sum of the execution times of the diagnostic items. Fault coverage is based on historical data to evaluate the probability of a sequence detecting common faults. The three metrics are weighted and summed to form the final fitness value. The weighting coefficients can be adjusted according to actual needs, such as increasing the weight of execution cost when emphasizing rapid diagnosis.

[0065] During the genetic operations phase, the selection process randomly selects three individuals each time, retaining the one with the highest fitness to enter the next generation. The crossover operation uses ordered crossover to ensure that the generated offspring do not violate dependency constraints. The mutation operation randomly swaps the positions of two diagnostic items with a low probability, increasing population diversity. To ensure the feasibility of the optimization process, the system introduces a constraint handling mechanism in the genetic operations: if the correlation between two diagnostic items is lower than a set threshold (e.g., 0.3), they are prohibited from being executed adjacently. The algorithm iteratively executes selection, crossover, and mutation operations until there is no significant improvement in fitness for 10 consecutive generations. The individual with the highest fitness in the final population is the target diagnostic sequence.

[0066] S500, the vehicle is diagnosed using the target diagnostic sequence.

[0067] Optionally, in one feasible implementation of this application, the diagnostic system first establishes a communication connection with each electronic control unit (ECU) of the vehicle through the on-board diagnostic interface, and triggers the corresponding diagnostic services sequentially according to the priority in the target diagnostic sequence. When executing each diagnostic item, the system collects sensor data, actuator feedback, and ECU status information in real time, and compares them with preset thresholds or standard waveforms. If an anomaly is detected, the system immediately marks the diagnostic item as a "fault" and automatically triggers related deep diagnostic items based on the correlation learned in the second correlation relationship.

[0068] During the diagnostic process, the system dynamically maintains the diagnostic progress schedule. If the result of a diagnostic item clearly identifies the root cause of the fault, it automatically skips subsequent low-relevance diagnostic items and proceeds to the fault repair suggestion stage ahead of schedule. After completing all necessary diagnostic items, the system integrates the results of each diagnosis and generates a report that includes fault location, severity assessment, and repair suggestions, which is then presented to the repair personnel through a human-machine interface. For example, the report might display "P0171 Fuel system too lean, it is recommended to check the air flow meter and related pipelines," while also providing repair operation guidelines and component replacement priorities. The entire diagnostic process strictly follows the optimized sequence of the target diagnostic sequence to ensure efficient and accurate fault location.

[0069] In a vehicle diagnostic method provided in this application embodiment, multiple diagnostic items of the vehicle are acquired, and an initial diagnostic sequence of the multiple diagnostic items is determined based on the dependencies between different vehicle components. This application embodiment introduces a reinforcement learning model to learn the deep second-level correlations between diagnostic items, thereby obtaining the correlation degree between each diagnostic item. Based on these correlation degrees, the initial diagnostic sequence is adjusted and optimized to generate a more efficient target diagnostic sequence. This data-driven diagnostic sequence optimization method effectively avoids the repeated attempts and error corrections that may occur in traditional manual diagnosis due to insufficient technician experience or when facing complex faults. Through intelligent task optimization and sequence adjustment, this application embodiment can significantly shorten the diagnostic cycle and improve the efficiency of vehicle diagnosis.

[0070] In one embodiment, the initial diagnostic sequence includes an initial diagnostic item and a termination diagnostic item;

[0071] The step of adjusting the initial diagnostic sequence according to the correlation to obtain the target diagnostic sequence for the vehicle includes:

[0072] The initial diagnostic sequence is modeled as a weighted directed graph; wherein, a node of the weighted directed graph corresponds to a diagnostic item in the initial diagnostic sequence, and the transition cost between nodes in the weighted directed graph is used as the edge weight of the weighted directed graph. The transition cost is determined based on the diagnostic time of the diagnostic item, the resource consumption of the diagnostic item, and the correlation degree.

[0073] Based on the weighted directed graph, determine the set of diagnostic steps, the transition cost matrix, the identifier of the initial diagnostic item, and the identifier of the termination diagnostic item for the initial diagnostic sequence;

[0074] The target diagnostic sequence is determined based on the set of diagnostic steps, the transition cost matrix, the identifier of the initial diagnostic item, and the identifier of the termination diagnostic item.

[0075] Optionally, in this embodiment, the initial diagnostic item is the starting point of the diagnostic process and can be a diagnostic task that can be performed without any preconditions. The termination diagnostic item is the end point of the diagnostic process, marking the completion of fault location. The definition of a termination diagnostic item must meet two conditions: 1) all necessary preliminary diagnostic steps have been completed; 2) the diagnostic results are sufficient to support maintenance decisions.

[0076] A weighted directed graph is a mathematical abstraction of a diagnostic sequence. In a weighted directed graph, nodes represent diagnostic items; directed edges represent execution order constraints between diagnostic items; and edge weights represent transition costs, i.e., the overall cost of transitioning from one diagnostic item to another.

[0077] Transfer cost is a quantitative indicator of edge weights, taking into account diagnostic time, the time required to execute the current diagnostic item; resource consumption, the computing resources, energy or equipment wear and tear consumed during the diagnostic process; and correlation penalty, which increases the transfer cost to avoid redundant operations if the two diagnostic items have low correlation.

[0078] Optionally, in one feasible implementation of this application, the initial diagnostic sequence is first modeled as a weighted directed graph: each diagnostic item corresponds to a node in the weighted directed graph, and the edge weights between nodes are the transition costs. These transition costs are calculated by comprehensively considering the time consumption, resource usage, and relevance of the diagnostic item; for example, time consumption accounts for 40%, resource usage for 30%, and relevance for 30%. Edge weights are generated using a weighted formula. Subsequently, based on the transition cost matrix, the identifiers of the initial and final diagnostic items, starting from the initial diagnostic item, a priority queue is used to select the adjacent node with the lowest current cost each time, iterating gradually towards the final diagnostic item, ultimately selecting the path with the lowest total cost as the target sequence.

[0079] In these alternative embodiments, the correlation of diagnostic items is visually presented through a weighted directed graph. By combining time consumption, resource consumption, and correlation quantification of transfer costs, key parameters are extracted to determine the target sequence, which can optimize the diagnostic order, reduce redundant steps, improve diagnostic accuracy, and adapt to the needs of complex vehicle systems.

[0080] In one embodiment, determining the target diagnostic sequence based on the set of diagnostic steps, the transition cost matrix, the identifier of the initial diagnostic item, and the identifier of the termination diagnostic item includes:

[0081] The set of diagnostic steps, the transition cost matrix, the identifier of the initial diagnostic item, and the identifier of the termination diagnostic item are input into the optimization model. The shortest path tree is constructed through the optimization model to obtain the target diagnostic sequence. The shortest path tree is the set of optimal paths from the initial diagnostic item to the termination diagnostic item. The optimization objective of the optimization model includes at least one of minimizing the total diagnostic time and maximizing the diagnostic accuracy.

[0082] Optionally, in this embodiment, the shortest path tree is the set of optimal paths from the initial diagnostic item to the final diagnostic item, where each node's path satisfies an optimization objective (such as minimizing total time or maximizing diagnostic accuracy). The tree can be constructed based on algorithms such as Dijkstra's algorithm or A*, searching for the path with the minimum cost in a weighted directed graph. Each branch of the tree represents a possible fault path, ensuring efficient problem localization in different scenarios.

[0083] The optimization model is an algorithmic framework for path optimization. Its inputs include a set of diagnostic steps, a transition cost matrix, and initial / terminating diagnostic item identifiers. The output is a shortest path tree. The optimization model can be implemented using dynamic programming or graph search algorithms (such as A* and Dijkstra's algorithm). Under the premise of satisfying the first association constraint, it intelligently adjusts the diagnostic order based on the association degree information provided by the second association, achieving a balance between diagnostic efficiency and accuracy.

[0084] Optionally, in one specific implementation of this application, firstly, the initial diagnostic sequence is modeled as a weighted directed graph, where each node corresponds to a diagnostic item, and the edge weights between nodes represent the transition cost. The transition cost comprehensively considers diagnostic time, resource consumption, and correlation penalty. Next, the set of diagnostic steps, the transition cost matrix, and the identifiers of the initial and final diagnostic items are extracted from the weighted directed graph. Subsequently, this information is input into an optimization model, which can use Dijkstra's algorithm to construct a shortest path tree with the goal of minimizing the total transition cost. Starting from the initial diagnostic item, the algorithm dynamically selects the current optimal node (i.e., the node with the minimum transition cost and that satisfies the constraints), and gradually expands the path until the final diagnostic item is reached.

[0085] During the path construction process, the optimization model strictly follows dependency constraints and correlation threshold constraints (e.g., direct connections between nodes with a correlation of less than 0.3 are prohibited). For example, when "engine vibration" is detected, the algorithm finds that "crankshaft position sensor detection" and "camshaft position sensor detection" have a high correlation (0.9) and short execution time, so it prioritizes executing these two items instead of executing "throttle body cleaning" which has a low correlation in the original sequence.

[0086] Taking the self-test of an onboard ECU as an example, after modeling the 15 diagnostic steps as a weighted directed graph, the algorithm uses the correlation matrix to find that "sensor signal verification" and "ECU firmware check" have a high correlation and short execution time. These two steps are executed first to directly locate the fault, skipping the "communication bus test" and "relay test" in the original sequence, reducing the total time from 50 seconds to 35 seconds. At the same time, it ensures that key test items are executed first according to constraints. The final output target diagnostic sequence is an optimized ordered array, achieving a balance between diagnostic efficiency and accuracy.

[0087] In these alternative embodiments, by modeling the initial diagnostic sequence as a weighted directed graph, determining the transition cost based on diagnostic time, resource consumption, and correlation, and then constructing a shortest path tree using an optimization model, a target sequence that balances diagnostic efficiency and accuracy can be dynamically generated while satisfying dependency constraints. This allows for intelligent skipping of redundant diagnostic items and optimization of execution order, achieving both diagnostic process compression and improved fault location accuracy, providing an efficient and precise solution for vehicle diagnostics.

[0088] In one embodiment, the target diagnostic sequence includes diagnostic items to be upgraded and confirmed;

[0089] The process of diagnosing the vehicle using the target diagnostic sequence includes:

[0090] Based on the diagnostic items to be upgraded, obtain the hardware identifiers of each electronic control unit of the vehicle, as well as the current software version information of each electronic control unit;

[0091] Based on the hardware identifier and the current software version information, the electronic control unit to be upgraded is determined;

[0092] Based on the baseline version of the electronic control unit to be upgraded and the current software version information of the electronic control unit to be upgraded, the version deviation warning value of the electronic control unit to be upgraded is determined;

[0093] If the version deviation warning value is greater than or equal to a preset threshold, the electronic control unit to be upgraded will be reloaded.

[0094] In the event of overload failure, the electronic control unit to be upgraded is upgraded based on the upgrade package corresponding to the electronic control unit to be upgraded, and an upgraded electronic control unit is obtained.

[0095] Optionally, in this embodiment, the diagnostic item to be upgraded is a specific diagnostic task in the target diagnostic sequence used to trigger the vehicle ECU upgrade verification process, and is a key link connecting the diagnostic sequence and the ECU upgrade operation. The core function of the diagnostic item to be upgraded is to determine whether there is a version deviation in each ECU of the vehicle, and whether heavy load or upgrade operations are required, through systematic information collection and analysis, so as to provide a basis for decision-making for subsequent ECU maintenance actions and ensure the necessity and accuracy of the upgrade operation.

[0096] The generation of diagnostic items to be upgraded is related to vehicle fault information and version management requirements. On the one hand, diagnostic items to be upgraded can be triggered by vehicle fault diagnostic codes. When the vehicle detects fault codes related to the ECU version (such as software incompatibility, functional abnormalities, etc.), this diagnostic item to be upgraded will be generated to further verify the version status. On the other hand, it can also come from the regular vehicle health check plan, which will automatically include it in the target diagnostic sequence according to the preset cycle for routine verification of the ECU version and to prevent potential risks caused by version deviation.

[0097] The baseline version is the standard software version that the electronic control unit should follow. It represents the software version that the electronic control unit should have installed under normal or ideal conditions. It is used to compare with the current software version to determine whether an upgrade is needed and in what direction the upgrade should be carried out.

[0098] The reload operation is an operation performed on the electronic control unit to reload the current software when the version deviation warning value is greater than or equal to a preset threshold. It aims to attempt to resolve problems that may be caused by abnormal software operation by reloading and restore the electronic control unit to normal working state.

[0099] The version deviation warning value is calculated based on the baseline version of the electronic control unit to be upgraded and the current software version information. It is used to measure the degree of deviation between the current software version and the baseline version. When the value is greater than or equal to the preset threshold, it indicates that the version difference has reached the level that requires intervention (such as reload or upgrade).

[0100] Optionally, in one specific implementation of this application, firstly, using the diagnostic items to be upgraded, hardware identifiers are accurately extracted from each ECU of the vehicle, and the current software version information of each ECU is collected to clarify its software status. Next, based on the hardware identifiers, the corresponding baseline version for each ECU can be found. The current software version information is compared with the baseline version, and a version deviation warning value is determined using a specific algorithm (such as calculating the version difference ratio) to measure the degree of deviation between the current version and the baseline version. If the warning value is greater than or equal to a preset threshold, a reload operation is initiated for the ECU to be upgraded, i.e., a reload task package is generated, encrypted firmware is downloaded to the vehicle, and the vehicle verifies the firmware's legitimacy using methods such as SM2 signature verification. If the signature verification is successful, the ECU is flashed, attempting to restore or correct the software status. If the reload fails, an upgrade operation based on the corresponding upgrade package is triggered, from obtaining the compatible upgrade package to deploying it to the ECU to be upgraded, completing the software version update, and obtaining the upgraded ECU.

[0101] It should be noted that the threshold settings differ for different types of ECUs, mainly based on functional safety level (e.g., ASIL-D level major version difference threshold is 0), network location (central gateway hash difference > 0.5% warning), software architecture (AUTOSAR components must be fully matched), and historical fault correlation (ECUs with a risk priority number (RPN) ≥ 80 use dynamic algorithms). The threshold is dynamically adjusted through FOTA feedback and Bayesian models to balance compatibility risks and management costs.

[0102] Optionally, the ECU overload verification pass criteria include: successful communication protocol handshake (e.g., CANFD frame response < 50ms), core functional parameters meeting standards (e.g., engine ECU torque error ≤ ±3%), and safety check value matching (hash value difference < 0.5%). If the overload fails, a three-level process is executed: 1) Automatic rollback to the verified version; 2) Generation of diagnostic logs with fault codes and uploading to the cloud; 3) Triggering vehicle downgrade mode, limiting power output and activating instrument warning lights. Subsequently, an upgrade operation based on the corresponding upgrade package is triggered, from obtaining the adapted upgrade package to deploying it to the ECU to be upgraded, completing the software version update, and obtaining the upgraded ECU. The key ECU adopts a dual microcontroller unit (MCU) redundancy verification mechanism.

[0103] In these alternative embodiments, by accurately identifying the electronic control unit to be upgraded, determining the upgrade requirements using hardware identifiers and version information, and triggering reload or upgrade operations in conjunction with version deviation warning values, the compliance of ECU software versions is ensured. Furthermore, by implementing a layered process of reload before upgrading, invalid upgrades are reduced and upgrade risks are mitigated. This provides an accurate basis for subsequent diagnosis and maintenance, thereby improving the efficiency of vehicle ECU management and system stability.

[0104] In one embodiment, determining the version deviation warning value of the electronic control unit to be upgraded based on the baseline version corresponding to the electronic control unit to be upgraded and the current software version information of the electronic control unit to be upgraded includes:

[0105] Based on the baseline version, determine the version number difference between the current software version information and the baseline version;

[0106] Based on the functional safety level of the electronic control unit to be upgraded and the historical fault information of the electronic control unit, determine the degree of impact of the electronic control unit to be upgraded on the safe driving of the vehicle.

[0107] Based on the degree of impact, the version number difference value is weighted and calculated to obtain the version deviation warning value of the electronic control unit.

[0108] Optionally, in this embodiment, the version number difference value is a quantitative indicator that measures the difference between the current software version of the electronic control unit to be upgraded and the baseline version. Specifically, it can be calculated based on the numerical difference or semantic difference of the version number (such as changes in the major version number, minor version number, and revision number). For example, if the baseline version is 2.0.0 and the current version is 1.5.0, then the version number difference value may be expressed as "major version difference 1, minor version difference 0.5".

[0109] The degree of impact is a weighted factor in the comprehensive assessment of the impact of the ECU to be upgraded on vehicle safety. It is determined by two parts. First, according to standards, ECU functions are classified into different safety levels; for example, the safety level of a braking system ECU is higher than that of a wiper control ECU. Second, the frequency and severity of failures caused by version issues in the history of this ECU are analyzed. For example, if an ECU has a safety level of C and a high historical failure rate, its degree of impact will have a larger weight. This weighting is used to correct for version number differences, so that the final version deviates from the warning value more closely to the actual safety risks.

[0110] Optionally, in one specific implementation of this application, firstly, based on the baseline version, the version number difference is calculated according to a set rule by parsing the current software version information and the version number of the baseline version. For example, for version numbers in SemVer format (major.minor.revision), the absolute values ​​of the differences between the major version number, minor version number, and revision number are calculated respectively. If the baseline version is v2.1.3 and the current version is v1.2.5, then the differences between the major, minor, and revision numbers are 1, 1, and 2 respectively. Next, based on the functional safety level of the ECU to be upgraded and historical fault information (statistics on the frequency of faults caused by the ECU due to version issues, the severity of the fault consequences, etc.), the degree of its impact on vehicle safe driving is comprehensively determined. ECUs with higher safety levels and greater historical fault impacts have a higher weight for their impact. For example, the weight of the impact of the braking ECU is set to 0.7, and that of the entertainment ECU is set to 0.3.

[0111] Finally, the version number difference value is weighted based on the degree of impact, and corresponding weights are assigned to the difference values ​​of different version positions (major, minor, and revision numbers) (e.g., major version difference weight 0.5, minor version difference weight 0.3, revision number difference weight 0.2). First, the sum of the products of each version position difference value and its corresponding weight is calculated, and then multiplied by the degree of impact weight to obtain the version deviation warning value, i.e., warning value = [(major version difference × 0.5 + minor version difference × 0.3 + revision number difference × 0.2)] × degree of impact weight. For example, if the brake ECU has a major version difference of 1 and a minor version difference of 2, then (1 × 0.5 + 2 × 0.3) = 1.1 is calculated first, and then multiplied by 0.7, resulting in a warning value of 0.77. If this value is greater than a preset threshold (e.g., 0.5), the corresponding version intervention process (reload or upgrade) is triggered. This achieves accurate warning by combining ECU safety attributes and version differences, improving the security and targeting of vehicle ECU version management.

[0112] In these alternative embodiments, on the one hand, version number differences are used to intuitively measure software version gaps and clarify upgrade requirements; on the other hand, functional safety levels and historical fault information are combined to determine the degree of impact and scientifically allocate weights, giving greater attention to version differences in critical systems. The version deviation warning value calculated by combining these two methods avoids blind upgrades and can promptly detect and handle high-risk version issues, improving the efficiency and accuracy of software version management while ensuring safe vehicle operation.

[0113] In one embodiment, diagnosing the vehicle using the target diagnostic sequence includes:

[0114] Execute each diagnostic item sequentially according to the target diagnostic sequence;

[0115] During execution, obtain the execution results of the currently executing diagnostic items;

[0116] If the execution result of the currently executed diagnostic item does not match the preset result, a secondary calibration diagnostic item is generated and added to the target diagnostic sequence to obtain an adjusted target diagnostic sequence; the execution priority of the secondary calibration diagnostic item is the highest priority of the adjusted target diagnostic sequence.

[0117] The process involves executing the adjusted target diagnostic sequence, and if the result of the currently executed diagnostic item does not match the preset result, returning to the step of generating a secondary calibration diagnostic item and adding the secondary calibration diagnostic item to the target diagnostic sequence to obtain the adjusted target diagnostic sequence, until the adjusted target diagnostic sequence is completed.

[0118] Optionally, in one specific implementation of this application, when diagnosing a vehicle using a target diagnostic sequence, each diagnostic item is executed sequentially according to the sequence. During execution, the execution result of the current diagnostic item is acquired in real time and compared with the preset result. If the execution result of the current diagnostic item does not match the preset result, for example, when executing "engine idle speed detection," if the detected actual speed does not match the preset speed range, the system will automatically generate a secondary calibration diagnostic item.

[0119] The generation of secondary calibration diagnostic items is based on the physical and functional relationships between various vehicle components. For example, abnormal engine idling may be related to the throttle position sensor, intake pressure sensor, etc. The system will determine the diagnostic items that need further calibration based on these relationships, such as "throttle position sensor recalibration". After generation, the secondary calibration diagnostic item will be added to the target diagnostic sequence and its execution priority will be set to the highest.

[0120] Subsequently, the system executes the adjusted target diagnostic sequence, continuously monitoring the execution results of the diagnostic items in real time. If a mismatch between the execution results and the preset results still occurs, the steps of generating secondary calibration diagnostic items, adding them to the sequence, and increasing their priority are repeated, continuously iterating and optimizing the diagnostic process. For example, after executing "throttle position sensor recalibration," if the engine idle speed still does not return to normal, the system may generate new secondary calibration diagnostic items such as "intake pressure sensor detection." Through continuous iterative adjustments until the adjusted target diagnostic sequence is completed, the system ensures comprehensive and accurate location and resolution of vehicle faults. Simultaneously, measured data during the diagnostic process, such as error values ​​after sensor calibration, can be transmitted back to the cloud database to optimize the dependency weights and execution logic of each diagnostic item in subsequent diagnostic sequences, continuously improving diagnostic efficiency and accuracy.

[0121] In these optional embodiments, real-time comparison of execution results triggers secondary calibration, which can quickly identify and address potential problems not covered by the initial diagnosis, forming a closed-loop correction mechanism. The secondary calibration item is set as the highest priority to ensure that critical anomalies are investigated first, avoiding redundant operations. Iterative adjustments to the diagnostic path reduce the risk of missed detections and avoid over-diagnosis. For example, when the window calibration error exceeds the tolerance, a secondary camera calibration is automatically inserted, forming a physical-visual coupled correction chain, improving system robustness. Ultimately, by continuously optimizing the diagnostic process, the fault diagnosis cycle is shortened, and maintenance costs are reduced.

[0122] In one embodiment, acquiring multiple diagnostic items for the vehicle includes:

[0123] Obtain the diagnostic codes for the vehicle;

[0124] Based on the fault diagnostic code, determine the plurality of diagnostic items associated with the fault diagnostic code;

[0125] The process of diagnosing the vehicle using the target diagnostic sequence includes:

[0126] In response to a user's request to execute the target diagnostic sequence, the vehicle is diagnosed using the target diagnostic sequence, and a first interface is displayed on the vehicle's display device. The first interface includes multiple display areas, one of which is used to display the real-time execution status of a diagnostic item in the target diagnostic sequence.

[0127] In response to the user's request to view the diagnostic item, a second interface is displayed on the display device. The second interface is used to display the diagnostic parameters of the diagnostic item by the diagnostic application associated with the diagnostic item.

[0128] Optionally, in one specific implementation of this application, firstly, the vehicle's fault diagnostic code is read through the on-board diagnostic interface. Based on predefined association rules, the set of diagnostic items related to the fault code is automatically mapped to form an initial diagnostic sequence. Subsequently, the system inputs this sequence into an optimization model, and generates a target diagnostic sequence by combining factors such as diagnostic time and correlation.

[0129] When a user initiates an execution request, the system presents a primary interface on the display device through a Human Machine Interface (HMI) interaction system. This primary interface can employ a multi-level navigation menu design, with the main area displaying diagnostic item cards in execution order. Each card displays the diagnostic status (e.g., "Pending Execution," "In Progress," "Completed") and a progress bar in real time. For example, when executing "Read Fault Codes," the corresponding card dynamically displays "In Progress" and the current reading progress. If a diagnostic item requires user operation (e.g., pressing the brake pedal), the card will display operation instructions and trigger an audible prompt.

[0130] If a user clicks on any diagnostic item card, they are redirected to a second interface via a cross-application navigation mechanism. This second interface integrates the diagnostic application and displays detailed parameters related to the selected diagnostic item. For example, clicking on "Throttle Position Sensor Test" displays the sensor voltage value, standard range curve, and dynamic waveform graph in real time. If the parameters are abnormal, the system automatically highlights them and indicates the percentage deviation. The interface also provides function buttons such as "View Historical Data" and "Compare to Standard Values" to support in-depth analysis by the user.

[0131] In these optional embodiments, a closed-loop diagnostic link is formed by intelligently recommending associated diagnostic items based on DTC (Diagnostic Troubleshooting). Through this three-level interaction framework (vehicle information → diagnostic function → execution result), combined with intelligent guidance and cross-application collaboration, the system achieves an efficient and intuitive vehicle diagnostic experience.

[0132] It should be noted that the various optional implementation methods described in the embodiments of this application can be combined with each other or implemented individually without conflict, and the embodiments of this application do not limit this.

[0133] To facilitate understanding of the vehicle diagnostic method provided in the above embodiments, the following describes the vehicle diagnostic method using a specific scenario embodiment.

[0134] Optionally, embodiments of this application provide a vehicle diagnostic system, including a vehicle-side diagnostic module, a cloud management platform, an HMI interaction system, and an intelligent diagnostic execution system.

[0135] The vehicle-side diagnostic module includes:

[0136] Multi-protocol adaptation layer: integrates ZDS 3.0 / ISO 14229 / UDS protocol stack;

[0137] Diagnostic execution engine: Supports 25+ diagnostic services, including fault detection of Autonomous Driving Control Unit (ADCU) and calibration of Automated Driving Parameter Unit (ADPU);

[0138] Local cache database: Stores VIN / ECU baseline versions / diagnostic history.

[0139] Specifically, this application achieves seamless collaboration of multi-protocol on-board diagnostic engines through a modular design. This is manifested in the following ways: a protocol abstraction layer defines a unified interface and dynamically loads various protocol stacks as plug-ins; during initialization, VIN parsing and ECU fingerprint recognition (hardware / software version) automatically match and adapt to the database, loading protocol parameter configurations in JSON / YAML format; at runtime, a context-aware switching mechanism automatically selects the protocol stack based on service ID characteristics, and a priority policy table supports manual intervention; the transport layer abstracts and shields the differences between CAN / CANFD / Ethernet to ensure protocol stack independence; in case of anomalies, protocol rollback is triggered and combined with an OTA hot update adaptation rule base; the database stores vehicle model-ECU-protocol mapping relationships and security level parameters, supporting AI-driven protocol prediction and blockchain-style adaptation records, ensuring coverage of over 98% of mixed-protocol vehicle scenarios. This design, through layered abstraction, dynamic adaptation, and intelligent decision-making, achieves unified scheduling and execution of diagnostic services in a multi-protocol environment, ensuring diagnostic efficiency, system compatibility, and maintainability.

[0140] The cloud management platform includes:

[0141] Diagnostic task orchestrator: Generates customized diagnostic sequences (such as the "window calibration → forward camera calibration" workflow);

[0142] Version synchronization service: Compares the actual ECU version with the cloud baseline and triggers a deviation warning code (threshold is configurable);

[0143] OTA protection module: Automatically performs ECU reload verification before firmware over-the-air (FOTA) download.

[0144] HMI interactive systems include:

[0145] Multi-level navigation menu: adopts a three-level interaction framework of "vehicle information → diagnostic function → execution result";

[0146] Intelligent guidance system: Automatically recommends associated diagnostic items based on DTC codes (such as fuel system test sequence triggered by P0171 fault);

[0147] Cross-application redirection mechanism: Seamless connection with the Intelligent Driving Engineering Mode APP is achieved through Intent.

[0148] The intelligent diagnostic execution system includes:

[0149] DTC (Distressed Troubleshooting) tiered management strategy: Based on the different levels of faults, vehicle faults are managed differently. Faults are divided into three levels: A, B, and C. Level A faults require cloud authorization to be cleared, and the processing time must be ≤2 hours to ensure rapid response to serious faults. Level B faults can be cleared independently by the store, with a processing time of ≤24 hours, suitable for handling routine faults. Level C faults are visible to the user and subject to continuous monitoring, allowing users to be aware of the vehicle's potential status. By clearly defining clearing permissions and processing timelines through tiered management, the systematic and targeted nature of vehicle fault diagnosis and maintenance is improved.

[0150] ECU version control matrix.

[0151] like Figure 2 As shown, the vehicle diagnostic APP serves as the core entry point for the diagnostic process. On one hand, it relies on the ZXC vehicle-cloud link, synchronizes with the diagnostic-dedicated cloud and Over-the-Air (OTA) technology, and links with the version deviation warning function. It also utilizes the cloud management platform to achieve diagnostic task orchestration, ECU version comparison, and pre-OTA overload verification. On the other hand, it connects to the vehicle-side diagnostic module through the ZDS 3.0 protocol. The vehicle-side diagnostic module, with its multi-protocol adaptation layer, diagnostic execution engine, and local cache database, performs vehicle diagnostics in conjunction with the ECU communication matrix. Simultaneously, the HMI interaction system and intelligent diagnostic execution system (including DTC hierarchical management and other strategies) work together to build a complete system from diagnostic initiation and execution to cloud-based collaborative management and interactive feedback, realizing the intelligent, networked, and collaborative nature of vehicle diagnostics.

[0152] Specifically, the detailed description of the vehicle diagnostic app is as follows:

[0153] [APP Software Version Number Display]

[0154] The software name displays "On-board Diagnostics";

[0155] Based on the current version number, the field is hardcoded in the front end to display the current version number of the vehicle diagnostic APP.

[0156] [Vehicle Information Display]

[0157] When a user clicks the "On-board Diagnostics" button on the homepage of the "Repair Mode APP" to launch and enter the "On-board Diagnostics APP":

[0158] Following the functional chain of 25N1U2, the on-board diagnostic app requests vehicle information to read the corresponding diagnostic sequence download address and executes it on the vehicle. During this process, the on-board diagnostic app is on a loading page.

[0159] After the information from the sequential execution is sent back to the vehicle and converted to the correct format, the on-board diagnostics app enters the "Vehicle Information Page," which displays the vehicle's information.

[0160] Table 1 Vehicle Information Display Table

[0161]

[0162]

[0163] Specifically, when the version deviation is ≥10%, a red warning icon can be displayed on the vehicle's display device; the ECU version matrix can adopt a zebra stripe table layout.

[0164]

APP Language Settings

[0165] The "Vehicle Information" page of the onboard diagnostic app provides a drop-down menu that allows users to switch between Chinese and English for fields within the app.

[0166] APP language setting logic:

[0167] Language initialization settings.

[0168] [Vehicle Diagnostics] During APP installation or each vehicle ignition cycle, the system will pre-set the APP's language according to the current vehicle's language environment.

[0169] The app can obtain the current vehicle infotainment system language settings through the Application Programming Interface (API) provided by the operating system;

[0170] The app only supports Chinese and English language configurations.

[0171] Car infotainment system voice monitoring.

[0172] [Vehicle Diagnostics] The app's language switches according to the vehicle's infotainment system language;

[0173] The in-vehicle infotainment app monitors language change events;

[0174] The app loads the corresponding resource files (such as string resources, image resources, etc.) according to the new language settings;

[0175] The app re-renders the user interface (UI) to display the new language content;

[0176] App language switching (user side);

[0177] The app settings module supports language switching.

[0178] Languages: Chinese, English;

[0179] During each vehicle infotainment system ignition cycle, manually set the language permissions to be higher than the system's automatic settings.

[0180] After manually setting the next vehicle ignition cycle, the app will still switch languages ​​according to the vehicle's infotainment system.

[0181] If the vehicle's infotainment system is in a language other than Chinese or English, the app will display in English.

[0182] [Version Announcement + App Feature Introduction]

[0183] Because the current on-board diagnostic app's software update process on the vehicle follows FOTA, the fields in the operation manual and version announcements will be hardcoded with this version and are not maintained in the cloud.

[0184] Based on the size and format requirements of the pop-up window on the HMI side, confirm the text content.

[0185] Table 2 Diagnostic APP User Operation Table

[0186]

[0187] Optionally, in this embodiment of the application, vehicle information management collects basic data such as VIN and mileage through the Controller Area Network (CAN) bus, displays them in a responsive layout, and compares them with the ECU baseline version every hour to trigger a deviation alarm.

[0188] In the ECU upgrade control process, the diagnostic script engine first obtains a list of upgradable ECUs. After the user selects one, a request is initiated. The integrity of the upgrade package is verified by the vehicle cloud collaboration, and then the flashing is performed and logs are generated.

[0189] Taking window calibration as an example, the diagnostic sequence sequentially triggers initialization commands, collects motion trajectories through cameras, compares preset and measured data, and finally generates a calibration report, forming a complete system from data collection and upgrade control to specific diagnostic processes.

[0190] Optionally, in this application embodiment, two embodiments are used to illustrate the application of the vehicle diagnostic system in in-store diagnostics and remote calibration scenarios, respectively. In the in-store diagnostics scenario, after the technician initiates the repair mode, the in-vehicle APP automatically obtains the VIN code and generates a device fingerprint containing the Media Access Control Address (MAC) address and security chip ID. This fingerprint is synchronized with the cloud baseline version library via the ZXC link. When an ADAS domain controller version deviation of 12% is detected, a red warning indicator is triggered, and a SWRL123 overload task package is generated to promptly address version issues. In the remote calibration scenario, when calibrating the forward-facing camera, the system calls the CAL_00AF instruction set in the ZDS 3.0 extended protocol, uploading calibration data frames to the diagnostic cloud in real time at a sampling rate of 100Hz. Based on cloud-based visual algorithm feedback, parameters are adjusted, typically achieving the required accuracy within no more than three iterations, thus realizing precise and efficient remote calibration.

[0191] like Figure 3 As shown, optionally, in one implementation of this application, a flowchart illustrating the collaborative operation of the vehicle diagnostic APP with the cloud and vehicle-side modules is provided. Specifically, the APP directly connects to the vehicle-side diagnostic module via the ZDS3.0 protocol; on the other hand, it connects to the dedicated diagnostic cloud via the ZXC vehicle-cloud link through two-way authentication using Hypertext Transfer Protocol Secure (HTTPS), establishing an "end-to-cloud-to-end" communication channel. The dedicated diagnostic cloud outputs two types of services: first, it pushes version synchronization services via OTA differential packets and then transmits them to the vehicle-side with SM4 encryption; second, it supplements the diagnostic logic of the vehicle-side diagnostic module from the diagnostic script library through protocol extension packets. The vehicle-side diagnostic module, acting as an intermediate layer, receives instructions from the cloud or the APP and interacts with the ECU communication matrix through the Variable Data Rate Controller Area Network (CAN with Flexible Data Rate, CANFD) / CAN protocol, ultimately realizing functions such as vehicle fault diagnosis and version synchronization, forming a complete diagnostic closed loop of "collection-transmission-processing-execution".

[0192] like Figure 4As shown, in one embodiment, in a store diagnostic scenario, after the technician triggers the vehicle ECU upgrade process, the system first performs a cloud baseline version comparison. If an ADAS domain controller version deviation of ≥5% is detected (assuming this is the detection standard for the vehicle ECU), a reload task package is generated. Then, the encrypted firmware is downloaded, and the vehicle verifies the signature using SM2. After successful verification, the ECU is flashed. Once flashing is complete, the version is sent back to the cloud to update the OTA version library. If the version is normal, the process ends; if the signature verification fails, an alarm is triggered and the system rolls back. This ensures the accuracy and security of the ECU upgrade process and achieves standardized and intelligent management of ECU upgrades in the vehicle diagnostic system. The firmware signature verification time is ≤300ms (based on the national cryptographic SM2 algorithm).

[0193] like Figure 5 As shown, in one embodiment, taking the calibration of a vehicle's forward-facing camera as an example, the vehicle-mounted APP sends a CAL_00AF calibration command. The vehicle-side diagnostic module encapsulates a ZDS3.0 extended frame and transmits it to the target ECU. The target ECU returns the original data stream. The vehicle-side uploads the calibration data to the diagnostic cloud at a sampling rate of 100Hz. The diagnostic cloud calculates and feeds back the parameter correction amount. The vehicle-side performs dynamic adjustment and enters a loop (including accuracy verification, real-time status code feedback, and secondary verification request). The single calibration cycle is controlled within 3.2s ± 0.5s (including cloud computing delay). The data frame follows the structure of packet header / report header (4B) + payload / data load (32B) + cyclic redundancy check (CRC) (2B). Finally, the diagnostic cloud generates a calibration report and sends it back to the vehicle-mounted APP, completing the accurate calibration process and ensuring the performance of the vehicle perception system.

[0194] The process involves dynamic adjustment and verification. After receiving the correction amount, the vehicle-side diagnostic module sends a dynamic adjustment command to the target ECU (such as adjusting the camera sensor gain and ISP image processing parameters). After adjustment, a loop verification process is initiated: the target ECU sends back a status code in real time (e.g., 0x00 indicates adjustment in progress, 0x01 indicates temporary stability), and the vehicle-side continuously monitors the process. The diagnostic cloud initiates a secondary verification request, requiring the re-collection of calibration data and verification of accuracy (e.g., pixel error ≤ 0.5%). If the accuracy is not met, the "adjustment → verification" loop is repeated, with the number of iterations ≤ 3 (to ensure efficiency).

[0195] Figure 6 A schematic diagram of a vehicle diagnostic device provided in another embodiment of this application is shown. For ease of explanation, only the parts related to the embodiments of this application are shown.

[0196] Reference Figure 6 The vehicle diagnostic device may include:

[0197] The acquisition module 601 is used to acquire multiple diagnostic items of the vehicle;

[0198] The first determining module 602 is used to determine the initial diagnostic sequence of the vehicle based on the first association relationship between the plurality of diagnostic items; the initial diagnostic sequence includes the plurality of diagnostic items and the diagnostic order corresponding to each of the plurality of diagnostic items, and the first association relationship is determined based on the predefined dependency relationship between vehicle components;

[0199] The second determining module 603 is used to input the plurality of diagnostic items into a reinforcement learning model, learn the second correlation relationship between the plurality of diagnostic items through the reinforcement learning model, and obtain the correlation degree between the plurality of diagnostic items.

[0200] The third determining module 604 is used to adjust the initial diagnostic sequence according to the correlation degree to obtain the target diagnostic sequence of the vehicle; the target diagnostic sequence includes at least some of the multiple diagnostic items, and the diagnostic order corresponding to each of the at least some diagnostic items;

[0201] The diagnostic module 605 is used to diagnose the vehicle using the target diagnostic sequence.

[0202] It should be noted that the information interaction and execution process between the above-mentioned devices / units are based on the same concept as the method embodiments of this application, and are devices corresponding to the above-mentioned methods. All implementation methods in the above-mentioned method embodiments are applicable to the embodiments of this device. For details on its specific functions and the technical effects it brings, please refer to the method embodiment section, which will not be repeated here.

[0203] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0204] Figure 7 A schematic diagram of the hardware structure of the electronic device provided in an embodiment of this application is shown.

[0205] The device may include a processor 701 and a memory 702 storing program instructions.

[0206] When processor 701 executes the program, it implements the steps in any of the above method embodiments.

[0207] For example, the program can be divided into one or more modules / units, one or more of which are stored in memory 702 and executed by processor 701 to complete this application. The one or more modules / units can be a series of program instruction segments capable of performing a specific function, which describe the execution process of the program in the device.

[0208] Specifically, the processor 701 may include a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits that can be configured to implement the embodiments of this application.

[0209] Memory 702 may include mass storage for data or instructions. For example, and not limitingly, memory 702 may include a hard disk drive (HDD), floppy disk drive, flash memory, optical disk, magneto-optical disk, magnetic tape, or Universal Serial Bus (USB) drive, or a combination of two or more of these. Where appropriate, memory 702 may include removable or non-removable (or fixed) media. Where appropriate, memory 702 may be internal or external to the integrated gateway disaster recovery device. In a particular embodiment, memory 702 is non-volatile solid-state memory.

[0210] Memory may include read-only memory (ROM), random access memory (RAM), disk storage media devices, optical storage media devices, flash memory devices, and electrical, optical, or other physical / tangible memory storage devices. Therefore, typically, memory includes one or more tangible (non-transitory) readable storage media (e.g., memory devices) encoded with software including computer-executable instructions, and when the software is executed (e.g., by one or more processors), it is operable to perform the operations described with reference to the methods according to one aspect of this disclosure.

[0211] The processor 701 implements any of the methods described in the above embodiments by reading and executing program instructions stored in the memory 702.

[0212] In one example, the electronic device may also include a communication interface 703 and a bus 710. The processor 701, memory 702, and communication interface 703 are connected via the bus 710 and communicate with each other.

[0213] The communication interface 703 is mainly used to realize communication between various modules, devices, units and / or equipment in the embodiments of this application.

[0214] Bus 710 includes hardware, software, or both, that couples components of an online data traffic metering device together. For example, and not limitingly, the bus may include an Accelerated Graphics Port (AGP) or other graphics bus, an Enhanced Industry Standard Architecture (EISA) bus, a Front Side Bus (FSB), HyperTransport (HT) interconnect, an Industry Standard Architecture (ISA) bus, an Infinite Bandwidth Interconnect, a Low Pin Count (LPC) bus, a memory bus, a Microchannel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCI-X) bus, a Serial Advanced Technology Attachment (SATA) bus, a Video Electronics Standards Association Local (VLB) bus, or other suitable buses, or combinations of two or more of these. Where appropriate, bus 710 may include one or more buses. Although specific buses are described and illustrated in embodiments of this application, any suitable bus or interconnect is contemplated herein.

[0215] Furthermore, in conjunction with the methods in the above embodiments, this application embodiment can provide a storage medium for implementation. This storage medium stores program instructions; when these program instructions are executed by a processor, they implement any of the methods in the above embodiments.

[0216] This application also provides a chip, which includes a processor and a communication interface. The communication interface and the processor are coupled. The processor is used to run programs or instructions to implement the various processes of the above method embodiments and achieve the same technical effect. To avoid repetition, it will not be described again here.

[0217] It should be understood that the chip mentioned in the embodiments of this application may also be referred to as a system-on-a-chip, system chip, chip system, or system-on-a-chip, etc.

[0218] This application provides a computer program product, which is stored in a storage medium and executed by at least one processor to implement the various processes of the above method embodiments and achieve the same technical effects. To avoid repetition, it will not be described again here.

[0219] This application embodiment also provides a vehicle, which includes at least one of the following:

[0220] The electronic device as described in the foregoing embodiments;

[0221] The computer-readable storage medium as described in the foregoing embodiments;

[0222] The computer program product as described in the foregoing embodiments.

[0223] It should be clarified that this application is not limited to the specific configurations and processes described above and shown in the figures. For the sake of brevity, detailed descriptions of known methods are omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of this application is not limited to the specific steps described and shown. Those skilled in the art can make various changes, modifications, and additions, or change the order of steps, after understanding the spirit of this application.

[0224] The functional modules shown in the above block diagram can be implemented as hardware, software, firmware, or a combination thereof. When implemented in hardware, they can be, for example, electronic circuits, application-specific integrated circuits (ASICs), appropriate firmware, plug-ins, function cards, etc. When implemented in software, the elements of this application are programs or code segments used to perform the required tasks. Programs or code segments can be stored on machine-readable media or transmitted over a transmission medium or communication link via data signals carried on a carrier wave. "Machine-readable media" can include any medium capable of storing or transmitting information. Examples of machine-readable media include electronic circuits, semiconductor memory devices, ROM, flash memory, erasable ROM (EROM), floppy disks, CD-ROMs, optical disks, hard disks, fiber optic media, radio frequency (RF) links, etc. Code segments can be downloaded via computer grids such as the Internet, intranets, etc.

[0225] It should also be noted that the exemplary embodiments mentioned in this application describe methods or systems based on a series of steps or apparatus. However, this application is not limited to the order of the above steps; that is, the steps can be performed in the order mentioned in the embodiments, or in a different order, or several steps can be performed simultaneously.

[0226] The aspects of this disclosure have been described above with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and program products according to embodiments of this disclosure. It should be understood that each block in the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to create a machine such that these instructions, executable via the processor of the computer or other programmable data processing apparatus, enable the implementation of the functions / actions specified in one or more blocks of the flowchart illustrations and / or block diagrams. Such a processor can be, but is not limited to, a general-purpose processor, a special-purpose processor, a special application processor, or a field-programmable logic circuit. It is also understood that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can also be implemented by special-purpose hardware performing the specified functions or actions, or can be implemented by a combination of special-purpose hardware and computer instructions.

[0227] The above are merely specific embodiments of this application. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, modules, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here. It should be understood that the protection scope of this application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in this application, and these modifications or substitutions should all be covered within the protection scope of this application.

Claims

1. A vehicle diagnostic method, characterized in that, The method includes: Obtain multiple diagnostic items for the vehicle; An initial diagnostic sequence for the vehicle is determined based on a first association relationship among the plurality of diagnostic items; the initial diagnostic sequence includes the plurality of diagnostic items and the diagnostic order corresponding to each of the plurality of diagnostic items, and the first association relationship is determined based on a predefined dependency relationship between vehicle components; The multiple diagnostic items are input into a reinforcement learning model, and the reinforcement learning model learns the second association relationship between the multiple diagnostic items to obtain the association degree between the multiple diagnostic items. The initial diagnostic sequence is adjusted based on the correlation to obtain the target diagnostic sequence for the vehicle; the target diagnostic sequence includes at least some of the multiple diagnostic items, and the diagnostic order corresponding to each of the at least some diagnostic items. The vehicle is diagnosed using the target diagnostic sequence.

2. The method according to claim 1, characterized in that, The initial diagnostic sequence includes an initial diagnostic item and a termination diagnostic item; The step of adjusting the initial diagnostic sequence according to the correlation to obtain the target diagnostic sequence for the vehicle includes: The initial diagnostic sequence is modeled as a weighted directed graph; wherein, a node of the weighted directed graph corresponds to a diagnostic item in the initial diagnostic sequence, and the transition cost between nodes in the weighted directed graph is used as the edge weight of the weighted directed graph. The transition cost is determined based on the diagnostic time of the diagnostic item, the resource consumption of the diagnostic item, and the correlation degree. Based on the weighted directed graph, determine the set of diagnostic steps, the transition cost matrix, the identifier of the initial diagnostic item, and the identifier of the termination diagnostic item for the initial diagnostic sequence; The target diagnostic sequence is determined based on the set of diagnostic steps, the transition cost matrix, the identifier of the initial diagnostic item, and the identifier of the termination diagnostic item.

3. The method according to claim 2, characterized in that, Determining the target diagnostic sequence based on the diagnostic step set, the transition cost matrix, the identifier of the initial diagnostic item, and the identifier of the termination diagnostic item includes: The set of diagnostic steps, the transition cost matrix, the identifier of the initial diagnostic item, and the identifier of the termination diagnostic item are input into the optimization model. The shortest path tree is constructed through the optimization model to obtain the target diagnostic sequence. The shortest path tree is the set of optimal paths from the initial diagnostic item to the termination diagnostic item. The optimization objective of the optimization model includes at least one of minimizing the total diagnostic time and maximizing the diagnostic accuracy.

4. The method according to claim 1, characterized in that, The target diagnostic sequence includes diagnostic items to be upgraded and confirmed; The process of diagnosing the vehicle using the target diagnostic sequence includes: Based on the diagnostic items to be upgraded, obtain the hardware identifiers of each electronic control unit of the vehicle, as well as the current software version information of each electronic control unit; Based on the hardware identifier and the current software version information, the electronic control unit to be upgraded is determined; Based on the baseline version of the electronic control unit to be upgraded and the current software version information of the electronic control unit to be upgraded, the version deviation warning value of the electronic control unit to be upgraded is determined; If the version deviation warning value is greater than or equal to a preset threshold, the electronic control unit to be upgraded will be reloaded. In the event of overload failure, the electronic control unit to be upgraded is upgraded based on the upgrade package corresponding to the electronic control unit to be upgraded, and an upgraded electronic control unit is obtained.

5. The method according to claim 4, characterized in that, The step of determining the version deviation warning value of the electronic control unit to be upgraded based on the baseline version corresponding to the electronic control unit to be upgraded and the current software version information of the electronic control unit to be upgraded includes: Based on the baseline version, determine the version number difference between the current software version information and the baseline version; Based on the functional safety level of the electronic control unit to be upgraded and the historical fault information of the electronic control unit, determine the degree of impact of the electronic control unit to be upgraded on the safe driving of the vehicle. Based on the degree of impact, the version number difference value is weighted and calculated to obtain the version deviation warning value of the electronic control unit.

6. The method according to claim 1 or 4, characterized in that, The process of diagnosing the vehicle using the target diagnostic sequence includes: Execute each diagnostic item sequentially according to the target diagnostic sequence; During execution, obtain the execution results of the currently executing diagnostic items; If the execution result of the currently executed diagnostic item does not match the preset result, a secondary calibration diagnostic item is generated and added to the target diagnostic sequence to obtain an adjusted target diagnostic sequence; the execution priority of the secondary calibration diagnostic item is the highest priority of the adjusted target diagnostic sequence. The process involves executing the adjusted target diagnostic sequence, and if the result of the currently executed diagnostic item does not match the preset result, returning to the step of generating a secondary calibration diagnostic item and adding the secondary calibration diagnostic item to the target diagnostic sequence to obtain the adjusted target diagnostic sequence, until the adjusted target diagnostic sequence is completed.

7. The method according to claim 1, characterized in that, The process of diagnosing the vehicle using the target diagnostic sequence includes: In response to a user's request to execute the target diagnostic sequence, the vehicle is diagnosed using the target diagnostic sequence, and a first interface is displayed on the vehicle's display device. The first interface includes multiple display areas, one of which is used to display the real-time execution status of a diagnostic item in the target diagnostic sequence. In response to the user's request to view the diagnostic item, a second interface is displayed on the display device. The second interface is used to display the diagnostic parameters of the diagnostic item by the diagnostic application associated with the diagnostic item.

8. An electronic device, characterized in that, The device includes: a processor and a memory storing computer program instructions; When the processor executes the computer program instructions, it implements the vehicle diagnostic method as described in any one of claims 1-7.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer program instructions that, when executed by a processor, implement the vehicle diagnostic method as described in any one of claims 1-7.

10. A vehicle, characterized in that, Includes at least one of the following: The electronic device as claimed in claim 8; The computer-readable storage medium as described in claim 9.

Images