Automobile troubleshooting method, device and computer readable storage medium

Abstract

Embodiments of the present application provide a vehicle troubleshooting method, device and computer readable storage medium. The vehicle troubleshooting method comprises: in response to a fault diagnosis request, scanning data information of a target vehicle; obtaining identity information of an operator; determining and displaying fault information of the target vehicle based on the data information, the fault information comprising at least one fault type; displaying a current operation step according to the target fault type; and displaying a next operation step in the case that the current operation step is completed, the next operation step being determined according to the identity information of the operator and an operation intention of the current operation step. Embodiments of the present application recommend an operation step that is suitable for the level of the operator, so that a novice operator can obtain sufficient guidance and recommendation, a senior operator can obtain a recommended step that matches his experience, redundancy interference is reduced, the applicability of the system is improved, and the system is more widely applied and promoted.

Description

Technical Field

[0001] This application relates to the field of automotive intelligent diagnostic technology, and in particular to a method, apparatus and computer-readable storage medium for troubleshooting automotive faults. Background Technology

[0002] Automotive intelligent fault diagnosis technology has long been driven by vehicle-side data. Existing systems mainly rely on fault codes, real-time data streams, and component operating parameters to establish a fixed mapping relationship from fault characteristics to standardized repair manuals, which is essentially a "vehicle-centric" technical approach.

[0003] In recent years, some companies have tried to introduce intent recognition technology, which relies on the fault description text spoken or entered by car owners and uses natural language processing (NLP) technology to realize the automatic classification and intelligent dispatch of repair orders. The service scenario is limited to the front-end customer service triage process and does not touch the actual fault diagnosis process of maintenance operators.

[0004] The aforementioned existing technologies have the following drawbacks: the diagnostic process is completely fixed in the standard maintenance manual, failing to capture and reuse the implicit diagnostic experience and flexible troubleshooting strategies developed by experienced operators in actual operation; and it pushes a completely uniform standardized process to operators of different skill levels, failing to achieve hierarchical and personalized human-machine collaborative assistance. For experienced operators, the efficiency is too low. Summary of the Invention

[0005] This application provides a method, apparatus, and computer-readable storage medium for troubleshooting automobile malfunctions to address the problems existing in related technologies. The technical solution is as follows: In a first aspect, embodiments of this application provide a method for troubleshooting automotive malfunctions, including: In response to a fault diagnosis request, scan the target vehicle's data information; Obtain the operator's identity information; Based on data information, the fault information of the target vehicle is determined and displayed, and the fault information includes at least one type of fault. Based on the target fault type, the current operation step is displayed; and if the current operation step is completed, the next operation step is displayed; the next operation step is determined based on the operator's identity information and the operation intent of the current operation step.

[0006] In one implementation, displaying the next operation step after the current operation step has been completed includes: Determine the operational intent of the current operation step. Operational intent includes intent to troubleshoot components, intent to verify faults, intent to reset and repair, and intent to blindly try and fail. Based on the intent recognition model and the operational intent, determine the next operational step for the operator after the current operational step.

[0007] In one implementation, the intent recognition model is trained through the following steps: Sample information is collected from historical log data, including vehicle information, operation behavior, operation status information, timestamp information, and exclusion result information. Based on sample information, determine the operational intent corresponding to the operational behavior; Construct the trajectory of the operation intent; Evaluate each step in the operational intent trajectory; Construct the optimal set of intent links.

[0008] In one implementation, constructing an operation intent trajectory includes: Based on sample information, the operation behavior is time-series aligned, anomaly filtered, and noise reduced to construct an ordered sequence of operation behavior. Semantically encode operational behaviors to construct an operational behavior graph; Determine the temporal transition frequency, behavior jump relationship, and conditional transition probability between operational behaviors, and construct the operational intent trajectory based on this.

[0009] In one implementation, each step in the operation intent trajectory is evaluated, and the evaluation metrics include: intent success rate, intent accuracy, intent redundancy, intent logic, and intent convergence speed.

[0010] In one implementation, constructing the optimal intent link set includes: Based on the operational intent trajectory, deviation analysis is performed; the deviation analysis includes: intent accuracy index, logical thinking index, operational efficiency index, and breadth of experience coverage. Based on deviation analysis, an operator profile is constructed, which includes at least two levels. Based on the evaluation of the operational intent trajectory, the optimal intent path corresponding to the operator profile is obtained, and each intent in the optimal intent path has a corresponding operational behavior.

[0011] In one implementation, it further includes: Obtain the actual data stream under real operational behavior; Compare the actual operational data flow with the optimal intent path; When the actual operational data flow differs from the operational behavior of the optimal intent link, a quality score is given to the actual operational data flow. If the score of the actual operation data stream exceeds a preset threshold, the intent link corresponding to the actual operation data stream will be updated to the optimal intent link.

[0012] Secondly, embodiments of this application provide an automotive troubleshooting device, comprising: The scanning module is used to scan the data information of the target vehicle in response to a fault diagnosis request; The identity recognition module is used to obtain the operator's identity information; The fault determination module is used to determine and display the fault information of the target vehicle based on data information, including at least one fault type. The operation display module is used to display the current operation steps according to the target fault type; and after the current operation step is completed, it displays the next operation step; the next operation step is determined based on the operator's identity information and the operation intention of the current operation step.

[0013] Thirdly, embodiments of this application provide an electronic device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor to enable the at least one processor to perform the above-described method for troubleshooting automobile malfunctions.

[0014] Fourthly, embodiments of this application provide a computer-readable storage medium that stores computer instructions, which, when executed on a computer, allow the vehicle troubleshooting method in any of the above embodiments to be performed.

[0015] The vehicle troubleshooting method provided in this application recommends operating steps that are appropriate for the operator's skill level. This allows advanced operators to obtain recommended steps that match their experience, reducing redundant interference and improving troubleshooting efficiency. At the same time, novice operators can receive sufficient guidance and recommendations, improving the applicability of the system and facilitating its wider application and promotion.

