Remote fault diagnosis method, device, equipment, storage medium and program product

Abstract

Embodiments of the present application provide a remote fault diagnosis method, device, equipment, storage medium and program product. The method comprises: obtaining log information associated with a fault vehicle; performing data processing on the log information by using a generative model to obtain a preliminary analysis result associated with the fault vehicle; performing information interaction with a user based on the preliminary analysis result to obtain interaction information; determining a remote diagnosis result associated with the fault vehicle based on the preliminary analysis result and the interaction information, wherein the remote diagnosis result comprises one or more of a fault cause, a fault node and a repair suggestion. The log utilization depth and the user scenario information participation level can be improved, and the accuracy and diagnosis efficiency of remote positioning of complex faults can be improved.

Description

Technical Field

[0001] This application relates to artificial intelligence, and more particularly to a remote fault diagnosis method, apparatus, device, storage medium, and program product. Background Technology

[0002] In the field of modern intelligent vehicles, complex malfunctions may occur during vehicle operation due to factors such as hardware aging, software abnormalities, communication interruptions, or environmental interference.

[0003] In related technologies, fault diagnosis generally relies on users to actively send their vehicles to repair shops, where repair personnel use specialized diagnostic equipment to read fault codes and log data for manual analysis.

[0004] However, when using the above method for fault diagnosis, repair personnel can only analyze based on limited fault codes and static logs. Key data on intermittent or scenario-dependent faults may be missing after the vehicle is sent to a repair shop, affecting the reliability of the diagnostic results. Summary of the Invention

[0005] The remote fault diagnosis method, apparatus, equipment, storage medium, and program products provided in this application are used to achieve the technical effect of remotely diagnosing vehicle faults and improving the accuracy and real-time performance of fault diagnosis.

[0006] In a first aspect, embodiments of this application provide a remote fault diagnosis method, including:

[0007] Obtain log information associated with the faulty vehicle;

[0008] By processing the log information using a generative model, preliminary analysis results of the association between the faulty vehicles are obtained.

[0009] Based on the preliminary analysis results, information is exchanged with the user to obtain interactive information;

[0010] Based on the preliminary analysis results and interactive information, the remote diagnostic results associated with the faulty vehicle are determined. The remote diagnostic results include one or more of the following: fault cause, fault node, and repair suggestions.

[0011] In one possible implementation, obtaining the log information associated with the faulty vehicle includes:

[0012] In response to receiving a fault diagnosis request triggered by a user, obtain the full log information of the faulty vehicle within the time range associated with the fault diagnosis request;

[0013] Alternatively, obtaining the log information associated with the faulty vehicle includes:

[0014] Obtain the log information uploaded by the faulty vehicle, including logs related to the current fault that are automatically uploaded when the faulty vehicle experiences a malfunction.

[0015] In one possible implementation, before processing the log information using a generative model to obtain preliminary analysis results related to the faulty vehicles, the method further includes:

[0016] Obtain a training dataset, which includes multiple training data pairs, each training data pair including vehicle-associated training logs and vehicle-associated fault logs, fault events, and fault association information.

[0017] The training dataset and preset prompt text are input into the generative model, and the generative model is fine-tuned.

[0018] In one possible implementation, the step of interacting with the user based on the preliminary analysis results to obtain interaction information includes:

[0019] Based on the preliminary analysis results, at least one interactive question is identified that is associated with the current fault event of the faulty vehicle. The interactive question is generated by the generative model based on the preliminary analysis results.

[0020] Based on the at least one interactive question, data interaction is performed with the user to obtain the response content generated by the user based on the interactive question, and the response content is determined as the interactive information.

[0021] In one possible implementation, determining the remote diagnostic results associated with the faulty vehicle based on the preliminary analysis results and interactive information includes:

[0022] Obtain a fault case library, which includes multiple sets of mapping data pairs. The mapping data pairs include historical analysis results associated with historical cases, historical interaction information, and diagnostic results associated with historical cases.

[0023] In the fault case database, historical cases corresponding to the preliminary analysis results and interaction information are identified, and the diagnostic results corresponding to the historical cases are determined as the remote diagnostic results.

[0024] In one possible implementation, determining the historical cases corresponding to the preliminary analysis results and interaction information in the fault case database includes:

[0025] Calculate the similarity between the preliminary analysis results and the interaction information and the historical analysis results and historical interaction information associated with each historical case in the fault case database;

[0026] Historical cases whose similarity meets the preset conditions are identified as historical cases corresponding to the preliminary analysis results and interaction information.

[0027] In one possible implementation, determining the remote diagnostic results associated with the faulty vehicle based on the preliminary analysis results and interactive information includes:

[0028] The preliminary analysis results and the interaction information are input into the generative model to obtain the remote diagnostic results generated by the generative model.

[0029] In one possible implementation, after determining the remote diagnostic results associated with the faulty vehicle based on the preliminary analysis results and interaction information, the method further includes:

[0030] The fault type associated with the faulty vehicle is determined based on the remote diagnostic results;

[0031] The faulty vehicle is handled using a fault handling method associated with the fault type.

[0032] In one possible implementation, the fault handling of the faulty vehicle using a fault handling method associated with the fault type includes:

[0033] If the fault type is a software fault, the faulty vehicle will be repaired remotely.

