Method and device for generating maintenance scheme based on diagnosis report and storage medium

By generating multiple repair plans in the diagnostic equipment and selecting the best plan, the problem of numerous operational steps in traditional automotive repair is solved, improving the efficiency of repair plan generation and user experience.

CN120912174APending Publication Date: 2025-11-07LAUNCH TECH CO LTD
View PDF 0 Cites 1 Cited by

Patent Information

Application Number
CN202511007272.9
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2025-07-22
Publication Date
2025-11-07

AI Technical Summary

Technical Problem

In traditional car repair, after a diagnostic report is generated, the repair guide needs to be found, which involves many steps and is inefficient, resulting in a poor user experience.

Method used

By acquiring vehicle attribute data and fault detection parameters, inputting them into a preset fault repair model, generating multiple repair plans, and determining the target repair plan based on success rate and cost, the plan is then displayed on the diagnostic device.

Benefits of technology

It improves the efficiency of maintenance plan generation, reduces user operation steps, and enhances the readability and user experience of maintenance plans.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN120912174A_ABST
    Figure CN120912174A_ABST
Patent Text Reader

Abstract

The invention provides a method and device for generating a maintenance scheme based on a diagnosis report and a storage medium, and is applied to diagnosis equipment, and the method comprises the steps: obtaining the vehicle attribute data of a target vehicle, extracting a fault code and a fault detection parameter from the diagnosis report, inputting the vehicle attribute data, the fault code and the fault detection parameter into a preset first fault maintenance model to obtain n fault maintenance schemes; n is an integer greater than 1, determining a maintenance success rate and a maintenance cost corresponding to each of the n fault maintenance schemes to obtain n maintenance success rates and n maintenance costs, and determining a target maintenance scheme from the n fault maintenance schemes according to the n maintenance success rates and the n maintenance costs, and displaying the target fault maintenance scheme on diagnosis equipment. By executing the method provided by the embodiment of the invention, the maintenance scheme generation efficiency can be improved in the aspect of the maintenance scheme generated by the diagnosis report.
Need to check novelty before this filing date? Find Prior Art

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of intelligent automobiles, and in particular to a method and device for generating a repair scheme based on a diagnosis report and a storage medium. BACKGROUND

[0002] With the rapid development of the automobile industry, diagnosis equipment plays an increasingly important role in the field of automobiles. In the field of automobile repair, the diagnosis report generated by the diagnosis equipment is an important basis for determining vehicle faults and repair schemes. However, the traditional automobile repair method has certain problems. After generating a diagnosis report through the diagnosis equipment, a repair technician needs to use the repair guide function to find a repair method according to a specific fault code, which has problems such as multiple operation steps, scattered technical materials, time-consuming and laborious query, low efficiency, and the like.

[0003] Therefore, in terms of generating a repair scheme based on a diagnosis report, how to improve the efficiency of repair scheme generation is an urgent problem to be solved. SUMMARY

[0004] The embodiments of the present application provide a method and device for generating a repair scheme based on a diagnosis report and a storage medium, which improve the efficiency of repair scheme generation in terms of generating a repair scheme based on a diagnosis report.

[0005] In a first aspect, the embodiments of the present application provide a method for generating a repair scheme based on a diagnosis report, applied to a diagnosis equipment, and the method comprises:

[0006] obtaining vehicle attribute data of a target vehicle;

[0007] extracting a fault code and a fault detection parameter from the diagnosis report;

[0008] inputting the vehicle attribute data, the fault code, and the fault detection parameter into a preset first fault repair model to obtain n fault repair schemes; n is an integer greater than 1;

[0009] determining a repair success rate and a repair cost corresponding to each fault repair scheme in the n fault repair schemes to obtain n repair success rates and n repair costs;

[0010] determining a target repair scheme from the n fault repair schemes according to the n repair success rates and the n repair costs;

[0011] displaying the target fault repair scheme on the diagnosis equipment.

[0012] In a second aspect, the embodiments of the present application provide a device for generating a repair scheme based on a diagnosis report, applied to a diagnosis equipment, and the device comprises:

[0013] obtain vehicle attribute data of the target vehicle;

[0014] extract a fault code and a fault detection parameter from the diagnosis report; input the vehicle attribute data, the fault code and the fault detection parameter into a preset first fault maintenance model to obtain n fault maintenance schemes; n is an integer greater than 1;

[0015] determine a maintenance success rate and a maintenance cost corresponding to each fault maintenance scheme in the n fault maintenance schemes to obtain n maintenance success rates and n maintenance costs; and determine a target fault maintenance scheme from the n fault maintenance schemes according to the n maintenance success rates and the n maintenance costs;

[0016] display the target fault maintenance scheme on the diagnosis device.

[0017] In a third aspect, an embodiment of the present application provides a diagnosis device, including a processor, a memory, a communication interface and one or more programs, wherein the one or more programs are stored in the memory and configured to be executed by the processor, and the programs include instructions for performing steps in any method of the first aspect of the embodiments of the present application.

[0018] In a fourth aspect, an embodiment of the present application provides a computer readable storage medium, which stores a computer program for diagnosis data exchange, wherein the computer program causes a computer to perform some or all of the steps described in any method of the first aspect of the embodiments of the present application.

[0019] In a fifth aspect, an embodiment of the present application provides a computer program product, which includes a non-transitory computer readable storage medium storing a computer program, and the computer program is operable to cause a computer to perform some or all of the steps described in any method of the first aspect of the embodiments of the present application. The computer program product can be a software installation package.

[0020] By implementing the embodiments of the present application, the following beneficial effects are achieved:

[0021] The method for generating a maintenance scheme based on a diagnostic report, the device, and the storage medium described in the application are applied to a diagnostic device. The method comprises the following steps: obtaining vehicle attribute data of a target vehicle, extracting a fault code and a fault detection parameter from a diagnostic report, inputting the vehicle attribute data, the fault code, and the fault detection parameter into a preset first fault maintenance model to obtain n fault maintenance schemes, n being an integer greater than 1, determining a maintenance success rate and a maintenance cost corresponding to each fault maintenance scheme in the n fault maintenance schemes to obtain n maintenance success rates and n maintenance costs, determining a target maintenance scheme from the n fault maintenance schemes according to the n maintenance success rates and the n maintenance costs, and displaying the target fault maintenance scheme on the diagnostic device. In this way, the method for finding a fault code through a fault code to complete the recommendation of a maintenance scheme is solved, and the efficiency of generating a maintenance scheme is improved. BRIEF DESCRIPTION OF DRAWINGS

[0022] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings needed in the embodiment description will be briefly introduced. Obviously, the drawings in the following description are some embodiments of the present application, and other drawings can also be obtained by those skilled in the art without creative labor.

[0023] Figure 1 is an architecture diagram of a system for generating a maintenance scheme based on a diagnostic report provided by an embodiment of the present application;

[0024] Figure 2 is a structural schematic diagram of a diagnostic device provided by an embodiment of the present application;

[0025] Figure 3 is a flowchart of a method for generating a maintenance scheme based on a diagnostic report provided by an embodiment of the present application;

[0026] Figure 4 is a flowchart of another method for generating a maintenance scheme based on a diagnostic report provided by an embodiment of the present application;

[0027] Figure 5 is a scene diagram of a method for generating a maintenance scheme based on a diagnostic report provided by an embodiment of the present application;

[0028] Figure 6 is another scene diagram of a method for generating a maintenance scheme based on a diagnostic report provided by an embodiment of the present application;

[0029] Figure 7 is a flowchart of a method for generating a maintenance scheme by a diagnostic device provided by an embodiment of the present application;

[0030] Figure 8is a functional module block diagram of a device for generating a maintenance scheme based on a diagnosis report provided by an embodiment of the present application. DETAILED DESCRIPTION

[0031] In order for those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be described clearly and completely below with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are only some of the embodiments of the present application, but not all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative labor fall within the scope of protection of the present application.

[0032] The terms "first", "second", and the like in the specification and claims of the present application and the above-described drawings are used to distinguish different objects, and are not used to describe a specific order. In addition, the terms "include" and "have" and any variations thereof are intended to cover non-exclusive inclusion. For example, a process, method, system, product or device including a series of steps or units is not limited to the listed steps or units, but can optionally include steps or units not listed or can optionally include other steps or units inherent to the process, method, product or device.