[0016] The above overview is for illustrative purposes only and is not intended to be limiting in any way. In addition to the illustrative aspects, embodiments, and features described above, further aspects, embodiments, and features of this application will become readily apparent from the accompanying drawings and the following detailed description. Attached Figure Description

[0017] In the accompanying drawings, unless otherwise specified, the same reference numerals throughout the various drawings denote the same or similar parts or elements. These drawings are not necessarily drawn to scale. It should be understood that these drawings depict only some embodiments disclosed in this application and should not be construed as limiting the scope of this application.

[0018] Figure 1 A schematic flowchart of a vehicle troubleshooting method according to an embodiment of this application is shown.

[0019] Figure 2 A schematic flowchart illustrating a training method for an intent recognition model according to an embodiment of this application is shown.

[0020] Figure 3 Show Figure 2 A schematic flowchart of the sub-steps in step S330.

[0021] Figure 4 Show Figure 2 A schematic flowchart of the sub-steps in step S350.

[0022] Figure 5 A schematic flowchart illustrating a vehicle troubleshooting method according to another embodiment of this application is shown.

[0023] Figure 6 A schematic structural block diagram of an automotive troubleshooting device according to an embodiment of this application is shown.

[0024] Figure 7 A schematic structural block diagram of an automotive troubleshooting device according to another embodiment of this application is shown.

[0025] Figure 8 This is a schematic structural block diagram of an electronic device used to implement the vehicle troubleshooting method of the embodiments of this application. Detailed Implementation

[0026] In the following description, only certain exemplary embodiments are briefly described. As those skilled in the art will recognize, the described embodiments can be modified in various ways without departing from the spirit or scope of this application. Therefore, the drawings and description are considered to be exemplary in nature and not restrictive.

[0027] This application provides a method for troubleshooting automotive faults, used to eliminate faults in a target vehicle one by one. Figure 1 A schematic flowchart illustrating a vehicle troubleshooting method according to an embodiment of this application is shown. Figure 1 As shown, this vehicle troubleshooting method may include the following steps: S210, in response to a fault diagnosis request, scans the data information of the target vehicle.

[0028] The target vehicle can be a vehicle with a fault to be diagnosed and requires troubleshooting.

[0029] The operator establishes a communication connection between the device terminal and the target vehicle via the OBD (On-Board Diagnostics) interface. The device terminal can be, for example, a diagnostic device that establishes a communication connection with the target vehicle, or a terminal device installed in the target vehicle that communicates with a diagnostic server.

[0030] A fault diagnosis request can be triggered either when the diagnostic equipment recognizes the establishment of a communication connection, or when the operator clicks "Start Diagnosis" on the diagnostic equipment. In response to the fault diagnosis request, the diagnostic equipment sends data read requests to each electronic control unit (ECU) of the target vehicle via communication protocols such as CAN bus, K-line, or Ethernet, scanning and collecting data information from the target vehicle.

[0031] The data information includes, but is not limited to: Vehicle Identification Number (VIN), software version number and hardware version number of each ECU, fault codes (DTC), freeze frame data, and vehicle network topology.

[0032] S220, obtain the operator's identity information.

[0033] Operators authenticate and log in to the diagnostic equipment. The system obtains a unique identifier for the current operator. This unique identifier is associated with information stored in the database, such as the operator's historical diagnostic records, skill level tags, years of experience, and / or training history.

[0034] S230, based on data information, determines and displays fault information of the target vehicle, the fault information including at least one fault type.

[0035] The system parses and categorizes the vehicle data information obtained in step S210. By querying the local or cloud-based fault code database, the system converts the original fault codes (such as P0301) into readable fault descriptions (such as "Misfire detected in cylinder 1"), and determines whether the fault is a current fault, a historical fault, or a permanent fault based on the fault code's attributes. Furthermore, the system matches the vehicle model year and configuration with the vehicle's VIN code, calls the vehicle's fault tree or fault association graph, and maps all read fault codes to the vehicle's system structure to generate a fault type list.

[0036] Diagnostic equipment can display fault information in categories such as powertrain, chassis system, body electrical, and communication network.

[0037] For example, after parsing the scan results, the system displays them on the diagnostic device screen in the form of a list, such as the following: The following fault was detected: ①P0301: Cylinder 1 misfire (current fault, Class A); ②P0171: Fuel system too lean (current fault, Class B); ③U0121: Communication with ABS controller lost (historical fault, Class C).

[0038] S240: Based on the target fault type, display the current operation steps; and if the current operation steps are completed, display the next operation steps. The next operation steps are determined based on the operator's identity information and the operational intent of the current operation steps.

[0039] Specifically, the operator selects one item from the displayed list of fault types as the target fault type to be processed, for example, clicking to select "P0301 Cylinder 1 misfire".

[0040] Based on the target fault type, the system queries the local cache or the offline optimal strategy library delivered by the cloud, and combines it with the identity information of the current operator. For example, if the operator's level profile is "senior operator", the system filters the optimal intent link that matches the level profile of the operator in the strategy library, and displays the standard operation behavior corresponding to the first intent node in the link as the "current operation step" on the device screen.

[0041] The current operation steps can be presented in a combination of text and images, and may include the operation name (such as "Read the ignition data stream of cylinder 1"), explanation of the purpose of the operation, and precautions for the operation.

[0042] The system continuously monitors the operation log stream of the diagnostic equipment. When the operator completes the current operation step and clicks the "Confirm Completion" button on the device, or when the system detects through the log that the corresponding operation code (such as "04-Data Flow") has been successfully executed, the current operation step is considered complete.

[0043] The system calls the intent recognition model to analyze the intent of the current operation step. Based on the intent, the entire completed operation sequence, and the operator profile, it determines the next intent node according to the recommended intent trajectory. Then, it maps the next intent node to the specific next operation step and displays it on the device screen.