[0034] In response to the fault type being a hardware fault, repair information is generated based on the faulty hardware. The repair information includes faulty hardware association information and repair suggestions. The repair information is then sent to the user's terminal device so that the user can repair the fault based on the repair information.

[0035] Secondly, embodiments of this application provide a remote fault diagnosis device, comprising:

[0036] The acquisition module is used to acquire log information associated with the faulty vehicle;

[0037] The processing module is used to process the log information through a generative model to obtain preliminary analysis results of the association of the faulty vehicles;

[0038] The interaction module is used to interact with the user based on the preliminary analysis results and obtain interactive information;

[0039] The diagnostic module is used to determine the remote diagnostic results associated with the faulty vehicle based on the preliminary analysis results and interactive information. The remote diagnostic results include one or more of the following: fault cause, fault node, and repair suggestions.

[0040] Thirdly, embodiments of this application provide an electronic device, including: a memory and a processor;

[0041] The memory stores computer-executed instructions;

[0042] The processor executes computer execution instructions stored in the memory, causing the processor to perform the first aspect and / or various possible implementations of the first aspect as described above.

[0043] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the first aspect and / or various possible implementations of the first aspect.

[0044] Fifthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the first aspect and / or various possible implementations of the first aspect.

[0045] The remote fault diagnosis method, apparatus, device, storage medium, and program product provided in this application can extract fault-related analysis clues from log data by acquiring log information associated with faulty vehicles and obtaining preliminary analysis results based on generative models. By interacting with users based on the preliminary analysis results, information related to the actual vehicle usage scenario and fault performance can be further supplemented. Then, based on the preliminary analysis results and interactive information, one or more remote diagnostic results including fault cause, fault node, and repair suggestions can be determined, thereby improving the accuracy of locating and the efficiency of diagnosing complex vehicle faults. Attached Figure Description

[0046] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0047] Figure 1 This is a diagram of the system architecture upon which this application is based;

[0048] Figure 2 A flowchart illustrating the remote fault diagnosis method provided in the embodiments of this application;

[0049] Figure 3 A flowchart illustrating a remote fault diagnosis method provided in another embodiment of this application;

[0050] Figure 4 A flowchart illustrating a remote fault diagnosis method provided in another embodiment of this application;

[0051] Figure 5A flowchart illustrating a remote fault diagnosis method provided in another embodiment of this application;

[0052] Figure 6 This is a schematic diagram of the structure of the remote fault diagnosis device provided in the embodiments of this application;

[0053] Figure 7 A schematic diagram of the structure of the electronic device provided in this application.

[0054] The accompanying drawings have illustrated specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to specific embodiments. Detailed Implementation

[0055] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0056] Remote vehicle fault diagnosis falls under the field of intelligent connected vehicles and in-vehicle data analysis technology. It is typically applied to remote troubleshooting scenarios involving new energy vehicles or vehicles with remote communication capabilities that experience power anomalies, communication failures, or functional malfunctions during operation. This scenario generally involves a data acquisition module on the vehicle side, a cloud-based analysis platform, and a user-side interactive terminal to enable fault information transmission and diagnostic support without the vehicle needing to be physically present at a service station.

[0057] Current vehicle fault diagnosis methods typically involve collecting fault codes, operating logs, or system status information from the vehicle and uploading them to the cloud, or having a repair shop analyze log data exported after the vehicle arrives at the shop. These methods mainly rely on preset rules, fault code matching, and limited log fragments to determine the cause of the fault. While these solutions can handle some common faults, their diagnostic process largely revolves around static data.

[0058] In practical applications, intermittent faults, scenario-dependent faults, and multi-module related anomalies often cannot be accurately identified solely through fault codes or limited logs. Due to the lack of information on operational behavior, driving status, or environmental conditions at the time of the fault, cloud-based analysis results tend to remain at the module level, making it difficult to pinpoint the specific fault node. This not only leads to misdiagnosis and missed diagnosis but also prolongs the remote diagnostic cycle and reduces the specificity of subsequent repair recommendations.

[0059] Therefore, how to simultaneously improve the depth of log information utilization and the degree of participation of user scenario information during remote diagnosis, thereby improving the accuracy of locating complex faults and the efficiency of diagnosis, has become an urgent technical problem to be solved.

[0060] In addressing the aforementioned technical problems, the inventors discovered that by acquiring log information associated with the faulty vehicle, using a generative model to process the log information to obtain preliminary analysis results, and then interacting with the user based on these preliminary analysis results, the remote diagnostic results are determined by combining the preliminary analysis results and the interactive information. This results in the output of one or more of the following: fault cause, fault node, and repair suggestions. This method can be applied to a remote diagnostic architecture consisting of a vehicle terminal, a cloud-based diagnostic platform, and a user interaction terminal to improve the remote analysis capabilities for complex vehicle faults.

[0061] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will be described below with reference to the accompanying drawings.

[0062] Figure 1 This is a system architecture diagram on which this application is based, such as Figure 1 As shown, the system architecture upon which this application is based includes at least a server 11, a faulty vehicle 12, and a terminal device 13. The server 11 is equipped with a remote fault diagnosis device, which can be written in languages ​​such as C / C++, Java, Shell, or Python.