[0033] It should be understood that the term "and / or" herein is only used to describe the association relationship of the associated objects, which means that there can be three relationships, for example, A and / or B can mean that A exists alone, A and B exist together, and B exists alone. In addition, the character " / " in this paper represents that the front and rear associated objects are a "or" relationship. The "multiple" appearing in the embodiments of the present application means two or more than two.

[0034] The "at least one" or similar expressions in the embodiments of the present application means any combination of these items, including any combination of single item or multiple items, means one or more, and multiple means two or more than two. For example, at least one of a, b or c can represent the following seven cases: a, b, c, a and b, a and c, b and c, a, b and c. Among them, each of a, b and c can be an element or a set containing one or more elements.

[0035] The "connection" appearing in the embodiments of the present application means direct connection or indirect connection and various connection modes to realize communication between devices, which is not limited by the embodiments of the present application.

[0036] Reference to“an embodiment” herein means that a particular feature, structure, or characteristic described in connection with the embodiment can be included in at least one embodiment of the application. The appearances of the phrase“in one embodiment” in various places in the specification are not necessarily all referring to the same embodiment, nor are they necessarily all mutually exclusive of one another. As will be apparent to those of ordinary skill in the art, embodiments described herein can be combined with other embodiments.

[0037] Currently, when the diagnostic report is generated, the maintenance guide needs to be viewed using the maintenance guide function to find the maintenance method according to a specific fault code, and a fault code is found for a fault code to complete the recommendation of the maintenance scheme. This method has many operation steps for finding the maintenance method, and needs to be repeated many times, which reduces the user experience. Therefore, how to make the maintenance scheme more readable and reduce user operations.

[0038] To solve the above problems, the embodiments of the application provide a method and device for generating a maintenance scheme based on a diagnostic report and a storage medium, which are applied to a diagnostic device. Vehicle attribute data of a target vehicle is obtained, fault codes and fault detection parameters are extracted from the diagnostic report, then the vehicle attribute data, the fault codes and the fault detection parameters are input into a preset first fault maintenance model to obtain n fault maintenance schemes; n is an integer greater than 1, then the maintenance success rate and the maintenance cost corresponding to each fault maintenance scheme in the n fault maintenance schemes are determined to obtain n maintenance success rates and n maintenance costs, finally, a target maintenance scheme is determined from the n fault maintenance schemes according to the n maintenance success rates and the n maintenance costs, and the target fault maintenance scheme is displayed on the diagnostic device. In this way, the current method of finding a fault code for a fault code to complete the recommendation of the maintenance scheme is solved, and the efficiency of generating the maintenance scheme is improved.

[0039] The following will be described in combination with Figure 1 The system architecture of the method for generating a maintenance scheme based on a diagnostic report in the embodiments of the application is described, Figure 1 is the architecture diagram of a system for generating a maintenance scheme based on a diagnostic report provided by the embodiments of the application. The system 100 for generating a maintenance scheme based on a diagnostic report includes a target vehicle 110, a diagnostic device 120 and an AI large language model 130.

[0040] The target vehicle 110 is the object of system diagnosis and maintenance scheme generation, and it has a standardized on-board diagnostic interface (such as an OBD-II port) and a communication module supporting remote data access. When a fault occurs, the target vehicle 110 can provide the diagnostic device 120 with vehicle identification code (VIN), production date, power type (fuel / pure electric / hybrid), real-time running parameters, fault snapshot data, etc., which are not limited here,

[0041] The diagnostic device 120 is an intelligent edge computing node connecting the target vehicle 110 and the AI ​​large language model 130. Its technical implementation includes a multi-protocol adaptation layer, a data preprocessing engine, and a diagnostic report generator. In one possible embodiment, after reading the fault code "P0A39" of the target vehicle 110 through the OBD-II interface, the diagnostic device 120 first calls the manufacturer's proprietary diagnostic protocol (such as BYD DDS) to obtain extended data; then, it performs Kalman filtering noise reduction on the 200 sets of collected battery voltage data and generates an interactive diagnostic report that includes a fault code parsing tree, parameter trend chart, and maintenance history comparison.

[0042] Among them, the AI ​​Large Language Model 130 is the decision-making center of the system. It can be the LUANCH AI model, whose architecture is based on the Transformer and includes: multimodal input processing, text numerical input, image input, etc. In addition, LUANAI has a built-in vehicle fault knowledge graph containing more than 500,000 triples.

[0043] In one possible embodiment, after receiving the report uploaded by the diagnostic device 120, the AI ​​large language model 130 (such as LAUNCH AI) first parses the fault code "P0A39" and searches the knowledge graph, determining that the parameter requiring key analysis is "battery module 3 voltage (11.2V)". Then, it calculates the success probability of each repair solution based on historical repair cases; for example, solution A (replacing the battery module): success rate 82%; solution B (calibrating BMS parameters): success rate 65%. A decision support report is then generated, including solution comparisons, risk warnings, and parts inventory status. Furthermore, the repair solution generation system 100 based on the diagnostic report operates through an edge-cloud collaborative architecture. It uses the target vehicle 110 as the data source to ensure the real-time nature of the raw data, utilizes edge computing via the diagnostic device 120 to reduce cloud load, and leverages the AI ​​large language model 130 to provide global intelligence, supporting large-scale concurrent analysis. Through multi-granularity knowledge fusion, interpretable content is output for user selection.

[0044] It is evident that the system architecture based on the diagnostic report-generated repair solution method described above can improve diagnostic efficiency, optimize repair accuracy, and enhance user experience.

[0045] The following is combined with Figure 2 The diagnostic device in the embodiments of this application will be described. Figure 2 This is a schematic diagram of the structure of a diagnostic device provided in an embodiment of this application, such as... Figure 2As shown, the diagnostic device 200 includes one or more processors 210, memory 220, a communication interface 230, and one or more programs 221, which are communicatively connected with each other via an internal communication bus.

[0046] The processor 210 may, for example, be a Central Processing Unit (CPU), a general-purpose processor, a Digital Signal Processor (DSP), an Application-Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA) or other programmable logic device, a transistor logic device, a hardware component, or any combination thereof. It can implement or execute various exemplary logical blocks, units, and circuits described in connection with the disclosure. The processor can also be a combination of implementing computing functions, such as a combination of one or more microprocessors, a combination of a DSP and a microprocessor, and the like. The communication unit can be a communication interface, a transceiver, a transceiver circuit, and the like, and the storage unit can be a memory.

[0047] The memory 220 can be a volatile memory or a nonvolatile memory, or can include both volatile and nonvolatile memory. The nonvolatile memory can be a read-only memory (ROM), a programmable ROM (PROM), an erasable PROM (EPROM), an electrically EPROM (EEPROM), or a flash memory, for example. The volatile memory can be a random access memory (RAM) used as an external cache memory. By way of example, and not limitation, many forms of random access memory (RAM) are available, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous dynamic RAM (SDRAM), double data rate SDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), synchlink DRAM (SLDRAM), and direct rambus RAM (DR RAM).

[0048] The one or more programs 221 stored in the memory 220 described above are configured to be executed by the processor 210 described above, and include instructions for performing any of the steps of the following data processing method embodiments.

[0049] It can be understood that the diagnostic device 200 can include more or fewer structural elements than those in the above structural block diagram, for example, including a power module, a physical key, a Wi-Fi module, a speaker, a Bluetooth module, a sensor, a display module, and the like, which are not limited herein. It can be understood that the diagnostic device 200 can be equipped with a system for generating a repair scheme based on a diagnostic report as described above. Figure 1 The architecture of the system for generating a repair scheme based on a diagnostic report.

[0050] After understanding the software and hardware architecture of the present application, the following will be combined with the Figure 3 A method for generating a repair scheme based on a diagnostic report in an embodiment of the present application is described, Figure 3 is a flowchart of a method for generating a repair scheme based on a diagnostic report provided by an embodiment of the present application, and specifically includes the following steps:

[0051] Step S310, obtaining vehicle attribute data of the target vehicle.