[0044] This process is repeated iteratively until the system determines that the diagnostic intent trajectory has reached the "fault diagnosis ended" state, or the operator manually terminates the diagnostic process.

[0045] In one example, after Mr. Zhang (a senior operator) selects "P0301 Cylinder 1 Misfire" as the target fault type, the system recognizes his senior operator status. Based on the diagnostic intent chain of the corresponding senior operator, the current operation step is displayed as "Perform primary / secondary resistance measurement of cylinder 1 ignition coil". After Mr. Zhang completes the measurement, he clicks "Complete" on the screen. The system, based on the intent of this step as "directional component troubleshooting" and combined with his completed operation sequence, infers that the next intent should be "fault verification", thus displaying the next operation step: "Read the ignition waveform of cylinder 1 and compare it with the normal waveform for analysis".

[0046] The vehicle troubleshooting method provided in this application recommends operating steps that are appropriate for the operator's skill level. This allows advanced operators to obtain recommended steps that match their experience, reducing redundant interference and improving troubleshooting efficiency. At the same time, novice operators can receive sufficient guidance and recommendations, improving the applicability of the system and facilitating its wider application and promotion.

[0047] In one implementation, displaying the next operation step after the current operation step has been completed includes: S241, Determine the operational intent of the current operation step. Operational intent includes directional component troubleshooting intent, fault verification intent, reset and repair intent, and trial-and-error intent. In practical applications, operational intent may include descriptions of components, such as engine component troubleshooting.

[0048] Operational intent can be categorized into the following four types: 1) Targeted component inspection intent: Characterizing targeted testing of a specific system / component. For example: measuring the resistance / voltage of a sensor, performing an action test on a component, or reading data stream parameters of a specific system. The judgment can be based on the fact that continuous operations all point to the same component or system.

[0049] Fault verification intent: This refers to the actions taken by operators to confirm or refute existing fault hypotheses through methods such as reading data streams, performing real vehicle road tests, and conducting replacement tests. Examples include: comparing frozen frames with standard values, clearing fault codes and then conducting road tests to verify whether the fault is reproduced, and performing bridging or short-circuiting tests.

[0050] Reset and Repair Intent: This refers to the operator's attempt to restore the system to its normal operating state at the software level by performing operations such as matching, resetting, programming, and adaptive learning. Examples include: throttle body matching, anti-theft system matching, transmission adaptive reset, and ECU firmware upgrade.

[0051] Blindly trying and failing: This refers to the behavior of operators who, lacking a clear direction for investigation, frequently change the inspection target, repeatedly perform completed inspection items, or replace parts without justification. The criteria for judgment include frequent changes in the operation target (e.g., inspecting 3 unrelated systems within 5 steps), repeating the operation more than twice within 30 minutes, and violating the basic logic of operating from the outside in.

[0052] S242, based on the intent recognition model and the operation intent, determine the next operation step for the operator after the current operation step.

[0053] The system inputs the operation intent label of the current operation step obtained in step S241 into the intent recognition model, determines the next intent label based on the intent recognition model, and maps the next intent label to the corresponding specific operation action in the standard operation behavior library, which is the next operation step.

[0054] In one example, when Mr. Zhang is troubleshooting, his current operation step is "reading the ignition waveform of cylinder 1," with the intent being "fault verification intent." Based on the intent recognition model, the system determines that the next intent with the highest transition probability (P=0.62) from "fault verification intent" is "directional troubleshooting intent (ignition system)," and the second highest (P=0.23) is "reset and repair intent." Combining Mr. Zhang's advanced operator profile, the system determines that in the P0301 misfire scenario, the optimal intent path after "fault verification" should be "directional troubleshooting (compression pressure)." Simultaneously, the system recognizes that Mr. Zhang has already performed ignition coil resistance measurement and ignition waveform reading, and the marginal benefit of continuing to troubleshoot the ignition system is reduced. Therefore, the next intent is determined to be "directional troubleshooting (cylinder compression pressure detection)," and mapped to the next operation step "perform cylinder 1 compression pressure test (standard value ≥10 bar; if below the standard, check valves / piston rings)" displayed on the screen. If the current operator is a novice operator, after the current operation step of "reading the ignition waveform of cylinder 1" is completed, the next operation step displayed by the system is ignition system troubleshooting. After this step is completed, the next operation step displayed is "perform cylinder 1 compression pressure test (standard value ≥10 bar, if it is lower than the standard, please check the valve / piston ring)".

[0055] In one implementation, such as Figure 2 As shown, the intent recognition model is trained through the following steps: S310 collects sample information from historical log data. Sample information includes vehicle information, operational behavior, operational status information, timestamp information, and exclusion result information.

[0056] Historical log data can be obtained from the repair station's backend database, for example, all repair log records from the past 36 months, as a sample data source. Each log record can contain the following fields: repair station ID, operator ID, vehicle VIN code, vehicle mileage, year of manufacture, model code, fault code list, timestamp of each operation (accurate to the second), operation code (e.g., 01-read code, 02-clear code, 03-read freeze frame, 04-data stream, 05-action test, 06-match reset, 07-programming code, 08-hardware disassembly and inspection, 09-road test verification, etc.), single-step operation execution status (success / failure / interruption), and final repair result (successfully repaired / not repaired / returned for repair).

[0057] This application's embodiments ensure the diversity and representativeness of training samples through large-scale, long-term historical log data collection, covering a wide range of scenarios involving different vehicle models, seasons, and operator skill levels, thus providing a data foundation for the generalization ability of the subsequent intent recognition model. Furthermore, using real maintenance logs as samples, rather than experimental data, guarantees the authenticity and engineering applicability of the model training data.

[0058] S320, based on sample information, determines the operational intent corresponding to the operational behavior.

[0059] For each operation step in each sample in step S310, manual annotation or automatic identification annotation is performed to determine its corresponding operation intention label.