[0063] Based on the above system architecture, the faulty vehicle 12 or terminal device 13 can initiate a fault diagnosis request. The server 11 can obtain the log information associated with the faulty vehicle 12 and interact with the user through the vehicle's infotainment system or terminal device 13 to achieve remote fault diagnosis based on the log information and interaction information.

[0064] Figure 2 This is a flowchart illustrating the remote fault diagnosis method provided in the embodiments of this application, as shown below. Figure 2 As shown, the method includes:

[0065] Step 201: Obtain the log information associated with the faulty vehicle.

[0066] In this embodiment, log information serves as input data for fault diagnosis, recording the vehicle's operating status and abnormal phenomena at the time of the fault. The faulty vehicle can be a new energy vehicle equipped with an onboard controller, onboard communication module, and data acquisition capabilities, or other vehicles with remote communication capabilities. The executing entity can be a cloud-based diagnostic platform or a remote fault diagnosis server connected to the cloud-based diagnostic platform.

[0067] Optionally, fault-related log information can be obtained. The log information may include one or more of the following: operation log, system log, communication log, and diagnostic information. The operation log is used to reflect the vehicle's operating parameters during the fault period. The system log is used to reflect controller state switching, task abnormalities, software errors, and restart records. The communication log is used to reflect the message sending and receiving status, timeout status, and packet loss status of each control node in the vehicle network. The diagnostic information is used to reflect fault codes, fault freeze frames, and self-test results.

[0068] To ensure that subsequent data processing can proceed, basic data processing can be performed after obtaining log information, so that the log information can be associated with the current diagnostic task and used as input for subsequent generative model processing.

[0069] By acquiring log information related to the fault, rather than just isolated fault codes or limited fragments, subsequent processing can utilize relevant operational records within the fault scenario. For intermittent faults, scenario-dependent faults, and multi-module correlated anomalies, this log acquisition method provides a sufficient contextual basis to support correlation analysis, allowing subsequent models to move beyond static judgments based on a single module.

[0070] Step 202: Process the log information using a generative model to obtain preliminary analysis results on the association of faulty vehicles.

[0071] In this embodiment, a generative model is used to parse, extract, and perform correlation analysis on log information to identify abnormal patterns, fault clues, and potential correlation information from the logs. The generative model includes, but is not limited to, any network model capable of performing preliminary fault analysis and target log filtering based on input logs, such as a large language model.

[0072] The preliminary analysis results are intermediate diagnostic conclusions formed after the generative model processes the logs. They are used to provide a basis for subsequent user interaction and final diagnosis. They may include one or more of the following: suspected faulty modules, faulty nodes, fault time range, key abnormal event chains, and problem points to be confirmed.

[0073] Optionally, after obtaining the log information, the logs can be organized first for processing by the generative model. Then, the processed log information is input into the generative model, which analyzes the anomaly and correlation information in the logs and outputs preliminary analysis results.

[0074] In one possible embodiment, the output of the model processing results can be constrained according to the diagnostic task to obtain analysis results relevant to the current fault diagnosis. During model processing, on the one hand, explicit anomalies in the logs are extracted, such as fault code triggering, bus offline, sensor value out-of-bounds, controller restart, and actuator response failure. On the other hand, the generative model can analyze the correlation information in the logs, such as the state changes and mutual influences of different modules before and after the fault occurs.

[0075] The preliminary analysis results output by the generative model may include, for example, suspected abnormal communication between a system and the controller leading to power limitation, suspected lack of response from a control node during a certain period of time, and continuous message timeouts accompanied by specific operations before the fault is triggered.

[0076] To make the preliminary analysis results usable in subsequent processes, the model output can be further converted into intermediate results. Here, the fault node is used to locate the specific component, module, or node in the vehicle where the anomaly occurred. If the model outputs multiple candidate conclusions, the platform can retain the relevant candidates as preliminary analysis results.

[0077] By analyzing log relationships using generative models, not only are explicit fault code reports processed, but also related behavioral information before and after a fault occurs. This allows for the generation of preliminary analysis results with subsequent interaction guidance, providing a direct basis for narrowing down the scope of the fault.

[0078] Step 203: Based on the preliminary analysis results, conduct information interaction with the user to obtain interactive information.

[0079] In this embodiment, information interaction is used to supplement human-perceived information in vehicle fault scenarios. The interactive information is supplementary content provided by the user during the information interaction process, which is used to make up for the problem that the log data is insufficient in describing the fault scenario.

[0080] Optionally, after obtaining preliminary analysis results, information can be exchanged with the user in conjunction with the current diagnostic task. The user interaction terminal can be an in-vehicle interface, a mobile application, a web-based diagnostic page, or a customer service assistance terminal. The information exchange content can be set around the operating steps, environmental conditions, triggering conditions, and external perceived phenomena when the fault occurred. For example, it can ask the user about their operating procedures before and after the fault occurred, the vehicle's environment, whether there were any abnormal noises, whether there were any instrument warnings, whether the fault is reproducible, and the operating sequence for reproducing it.

[0081] Information interaction can take one or more forms, including single-choice, multiple-choice, numerical input, time input, and natural language description input. The platform can organize user feedback to obtain interactive information that can be used for subsequent diagnosis. To ensure the quality of information interaction, the platform can also initiate supplementary inquiries when information is insufficient.