[0052] The vehicle attribute data is a structured data set for describing the basic characteristics and technical parameters of the vehicle, which includes not only static identity identification (such as vehicle identification code VIN), but also dynamic technical characteristics (such as power system type, software version number, etc.), which together constitute the bottom input of the maintenance decision.

[0053] Specifically, the vehicle attribute data can be divided into identity identification data, technical configuration data and use environment data. The identity identification data can be the vehicle identification code (VIN) and the vehicle model year; the technical configuration data can be the power system type, for example, to distinguish between pure electric vehicles (BEV), plug-in hybrid vehicles (PHEV), and fuel vehicles (ICE), which directly affects the fault diagnosis path. The software version number includes the vehicle ECU firmware version and the vehicle system version; the use environment data includes regional characteristics, driving mileage, etc., which are not limited here.

[0054] It should be noted that the collection of vehicle attribute data is realized through a multi-source heterogeneous mode, which can be through the BD-II interface to obtain standardized data such as VIN and ECU version, or through image recognition assisted identification, or through cloud data search and completion, which are not limited here.

[0055] Step S320, extracting fault codes and fault detection parameters from the diagnostic report.

[0056] The diagnostic report is a structured data document generated by the vehicle diagnostic device after comprehensive detection of the target vehicle, which is a systematic record of vehicle fault information and real-time running state. The diagnostic report not only contains the original fault code (such as "P0A39"), but also includes the environmental parameters at the time of fault triggering (such as engine speed, battery temperature, etc.). The fault code, as the core identification of vehicle faults, its coding follows international standards (such as SAE J2012 standard of OBD-II) or manufacturer-defined rules (such as "BMS_" prefix fault code of BYD new energy vehicles), and the fault subsystem can be quickly located by analyzing the coding structure.

[0057] The fault detection parameter is a physical quantity or logical state that quantitatively represents the running state of the vehicle component, including electrical parameters, mechanical parameters and software state parameters of the vehicle. The electrical parameters include instantaneous values such as voltage, current, resistance and fluctuation characteristics (such as 12V storage battery voltage lower than 11.5V for 10 seconds is judged as abnormal). For example, when the fault code "P0562" (low system voltage) appears, the generator output voltage (standard range 13.5-14.5V) and load current curve need to be extracted synchronously; the mechanical parameters include temperature, pressure, vibration, etc. Physical quantities; software state parameters are records of ECU internal logic variables.

[0058] In a possible embodiment, the extracting the fault code and the fault detection parameter from the diagnostic report specifically includes the following steps:

[0059] 321, adopting a preset entity recognition model to recognize the fault code in the diagnostic report to obtain the fault code;

[0060] 322, determining the detection parameter in the diagnostic report to obtain a first detection parameter;

[0061] 323, mapping the detection parameter corresponding to the fault code from a preset vehicle fault knowledge graph to obtain a first fault detection parameter;

[0062] 324, determining the fault detection parameter according to the first detection parameter and the first fault detection parameter.

[0063] The entity recognition model can be constructed based on a deep learning architecture and fuse a BERT-CNN encoding feature fusion algorithm, and can perform semantic analysis on unstructured text in the diagnostic report. For the diagnostic report in the picture format, first, the OCR technology is used for preprocessing, including image denoising, tilt correction and character segmentation, the convolutional neural network is used for character recognition, and the named entity recognition model is used to extract the fault code entity. For example, when the report appears "fault code P0442", the model accurately identifies "P0442" as the target fault code through keyword matching and context semantic analysis, and associates it to the fault description of "fuel evaporation emission system".

[0064] The knowledge graph fuses the fault code, the detection parameter, the component association relationship and the industry standard data. For example, for the fault code "P0172" (high fuel value), the knowledge graph defines its corresponding detection parameters including "fuel correction value", "oxygen sensor voltage", "injection pulse width" and the like, and establishes a standardized mapping through parameter group number and suspicious parameter number. For the fault code specific to new energy vehicles (such as "P2563" motor controller fault), the knowledge graph internally has a parameter classification system specific to the three-electric system, which explicitly maps the parameters such as "motor controller temperature" and "bus voltage" to the "electric drive module area" under the "power system".

[0065] Specifically, the diagnostic report processing flow includes the following processes: firstly, multi-modal data fusion, for text type report, directly extract fault codes through entity recognition model; for picture type report, first convert the image to text through OCR technology, and then perform entity recognition. For example, the diagnostic report of a new energy vehicle is presented in PDF format, which contains table form detection parameters (such as “battery pack voltage: 380V” “motor speed: 5000 rpm”), after identifying the table content through OCR technology, combined with rule engine to extract key parameters. Then, the semantic network of knowledge graph is used to realize the accurate mapping of fault codes and detection parameters. The knowledge graph defines the units, normal ranges and associated components of these entity parameters. When the first detection parameter is different from the parameter in the knowledge graph, D-S evidence theory is used for data fusion, combined with historical maintenance data to calculate the parameter confidence, and finally determine the abnormal detection parameter as the effective detection parameter. Finally, in the multi-fault code concurrent scene, the association between fault codes is analyzed by using Bayesian network. For example, when fault codes “P0442” and “P0172” appear at the same time, the associated detection parameters in the knowledge graph include “fuel vapor canister pressure” and “fuel injection pulse width”, by calculating the causal probability of the two (such as fuel vapor leakage leading to lean mixture, and then triggering fuel correction value anomaly), the “fuel vapor emission system” is determined as the main fault area, and the “fuel vapor canister pressure” is determined as the detection parameter.

[0066] In a possible embodiment, the determining the fault detection parameter according to the first detection parameter and the first fault detection parameter specifically includes the following steps:

[0067] 3241, determining a fault type corresponding to the first fault detection parameter;

[0068] 3242, screening parameters corresponding to the fault type from the first detection parameter to obtain the fault detection parameter.

[0069] Wherein, the determination of fault type is according to multi-level fault classification system and semantic reasoning mechanism of knowledge graph, the multi-level classification system divides fault type into first level classification such as power system, chassis system and vehicle body electronics, and second level classification such as fuel injection system and ignition system. For example, for the first fault detection parameter “fuel vapor canister pressure”, the knowledge graph is located to the “power system → fuel supply system → evaporative emission control” fault type through semantic association. The parameter screening mechanism combines rule engine and machine learning algorithm, which can be traditional machine learning algorithm (random forest, XGBoost, etc.), or deep learning algorithm, which is not limited here, and the rule engine establishes parameter association rules based on SAE J2962 diagnostic standard.

[0070] Specifically, the determination of the fault detection parameter mainly includes: semantic analysis of fault type, through semantic segmentation of the first fault detection parameter, through the entity relationship query interface of the knowledge graph, and using the LSTM-CRF sequence labeling model to identify the parameter dimension, and determining the corresponding fault type through the association rule engine; then, conflict resolution of parameter screening, when the first detection parameter and the first fault detection parameter exist parameter dimension conflict (such as detecting "cooling liquid temperature sensor voltage" in the report, and the parameter mapped by the knowledge graph is "cooling liquid temperature actual value"), using Dempster-Shafer evidence theory to fuse multi-source data; then, dynamic weight updating mechanism, continuously optimizing the parameter screening weight through maintenance feedback data; finally, parameter aggregation of multiple fault types. Among them, in the multi-fault type concurrent scene (such as "fuel vapor emission system leakage" and "ignition coil fault" exist at the same time), a parameter aggregation algorithm based on graph neural network is used to construct a fault type-parameter association graph, the nodes are fault types and detection parameters, and the edge weight is the historical association strength. Through the message passing mechanism of GNN, the comprehensive weight of the parameter under multiple types is calculated. Through the test of 100,000-level large-scale diagnostic reports, the screening accuracy of the fault detection parameter can reach 96.3%, which significantly improves the efficiency and accuracy of the maintenance scheme generation.

[0071] Step S330, input the vehicle attribute data, the fault code and the fault detection parameter into the preset first fault maintenance model to obtain n fault maintenance schemes; n is an integer greater than 1.