[0060] An exemplary annotation method can be as follows: For each operation step, combined with the context of the two steps before and after it, the target component, the operation time, and the final repair result, senior technical experts can annotate it according to the four types of operation intentions mentioned above (targeted component troubleshooting, fault verification, reset repair, and blind trial and error); or the operation intention can be inferred and identified based on the attributes of the operation steps.

[0061] By annotating operation intent, the original operation code is transformed into operation intent labels with semantic information, enabling machine learning models to learn "what kind of operation mode corresponds to what kind of diagnostic thinking". This elevates behavioral data to thinking data, providing a label foundation for supervised learning of intent recognition.

[0062] S330, construct the operation intent trajectory.

[0063] The intent tags corresponding to all operation steps in each maintenance work order are arranged in chronological order (the order in which they are executed) to form an ordered sequence of intent tags, i.e., the operation intent trajectory.

[0064] Each intent trajectory can be represented as a vector T = [intent1, intent2, ..., intent...].n ], where n is the total number of operation steps recorded in the operation log. All operation intent trajectories under all the same fault codes (such as P0301) are classified into a trajectory set for that fault scenario.

[0065] In one example, among multiple operation intent trajectories of the same fault type, some operation intent trajectories may have about 10 steps, some may have about 10 to 50 steps, and some may have about 60 steps, etc. Based on the number of steps, multiple operation intent trajectories can be distinguished into novice operation intent trajectories, intermediate operator operation intent trajectories, and advanced operator operation intent trajectories.

[0066] In another example, classifying multiple operational intent trajectories by level is not entirely based on the number of operational steps. It can also be based on a comprehensive classification of diagnostic thinking convergence speed and the rationality of operational jumps within the operational steps.

[0067] S340 evaluates each step in the operational intent trajectory.

[0068] For each level of multiple operation intent trajectories, each step of each operation intent trajectory is evaluated. Based on the evaluation results, multiple operation trajectories of the same level can be integrated into an optimal operation intent trajectory.

[0069] S350, construct the optimal set of intent links.

[0070] It is worth noting that the optimal operation intention trajectory is not a fixed and completely unchanging operation intention trajectory, but is obtained in real time by selecting the best (highest score) from multiple quantitative indicators of the operation intention node.

[0071] Specifically, among all historical operational intent trajectories, a five-dimensional scoring vector is used as the multi-objective fitness function for optimization. A multi-objective particle swarm optimization (MOPSO) algorithm is employed for global optimization. For each high-frequency fault scenario (such as the Top 20 fault codes), an optimal intent link set is output, with approximately 5 to 10 links per scenario. These optimal intent links provide a thought path template for diagnosis under that fault scenario.

[0072] In one example, for the P0301 fault, one of the optimal intent paths obtained after MOPSO optimization is: [Fault verification (code reading confirmation) → Targeted troubleshooting (ignition system component detection) → Fault verification (data stream comparison) → Reset repair (perform ignition compensation learning) → Fault verification (road test verification)]. Mapped to an operation sequence, this is: [01-Code reading → 05-Action test (ignition coil) → 04-Data stream (ignition waveform analysis) → 06-Matching reset (engine) → 09-Road test]. This path is stored in the offline strategy library as one of the recommended paths in the P0301 scenario.

[0073] This application embodiment trains based on the operator's historical operational intentions as sample data, outputs the optimal intention link, and transforms the implicit experience of senior operators into a reusable standardized knowledge base, overcoming the limitation of traditional maintenance manuals that rely solely on theoretical logic.

[0074] In one implementation, such as Figure 3 As shown, step S330 includes: S331, based on sample information, performs time-series alignment, anomaly filtering, and noise reduction on the operation behavior to construct an ordered sequence of operation behavior.

[0075] Perform data preprocessing on historical log data.

[0076] Time sequence alignment: Each operation record is arranged in time sequence based on its timestamp to ensure time sequence consistency.

[0077] Anomaly Filtering: Remove records with obvious anomalies, including invalid records whose operation codes are not in the predefined coding table (01~09), records whose operation time exceeds a reasonable range (e.g., single-step operation <1 second is considered a mis-touch, >1 hour is considered a suspension interruption), and work orders whose operation timestamps span multiple days (more than 24 hours) are considered interrupted work orders and are removed.

[0078] Noise reduction: A sliding window (window size = 3) is used to detect transient isolated operations. If an operation has no contextual relationship within two steps before and after it (such as a sudden "programming code" operation but before and after it are "read code" operations), it is judged as a noise point and removed.

[0079] By using time alignment, anomaly filtering, and noise reduction, the original irregular and noisy log data is transformed into a clean, ordered, and consistent structured sequence, ensuring the quality of the input data for subsequent intent recognition models.

[0080] S332, semantically encodes operational behaviors to construct an operational behavior graph.

[0081] For the multiple preprocessed sequences of operational behaviors, each behavior is semantically encoded to construct an operational behavior graph. The operational behavior graph records the temporal transition frequency and conditional transition probability between each behavior. Simultaneously, the operational behavior graph provides structured prior knowledge for diagnostic reasoning, supporting intent path search and rationality checks based on graph traversal.

[0082] S333, determine the temporal transition frequency, behavior jump relationship and conditional transition probability between operation behaviors, and construct the operation intention trajectory based on this.

[0083] Specifically, based on the operation behavior map constructed in step S332, the temporal transition frequency between any two adjacent operations in all samples is statistically obtained. For each predecessor operation opᵢ, the occurrence frequency of its successor operation opⱼ is counted, and divided by the total occurrence frequency of opᵢ to obtain the operation-level conditional transition probability P(opⱼ | opᵢ).

[0084] Simultaneously, behavioral jump relationships are analyzed: if a work order contains a jump from opᵢ to opⱼ, but the probability of this jump in the global statistics is less than 1% and the two operations have no semantic connection in the knowledge graph (e.g., "02-Clear Code" immediately jumps to "07-Programming Code"), it is marked as an "abnormal jump" and deducted points in the logical scoring. Based on this, the operation encoding sequence of each work order is combined with the operation-level transition probability matrix to decode the intent label sequence corresponding to the highest probability, thus converting the operation sequence into an operation intent trajectory. At the same time, the transition frequency and conditional transition probability between any two intent nodes in the operation intent trajectory are recorded as the basic probability data for subsequent intent evolution reasoning.