[0082] Once the interactive information is generated, the platform binds it to the current diagnostic task and stores it in a unified format. By interacting with the user, the remote diagnostic process not only relies on vehicle-side data but also incorporates scenario factors that the user can perceive when a fault occurs but may not be fully recorded in the logs, such as operating habits, changes in road conditions, environmental triggering conditions, and the reproducibility of the fault. This provides the necessary basis for subsequent differentiation among multiple candidate conclusions.

[0083] Step 204: Based on the preliminary analysis results and interactive information, determine the remote diagnostic results associated with the faulty vehicle. The remote diagnostic results include one or more of the following: fault cause, fault node, and repair suggestions.

[0084] In this embodiment, the remote diagnostic result is the final diagnostic output generated for the faulty vehicle, which is used to provide a basis for fault handling. The fault cause is used to characterize the cause of the vehicle's abnormality, the fault node is used to characterize the target component, module or control node related to the abnormality, and the repair suggestion is used to characterize the handling method for the fault cause and the fault node.

[0085] Optionally, the preliminary analysis results and interaction information can be comprehensively processed to determine the remote diagnostic results. During the comprehensive processing, the abnormal clues obtained from log analysis can be matched with the scenario information reported by the user, and candidate conclusions can be screened to output a diagnostic conclusion related to the currently faulty vehicle.

[0086] In one possible embodiment, the platform can generate comprehensive information for fault determination based on preliminary analysis results and interactive information, and output the final diagnostic result accordingly. For repair suggestions in the remote diagnostic results, corresponding processing suggestions can be given based on the identified fault causes and fault nodes.

[0087] Finally, the platform outputs the remote diagnostic results to the user terminal and maintenance support terminal. The output can be in the form of a combination of structured and descriptive text, and should at least include a description of the cause of the fault, the location of the fault node, a summary of the corresponding evidence, and repair suggestions. If there are multiple possible causes in the final conclusion, the platform can output them in order of relevance.

[0088] By combining preliminary analysis results with interactive information in fault determination, the final diagnosis no longer stops at the module-level initial judgment, but can further pinpoint the cause of the anomaly and the target node by combining real-world vehicle usage scenarios, and generate handling suggestions corresponding to the current fault status, thereby completing the closed loop of remote fault diagnosis.

[0089] The remote fault diagnosis method provided in this embodiment obtains fault-related log information, performs log parsing and anomaly correlation by a generative model, and then combines the fault scenario information supplemented by the user to identify and converge candidate conclusions. This enables the generation of executable remote diagnostic outputs for intermittent faults, scenario-dependent faults, and multi-module related anomalies.

[0090] Optionally, based on any of the above embodiments, step 201 includes:

[0091] In response to a user-triggered fault diagnosis request, obtain full log information of the faulty vehicle within the time range associated with the fault diagnosis request.

[0092] Alternatively, step 201 includes:

[0093] Obtain log information uploaded by the faulty vehicle. The log information includes logs related to the current fault that are automatically uploaded when the faulty vehicle experiences a malfunction.

[0094] In this embodiment, the vehicle-side log collection module continuously records controller status, communication status, sensor readings, alarm information, and fault code information, and archives them by timestamp. When a user triggers a fault diagnosis request, the cloud-based diagnostic platform determines the target time range based on the vehicle identifier and timestamp carried in the request, and sends a log retrieval command to the vehicle. The vehicle retrieves the corresponding historical logs from its local storage according to the time range and uploads them to form a complete log information. If the vehicle is configured with a fault self-triggered upload mechanism, the vehicle automatically caches the current fault-related logs when it detects a fault code, communication interruption, or critical module abnormality, and uploads them immediately after network recovery or fault confirmation. The uploaded content includes key operational segments before and after the fault occurred, pre-abnormality state data, and instantaneous fault records.

[0095] When using the full log acquisition method within a time range, the cloud can obtain continuous context before and after the fault; when using the automatic fault upload method, the cloud can directly obtain key logs corresponding to the current fault, thus providing complete and targeted raw input for subsequent generative model analysis.

[0096] The remote fault diagnosis method provided in this embodiment ensures the integrity of the information related to the fault before and after it by acquiring the full log triggered by the fault diagnosis request, and the automatic fault upload mechanism can retain key abnormal fragments in a timely manner when the fault occurs. Both of these make the log input closer to the real fault scene, thereby improving the accuracy of subsequent identification of fault causes, fault nodes and repair suggestions.

[0097] Furthermore, based on any of the above embodiments, before step 202, the method further includes:

[0098] Obtain the training dataset, which includes multiple training data pairs. Each training data pair includes vehicle-related training logs, vehicle-related fault logs, fault events, and fault association information.

[0099] Input the training dataset and preset prompt text into the generative model, and then fine-tune the generative model.

[0100] In this embodiment, a training dataset can be obtained. The training dataset includes multiple training data pairs, which include vehicle-related training logs, vehicle-related fault logs, fault events, and fault association information.

[0101] Generative models can employ pre-trained models with text understanding and generation capabilities. During fine-tuning, the model calculates the deviation between the predicted output and the target output based on training data, and updates the model parameters accordingly. This allows the model to generate preliminary analysis results by combining the fault association patterns formed during training when receiving faulty vehicle log information. This process enables the model to learn the correspondence between abnormal features, fault event labels, and related information in the vehicle logs during the training phase, thereby more accurately identifying key fault-related information during actual diagnosis.