[0072] Among them, the first fault maintenance model takes LAUNCH AI large language model as the core, and constructs a distributed reasoning architecture integrating multi-source data. LAUNCH AI integrates the maintenance case library (covering 1 million+ historical maintenance records) in the meta signature database, the maintenance guide library (integrating manufacturer technical specifications and diagnostic protocols), the diagnostic report database and third-party industry data (including Internet maintenance forums, vehicle OTA upgrade logs, etc.), forms a multi-level knowledge graph, and the model adopts the Transformer encoder-decoder structure. Its self-attention mechanism can adaptively learn the weight association of vehicle attributes (such as brand, year, power type), fault code sequence and detection parameter.

[0073] Among them, the vehicle attribute data is converted into a binary vector by One-Hot Encoding (for example, "2023" is mapped to [0, 1, 0]), the fault code is mapped into a multi-dimensional semantic vector by a pre-trained Word2Vec model, capturing the implicit association between fault codes (for example, the coupling relationship of P0A39 and P1A00 in the three-electric system), and the detection parameters are normalized by Z-Score (for example, the motor speed data is standardized to the interval [-1, 1]). For missing data, the model uses a bidirectional LSTM interpolation algorithm, for example, according to the time series correlation of "motor temperature-speed" in historical data, the missing speed value is predicted and the confidence is labeled.

[0074] Specifically, the repair scheme generation process mainly includes: first, multi-source feature fusion reasoning is performed, and through cross-modal fusion technology, structured data (such as parameter values) and unstructured data (such as vehicle text description) are mapped to a unified feature space. Next, the output layer adopts a multi-label classification architecture, and n schemes and their success probabilities are generated by a softmax function, wherein the probability calculation is based on case matching degree, parameter correlation strength, and real-time feedback correction fusion, the cosine similarity between the current fault features and the historical cases is calculated through the Faiss vector retrieval engine (for example, when 500 similar cases are matched, the basic probability is increased to 40%), the parameter weight is trained by using the XGBoost model, and the probability value is dynamically adjusted by real-time feedback correction. The following is an example for illustration: the model may output 5 schemes, wherein: scheme A, replace the motor controller heat dissipation module (probability 50%); scheme B, clean the heat dissipation fan dust (probability 25%); scheme C, upgrade the motor control firmware (probability 15%); scheme D, check the high-voltage wire bundle insulation (probability 8%); and scheme E, replace the cooling liquid pump (probability 2%). Then, the model introduces constraint conditions such as repair cost, time consumption and technical difficulty by gradient boosting tree, for example, although scheme A has the highest probability, when it is detected that "the heat dissipation fan speed is normal", the priority of scheme B (cleaning the fan) is automatically increased to 30%. For the concurrent scene of multiple fault codes (such as P0A39 and P0B41 appearing at the same time), the model first calculates the fault code causal probability by a Bayesian network (for example, the probability of P0A39 causing P0B41 is 0.78), determines the main fault code, and then aggregates the associated parameters to avoid secondary faults interfering with scheme ranking. Finally, feedback loop and model evolution, when the technician selects a scheme to complete the repair, the actual results (success / failure), time consumption, and parts used are collected, and the model parameters are updated by FTRL online learning algorithm.

[0075] In step S340, the repair success rate and the repair cost corresponding to each of the n fault repair schemes are determined, and n repair success rates and n repair costs are obtained.

[0076] The calculation of the repair success rate is based on a multi-source data fusion probability reasoning mechanism, which is based on historical repair cases in the LAUNCH AI database and combines real-time feedback data to build a dynamic probability model. The calculation of the repair cost is based on a multi-level cost database and a dynamic pricing model. The cost database includes: a parts base library, which integrates the standard procurement price of parts in the component database, a standard labor time library, and a regional dynamic library. The cost calculation model uses gradient boosting trees and introduces factors such as parts inventory turnover rate and repair technical difficulty coefficient. For example, when a certain part is in short supply, the cost automatically increases by 15%; for operations that require special tools (such as high-voltage electrical maintenance), the labor cost increases by 30%.

[0077] Specifically, the determination of success rate and cost mainly includes: continuously optimizing the success rate estimate through the Bayesian update mechanism. Taking the "replace the motor controller heat dissipation module" scheme as an example, the initial success rate is 50% based on historical case statistics. If 80 of the subsequent 100 applications are successful, the success rate is updated to 55% through the Bayesian formula, and the weight of the "motor temperature" parameter is adjusted from 0.6 to 0.65. The repair cost is composed of direct cost and indirect cost: direct cost = parts price × (1 + inventory premium rate) + standard labor time × regional labor time unit price. For example, the BYD battery equalization module has a unit price of 850 yuan, an inventory premium of 10%, 2.5 labor hours × 120 yuan / labor hour × 1.2, and a direct cost of 1295 yuan. Indirect costs include depreciation of diagnostic equipment, technical support fees (50 yuan / time), etc., which are associated with repair duration through a linear regression model.

[0078] In one possible embodiment, the determination of the repair success rate and the repair cost corresponding to each of the n fault repair schemes to obtain n repair success rates and n repair costs specifically includes the following steps:

[0079] 341. Determine the vehicle model year based on the vehicle attribute data;

[0080] 342. Find the repair scheme corresponding to the fault code from the preset repair case library to obtain m first repair schemes; m is greater than or equal to n;

[0081] 343. Select the repair scheme corresponding to the vehicle model year from the m first repair schemes to obtain n second repair schemes;

[0082] 344. Calculate the ratio of the number of times each second repair scheme in the n second repair schemes is successfully completed to the total number of times the corresponding n second repair schemes are completed within a preset time period to obtain the n repair success rates;

[0083] 345、According to the n fault repair schemes, determine the corresponding repair process of each fault repair scheme, and obtain the n repair processes;

[0084] 346、Determine the repair cost corresponding to each of the n repair processes, and obtain the n repair costs.

[0085] Wherein, the repair case library integrates the historical repair records in the meta database, and adopts a distributed index architecture to realize the rapid matching of fault codes and repair schemes. The case library is stored in a three-dimensional structure of "fault code - vehicle model year - repair scheme", for example, the repair scheme of BYD 2023 model corresponding to fault code "P0A39" includes "replace motor controller heat dissipation module", "clean heat dissipation fan" and other operations. When searching, the basic scheme set is located through the fault code hash index, and then filtered through the vehicle model year keyword to ensure that the scheme matches the vehicle configuration. For faults specific to new energy vehicles (such as three-electric system faults), the case library has built-in special classification labels (such as "EV - motor controller"), which improve the matching accuracy through semantic search. The statistical model of repair success rate combines time decay factor and Bayesian update mechanism, and the preset time period is usually set to nearly 1 day or 3 days, and the data samples are dynamically updated through sliding window. For example, when counting the "replace heat dissipation module" scheme of BYD 2023 model fault code P0A39, if 20 times of repair are completed in nearly 1 day, and 18 times are successful, the success rate is 90%.

[0086] Wherein, the vehicle attribute data is parsed by a natural language processing model, and the parsing model adopts BERT-CRF architecture and is pre-trained on automobile industry corpus. The recognition accuracy rate of year expression (such as "2023 model" "23 model" "MY2023") reaches 98.5%, and for ambiguous expressions (such as "BYD new energy vehicle"), the system recommends vehicle models through fault code association and prompts the technician to confirm the year information. The mapping relationship between "vehicle model year - repair scheme" is established through knowledge graph. The graph nodes include the vehicle model year, repair scheme and of most vehicle models on the market, and the edge weight is determined by manufacturer technical announcement (40%), historical repair frequency (35%) and parts compatibility (25%). During the statistical process, the system automatically filters invalid data (such as incomplete repair, missing data records), and continuously optimizes through the online learning algorithm of LAUNCH AI. For example, if the initial success rate of a certain scheme is 50%, and 80 times of success are added in 100 new feedbacks, the model updates the parameters through FTRL algorithm, and the success rate is increased to 55%, and the weight of "motor temperature" parameter is adjusted from 0.6 to 0.65. Wherein, the repair process disassembly is based on SAE J2919 work standard, for example, "replace motor controller heat dissipation module" includes "remove the guard plate (0.5 work hours)", "replace the module (1.5 work hours)", "test the function (0.5 work hours)" and other sub-processes.

[0087] In a possible implementation, the determining of the maintenance cost corresponding to each of the n maintenance procedures includes the following steps:

[0088] 3461、determining a target maintenance man-hour and a target replacement part according to a target maintenance procedure; the target maintenance procedure is any one of the n maintenance procedures;