[0085] In one implementation, in step S340, the evaluation metrics include: intent success rate, intent accuracy, intent redundancy, intent logic, and intent convergence speed.

[0086] 1) Intent Success Rate: In this type of fault scenario, among maintenance work orders that use the same or highly similar troubleshooting path as the intent trajectory, the percentage of work orders that ultimately result in "repair success". The calculation method is as follows: First, cluster similar trajectories based on the edit distance of the intent trajectory, then group them together, and finally count the number of successful work orders within that group divided by the total number of work orders. A higher success rate indicates that the diagnostic path is more effective in actual production.

[0087] For example, under the P0301 fault, an intent trajectory is [fault verification → targeted troubleshooting → reset repair → fault verification]. Among all 246 work orders that use this similar path, 218 were eventually successfully repaired. Therefore, the intent success rate of this trajectory is 218 / 246 = 88.6%.

[0088] 2) Intended Accuracy: The Jaccard Similarity coefficient between the set of components actually detected by the operator and the set of truly faulty components in this trajectory. The formula is J = |A∩B| / |A∪B|, where A is the set of detected components (extracted from the operation object field), and B is the set of replaced / repaired components in the final maintenance settlement document. Higher accuracy indicates that the operator's detection scope is more focused on the actual fault point, with fewer invalid detections.

[0089] For example, in a certain trajectory, three components {ignition coil, spark plug, fuel injector} were detected, and the ignition coil was ultimately identified as faulty. The actual fault set is {ignition coil}. Then, J = |{ignition coil}| / |{ignition coil, spark plug, fuel injector}| = 1 / 3 ≈ 0.33. This trajectory has low accuracy, indicating that the detection range includes non-faulty components.

[0090] 3) Intent Redundancy: Defined as the proportion of the number of times the same operation (same operation code and applied to the same component) is repeatedly executed within a 30-minute time window, out of the total number of operations in the work order. The calculation formula is Redundancy = (∑Number of Repeated Operations) / Total Number of Operations, where the repetition determination condition is: the same operator in the same vehicle, performing the same operation type on the same component again within 30 minutes. The higher the redundancy, the more ineffective trial and error and repetitive work there is.

[0091] For example, if a work order has a total of 10 operations, and the operator measures the resistance of the ignition coil of cylinder 1 at 9:00 and measures the same parameter of the same component again at 9:20, then the count of this repeated operation is 2, and the redundancy is 2 / 10 = 0.20.

[0092] 4) Intent Logicality: A Bayesian network-based score for the reasonableness of the investigation sequence. A three-layer Bayesian network is constructed with "fault phenomenon → possible cause → detection operation" as its structure. The prior probabilities of each possible cause are obtained based on historical statistical data (e.g., in fault P0301, the prior probability of the ignition system fault is 55%, the fuel system is 25%, and the mechanical system is 20%). For a given intent trajectory, the current posterior probability ranking of the fault hypothesis corresponding to each detection step is checked sequentially: if the operator prioritizes the hypothesis with the highest posterior probability, full marks are awarded; the later the detected hypothesis is ranked, the lower the reasonableness score of the sequence. The final logicality score is normalized to a range of 0-100. For example, in scenario P0301, the ignition system has the highest prior probability (55%), followed by the fuel system (25%). An operator first checked the fuel injector (fuel system, ranked 2nd) and then checked the ignition coil (ignition system, ranked 1st), violating the principle of "high probability before low probability". The logic score was 65 points.

[0093] 5) Intended convergence speed: Defined as the number of operation steps from the first operation of the work order until the first execution of the detection item that directly hits the actual faulty component. The faster the convergence speed (the fewer the steps), the sooner the operator can identify the direction for troubleshooting.

[0094] For example, if the operation sequence for a certain trajectory is [read code → read data stream (oxygen sensor) → read data stream (ignition) → action test (ignition coil)], the actual faulty component is the ignition coil, and the first hit point is step 3 "read data stream (ignition)" (this operation allows observation of ignition abnormalities), then the convergence speed = 3. If step 1 "read code" directly points to P0301 and the operator immediately checks the ignition coil, then the convergence speed = 1.

[0095] Based on this, the system weights and sums the five-dimensional scores to obtain a comprehensive quality score Q for each trajectory. For example, the weights can be configured as follows: Q = 0.3 × success rate + 0.25 × accuracy + 0.2 × (1 - redundancy) + 0.15 × (logic / 100) + 0.1 × (1 / convergence speed × normalization factor K), where K is a constant that normalizes (1 / convergence speed) to [0,1] (e.g., taking the reciprocal of the maximum convergence speed of 10, which is 0.1). The system supports custom adjustments of the weights based on the maintenance station management preferences.

[0096] For example, the five-dimensional scores of a P0301 trajectory are as follows: success rate 0.88, accuracy 0.33, redundancy 0.20, logicality 65, and convergence speed 3. The overall quality score Q = 0.3 × 0.88 + 0.25 × 0.33 + 0.2 × 0.80 + 0.15 × 0.65 + 0.1 × (1 / 3 × 0.1) = 0.264 + 0.0825 + 0.16 + 0.0975 + 0.0033 ≈ 0.607.

[0097] This application's embodiments transform qualitative diagnostic levels into quantitative rankings through comprehensive quality scoring, providing a unified metric for subsequent path optimization, operator profiling, and quality assessment.

[0098] In one implementation, such as Figure 4 As shown, step S350 includes: S351, based on the operational intent trajectory, performs deviation analysis. Deviation analysis includes: intent accuracy index, logical thinking index, operational efficiency index, and breadth of experience coverage.