[0102] The remote fault diagnosis method provided in this embodiment enhances the generative model's ability to understand vehicle logs and model fault associations by fine-tuning the training dataset and prompt text. This allows the model to output preliminary analysis results that are more consistent with the vehicle scenario when receiving log information related to faulty vehicles, and provides a foundation for subsequent information interaction and determination of remote diagnosis results.

[0103] Figure 3 This is a flowchart illustrating a remote fault diagnosis method provided in another embodiment of this application. Based on any of the above embodiments, such as... Figure 3 As shown, step 203 includes:

[0104] Step 301: Based on the preliminary analysis results, determine at least one interactive question associated with the current fault event of the faulty vehicle. The interactive question is generated by the generative model based on the preliminary analysis results.

[0105] Step 302: Interact with the user based on at least one interactive question, obtain the user's response content generated based on the interactive question, and determine the response content as interactive information.

[0106] In this embodiment, after obtaining the preliminary analysis results, the results are input into the prompt template of the generative model. The prompt template includes at least the fault event identifier, the current abnormal characteristics, and the information category to be supplemented. Based on this, the generative model generates at least one interactive question associated with the current fault event.

[0107] Interactive questions can be generated for different information dimensions of the same fault event. For example, questions can be asked whether a charging operation was performed before the fault occurred, whether the vehicle was stationary or in motion when the fault occurred, and whether there were any warning prompts on the instrument panel. This is to ensure that user feedback can cover the key context required for fault localization.

[0108] Furthermore, after the interactive questions are sent to the user's interactive terminal, the system can receive user responses through a message interface, voice interface, or form interface. The responses are then structured and parsed to extract status words, time information, operational information, and environmental information related to the fault event. The parsed responses are identified as interactive information and correlated with the preliminary analysis results. This information serves as supplementary evidence in subsequent diagnostic processes to determine the cause, fault location, or repair recommendations. If the same fault event corresponds to multiple interactive questions, the system can send them sequentially in a preset order until interactive information meeting diagnostic requirements is collected.

[0109] The remote fault diagnosis method provided in this embodiment uses a generative model that can dynamically generate questions for the current fault event based on preliminary analysis results. The user's response is transformed into interactive information after being transmitted back through information interaction. This allows remote diagnosis to go beyond log fragments and incorporate the user's actual feedback on the fault scenario into the analysis process, thereby improving the accuracy of identifying intermittent faults and scenario-dependent faults and shortening the time required for fault location.

[0110] Figure 4 This is a flowchart illustrating a remote fault diagnosis method provided in another embodiment of this application. Based on any of the above embodiments, such as... Figure 4 As shown, step 204 includes:

[0111] Step 401: Obtain the fault case library, which includes multiple sets of mapping data pairs. The mapping data pairs include historical analysis results associated with historical cases, historical interaction information, and diagnostic results associated with historical cases.

[0112] Step 402: Identify the historical cases in the fault case library that correspond to the preliminary analysis results and interactive information, and determine the diagnostic results corresponding to the historical cases as remote diagnostic results.

[0113] In this embodiment, the fault categories, abnormal modules, abnormal feature parameters in the preliminary analysis results and the text content, selection items or numerical feedback in the interaction information can be structured to form the current query vector, and the query vector can be compared with the fault case library.

[0114] The fault case database can be organized using key-value indexes, vector retrieval indexes, or hierarchical matching indexes. Historical analysis results and historical interaction information in each mapped data pair can be pre-encoded as comparable features. The system determines candidate historical cases based on feature similarity, semantic consistency, or matching scores. When multiple candidate historical cases exist, the historical case with the highest comprehensive matching score can be selected, or the historical case closest to the current fault scenario can be determined from historical cases whose scores reach a preset threshold. The diagnostic results corresponding to this historical case are then directly output as the current remote diagnostic results.

[0115] In some implementations, the fault case library can be deployed on a cloud server. This library can consist of database tables, vector index files, or a hybrid retrieval structure, enabling rapid query completion after receiving the current preliminary analysis results and interactive information. If the diagnostic results corresponding to historical cases contain multiple diagnostic items, the system can output the entire set of corresponding diagnostic items as a remote diagnostic result according to case association rules, or only output the diagnostic item that best matches the current query content.

[0116] The remote fault diagnosis method provided in this embodiment can directly reuse historical diagnosis experience for the current fault diagnosis, and incorporate preliminary analysis results and interactive information into the matching criteria, thereby improving the accuracy and stability of the remote diagnosis results.

[0117] Furthermore, based on any of the above embodiments, step 403 includes:

[0118] Calculate the similarity between the preliminary analysis results and the interaction information and the historical analysis results and historical interaction information associated with each historical case in the fault case library.

[0119] Historical cases whose similarity meets the preset conditions are identified as historical cases corresponding to the preliminary analysis results and interaction information.

[0120] In this embodiment, each set of mapping data pairs in the fault case library can be composed of historical analysis results, historical interaction information, and diagnostic results associated with historical cases, and the fault case library can be established as a searchable data index table.