[0089] 3462、obtaining a cost price of the target replacement part and a replacement technical cost of the target replacement part;

[0090] 3463、determining a first maintenance cost according to the cost price of the target replacement part and the replacement technical cost of the target replacement part;

[0091] 3464、determining a second maintenance cost corresponding to the target maintenance man-hour;

[0092] 3465、determining a third maintenance cost corresponding to the target maintenance procedure based on a preset operation risk condition;

[0093] 3466、determining the maintenance cost corresponding to the target maintenance procedure according to the first maintenance cost, the second maintenance cost and the third maintenance cost.

[0094] The association mechanism of maintenance man-hour and parts relies on a vehicle maintenance knowledge graph and a dynamic man-hour standard library. The knowledge graph integrates SAE J2919 maintenance man-hour specifications and historical maintenance data, and constructs a three-dimensional mapping relationship of “maintenance procedure-man-hour-parts”. For example, the “replace motor controller heat dissipation module” procedure corresponds to a standard man-hour of 2.5 hours, and requires replacement of parts such as “heat dissipation module assembly” and “sealing rubber strip”. The man-hour library supports dynamic updates. For new energy vehicle models with new procedures (such as “battery pack balancing maintenance”), the LAUNCH AI small sample learning technology is used to quickly generate an initial man-hour standard (such as 3.0 hours) based on more than 20 cases, and iteratively optimize the man-hour standard with maintenance feedback. The quantitative model of operation risk cost integrates fault mode and effect analysis (FMEA) and real-time risk assessment algorithm. The preset risk conditions include: safety level (such as high-voltage electric operation requiring additional safety measures); technical difficulty (such as requiring special diagnostic equipment); environmental requirements (such as dust-free workshop operation). The risk cost is calculated by fuzzy analytic hierarchy process (FAHP), for example, the risk coefficient of high-voltage electric maintenance is 1.3, the coefficient of special tool use is 1.2, and the comprehensive risk coefficient after coupling is 1.3x1.2=1.56, and the third maintenance cost = basic cost x risk coefficient.

[0095] Step S350, determining a target maintenance scheme from the n failure maintenance schemes according to the n maintenance success rates and the n maintenance costs.

[0096] The decision fusion mechanism of the maintenance success rate and the maintenance cost is constructed based on a multi-criteria decision theory, and the scheme optimization is achieved through quantitative mapping and weight allocation.

[0097] In a possible embodiment, the step of determining a target maintenance scheme from the n failure maintenance schemes according to the n maintenance success rates and the n maintenance costs specifically includes the following steps:

[0098] 351, determining maintenance recommended values corresponding to the n maintenance costs based on a preset mapping relationship between the maintenance costs and the maintenance scheme recommended values, to obtain n first maintenance scheme recommended values;

[0099] 352, determining maintenance recommended values corresponding to the n maintenance success rates based on a preset mapping relationship between the maintenance success rates and the maintenance scheme recommended values, to obtain n second maintenance scheme recommended values;

[0100] 353, determining n target recommended values according to a preset weight calculation formula, a preset weight allocation coefficient, the n first maintenance scheme recommended values and the n second maintenance scheme recommended values;

[0101] 354, determining a maximum target recommended value in the n target recommended values, and obtaining a maintenance scheme corresponding to the maximum target recommended value as the target maintenance scheme.

[0102] The mapping relationship between the maintenance cost and the recommended value is constructed based on a cost-benefit function, and follows the law of diminishing marginal benefit. The function adopts a piecewise linear conversion model. When the maintenance cost is less than or equal to a benchmark cost, the recommended value is calculated in a linear positive correlation (for example, the recommended value is increased by 10 when the cost is reduced by 100 yuan); when the cost is greater than the benchmark cost, an exponential decay function is adopted (for example, the recommended value = 100 × e^(-k × (cost-benchmark cost)), k is a decay coefficient). The benchmark cost is dynamically determined by the vehicle model year and the maintenance type, for example, the battery system maintenance benchmark cost of a BYD 2023 new energy vehicle model is 1500 yuan. The mapping relationship is obtained through LAUNCH AI. When the target recommended values of multiple schemes are the same, the following priority rules are adopted: the scheme with a higher success rate is preferred; the scheme with a lower cost is preferred; the scheme with a shorter maintenance time is preferred. For example, scheme A (success rate 55%, cost 1390 yuan, recommended value 70) and scheme B (success rate 55%, cost 1400 yuan, recommended value 69.5), scheme A is preferred.

[0103] The embodiments consistent with the above Figure 3 , please refer to Figure 4 ,Figure 4 is another flow diagram provided by an embodiment of the application for generating a repair scheme based on a diagnosis report. After determining the target repair scheme based on the n repair success rates and the n repair costs, the method specifically further includes the following processes:

[0104] S410, vectorizing the vehicle attribute data, the fault code, and the fault detection parameter to obtain first vector data;

[0105] S420, obtaining a first training set of the first fault repair model;

[0106] S430, adding the first vector data and the target repair scheme to the first training set to obtain a second training set;

[0107] S440, retraining the first fault repair model based on the second training set to obtain a second fault repair model.

[0108] Among them, the vehicle attribute data is converted into a binary vector by one-hot encoding, mapping discrete features into orthogonal vectors in a multi-dimensional space; the fault code is mapped into a 512-dimensional semantic vector by a pre-trained Word2Vec model, capturing the implicit association between fault codes (such as the coupling relationship of P0A39 and P1A00 in the three-electric system); the detection parameter (such as "battery cell voltage difference 0.3V") is normalized to the [-1, 1] interval by Z-Score.

[0109] Among them, the construction of the first training set integrates historical repair cases in the meta-feature database according to the distributed data storage architecture of LAUNCH AI. The training set is stored in pairs of "feature vector-repair scheme", each sample contains vehicle attribute vector, fault code vector, detection parameter vector, and the corresponding successful repair scheme, and the data collection follows the time decay principle, with the data of the last 30 days accounting for 40%, the data of 30-90 days accounting for 30%, and the data of more than 90 days accounting for 30%, ensuring that the training set reflects the latest repair trends. For three-electric system fault cases specific to new energy vehicles, the training set aligns temperature sensor data with high-voltage circuit topology semantics through cross-modal fusion technology to form exclusive training samples.

[0110] Specifically, first, the new sample is subjected to anomaly detection, and outliers (such as samples with abnormally high repair success rate or significantly deviated cost) are removed by the Isolation Forest algorithm. For valid samples, the gradient accumulation technique is used to gradually integrate into the training set, avoiding the computational overhead of large-scale data retraining. To address the problem of uneven distribution of fault codes (such as P0A39 appearing 100 times more frequently than P9999), a balancing method combining oversampling and undersampling is used. For minority class faults (such as new fault codes for new energy vehicles), synthetic samples are generated by the SMOTE algorithm; for majority class faults, redundant samples are removed using the Tomek Links algorithm. Finally, combined with the Adam optimizer and cosine annealing learning rate scheduling strategy, the model accelerates the calculation in the forward propagation and restores the gradient accuracy in the backward propagation.

[0111] Step S360, the target fault repair scheme is displayed on the diagnostic device.

[0112] The man-machine interface of the diagnostic device adopts a layered visualization design, integrating data visualization technology and maintenance scene requirements. The display interface uses a card layout to display the target repair scheme as "core recommendation - detailed explanation - auxiliary information". The recommendation area marks the target scheme with a prominent color label (such as "Recommended Scheme: Replace Battery Balancing Module") and visualizes the success rate (55%) and cost (1390 yuan) proportion relationship through a ring progress bar; the detailed explanation area uses a folding panel to display the repair procedures (disassemble the guard plate → replace the module → function test), parts information (model BYD-12345, inventory status), and safety warnings (high-voltage operation requires power off for 5 minutes); the auxiliary information area provides historical case references (500 successful cases for the same vehicle model), technician evaluations (4.8 / 5 stars), and feedback portals.