[0099] Specifically, for all historical intent trajectories under a specific repair station or operator ID, using the globally optimal trajectory for that fault scenario, the deviation between each trajectory for each operator in the historical log data and the optimal trajectory is calculated. The deviation analysis consists of four dimensions: 1) Intent Precision Index: The arithmetic mean of intent precision (Jaccard similarity) across all of the operator's historical trajectories. A higher precision index indicates that the operator is more focused on the correct operational steps when detecting targets in daily diagnostics.

[0100] 2) Logical Thinking Index: Calculate the edit distance (Levenshtein distance) between each trajectory of the operator and the globally optimal intention trajectory. Normalize the edit distance, take the reciprocal, and then average. The smaller the edit distance, the closer the operator's diagnostic sequence is to the optimal logic. Specifically, the calculation is: Logical Matching Degree = 1 / (1 + Average Edit Distance). Normalized to the [0,1] interval.

[0101] 3) Operational Efficiency Index: This index calculates the average number of steps an operator takes to handle a single fault, as well as the average repair time (the time difference between the first and last steps). Using the median of all operators in this fault scenario as a benchmark, the relative efficiency is calculated as follows: Efficiency Index = (Benchmark Average Steps / Operator's Average Steps) × (Benchmark Average Time / Operator's Average Time). An index greater than 1 indicates efficiency above average.

[0102] 4) Breadth of experience coverage: Calculate the number of duplicates of different fault types (grouped by the first three DTCs, e.g., P03x for ignition faults) successfully handled by the operator over a past period (e.g., 12 months). The more types covered, the more experienced the operator is.

[0103] For example, operator Zhang (ID=GZ20241001) has an average accuracy of 0.78 and an average edit distance of 2.3 for his 8 historical tracks on fault P0301 (based on the optimal track). Therefore, his accuracy index is 0.78 and his logic index is 1 / (1+2.3)=0.303. His average number of operation steps is 5.0, while the median is 7.2. His average time is 18 minutes, while the median is 25 minutes. Therefore, his efficiency index is (7.2 / 5.0)×(25 / 18)=1.0×1.39=1.39. He has handled four types of faults, P0301, P0302, P0171, and P0420, in the past 12 months, giving him an experience coverage breadth of 4.

[0104] Deviation analysis transforms operators' diagnostic behavior from "subjective feelings of good or bad" into four quantifiable and comparable numerical indicators. This allows operator competence assessment to move away from management's subjective impressions and instead be based on objective data for precise measurement, providing a scientific basis for subsequent personalized strategy adaptation.

[0105] S352, Based on deviation analysis, construct operator profiles. Operator profiles include at least two levels.

[0106] Specifically, the four-dimensional indices calculated in step S351 are used as feature vectors to perform unsupervised clustering analysis on all operators. The K-Means algorithm (K=3) is used to divide operators into three levels: novice operators, intermediate operators, and advanced operators. After clustering, each level corresponds to a set of feature center values: Novice operators (cluster center characteristics: accuracy index <0.5, logic index <0.4, efficiency index <0.8, coverage breadth <5): are characterized by scattered detection targets, skipped troubleshooting order, long operation time, and fewer types of faults handled.

[0107] Intermediate operators (cluster center characteristics: 0.5≤accuracy index<0.75, 0.4≤logic index<0.7, 0.8≤efficiency index<1.2, 5≤coverage breadth<15): They demonstrate a certain ability to focus their investigations, their order is generally reasonable, and their efficiency is at the industry average level.

[0108] Senior operators (cluster center characteristics: accuracy index ≥ 0.75, logic index ≥ 0.7, efficiency index ≥ 1.2, coverage breadth ≥ 15): characterized by high focus on detection targets, high consistency between the sequence and the optimal trajectory, significantly higher efficiency than average, and rich experience.

[0109] The system assigns a corresponding level tag to each operator ID and stores it in the operator profile database. This level tag is dynamically updated as new operator data is generated (e.g., recalculated monthly), enabling continuous advancement of the operator profile.

[0110] For example, Mr. Zhang's feature vector is [0.78, 0.303, 1.39, 4]. According to K-Means clustering, although its accuracy and efficiency are high, its logicality index is low and its coverage is only 4. Therefore, he is classified as "intermediate operator".

[0111] By using data-driven unsupervised clustering to classify operators into different levels, the subjectivity and arbitrariness of manual classification are avoided, and the profiles can be dynamically updated as operators grow, achieving accurate stratification of personnel capabilities.

[0112] S353, based on the evaluation of the operational intent trajectory, obtain the optimal intent path corresponding to the operator profile. Each intent in the optimal intent path has a corresponding operational behavior.

[0113] For multiple operational intent trajectories, based on the evaluation of each trajectory, it is mapped to an operator profile, such that each trajectory corresponds to a specific operator profile level. In other words, multiple operational intent trajectories are categorized according to the corresponding operator level. This allows the intent recognition model to output the optimal intent path for an intermediate-level operator.

[0114] In one implementation, such as Figure 5 As shown, car troubleshooting methods also include: S250 obtains the actual data stream under actual operational behavior.

[0115] Specifically, during the maintenance and diagnostic process, the diagnostic equipment records the operation log in real time as the operator performs each step of the operation. This real data stream includes: the actual operation performed, the operation timestamp, the operation object, the operation result (success / failure), and the operation time.

[0116] S260 compares the actual operational data flow with the optimal intent path.

[0117] The system compares the actual sequence of operations performed by the operator (real operation data flow) with the recommended optimal intent path for the fault scenario and the operator's level step by step.

[0118] S270, when the actual operation data stream differs from the operation behavior of the optimal intent link, a quality score is given to the actual operation data stream.

[0119] When a deviation is detected between the actual operation behavior and the optimal intent link, and the final repair result is successful, the system scores the actual operation data stream and determines which is better, the actual operation data stream or the optimal intent link.