[0121] Based on the current preliminary analysis results and the historical analysis results of each historical case, the two can be converted into structured feature vectors. The feature vectors include faulty component identifiers, abnormal phenomenon descriptions, fault code sequences, time-series log fragment labels, and confidence distributions, and are calculated using cosine similarity, edit distance similarity, or weighted matching similarity.

[0122] Optionally, for the current interaction information and the historical interaction information of each historical case, the user's response content, the operation behavior when the fault occurred, the vehicle's operating status, and environmental conditions can be segmented and normalized, and then similarity can be calculated with the structured features corresponding to the historical interaction information. The two types of similarity can be calculated separately and then weighted and fused to obtain the comprehensive matching score of the historical case.

[0123] When the overall matching score is greater than or equal to a preset threshold, or falls within a preset quantity range in the sorting results, the corresponding historical case is identified as a historical case corresponding to the preliminary analysis results and interaction information. The preset conditions can be written into the rule configuration file of the cloud-based diagnostic platform and can be dynamically adjusted based on vehicle model, fault type, or case library size. Through this mapping and filtering, the system can output a set of historical cases most closely related to the current fault and use their corresponding diagnostic results as candidate criteria for remote diagnostic results.

[0124] The remote fault diagnosis method provided in this embodiment incorporates the current analysis results and user feedback into the historical case retrieval process simultaneously. This allows case matching to no longer rely solely on a single log feature, but instead combines fault semantics and scenario semantics for joint judgment. This improves the accuracy of historical case location and ensures that the subsequent output of fault causes, fault nodes, and repair suggestions maintains a higher consistency with the current vehicle status.

[0125] Optionally, based on any of the above embodiments, step 204 includes:

[0126] The preliminary analysis results and interactive information are input into the generative model to obtain the remote diagnostic results generated by the generative model.

[0127] In this embodiment, after obtaining the preliminary analysis results and interaction information, the two are uniformly converted into a text sequence or structured cue vector that the model can parse, and then input into the inference end of the generative model.

[0128] The inference engine reweights candidate fault modules from the preliminary analysis results based on contextual relationships, and performs semantic completion by incorporating scenario constraints from interactive information, thereby generating diagnostic conclusions. The output of the generative model can be in the form of natural language text or in a structured result format that includes fault items, confidence scores, and suggestions.

[0129] Optionally, the generative model can also be a model based on the Transformer architecture. This application does not limit this choice because such models have strong context modeling capabilities and are suitable for integrating scattered analytical information into complete diagnostic conclusions. In practical applications, other models of this component can also be selected. This application does not limit this choice either.

[0130] The generation process of this remote diagnostic result is essentially a joint semantic inference process of the preliminary analysis results and the interactive information. The preliminary analysis results provide the basis for fault location, the interactive information provides supplementary constraints on the user scenario at the time of the fault, and the generative model models the correlation between the two types of inputs and outputs the final conclusion. This allows the remote diagnostic result to go beyond the initial judgment corresponding to a single log fragment and cover a more complete fault context.

[0131] The remote fault diagnosis method provided in this embodiment generates remote diagnosis results collaboratively by a generative model based on preliminary analysis results and interactive information. This can improve the completeness and consistency of diagnostic conclusions in complex fault scenarios and make the output results more consistent with the actual operating status of the vehicle and user feedback information.

[0132] Figure 5 This is a flowchart illustrating a remote fault diagnosis method provided in another embodiment of this application. Based on any of the above embodiments, such as... Figure 5 As shown, the method also includes:

[0133] Step 501: Determine the fault type associated with the faulty vehicle based on the remote diagnostic results.

[0134] Step 502: Use the fault handling method associated with the fault type to handle the faulty vehicle.

[0135] In this embodiment, after generating the remote diagnostic results, the results are input into the fault type determination module for classification and identification. The determination module can be implemented based on rule mapping, classification model or case matching.

[0136] If the remote diagnostic results include abnormal control parameters, abnormal software versions, or abnormal communication reconnection that can be corrected by remote commands, it is determined to be a software fault type, and a corresponding remote repair command is generated, such as resetting the control unit, resending configuration parameters, issuing a patch package, or triggering a remote restart; if the remote diagnostic results indicate that the hardware component is damaged, the physical connection is abnormal, or the parts need to be replaced, it is determined to be a hardware fault type, and repair information is generated. The repair information includes at least the name of the faulty component, the location of the fault, the suggested repair items, and the prompt for in-store processing.

[0137] Once the fault type is determined, the system handles the faulty vehicle according to the fault handling method associated with that type. For software fault types, the handling method can be that the cloud sends repair instructions directly to the vehicle. After receiving the instructions, the vehicle executes the corresponding parameter restoration, program update, or function reset through the vehicle communication module and controller. For hardware fault types, the handling method can be that the cloud generates a repair work order and sends it to the user terminal or repair terminal. The work order includes remote diagnostic results, fault type, recommended spare parts information, and repair suggestions, so that the user can schedule an appointment for on-site repair or the repair personnel can prepare the corresponding parts in advance.

[0138] The remote fault diagnosis method provided in this embodiment further determines the fault type based on the remote diagnosis results and matches the fault handling method according to the type. This enables the remote diagnosis results to be directly converted into targeted handling outputs, allowing software anomalies to be handled in a closed loop on the remote side and hardware anomalies to be quickly processed into maintenance guidelines, thereby improving the targeting and efficiency of fault handling.