[0113] The dynamic rendering engine supports multi-dimensional information correlation display. The display content realizes 3D interaction through WebGL technology, such as clicking on the "battery balancing module" component name, the interface pops up a three-dimensional location map of the component in the vehicle on the right side, and uses a heat map to mark the common fault area (such as highlighting the location of the balancing resistor). For the repair scheme of the three-electricity system specific to new energy vehicles, the interface automatically loads high-voltage safety operation animation tutorials (such as insulation glove wearing steps, voltage detection process), ensuring compliance of the repair process. The display data is updated in real time using the WebSocket protocol, and when the parts inventory status or work time and cost standards change, the interface automatically refreshes the cost value and marks the change time.

[0114] For ease of understanding, please refer to Figure 5 , Figure 5 is a scene diagram provided by the application embodiment for generating a repair scheme based on a diagnostic report, which shows that Figure 5The displayed repair scheme display interface includes a time identification area with the field "Time: XXXX-XX-XX, XX:XX", recording the timestamp of the generation of the diagnosis report, with time accuracy up to minute level (such as "2023-08-15, 14:30"). This field synchronizes the network time through the NTP protocol, ensuring the time sequence relevance with the time when the vehicle fault occurs, providing a benchmark for the subsequent time-sensitive analysis of the repair scheme (for example, the emergency handling priority of the battery fault in high temperature environment is raised). The scheme comparison scheme box displays the comparison of key parameters of five repair schemes (A-E) in a horizontal table form, including: technical feasibility index: historical success rate (such as scheme A marked "85%", based on 1000+ similar case statistics; risk level (such as scheme C marked "high risk", referring to high pressure system operation) economic index, estimated cost (such as scheme B shows "¥2,800", including parts and labor cost); repair time (such as scheme D marked "3.5 hours", including standard deviation ± 0.5 hours); interactive decision assistance function, etc., which are not limited here. By uniformly quantifying heterogeneous indicators such as success rate, cost, and time into comparable parameters (such as converting risk level to 0-1 utility value), the traditional repair scheme selection problem is solved. For example, scheme A (success rate 85%, cost 3200) and scheme D (success rate 78%, cost 2100) can choose scheme D from the cost.

[0115] For ease of understanding, please refer to Figure 6 , Figure 6is another scene schematic diagram provided by the embodiment of the application for generating a maintenance scheme based on a diagnosis report. As can be seen, the "maintenance engineer" is the subject of the scheme, and his professional qualifications and experience and skills are directly related to the maintenance quality. In the maintenance scheme based on the diagnosis report, the engineer level (such as junior, intermediate, and senior engineer) suitable for the fault type, the professional field, and the number of past similar fault maintenance cases need to be determined. According to the fault complexity of the diagnosis report, an engineer with corresponding technical ability and experience is matched to ensure the professionalism and reliability of the scheme execution. Secondly, "maintenance time required" includes the time consumed for fault detection and confirmation, the time for spare parts preparation, the operation time and quality detection time of maintenance; "success rate within maintenance time" reflects the reliability and risk prediction of the scheme. According to the fault cause analysis (such as "electromagnetic valve stuck due to carbon deposition, 15% recurrence probability after cleaning; coil aging, 2% recurrence probability after replacement") of the diagnosis report, combined with the maturity of the maintenance process (such as the success rate of traditional mechanical fault maintenance being more than 95%, and the success rate of new energy electric control system fault maintenance being about 85%), and the quality stability of spare parts, the probability of solving the fault within the estimated time of the maintenance scheme is calculated through a statistical learning model or an expert system, to provide a risk quantitative reference for maintenance decision-making; "maintenance cost required" includes the full cost accounting of the scheme execution, including spare parts procurement cost (distinguishing between original, alternative, and refurbished parts prices), engineer hourly cost (valued according to level and hours), equipment use cost (such as diagnosis instrument rental, special tool wear and tear), and quality detection cost.

[0116] For ease of understanding, please refer to Figure 7 , Figure 7 is a flowchart of a diagnosis equipment generating a maintenance scheme provided by the embodiment of the application. As can be seen, Figure 7The full process of the diagnostic device from reading fault codes based on LAUNCH AI to iterating maintenance solutions is demonstrated, and the complete logic of data-driven, intelligent analysis, solution generation, and self-evolution is constructed, aiming to provide precise and dynamic optimization technical support for vehicle maintenance. First, the diagnostic device obtains vehicle fault codes through OBD and other interfaces, synchronously collects multi-dimensional data such as vehicle basic information (brand, model, year), running parameters (engine speed, oil temperature, voltage, etc.), and historical maintenance records (if accessible). Then, LAUNCH AI analyzes the collected vehicle information and fault information. As an intelligent analysis engine, LAUNCH AI is based on a massive vehicle maintenance knowledge graph and machine learning models to deeply deconstruct the input data. On the one hand, it uses rule-based reasoning to match fault codes with common maintenance strategies (e.g., fault code P0300 combined with ignition voltage data to infer spark plug wearout fault); on the other hand, it uses machine learning to mine hidden correlations in data and output analysis results including fault root cause, impact range, and maintenance direction, providing intelligent decision-making basis for solution generation. Then, the diagnostic device generates multi-dimensional maintenance solutions based on AI analysis results and maintenance resource databases. The solutions cover specific maintenance steps (e.g., "replace spark plug → clean fuel injectors → test ignition coil"), estimated time (distinguishing between spare parts preparation, operation, and detection time), and cost accounting (spare parts and labor costs), and key indicators are presented in percentage form. After the maintenance solution is executed, the diagnostic device collects actual maintenance data (whether the fault is completely resolved, actual time / cost deviation from estimates, and newly discovered fault correlations) and inputs it as "feedback samples" into the LAUNCH AI database. The LAUNCH AI algorithm iteratively updates the knowledge graph and model parameters through online learning to continuously evolve the diagnostic device and LAUNCH AI capabilities, ensuring that the adaptability and accuracy of maintenance solutions improve dynamically with practice.

[0117] As can be seen, through the above embodiment of the method for generating a maintenance solution based on a diagnostic report, vehicle attribute data of a target vehicle is obtained, fault codes and fault detection parameters are extracted from the diagnostic report, then the vehicle attribute data, fault codes, and fault detection parameters are input into a preset first fault maintenance model to obtain n fault maintenance solutions; n is an integer greater than 1, then the maintenance success rate and maintenance cost corresponding to each fault maintenance solution in the n fault maintenance solutions are determined to obtain n maintenance success rates and n maintenance costs, finally, a target maintenance solution is determined from the n fault maintenance solutions according to the n maintenance success rates and the n maintenance costs, and the target fault maintenance solution is displayed on the diagnostic device. In this way, the current method of finding a fault code through a fault code to complete the recommendation of a maintenance solution is solved, thereby improving the efficiency of maintenance solution generation.

[0118] The above describes the scheme of the embodiments of the present application mainly from the perspective of the process of executing the method. It can be understood that, in order to implement the above functions, the diagnostic device comprises a hardware structure and / or a software module corresponding to the execution of each function. Those skilled in the art should easily realize that, in combination with the unit and algorithm steps of each example described in the embodiments provided herein, the present application can be implemented in the form of hardware or a combination of hardware and computer software. Whether a certain function is implemented in the form of hardware or computer software driven hardware depends on the specific application and design constraints of the technical solution. The skilled person can use different methods to implement the described functions for each specific application, but such implementation should not be considered as beyond the scope of the present application.

[0119] The embodiments of the present application can divide the functional units of the diagnostic device according to the above method examples. For example, each functional unit can be divided corresponding to each function, or two or more functions can be integrated in one processing unit. The integrated unit can be implemented in the form of hardware or software functional unit. It should be noted that the division of units in the embodiments of the present application is illustrative, and is only a logical functional division. In actual implementation, there can be another division method.

[0120] In the case of dividing each functional module corresponding to each function, Figure 8 is a functional module composition block diagram of a device for generating a repair scheme based on a diagnostic report provided by the embodiments of the present application. The device for generating a repair scheme based on a diagnostic report 800 comprises:

[0121] The acquisition module 810 is configured to acquire vehicle attribute data of a target vehicle.

[0122] The control module 820 is configured to extract fault codes and fault detection parameters from the diagnostic report, input the vehicle attribute data, the fault codes and the fault detection parameters into a preset first fault repair model, and obtain n fault repair schemes. n is an integer greater than 1.

[0123] The determination module 830 is configured to determine a repair success rate and a repair cost corresponding to each fault repair scheme in the n fault repair schemes, and obtain n repair success rates and n repair costs. The determination module 830 is further configured to determine a target repair scheme from the n fault repair schemes according to the n repair success rates and the n repair costs.

[0124] The display module 840 is configured to display the target fault repair scheme on the diagnostic device.

[0125] In a possible embodiment, the control module 820, in terms of extracting fault codes and fault detection parameters from the diagnostic report, is specifically configured to:

[0126] identify the fault code in the diagnostic report by using a preset entity recognition model, to obtain the fault code;

[0127] determine a detection parameter in the diagnostic report, to obtain a first detection parameter;

[0128] map the detection parameter corresponding to the fault code from a preset vehicle fault knowledge graph, to obtain a first fault detection parameter;

[0129] determine the fault detection parameter according to the first detection parameter and the first fault detection parameter.

[0130] In a possible implementation, the control module 820 is specifically configured to, in the determination of the fault detection parameter according to the first detection parameter and the first fault detection parameter:

[0131] determine a fault type corresponding to the first fault detection parameter;

[0132] screen a parameter corresponding to the fault type from the first detection parameter, to obtain the fault detection parameter.

[0133] In a possible implementation, the determination module 830 is specifically configured to, in the determination of the maintenance success rate and the maintenance cost of each fault maintenance scheme in the n fault maintenance schemes, to obtain n maintenance success rates and n maintenance costs:

[0134] determine a vehicle model year according to the vehicle attribute data;

[0135] find a maintenance scheme corresponding to the fault code from a preset maintenance case library, to obtain m first maintenance schemes; m is greater than or equal to n;

[0136] screen a maintenance scheme corresponding to the vehicle model year from the m first maintenance schemes, to obtain n second maintenance schemes;

[0137] statistically determine a ratio of a number of times of successfully completing each second maintenance scheme in the n second maintenance schemes to a total number of times of completing the corresponding second maintenance scheme in the n second maintenance methods in a preset time period, to obtain the n maintenance success rates;

[0138] determine a maintenance procedure corresponding to each fault maintenance scheme according to the n fault maintenance schemes, to obtain the n maintenance procedures;

[0139] determine a maintenance cost corresponding to each maintenance procedure in the n maintenance procedures, to obtain the n maintenance costs.

[0140] In a possible implementation, the determining module 830, in the aspect of determining the n maintenance costs according to the maintenance cost corresponding to each of the n maintenance procedures, is specifically configured to:

[0141] determine a target maintenance man-hour and a target replacement accessory according to a target maintenance procedure, the target maintenance procedure being any one of the n maintenance procedures;

[0142] obtain a cost price of the target replacement accessory and a replacement technical cost of the target replacement accessory;

[0143] determine a first maintenance cost according to the cost price of the target replacement accessory and the replacement technical cost of the target replacement accessory;

[0144] determine a second maintenance cost corresponding to the target maintenance man-hour;

[0145] determine a third maintenance cost corresponding to the target maintenance procedure based on a preset operation risk condition;

[0146] determine the maintenance cost corresponding to the target maintenance procedure according to the first maintenance cost, the second maintenance cost, and the third maintenance cost.

[0147] In a possible implementation, the determining module 830, in the aspect of determining the target maintenance scheme according to the n maintenance success rates and the n maintenance costs, is specifically configured to:

[0148] determine maintenance recommendation values corresponding to the n maintenance costs based on a preset mapping relationship between maintenance costs and maintenance scheme recommendation values, to obtain n first maintenance scheme recommendation values;

[0149] determine maintenance recommendation values corresponding to the n maintenance success rates based on a preset mapping relationship between maintenance success rates and maintenance scheme recommendation values, to obtain n second maintenance scheme recommendation values;

[0150] determine n target recommendation values according to a preset weight calculation formula, a preset weight distribution coefficient, the n first maintenance scheme recommendation values, and the n second maintenance scheme recommendation values;

[0151] determine a maximum target recommendation value in the n target recommendation values, and obtain a maintenance scheme corresponding to the maximum target recommendation value as the target maintenance scheme.

[0152] In a possible implementation, the determining module 830, after determining the target maintenance scheme according to the n maintenance success rates and the n maintenance costs, is specifically further configured to:

[0153] The vehicle attribute data, the fault code, and the fault detection parameters are vectorized to obtain the first vector data;

[0154] Obtain the first training set of the first fault repair model;

[0155] Add the first vector data and the target repair plan to the first training set to obtain the second training set;

[0156] The first fault repair model is retrained based on the second training set to obtain the second fault repair model.

[0157] It should be noted that the specific functional implementation of the device 800 for generating maintenance plans based on diagnostic reports is described above. Figure 3 The description of a method for generating a maintenance plan based on a diagnostic report is shown below. For example, the acquisition module 810 is used to implement the relevant content of execution S310, and the display module 840 is used to implement the relevant content of execution S360. Further details are omitted here. The various units or modules in the device 800 for generating a maintenance plan based on a diagnostic report can be individually or entirely merged into one or more other units or modules, or some of the units or modules can be further divided into multiple functionally smaller units or modules. This achieves the same operation without affecting the technical effects of the embodiments of the present invention. The aforementioned units or modules are based on logical function division. In practical applications, the function of one unit (or module) is implemented by multiple units (or modules), or the function of multiple units (or modules) is implemented by one unit (or module).

[0158] As can be seen, the repair method and apparatus based on diagnostic reports described in this application, applied to diagnostic equipment, obtains vehicle attribute data of the target vehicle, extracts fault codes and fault detection parameters from the diagnostic report, and then inputs the vehicle attribute data, fault codes, and fault detection parameters into a preset first fault repair model to obtain n fault repair schemes; n is an integer greater than 1. Then, the repair success rate and repair cost corresponding to each of the n fault repair schemes are determined, resulting in n repair success rates and n repair costs. Finally, based on the n repair success rates and n repair costs, a target repair scheme is determined from the n fault repair schemes and displayed on the diagnostic equipment. This solves the current problem of recommending repair schemes by finding one fault code at a time during repairs, thereby improving the efficiency of repair scheme generation.

[0159] The embodiment of the present application further provides a computer readable storage medium, wherein the computer readable storage medium stores a computer program for electronic data exchange, and the computer program causes a computer to execute part or all steps of any method described in the above method embodiments, and the computer includes a diagnostic device.

[0160] The embodiment of the present application further provides a computer program product, which includes a non-transitory computer readable storage medium storing a computer program, and the computer program is operable to cause a computer to execute part or all steps of any method described in the above method embodiments. The computer program product can be a software installation package, and the computer includes a diagnostic device.

[0161] It should be noted that, for each of the above embodiments, in order to simply describe, each is expressed as a combination of a series of actions. Those skilled in the art should know that the present application is not limited to the order of actions described, because some steps in the embodiments of the present application can be performed in other order or simultaneously. In addition, those skilled in the art should know that the embodiments described in the specification all belong to preferred embodiments, and the actions, steps, modules or units involved are not necessarily required in the embodiments of the present application.

[0162] In the above embodiments, the description of each embodiment of the embodiments of the present application has its own focus, and the parts not described in detail in an embodiment can be referred to the relevant description of other embodiments.

[0163] Those skilled in the art can understand that all or part of the above-mentioned embodiment methods can be implemented by a computer program, and the program can be stored in a computer readable storage medium. When the program is executed, it can include the processes of the above-mentioned method embodiments. The storage medium includes ROM, RAM, magnetic disk or optical disk and other various storage media which can store program codes.

[0164] The steps of a method or algorithm described in connection with the embodiments disclosed herein can be embodied directly in hardware, in a software module executed by a processor, or in a combination of the two. A software module can reside in RAM, flash memory, ROM, EPROM, EEPROM, registers, hard disk, a removable media, a CD-ROM, or any other form of storage medium known in the art. An exemplary storage medium is coupled to the processor such that the processor can read information from, and write information to, the storage medium. In the alternative, the storage medium can be integral to the processor. The processor and the storage medium can reside in an ASIC. Alternatively, the processor and the storage medium can be located in a terminal device or an access device. The processor and the storage medium can also be located in any other

[0165] Those skilled in the art will recognize that the functions described in one or more embodiments disclosed herein can be implemented in whole or part by software, hardware, firmware, or any combination thereof. Such software can be implemented in a computer program product which can be executed by one or more computers. The computer program product includes one or more computer instructions. When the computer instructions are loaded and executed by a computer, the whole or part of the processes or functions described in the embodiments disclosed herein are generated. The computer can be a general purpose computer, a special purpose computer, a computer network, or other programmable apparatus. The computer instructions can be stored in a computer readable storage medium or transferred from one computer readable storage medium to another computer readable storage medium. For example, the computer instructions can be transferred from one website, computer, server, or data center to another website, computer, server, or data center through a wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) manner. The computer readable storage medium can be any available medium that can be accessed by a computer or a data storage device such as a server, data center, etc. which includes one or more available media sets. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., digital video disc (DVD)), or a semiconductor medium (e.g., solid state disk (SSD)), etc.