[0120] Furthermore, while scoring the quality of the actual operational data stream, the system can also determine whether the operator is eligible for a promotion based on the score.

[0121] S280, if the score of the actual operation data stream exceeds a preset threshold, update the intent link corresponding to the actual operation data stream to the optimal intent link.

[0122] For example, if the quality score of the actual operation data stream is ≥85 points and the final result of the repair is "successful", the system determines that the actual path is an "excellent new path" and is eligible for inclusion in the database. At this time, the system converts the actual operation sequence into its corresponding intent trajectory and adds it to the offline policy library for this fault scenario as a new candidate for optimal intent link. Simultaneously, during the next global offline optimization, the system incorporates this new trajectory into the initial population of particle swarm optimization, achieving dynamic updates of the optimal intent link.

[0123] In one example, a reward function can also be calculated, and based on the reward function, it can be determined whether to update to the optimal intent path.

[0124] The reward function can be: R = α × diagnostic accuracy + β × operation step saving rate + γ × operator adoption rate - δ × rework rate (α, β, γ, δ are dynamic weights).

[0125] In this embodiment, when the system detects that the recommended path is frequently skipped by operators or that the actual success rate of the recommended path is lower than the offline expectation, it triggers path fine-tuning to achieve continuous evolution of the diagnostic strategy. Simultaneously, newly discovered optimal paths can feed back into the offline strategy library, forming a positive iterative closed loop of "offline batch optimization → online real-time fine-tuning → high-quality paths returning to the library," thus addressing the pain point of traditional systems becoming fixed upon deployment.

[0126] It should be noted that in the vehicle troubleshooting method provided in this application, the next operation step is obtained based on an intent recognition model. This next operation step is dynamic, not fixed. The strategy library, corresponding to specific fault types and operator levels, does not retain a single optimal intent chain, but rather multiple optimal intent chains. Each next intent node with a temporal connection in these multiple optimal intent chains has a corresponding score. The system selects the next intent node with the highest score from among these multiple next intent nodes based on the current operation step. Therefore, if the recommended current operation step is not adopted, a recommendation will be made based on the operator's actual operational intent for the current operation step.

[0127] This application also provides a vehicle troubleshooting device. Figure 6 This diagram illustrates a structural block diagram of an automotive troubleshooting device 600 according to an embodiment of this application. Figure 6 As shown, the vehicle troubleshooting device 600 may include: The scanning module 610 is used to scan the data information of the target vehicle in response to a fault diagnosis request; The identity recognition module 620 is used to obtain the operator's identity information; The fault determination module 630 is used to determine and display the fault information of the target vehicle based on data information, including at least one fault type. The operation display module 640 is used to display the current operation steps according to the target fault type; and to display the next operation step after the current operation step is completed; the next operation step is determined according to the operator's identity information and the operation intention of the current operation step.

[0128] In one implementation, the operation display module 640 is used for: Determine the operational intent of the current operation step. Operational intent includes intent to troubleshoot components, intent to verify faults, intent to reset and repair, and intent to blindly try and fail. Based on the intent recognition model and the operational intent, determine the next operational step for the operator after the current operational step.

[0129] In one implementation, the intent recognition model is trained through the following steps: Sample information is collected from historical log data, including vehicle information, operation behavior, operation status information, timestamp information, and exclusion result information. Based on sample information, determine the operational intent corresponding to the operational behavior; Construct the trajectory of the user's intention; Evaluate each step in the operational intent trajectory; Construct the optimal set of intent links.

[0130] In one implementation, constructing an operation intent trajectory includes: Based on sample information, the operation behavior is time-series aligned, anomaly filtered, and noise reduced to construct an ordered sequence of operation behavior. Semantically encode operational behaviors to construct an operational behavior graph; Determine the temporal transition frequency, behavior jump relationship, and conditional transition probability between operational behaviors, and construct the operational intent trajectory based on this.

[0131] In one implementation, each step in the operation intent trajectory is evaluated, and the evaluation metrics include: intent success rate, intent accuracy, intent redundancy, intent logic, and intent convergence speed.

[0132] In one implementation, constructing the optimal intent link set includes: Based on the operational intent trajectory, deviation analysis is performed; the deviation analysis includes: intent accuracy index, logical thinking index, operational efficiency index, and breadth of experience coverage. Based on deviation analysis, an operator profile is constructed, which includes at least two levels. Based on the evaluation of the operational intent trajectory, the optimal intent path corresponding to the operator profile is obtained, and each intent in the optimal intent path has a corresponding operational behavior.

[0133] In one implementation, such as Figure 7 As shown, the vehicle troubleshooting device also includes: The Real Log Module 650 is used to obtain the real data stream under real operation behavior; The comparison module 660 is used to compare the actual operation data stream with the optimal intent link; The scoring module 670 is used to score the quality of the real operation data stream when the operation behavior of the real operation data stream differs from that of the optimal intent link. The update module 680 is used to update the intent link corresponding to the real operation data stream to the optimal intent link when the score of the real operation data stream exceeds a preset threshold.

[0134] The functions of each module in each device of the application embodiments can be found in the corresponding descriptions in the above methods, and will not be repeated here.

[0135] Figure 8 A structural block diagram of an electronic device according to an embodiment of this application is shown. Figure 8 As shown, the electronic device includes a memory 910 and a processor 920. The memory 910 stores instructions that can be executed on the processor 920. When the processor 920 executes the instructions, it implements the vehicle troubleshooting method in the above embodiments. The number of memories 910 and processors 920 can be one or more. This electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely examples and are not intended to limit the implementation of the present application described and / or claimed herein.