[0139] Optionally, based on any of the above embodiments, step 502 includes:

[0140] If the fault type is software fault, the faulty vehicle will be repaired remotely.

[0141] If the fault type is hardware fault, repair information is generated based on the faulty hardware. The repair information includes the faulty hardware association information and repair suggestions. The repair information is sent to the user's terminal device so that the user can repair the fault based on the repair information.

[0142] In this embodiment, after determining the type of the current fault based on the remote diagnostic results, if it is determined to be a software fault, the cloud repair service is invoked to generate repair content corresponding to the faulty vehicle model, fault controller, and fault identifier. The repair content is then sent to the vehicle end through the vehicle-cloud communication link. After receiving the repair content, the vehicle end performs reset, patch loading, parameter write-back, or configuration synchronization to complete the remote repair.

[0143] If the fault is determined to be a hardware fault, the system generates repair information based on the faulty hardware's identifier, installation location, associated subsystems, and fault symptoms. The faulty hardware association information indicates the name, number, location, or fault phenomenon of the component to be repaired, while the repair suggestions indicate options such as replacement, tightening, inspection, or in-store repair. This repair information is then sent to the user's terminal so that the user can perform fault repair accordingly.

[0144] The remote fault diagnosis method provided in this embodiment can directly repair software faults remotely, while for hardware faults, it outputs clear component location and handling suggestions to the user in the form of maintenance information, so that the fault handling method matches the fault type, thereby improving the pertinence of remote handling and reducing unnecessary in-store inspections.

[0145] Figure 6 This is a schematic diagram of the structure of the remote fault diagnosis device provided in the embodiments of this application, as shown below. Figure 6 As shown, the device includes: an acquisition module 61, a processing module 62, an interaction module 63, and a diagnostic module 64. The acquisition module 61 acquires log information associated with the faulty vehicle. The processing module 62 processes the log information using a generative model to obtain preliminary analysis results of the faulty vehicle association. The interaction module 63 interacts with the user based on the preliminary analysis results to obtain interactive information. The diagnostic module 64 determines remote diagnostic results of the faulty vehicle association based on the preliminary analysis results and the interactive information. The remote diagnostic results include one or more of the following: fault cause, fault node, and repair suggestions.

[0146] Furthermore, based on any of the above embodiments, the acquisition module is configured to: in response to receiving a fault diagnosis request triggered by a user, acquire full log information of the faulty vehicle within the time range associated with the fault diagnosis request. Alternatively, acquiring log information associated with the faulty vehicle includes: acquiring log information uploaded by the faulty vehicle, the log information including logs automatically uploaded by the faulty vehicle when the fault occurs and related to the current fault.

[0147] Furthermore, based on any of the above embodiments, the remote fault diagnosis device further includes: an acquisition module, used to acquire a training dataset, the training dataset including multiple training data pairs, the training data pairs including vehicle-related training logs and vehicle-related fault logs, fault events, and fault association information; and a training module, used to input the training dataset and preset prompt text into the generative model, and to fine-tune the generative model.

[0148] Furthermore, based on any of the above embodiments, the interaction module is configured to: determine at least one interactive question associated with the current fault event of the faulty vehicle based on preliminary analysis results, wherein the interactive question is generated by a generative model based on the preliminary analysis results; and interact with the user based on the at least one interactive question, obtain the user's response content generated based on the interactive question, and determine the response content as interactive information.

[0149] Furthermore, based on any of the above embodiments, the diagnostic module is configured to: acquire a fault case library, which includes multiple sets of mapping data pairs, each mapping data pair including historical analysis results associated with historical cases, historical interaction information, and diagnostic results associated with historical cases; identify historical cases in the fault case library that correspond to the preliminary analysis results and interaction information; and determine the diagnostic results corresponding to the historical cases as remote diagnostic results.

[0150] Furthermore, based on any of the above embodiments, the diagnostic module is used to: calculate the similarity between the preliminary analysis results and the interaction information and the historical analysis results and historical interaction information associated with each historical case in the fault case library. Historical cases whose similarity meets preset conditions are identified as historical cases corresponding to the preliminary analysis results and interaction information.

[0151] Furthermore, based on any of the above embodiments, the diagnostic module is used to: input preliminary analysis results and interactive information into the generative model, and obtain remote diagnostic results generated by the generative model.

[0152] Furthermore, based on any of the above embodiments, the remote fault diagnosis device further includes: a determination module, used to determine the fault type associated with the faulty vehicle based on the remote diagnosis results; and a processing module, used to perform fault processing on the faulty vehicle using a fault processing method associated with the fault type.

[0153] Furthermore, based on any of the above embodiments, the processing module is configured to: respond to a software fault type by performing fault repair on the faulty vehicle remotely; and respond to a hardware fault type by generating repair information based on the faulty hardware, the repair information including faulty hardware association information and repair suggestions, and sending the repair information to the user's terminal device so that the user can perform fault repair based on the repair information.

[0154] The remote fault diagnosis device provided in this embodiment can execute the method provided in the above method embodiment. Its implementation principle and technical effect are similar, and will not be described in detail here.