[0166] The various modules / units included in the various devices and products described in the above embodiments can be software modules / units or hardware modules / units, or partially software modules / units and partially hardware modules / units. For example, for the various devices and products applied to or integrated into a chip, the various modules / units included therein can all be implemented in the form of hardware such as circuitry, or at least some of the modules / units can be implemented in the form of software programs running on a processor integrated in the chip, and the remaining (if any) modules / units can be implemented in the form of hardware such as circuitry; for the various devices and products applied to or integrated into a chip module, the various modules / units included therein can all be implemented in the form of hardware such as circuitry, and different modules / units can be located in the same component (e.g., a chip, a circuit module, etc.) or different components of the chip module, or at least some of the modules / units can be implemented in the form of software programs running on a processor integrated in the chip module, and the remaining (if any) modules / units can be implemented in the form of hardware such as circuitry; for the various devices and products applied to or integrated into a terminal device, the various modules / units included therein can all be implemented in the form of hardware such as circuitry, and different modules / units can be located in the same component (e.g., a chip, a circuit module, etc.) or different components of the terminal device, or at least some of the modules / units can be implemented in the form of software programs running on a processor integrated in the terminal device, and the remaining (if any) modules / units can be implemented in the form of hardware such as circuitry.

[0167] The above detailed description of the specific implementation of the embodiments of the present application has further explained the purposes, technical solutions, and beneficial effects of the embodiments of the present application. It should be understood that the above description is only a specific implementation of the embodiments of the present application and is not intended to limit the protection scope of the embodiments of the present application. Any modification, equivalent replacement, improvement, etc. made on the basis of the technical solutions of the embodiments of the present application shall be included in the protection scope of the embodiments of the present application.