[0136] The electronic device may also include a communication interface 930 for communicating with external devices and exchanging data. The devices are interconnected using different buses and can be mounted on a common motherboard or otherwise as needed. The processor 920 can process instructions executed within the electronic device, including instructions stored in or on memory to display graphical information of a GUI on an external input / output device (such as a display device coupled to the interface). In other embodiments, multiple processors and / or multiple buses can be used with multiple memories and multiple memory modules, if desired. Similarly, multiple electronic devices can be connected, each providing some of the necessary operations (e.g., as a server array, a group of blade servers, or a multiprocessor system). The bus can be divided into address buses, data buses, control buses, etc. For ease of illustration, Figure 8 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0137] Optionally, in a specific implementation, if the memory 910, processor 920, and communication interface 930 are integrated on a single chip, then the memory 910, processor 920, and communication interface 930 can communicate with each other through an internal interface.

[0138] It should be understood that the aforementioned processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. General-purpose processors can be microprocessors or any conventional processor. It is worth noting that the processor can be a processor supporting the Advanced Reduced Instruction Set Computing (RISC) machine (ARM) architecture.

[0139] This application provides a computer-readable storage medium (such as the memory 910 described above) that stores computer instructions, which, when executed by a processor, implement the method provided in this application.

[0140] Optionally, the memory 910 may include a program storage area and a data storage area, wherein the program storage area may store the operating system and applications required for at least one function; the data storage area may store data created by the use of the electronic equipment in the vehicle troubleshooting method, etc. Furthermore, the memory 910 may include high-speed random access memory and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, the memory 910 may optionally include memory remotely located relative to the processor 920, and these remote memories can be connected to the electronic equipment of the vehicle troubleshooting method via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0141] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of this application. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of those different embodiments or examples.

[0142] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this application, "a plurality of" means two or more, unless otherwise explicitly specified.

[0143] Any process or method description in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or more (two or more) executable instructions for implementing a particular logical function or process. Furthermore, the scope of the preferred embodiments of this application includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functionality involved.

[0144] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus or device (such as a computer-based system, a processor-included system or other system that can fetch and execute instructions from, an instruction execution system, apparatus or device).

[0145] It should be understood that various parts of this application can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented using software or firmware stored in memory and executed by a suitable instruction execution system. All or part of the steps of the methods in the above embodiments can be implemented by a program instructing related hardware, the program being stored in a computer-readable storage medium, which, when executed, includes one or a combination of the steps of the method embodiments.

[0146] Furthermore, the functional units in the various embodiments of this application can be integrated into a single processing module, or each unit can exist physically separately, or two or more units can be integrated into a single module. The integrated module can be implemented in hardware or as a software functional module. If the integrated module is implemented as a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium. This storage medium can be a read-only memory, a disk, or an optical disk, etc.

[0147] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any person skilled in the art can easily conceive of various variations or substitutions within the technical scope disclosed in this application, and these should all be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for troubleshooting automotive malfunctions, characterized in that, include: In response to a fault diagnosis request, scan the target vehicle's data information; Obtain the operator's identity information; Based on the data information, the fault information of the target vehicle is determined and displayed, and the fault information includes at least one fault type; Based on the target fault type, display the current operation steps; And if the current operation step is completed, the next operation step will be displayed; The next operation step is determined based on the operator's identity information and the operation intent of the current operation step.

2. The method according to claim 1, characterized in that, The step of displaying the next operation step after the current operation step is completed includes: Determine the operational intent of the current operation step, which includes the intent to conduct targeted component troubleshooting, the intent to verify faults, the intent to reset and repair, and the intent to blindly try and fail. Based on the intent recognition model and the operation intent, determine the next operation step for the operator after the current operation step.

3. The method according to claim 2, characterized in that, The intent recognition model is trained through the following steps: Sample information is collected from historical log data, including vehicle information, operation behavior, operation status information, timestamp information, and exclusion result information; Based on the sample information, the operational intent corresponding to the operational behavior is determined; Construct the trajectory of the user's intention; Each step in the stated operational intent trajectory is evaluated; Construct the optimal set of intent links.

4. The method according to claim 3, characterized in that, The construction operation intent trajectory includes: Based on the sample information, the operation behavior is time-series aligned, anomaly filtered, and noise reduced to construct an ordered sequence of operation behavior. The operational behaviors are semantically encoded to construct an operational behavior graph; Determine the temporal transition frequency, behavior jump relationship, and conditional transition probability between operational behaviors, and construct the operational intent trajectory based on this.

5. The method according to claim 3, characterized in that, The evaluation of each step in the operation intent trajectory includes the following evaluation metrics: intent success rate, intent accuracy, intent redundancy, intent logic, and intent convergence speed.

6. The method according to claim 3, characterized in that, The construction of the optimal intent link set includes: Based on the operational intent trajectory, a deviation analysis is performed; the deviation analysis includes: intent accuracy index, logical thinking index, operational efficiency index, and experience coverage breadth; Based on the deviation analysis, an operator profile is constructed, which includes at least two levels. Based on the evaluation of the operational intent trajectory, the optimal intent chain corresponding to the operator profile is obtained, and each intent in the optimal intent chain has a corresponding operational behavior.

7. The method according to claim 6, characterized in that, Also includes: Obtain the actual data stream under real operational behavior; Compare the actual operation data stream with the optimal intent link; When the actual operation data stream differs from the operation behavior of the optimal intent link, a quality score is given to the actual operation data stream. If the score of the actual operation data stream exceeds a preset threshold, the intent link corresponding to the actual operation data stream will be updated to the optimal intent link.

8. A vehicle troubleshooting device, characterized in that, include: The scanning module is used to scan the data information of the target vehicle in response to a fault diagnosis request; The identity recognition module is used to obtain the operator's identity information; A fault determination module is used to determine and display fault information of the target vehicle based on the data information, wherein the fault information includes at least one fault type; The operation display module is used to display the current operation step according to the target fault type; and to display the next operation step after the current operation step is completed. The next operation step is determined based on the operator's identity information and the operation intent of the current operation step.

9. An electronic device, characterized in that, include: At least one processor; as well as A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method of any one of claims 1-7.

10. A computer-readable storage medium storing computer instructions that, when executed by a processor, implement the method as described in any one of claims 1-7.

Images