[0155] Figure 7 A schematic diagram of the structure of the electronic device provided in this application. Figure 7 As shown, the electronic device 70 provided in this embodiment includes at least one processor 701 and a memory 702. Optionally, the device 70 further includes a communication component 703. The processor 701, memory 702, and communication component 703 are connected via a bus 704.

[0156] In a specific implementation, at least one processor 701 executes computer execution instructions stored in memory 702, causing at least one processor 701 to perform the above-described method.

[0157] The specific implementation process of processor 701 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0158] In the above embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0159] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.

[0160] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0161] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0162] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the above-described method.

[0163] The aforementioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0164] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the processor and the readable storage medium can exist as discrete components in the device.

[0165] The division of units is merely a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

[0166] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0167] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0168] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0169] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0170] Finally, it should be noted that other embodiments of the invention will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This invention is intended to cover any variations, uses, or adaptations of the invention that follow the general principles of the invention and include common knowledge or customary techniques in the art not disclosed herein, and is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of the invention is limited only by the appended claims.

Claims

1. A remote fault diagnosis method, characterized in that, include: Obtain log information associated with the faulty vehicle; By processing the log information using a generative model, preliminary analysis results of the association between the faulty vehicles are obtained. Based on the preliminary analysis results, information is exchanged with the user to obtain interactive information; Based on the preliminary analysis results and interactive information, the remote diagnostic results associated with the faulty vehicle are determined. The remote diagnostic results include one or more of the following: fault cause, fault node, and repair suggestions.

2. The method according to claim 1, characterized in that, The process of obtaining log information associated with the faulty vehicle includes: In response to receiving a fault diagnosis request triggered by a user, obtain the full log information of the faulty vehicle within the time range associated with the fault diagnosis request; Alternatively, obtaining the log information associated with the faulty vehicle includes: Obtain the log information uploaded by the faulty vehicle, including logs related to the current fault that are automatically uploaded when the faulty vehicle experiences a malfunction.

3. The method according to claim 1, characterized in that, Before processing the log information using a generative model to obtain preliminary analysis results related to the faulty vehicles, the process further includes: Obtain a training dataset, which includes multiple training data pairs, each training data pair including vehicle-associated training logs and vehicle-associated fault logs, fault events, and fault association information. The training dataset and preset prompt text are input into the generative model, and the generative model is fine-tuned.

4. The method according to claim 1, characterized in that, The step of interacting with the user based on the preliminary analysis results to obtain interactive information includes: Based on the preliminary analysis results, at least one interactive question is identified that is associated with the current fault event of the faulty vehicle. The interactive question is generated by the generative model based on the preliminary analysis results. Based on the at least one interactive question, data interaction is performed with the user to obtain the response content generated by the user based on the interactive question, and the response content is determined as the interactive information.

5. The method according to claim 1, characterized in that, The determination of the remote diagnostic results associated with the faulty vehicle based on the preliminary analysis results and interactive information includes: Obtain a fault case library, which includes multiple sets of mapping data pairs. The mapping data pairs include historical analysis results associated with historical cases, historical interaction information, and diagnostic results associated with historical cases. In the fault case database, historical cases corresponding to the preliminary analysis results and interaction information are identified, and the diagnostic results corresponding to the historical cases are determined as the remote diagnostic results.

6. The method according to claim 5, characterized in that, The step of determining the historical cases in the fault case database that correspond to the preliminary analysis results and interaction information includes: Calculate the similarity between the preliminary analysis results and the interaction information and the historical analysis results and historical interaction information associated with each historical case in the fault case database; Historical cases whose similarity meets the preset conditions are identified as historical cases corresponding to the preliminary analysis results and interaction information.

7. The method according to claim 1, characterized in that, The determination of the remote diagnostic results associated with the faulty vehicle based on the preliminary analysis results and interactive information includes: The preliminary analysis results and the interaction information are input into the generative model to obtain the remote diagnostic results generated by the generative model.

8. The method according to any one of claims 1-7, characterized in that, After determining the remote diagnostic results associated with the faulty vehicle based on the preliminary analysis results and interactive information, the method further includes: The fault type associated with the faulty vehicle is determined based on the remote diagnostic results; The faulty vehicle is handled using a fault handling method associated with the fault type.

9. The method according to claim 8, characterized in that, The fault handling method associated with the fault type is used to handle the faulty vehicle, including: If the fault type is a software fault, the faulty vehicle will be repaired remotely. In response to the fault type being a hardware fault, repair information is generated based on the faulty hardware. The repair information includes faulty hardware association information and repair suggestions. The repair information is then sent to the user's terminal device so that the user can repair the fault based on the repair information.

10. A remote fault diagnosis device, characterized in that, include: The acquisition module is used to acquire log information associated with the faulty vehicle; The processing module is used to process the log information through a generative model to obtain preliminary analysis results of the association of the faulty vehicles; The interaction module is used to interact with the user based on the preliminary analysis results and obtain interactive information; The diagnostic module is used to determine the remote diagnostic results associated with the faulty vehicle based on the preliminary analysis results and interactive information. The remote diagnostic results include one or more of the following: fault cause, fault node, and repair suggestions.

11. An electronic device, characterized in that, include: Memory, processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory, causing the processor to perform the method as described in any one of claims 1-9.

12. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1-9.

13. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method described in any one of claims 1-9.

Images