Claims

1. A method for generating maintenance plans based on diagnostic reports, characterized in that, Applied to a diagnostic device, the method comprises: Obtaining vehicle attribute data of a target vehicle; Extracting fault codes and fault detection parameters from the diagnostic report; Inputting the vehicle attribute data, the fault codes and the fault detection parameters into a preset first fault repair model to obtain n fault repair schemes; n is an integer greater than 1; Determining the repair success rate and the repair cost corresponding to each fault repair scheme in the n fault repair schemes to obtain n repair success rates and n repair costs; Determining a target repair scheme from the n fault repair schemes according to the n repair success rates and the n repair costs; Displaying the target fault repair scheme on the diagnostic device.

2. The method of claim 1, wherein, The extracting fault codes and fault detection parameters from the diagnostic report comprises: Identifying fault codes in the diagnostic report using a preset entity recognition model to obtain the fault codes; Determining detection parameters in the diagnostic report to obtain first detection parameters; Mapping the detection parameters corresponding to the fault codes from a preset vehicle fault knowledge graph to obtain first fault detection parameters; Determining the fault detection parameters according to the first detection parameters and the first fault detection parameters.

3. The method of claim 2, wherein, The determining the fault detection parameters according to the first detection parameters and the first fault detection parameters comprises: Determining the fault type corresponding to the first fault detection parameters; Screening the parameters corresponding to the fault type from the first detection parameters to obtain the fault detection parameters.

4. The method according to any one of claims 1 to 3, characterized in that, The determining the repair success rate and the repair cost corresponding to each fault repair scheme in the n fault repair schemes to obtain n repair success rates and n repair costs comprises: Determining the vehicle model year according to the vehicle attribute data; Finding m first repair schemes corresponding to the fault codes from a preset repair case library; m is greater than or equal to n; Screening n second repair schemes corresponding to the vehicle model year from the m first repair schemes; Statistically obtaining the n repair success rates by calculating the ratio of the number of times that each second repair scheme in the n second repair schemes is successfully completed to the total number of times that the corresponding second repair scheme in the n second repair schemes is completed within a preset time period; Determining the n repair procedures corresponding to each fault repair scheme according to the n fault repair schemes to obtain the n repair procedures; Determining the n repair costs corresponding to each repair procedure in the n repair procedures.

5. The method of claim 4, wherein, The determining the n repair costs corresponding to each repair procedure in the n repair procedures comprises: Determining a target repair man-hour and a target replacement part according to a target repair procedure; the target repair procedure is any one of the n repair procedures; Obtaining the cost price of the target replacement part and the replacement technical cost of the target replacement part; Determining a first repair cost according to the cost price of the target replacement part and the replacement technical cost of the target replacement part; Determining a second repair cost corresponding to the target repair man-hour; determine a third maintenance cost corresponding to the target maintenance procedure based on a preset operation risk condition; determine a maintenance cost corresponding to the target maintenance procedure according to the first maintenance cost, the second maintenance cost and the third maintenance cost.

6. The method according to any one of claims 1 to 3, wherein The determining of the target maintenance scheme from the n fault maintenance schemes according to the n maintenance success rates and the n maintenance costs comprises: determine maintenance recommendation values corresponding to the n maintenance costs based on a mapping relationship between preset maintenance costs and maintenance scheme recommendation values, to obtain n first maintenance scheme recommendation values; determine maintenance recommendation values corresponding to the n maintenance success rates based on a mapping relationship between preset maintenance success rates and maintenance scheme recommendation values, to obtain n second maintenance scheme recommendation values; determine n target recommendation values according to a preset weight calculation formula, a preset weight distribution coefficient, the n first maintenance scheme recommendation values and the n second maintenance scheme recommendation values; determine a maximum target recommendation value in the n target recommendation values, and obtain a maintenance scheme corresponding to the maximum target recommendation value as the target maintenance scheme.

7. The method of any one of claims 1-3, wherein, After the determining of the target maintenance scheme from the n fault maintenance schemes according to the n maintenance success rates and the n maintenance costs, the method further comprises: vectorize the vehicle attribute data, the fault code and the fault detection parameter to obtain first vector data; obtain a first training set of the first fault maintenance model; add the first vector data and the target maintenance scheme to the first training set to obtain a second training set; retrain the first fault maintenance model based on the second training set to obtain a second fault maintenance model.

8. A device for generating maintenance plans based on diagnostic reports, characterized in that, The device is applied to a diagnostic equipment, and the device comprises: an obtaining module configured to obtain vehicle attribute data of a target vehicle; a control module configured to extract a fault code and a fault detection parameter from the diagnostic report, and input the vehicle attribute data, the fault code and the fault detection parameter into a preset first fault maintenance model to obtain n fault maintenance schemes; n is an integer greater than 1; a determining module configured to determine a maintenance success rate and a maintenance cost corresponding to each fault maintenance scheme in the n fault maintenance schemes to obtain n maintenance success rates and n maintenance costs, and determine a target maintenance scheme from the n fault maintenance schemes according to the n maintenance success rates and the n maintenance costs; a display module configured to display the target fault maintenance scheme on the diagnostic equipment.

9. A diagnostic device, characterized by comprise: a processor, a memory, a communication interface and one or more programs; the one or more programs are stored in the memory and configured to be executed by the processor, and the programs comprise instructions for performing steps in the method of any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer readable storage medium stores a computer program, and the computer program comprises program instructions, which, when executed by a processor, cause the processor to execute the method of any one of claims 1-7. The computer readable storage medium stores a computer program, and the computer program comprises program instructions, which, when executed by a processor, cause the processor to execute the method of any one of claims 1-7.

Citation Information

Cited By

  • Diagnostic rule chain-based motor train unit intelligent operation and maintenance method, system and equipment

    CN121120034A