Vehicle off-line fault processing method and device, storage medium and electronic equipment

Abstract

The invention discloses a vehicle off-line fault processing method and device, a storage medium and electronic equipment. The method comprises the steps of obtaining a fault code corresponding to an off-line fault when it is detected that the vehicle has the off-line fault; the fault code, a fault knowledge base corresponding to the fault code and a fault reasoning model corresponding to the input fault code are subjected to first reasoning operation, a first reasoning result is obtained, and the first reasoning result is used for indicating multiple candidate fault events associated with the offline fault; based on verification information of a plurality of candidate fault events obtained from the vehicle, determining a target fault event causing an offline fault from the plurality of candidate fault events; the target fault event and the fault knowledge base are input into a fault reasoning model for second reasoning operation, a second reasoning result is obtained, and the second reasoning result is used for indicating first fault recovery operation corresponding to the target fault event; a first fault recovery operation is performed on the vehicle.

Description

Technical Field

[0001] This application relates to the field of vehicle-mounted testing technology, and more specifically, to a method and apparatus for handling vehicle off-line faults, a storage medium, and an electronic device. Background Technology

[0002] During vehicle off-line inspection, when a fault is detected, traditional fault handling methods rely on on-site engineers' experience-based analysis and manual information acquisition and processing. This process is not only time-consuming, but also prone to inconsistencies in the accuracy and efficiency of problem analysis due to differences in the skill levels of engineers. It may require multiple attempts and manual intervention, resulting in a significant waste of time and low efficiency in handling lower-level vehicle faults. Summary of the Invention

[0003] This application provides a method and apparatus for handling vehicle off-line faults, a storage medium, and an electronic device, to at least solve the technical problem of low processing efficiency for vehicle lower limit faults.

[0004] According to one aspect of the embodiments of this application, a method for handling vehicle decommissioning faults is provided, comprising: upon detecting a vehicle decommissioning fault, obtaining a fault code corresponding to the decommissioning fault; inputting the fault code and a fault knowledge base corresponding to the fault code into a fault reasoning model corresponding to the fault code for a first reasoning operation to obtain a first reasoning result, wherein the first reasoning result is used to indicate multiple candidate fault events associated with the decommissioning fault; based on verification information of the multiple candidate fault events obtained from the vehicle, determining a target fault event causing the decommissioning fault from the multiple candidate fault events; inputting the target fault event and the fault knowledge base into the fault reasoning model for a second reasoning operation to obtain a second reasoning result, wherein the second reasoning result is used to indicate a first fault recovery operation corresponding to the target fault event; and performing a first fault recovery operation on the vehicle.

[0005] According to another aspect of the embodiments of this application, a processing apparatus for vehicle decommissioning faults is also provided, comprising: an acquisition unit, configured to acquire a fault code corresponding to the decommissioning fault when a vehicle decommissioning fault is detected; a first reasoning unit, configured to input the fault code and a fault knowledge base corresponding to the fault code into a fault reasoning model corresponding to the fault code to perform a first reasoning operation and obtain a first reasoning result, wherein the first reasoning result is used to indicate multiple candidate fault events associated with the decommissioning fault; a determination unit, configured to determine a target fault event causing the decommissioning fault from multiple candidate fault events based on verification information obtained from the vehicle; a second reasoning unit, configured to input the target fault event and the fault knowledge base into a fault reasoning model to perform a second reasoning operation and obtain a second reasoning result, wherein the second reasoning result is used to indicate a first fault recovery operation corresponding to the target fault event; and a recovery unit, configured to perform a first fault recovery operation on the vehicle.

[0006] According to another aspect of the embodiments of this application, a computer-readable storage medium is also provided, wherein a computer program is stored in the computer program, and the computer program is configured to execute the above-described method for handling vehicle off-line failures when running.

[0007] According to another aspect of the embodiments of this application, a computer program product is provided, which includes a computer program / instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer program / instructions from the computer-readable storage medium and executes the computer program / instructions, causing the computer device to perform the above-described method for handling vehicle off-line failures.

[0008] According to another aspect of the embodiments of this application, an electronic device is also provided, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to execute the above-described method for handling vehicle off-line faults through the computer program.

[0009] In this embodiment, by using a fault reasoning model and a fault knowledge base, the fault codes corresponding to the offline fault are parsed / reasoned, generating preliminary fault cause hypotheses, i.e., multiple candidate fault events, in a very short time. This shortens the initial fault analysis time and improves response efficiency. Based on verification information from real-time vehicle feedback, the target fault event directly causing the offline fault can be accurately identified from the candidate fault events, providing more accurate fault location capabilities and reducing unnecessary resource consumption and the risk of misjudgment. Furthermore, by using the fault reasoning model, combined with historical data and solutions in the fault knowledge base, the optimal first fault recovery operation is derived and executed, ensuring the scientific nature and effectiveness of fault recovery measures, avoiding blind attempts and repeated debugging, and accelerating the fault recovery process. Therefore, this embodiment, by integrating the fault reasoning model and the fault knowledge base, achieves the technical effect of improving the processing efficiency of vehicle lower limit faults, solving the technical problem of low processing efficiency of vehicle lower limit faults in related technologies. Attached Figure Description

[0010] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0011] Figure 1 This is a flowchart of an optional method for handling vehicle off-line failure according to an embodiment of this application.

[0012] Figure 2 This is a flowchart illustrating an optional AI-based method for analyzing vehicle off-line inspection problems according to an embodiment of this application.

[0013] Figure 3 This is a schematic diagram of the framework of an optional AI-based vehicle off-line inspection problem analysis system according to an embodiment of this application.

[0014] Figure 4 This is a flowchart illustrating another optional AI-based method for analyzing vehicle off-line inspection problems according to an embodiment of this application.

[0015] Figure 5 This is a schematic diagram of an optional vehicle off-line fault handling device according to an embodiment of this application.

[0016] Figure 6 This is a schematic diagram of an optional electronic device according to an embodiment of this application. Detailed Implementation

[0017] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0018] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0019] According to one aspect of the embodiments of this application, a method for handling vehicle off-line failures is provided, applied in a vehicle terminal. In optional embodiments, such as Figure 1 As shown, the method for handling the above-mentioned vehicle off-line failure includes the following steps:

[0020] S102, if a vehicle is detected to have a failure to go offline, obtain the fault code corresponding to the failure to go offline;

[0021] S104, input the fault code and the fault knowledge base corresponding to the fault code into the fault reasoning model corresponding to the fault code to perform the first reasoning operation and obtain the first reasoning result. The first reasoning result is used to indicate multiple candidate fault events associated with the offline fault.

[0022] S106, Based on the verification information of multiple candidate fault events obtained from the vehicle, determine the target fault event that caused the offline failure from the multiple candidate fault events;

[0023] S108, Input the target fault event and fault knowledge base into the fault reasoning model to perform the second reasoning operation and obtain the second reasoning result, wherein the second reasoning result is used to indicate the first fault recovery operation corresponding to the target fault event;

[0024] S110, perform the first fault recovery operation on the vehicle.

[0025] Optionally, in this embodiment, vehicle off-line failure refers to the detection and identification of technical faults or abnormalities in the vehicle that do not meet the factory standards when the vehicle has completed production and is undergoing off-line testing.

[0026] Optionally, in this embodiment, the fault code is a code generated in the vehicle electronics when an abnormality is detected, used to quickly locate vehicle faults.

[0027] Optionally, in this embodiment, the fault knowledge base is a pre-established database containing historical fault cases, solutions, and related technical information, used to assist the fault reasoning model in intelligent analysis. The fault reasoning model is a model built using artificial intelligence technology, capable of reasoning based on fault codes and the fault knowledge base to predict possible fault causes and recovery solutions.

[0028] Optionally, in this embodiment, candidate fault events are a series of events or component faults that may cause offline failures, initially identified by the fault reasoning model. Target fault events are specific events or components that directly cause offline failures, determined from the candidate fault events through further verification and analysis. The first fault recovery operation is an operation instruction proposed by the fault reasoning model to restore the vehicle's functions to a normal state in response to the target fault event.

[0029] Optionally, in this embodiment, during the vehicle off-line inspection process, once a fault is detected in the vehicle, the fault code of this fault will be immediately captured and recorded as input information for subsequent intelligent fault processing.

[0030] The detected fault codes are combined with a fault knowledge base and input into a fault reasoning model for analysis. The model will reason based on the data in the fault knowledge base and output multiple candidate fault events associated with the fault codes, providing a preliminary reference for subsequent fault localization.

[0031] Based on the aforementioned candidate fault events, we will interact with the vehicle to obtain further necessary verification information. This information will be used to narrow down the range of fault causes and ultimately determine the target fault event, i.e., the direct cause of the offline fault.

[0032] The identified target fault event and fault knowledge base are then input into the fault reasoning model for deeper analysis to obtain the first fault recovery operation, i.e., the most effective recovery measure for the target fault event.

[0033] Automatically execute the first fault recovery operation or provide guidance to engineers to ensure that the fault can be resolved quickly and correctly, thereby restoring the normal function of the vehicle, reducing the time the vehicle spends in the repair area, and improving the overall production efficiency of the production line.

[0034] Optionally, in this embodiment, by combining a fault reasoning model with a fault knowledge base, faults can be quickly identified and located during the off-line inspection stage, providing intelligent guidance for fault recovery. This process not only reduces reliance on on-site engineers and improves the accuracy of fault handling, but also significantly shortens the time from fault detection to restoring vehicles to factory standards, thereby optimizing the production cycle of the entire production line and reducing labor costs.

[0035] To further illustrate, suppose a vehicle undergoing off-line testing reports a specific fault code (e.g., P0123), which may indicate a problem with one of the vehicle's sensors. In this embodiment, the fault code is first analyzed. Through a first inference operation, several candidate fault events related to the fault code are filtered out, such as a loose sensor connection, sensor damage, or improper software configuration. Next, the system automatically interacts with the vehicle to obtain verification information for each candidate fault event, such as real-time sensor data, connection status, or software version number. This information helps identify the target fault event, such as a loose sensor connection. Subsequently, a second inference operation is performed to derive a first fault recovery operation, such as automatically tightening the sensor connection. Finally, this operation is performed automatically or guided to engineers for manual repair, ensuring the vehicle returns to normal operation and successfully passes off-line testing.

[0036] The embodiments provided in this application, through fault reasoning models and fault knowledge bases, parse / reason about fault codes corresponding to offline faults, generating preliminary fault cause hypotheses, i.e., multiple candidate fault events, in a very short time, shortening the initial fault analysis time and improving response efficiency. Based on verification information from real-time vehicle feedback, the target fault event directly causing the offline fault can be accurately identified from the candidate fault events, providing more accurate fault location capabilities and reducing unnecessary resource consumption and the risk of misjudgment. Furthermore, by utilizing the fault reasoning model and combining historical data and solutions in the fault knowledge base, the optimal first fault recovery operation is derived and executed, ensuring the scientific validity and effectiveness of fault recovery measures, avoiding blind attempts and repeated debugging, and accelerating the fault recovery process. Therefore, this embodiment, by integrating fault reasoning models and fault knowledge bases, achieves the technical effect of improving the processing efficiency of vehicle lower-limit faults.

[0037] As an optional approach, after performing the first fault recovery operation on the vehicle, the method further includes:

[0038] Based on the first operation result information of the first fault recovery operation obtained from the vehicle, determine whether the offline fault has been recovered;

[0039] If the offline fault is not recovered, the first fault recovery operation, the target fault event, and the fault knowledge base are input into the fault reasoning model to perform the third reasoning operation and obtain the third reasoning result. The third reasoning result is used to indicate the second fault recovery operation corresponding to the target fault event.

[0040] Perform a second fault recovery operation on the vehicle.

[0041] Optionally, in this embodiment, the first operation result information is the feedback information obtained from the vehicle after the first fault recovery operation is performed, which is used to evaluate whether the fault has been effectively resolved.

[0042] Optionally, in this embodiment, the third inference operation indicates a deeper analysis performed by the fault inference model when the offline fault cannot be resolved by the first fault recovery operation, in order to generate a new fault recovery solution. The second fault recovery operation is a second fault recovery attempt proposed by the fault inference model after the third inference operation when the first fault recovery operation is ineffective, and generally includes more complex troubleshooting or repair steps.

[0043] Optionally, in this embodiment, after the first fault recovery operation is completed, the first operation result information will be collected from the vehicle immediately, including but not limited to vehicle status, fault code changes, component feedback, etc., so as to determine whether the offline fault has been eliminated or improved.

[0044] If the offline fault is still not resolved based on the results of the first operation, the detailed information from the first operation, the target fault event, and the latest fault knowledge base will be input into the fault reasoning model again for a third reasoning operation. This reasoning aims to find deeper or more effective fault recovery strategies by using more comprehensive information and knowledge base content.

[0045] The result of the third inference operation will instruct one or more second fault recovery operations. These recommendations may be to further refine the handling of the fault event or to adopt a repair scheme different from the first attempt, aiming to completely resolve the offline fault.

[0046] It automatically executes or guides engineers to perform a second fault recovery operation until the vehicle's off-line failure is successfully resolved.

[0047] To illustrate further, suppose a car experiences an incorrect oil pressure sensor reading during off-line testing. First, a fault code (e.g., P0300) is identified, and a first fault recovery operation is performed (e.g., resetting the sensor). However, by collecting information from this first operation, the problem persists; the oil pressure reading has not returned to normal. At this point, a third reasoning operation is performed. Considering possible factors such as aging sensor hardware, poor wiring connections, or incorrect ECU software parameter settings, a second fault recovery operation suggestion is generated (e.g., replacing the sensor or checking the sensor wiring). Subsequently, on-site engineers are guided to take appropriate measures until the fault is completely resolved, the vehicle successfully passes off-line testing, and returns to the production line to continue subsequent testing processes.

[0048] The embodiments provided in this application do not halt the fault handling process if the initial fault recovery operation fails to achieve the desired results. Instead, a third inference operation is introduced, utilizing more detailed information and an updated fault knowledge base to explore the possibility of a second fault recovery operation. This iterative fault recovery strategy not only ensures the proper handling of complex or rare faults but also enhances the flexibility and robustness of handling vehicle off-line faults.

[0049] As an optional approach, after determining whether the offline fault has been resolved, the method also includes:

[0050] When the offline fault has been recovered, knowledge extraction is performed on the fault information associated with the offline fault to obtain the fault knowledge corresponding to the offline fault. The fault information includes the target fault event, the first fault recovery operation, and the first operation result information.

[0051] Fault knowledge is stored in a fault knowledge base.

[0052] Optionally, in this embodiment, the fault information includes the specific details of the vehicle's off-line fault, the target fault event that caused the fault, the first fault recovery operation taken, and the first operation result information after the operation, which constitutes a comprehensive fault description and processing record.

[0053] Optionally, in this embodiment, fault knowledge refers to valuable knowledge points extracted from fault information, including potential causes of faults, effective recovery operations, and best practices for fault handling, which is an important component of the fault knowledge base.

[0054] Optionally, in this embodiment, after confirming that the offline fault has been resolved through the first fault recovery operation, a deep analysis of all information about the fault will be performed, including the target fault event, the recovery operation taken, and the operation result, in order to extract valuable fault knowledge.

[0055] Through the knowledge extraction process, a comprehensive solution strategy for this offline failure can be summarized, including the root cause of the failure, effective recovery steps, and the final handling effect. This information together constitutes new failure knowledge.

[0056] Storing the extracted and generated fault knowledge in the fault knowledge base not only enriches the content of the knowledge base, but also promotes the accumulation and sharing of fault handling experience, providing a reference for handling future vehicle off-line faults.

[0057] To further illustrate, consider a new car that experiences a slow braking response during off-line testing. After identifying the fault code, the first reasoning operation and interaction determine that the target fault event is a brake fluid pressure sensor malfunction. The subsequent second reasoning operation proposes the first fault recovery operation—sensor reset. After executing this operation, the vehicle's braking returns to normal, confirming that the fault has been resolved. Next, knowledge extraction will be performed to summarize detailed information about this fault, including the specific manifestations of the sensor malfunction, the reset operation performed, and the result of the braking returning to normal after the operation.

[0058] This information will be organized and transformed into fault knowledge, including but not limited to how to quickly identify the characteristics of brake fluid pressure sensor malfunctions, the applicable conditions and steps for sensor reset operations, and the actual effects of this operation. Finally, this fault knowledge will be stored in a fault knowledge base, becoming an important reference for handling similar faults during subsequent vehicle off-line testing. Through this closed-loop mechanism, new fault cases and solutions can be continuously learned, gradually improving the intelligence level of fault diagnosis and recovery, and promoting continuous improvement and efficiency enhancement of the production line.

[0059] Through the embodiments provided in this application, and through the knowledge extraction and storage mechanism, fault knowledge can be accumulated automatically or manually from each fault handling instance, continuously improving the accuracy of the fault reasoning model and the efficiency of fault handling. This mechanism not only reduces the processing time when encountering similar faults in the future, but also promotes the rapid dissemination and application of fault knowledge among different production lines and teams.

[0060] As an optional approach, after inputting the fault code and its corresponding fault knowledge base into the fault reasoning model for the first reasoning operation and obtaining the first reasoning result, the method further includes:

[0061] Based on the verification information, at least two fault events are selected from multiple candidate fault events, wherein the target fault event is the fault event among the at least two fault events;

[0062] Based on the priority information of each fault event in at least two fault events stored in the fault knowledge base, determine the first fault event with the highest priority from at least two fault events;

[0063] If the third fault recovery operation corresponding to the first fault event is obtained through the fault knowledge base and fault reasoning model, the third fault recovery operation is executed on the vehicle.

[0064] If the second operation result information corresponding to the third fault recovery operation indicates that the offline fault has been recovered, it is determined that the offline fault handling is complete.

[0065] Increase the priority of the first fault event stored in the fault knowledge base.

[0066] Optionally, in this embodiment, the priority information is a fault event sorting preset in the fault knowledge base based on factors such as the commonness, severity, impact on production efficiency, and required processing complexity of the fault events, which is used to guide the order of fault event processing.

[0067] Optionally, in this embodiment, the third fault recovery operation is a targeted fault recovery instruction given by the fault reasoning model based on fault database data and fault event priority information after the first fault event is determined. The second operation result information is the feedback information obtained from the vehicle after the third fault recovery operation is executed, used to evaluate whether the fault handling was successful.

[0068] Optionally, in this embodiment, after the first reasoning operation, it is not limited to determining a single fault event, but rather, based on the verification information obtained from the vehicle, at least two possible fault events are selected, and priority information in the fault knowledge base is used to identify the first fault event with the highest priority and the most urgent need for processing.

[0069] Based on the characteristics of the first fault event, the fault reasoning model will search for or generate the most suitable third fault recovery operation from the fault knowledge base, and then perform this operation on the vehicle, aiming to efficiently resolve the fault with the greatest impact.

[0070] After performing the third fault recovery operation, if the test results show that the offline fault has been resolved, the fault handling will be considered complete. Furthermore, since the handling solution for this fault event has proven effective, its priority in the fault knowledge base will be increased to optimize future fault handling strategies and processes.

[0071] To illustrate further, suppose a vehicle undergoing off-line testing reports a power failure. Initial fault codes identify three candidate fault events: fuel pump failure (priority B), oxygen sensor malfunction (priority A), and injector blockage (priority C). Based on real-time detection verification information, the oxygen sensor malfunction and injector blockage are ultimately selected as priority events. The oxygen sensor malfunction has a higher priority (A) and is therefore identified first as the target fault event.

[0072] Subsequently, based on data from the fault knowledge base, the fault reasoning model proposed a third fault recovery operation for the oxygen sensor malfunction—replacing the oxygen sensor—and automatically performed this operation. After re-inspection, it was confirmed that the power fault had been eliminated, and the fault handling was deemed complete. Given the validated effectiveness of replacing the oxygen sensor, the priority of this fault event in the fault knowledge base was increased from A to A+, ensuring faster identification and handling of similar faults in the future, reducing vehicle downtime during inspection, and improving overall production efficiency and quality control.

[0073] The embodiments provided in this application not only enhance the fault reasoning model's ability to handle frequent and complex faults, but also introduce the concept of fault event priority, ensuring that the most urgent and common problems are addressed first. Through the priority adjustment mechanism of the fault knowledge base, the fault event list can be dynamically optimized based on the actual effectiveness of fault handling, ensuring that the most effective solutions are prioritized in subsequent fault handling, thereby continuously improving overall fault handling efficiency and production line operational stability.

[0074] As an optional approach, after performing the third fault recovery operation on the vehicle, the method further includes:

[0075] If the second operation result information indicates that the offline fault has not been recovered, the priority of the first fault event stored in the fault knowledge base is reduced.

[0076] From the remaining failure events of at least two failure events, determine the second failure event with the highest priority;

[0077] If the fourth fault recovery operation corresponding to the second fault event is obtained through the fault knowledge base and fault reasoning model, the fourth fault recovery operation is performed on the vehicle.

[0078] Optionally, in this embodiment, the second fault event is the next processing target selected from the remaining candidate fault events according to priority when the third fault recovery operation of the first fault event is ineffective, and is used for further fault investigation and recovery attempts. The fourth fault recovery operation is a new fault recovery measure obtained through joint analysis of the fault reasoning model and the fault knowledge base for the second fault event.

[0079] Optionally, in this embodiment, if the second operation result information indicates that the offline fault is still not resolved after the third fault recovery operation is performed, the priority of the first fault event in the fault knowledge base will be reduced, reflecting that the diagnosis or recovery plan for this event is not mature enough or has low effectiveness.

[0080] After the recovery attempt for the first fault event fails, the second fault event with the highest priority will be selected from the remaining candidate fault events based on the latest priority information as the new fault handling focus.

[0081] Based on the second fault event, the fault reasoning model and fault knowledge base are used again for analysis to generate a fourth fault recovery operation, which is then immediately performed on the vehicle to achieve the purpose of fault recovery.

[0082] To illustrate further, suppose a new car encounters an engine performance degradation issue during off-line testing. A fault reasoning model initially identifies three candidate fault events: fuel pump failure, oxygen sensor malfunction, and ignition problem, with fuel pump failure being the first priority. After performing the third fault recovery operation (fuel pump repair), the test results show no improvement in engine performance. At this point, the priority of fuel pump failure in the fault knowledge base is reduced, and from the remaining candidate fault events, oxygen sensor malfunction is identified as the second highest priority fault event.

[0083] Next, based on the latest fault knowledge base and fault reasoning model, a fourth fault recovery operation—replacing the oxygen sensor—is generated for the oxygen sensor malfunction and performed on the vehicle. If engine performance is effectively restored after replacing the oxygen sensor, it indicates that the original fault was caused by the oxygen sensor malfunction, and the effectiveness of this process will be recorded for rapid location and handling of similar faults in the future. Conversely, if the fault remains unresolved, ignition issues will continue to be evaluated as the next step until the fault is completely resolved. Simultaneously, the priority information in the fault knowledge base is continuously adjusted to reflect the actual handling difficulty and frequency of various fault events. Through this series of intelligent decisions and dynamic adjustments, complex faults occurring during vehicle off-line inspection can be handled more effectively, the fault recovery process optimized, and overall production efficiency improved.

[0084] Through the embodiments provided in this application, when the recovery operation recommended based on the fault reasoning model and fault knowledge base fails to resolve the problem, it not only lowers the priority of the event to avoid over-reliance on this path in future fault handling, but also quickly identifies a new processing direction, namely the second fault event with the highest priority. This mechanism ensures the flexibility and efficiency of the fault handling process. By continuously trying different fault recovery operations until the most suitable specific solution is found, it effectively avoids the limitations of a single fault recovery scheme and promotes refined management and continuous optimization of the fault handling process.

[0085] As an optional approach, the target fault event and fault knowledge base are input into the fault reasoning model for a second reasoning operation to obtain a second reasoning result. This second reasoning result is used to indicate the first fault recovery operation corresponding to the target fault event, including:

[0086] Input the target fault event and fault knowledge base into the fault reasoning model to perform the second reasoning operation, and obtain the first fault recovery sub-operation and the second fault recovery sub-operation corresponding to the target fault event;

[0087] Perform the first fault recovery operation on the vehicle, including:

[0088] Perform a first fault recovery sub-operation on the vehicle and obtain the third operation result information corresponding to the first fault recovery sub-operation;

[0089] If the result of the third operation matches the expected result of the first fault recovery operation, the second fault recovery sub-operation is performed on the vehicle.

[0090] If the operation result information does not meet the expected operation result, the third operation result information, the target fault event and the fault knowledge base are input into the fault reasoning model to adjust the second fault recovery sub-operation and obtain the third fault recovery sub-operation.

[0091] Perform the third fault recovery sub-operation on the vehicle.

[0092] Optionally, in this embodiment, the first fault recovery sub-operation is a preliminary step in the first fault recovery operation, aimed at directly addressing the fundamental problem of the target fault event and creating conditions for subsequent, deeper fault recovery. The second fault recovery sub-operation is a subsequent step in the first fault recovery operation, typically involving a more detailed inspection or repair of the vehicle based on the first fault recovery sub-operation, to completely eliminate the fault.

[0093] Optionally, in this embodiment, the third operation result information is feedback information obtained from the vehicle after executing the first fault recovery sub-operation, used to evaluate whether the sub-operation achieved the expected effect. The expected operation result is the desired state or effect set for the first fault recovery sub-operation based on the fault reasoning model and the fault knowledge base.

[0094] Optionally, in this embodiment, the third fault recovery sub-operation is a correction sub-operation regenerated by the fault reasoning model based on the third operation result information, the target fault event, and the fault knowledge base when the first fault recovery sub-operation fails to meet expectations.

[0095] Optionally, in this embodiment, the target fault event and the fault knowledge base are input into the fault reasoning model. After the second reasoning operation, not only is the first fault recovery operation generated, but it is also subdivided into the first fault recovery sub-operation and the second fault recovery sub-operation. The former is used to initially alleviate the fault, while the latter completely resolves the fault based on the success of the former.

[0096] First, the first fault recovery sub-operation is executed, and then the result information of the third operation is obtained to determine whether this sub-operation meets the expected results. If the third operation result information indicates that the sub-operation was successful, the execution of the second fault recovery sub-operation will proceed; otherwise, the fault recovery strategy adjustment phase will begin.

[0097] If the first fault recovery sub-operation fails to achieve the expected results, the collected third operation result information, the target fault event, and the fault knowledge base are input into the fault reasoning model again to adjust the second fault recovery sub-operation, generate a more accurate third fault recovery sub-operation, and execute it on the vehicle immediately until the fault recovery operation fully meets the expectations and the target fault event is completely resolved.

[0098] To further illustrate, suppose a new car is diagnosed with sluggish brake response during off-line inspection, and the target fault event is further identified as a brake fluid level sensor malfunction. After analysis, the fault reasoning model generates two sub-operations for the first fault recovery operation: First, the first fault recovery sub-operation is to check and clean the brake fluid level sensor; then, the second fault recovery sub-operation is to calibrate the communication parameters between the brake fluid level sensor and the control system to ensure the accuracy of the sensor data.

[0099] After executing the first fault recovery sub-operation, the cleanliness of the brake fluid level sensor is checked, and it is verified whether the brake fluid level reading has returned to normal. If the third operation result information indicates that the reading is accurate, meaning the sensor cleaning has achieved the expected effect, the second fault recovery sub-operation will be performed on the vehicle, namely, calibrating the sensor communication parameters. If the sensor cleaning is ineffective, meaning the third operation result information does not meet the expected operation result, this information, the target fault event, and the fault knowledge base will be re-input into the fault reasoning model to adjust the second fault recovery sub-operation. This may involve replacing the brake fluid level sensor as the third fault recovery sub-operation, and the vehicle will be processed again until the sluggish brake response fault is completely resolved. Through this meticulous and flexible fault recovery strategy, the efficiency and accuracy of vehicle off-line inspection are ensured, reducing production line downtime and rework time.

[0100] The embodiments provided in this application, by breaking down the first fault recovery operation into two sub-operations, not only improve the hierarchy and accuracy of fault handling, but also allow for monitoring and evaluation of the fault recovery effect from the initial stage of execution. This hierarchical processing and dynamic adjustment mechanism ensures the flexibility and effectiveness of the fault recovery operation, enabling rapid adjustment of strategies even if the initial attempt fails, avoiding redundant operations, saving time and resources, and improving the overall efficiency and success rate of fault handling.

[0101] As an optional approach, before inputting the fault code and its corresponding fault knowledge base into the fault reasoning model for the first reasoning operation and obtaining the first reasoning result, the method further includes:

[0102] Obtain the target fault code range to which the fault code belongs;

[0103] The fault knowledge base corresponding to the target fault code interval is determined from multiple fault knowledge bases, and the fault reasoning model corresponding to the target fault code interval is determined from multiple fault reasoning models. Each fault code interval corresponds to a fault knowledge base and a fault handling model.

[0104] Optionally, in this embodiment, the target fault code range is a set of regions corresponding to a specific type of vehicle fault, divided according to the specific numerical range of the fault codes. These ranges can help to quickly locate the nature of the fault.

[0105] Optionally, in this embodiment, the multiple fault knowledge bases contain multiple independent databases of fault handling history and solutions related to different fault code ranges, with each fault knowledge base corresponding to a specific type of fault. The multiple fault reasoning models are a series of artificial intelligence reasoning models designed for different fault code ranges, which can propose customized fault handling suggestions based on their respective fault knowledge bases.

[0106] Optionally, in this embodiment, the detected fault codes are first analyzed and classified into a preset target fault code range to quickly define the approximate type and scope of the fault.

[0107] Based on the target fault code range, the most relevant knowledge base and model are determined from multiple pre-established fault knowledge bases and fault reasoning models. This is to ensure that subsequent fault handling strategies are formulated based on information and algorithms that best fit the current fault characteristics.

[0108] After determining the fault knowledge base and fault reasoning model corresponding to the target fault code range, we prepare to input the fault codes and fault knowledge base into the model to warm up the data and algorithm levels for the first reasoning operation.

[0109] To illustrate further, suppose a new car reports a fault code P0301 during off-line inspection, indicating a misfire in engine cylinder 1. First, this fault code is identified as belonging to the engine performance fault range, which covers a series of faults related to engine operating conditions.

[0110] Subsequently, a knowledge base specifically for engine performance faults was selected from multiple fault knowledge bases, and a fault reasoning model matching the fault code range was activated from multiple fault reasoning models. This knowledge base contains historical engine performance fault cases, and the reasoning model is trained based on these cases, focusing on analyzing and handling similar faults.

[0111] After identifying the fault code range and matching the model with the knowledge base, fault code P0301 and the engine performance fault knowledge base are input into the fault reasoning model to prepare for the first reasoning operation, generating preliminary fault cause prediction and recovery suggestions. This process ensures the accuracy and effectiveness of subsequent fault handling strategies and is key to achieving rapid fault location and efficient recovery.

[0112] Through the embodiments provided in this application, by identifying fault code ranges and matching them with corresponding fault knowledge bases and inference models, the most relevant processing knowledge and intelligent algorithms for the current fault can be quickly identified from massive amounts of fault information. This not only speeds up the initial fault analysis but also ensures the relevance and accuracy of the analysis results, thus providing a solid foundation for subsequent intelligent fault processing.

[0113] As an optional solution, in order to better understand the process of handling the above-mentioned vehicle off-line failure, the following describes the execution flow of the above-mentioned vehicle off-line failure handling method in conjunction with optional embodiments, but it is not intended to limit the technical solution of the embodiments of this application.

[0114] In the fields of automotive technology and vehicle inspection technology, specifically, this embodiment proposes an AI-based vehicle off-line inspection problem analysis system and method, which is particularly suitable for solving the efficiency and accuracy problems of fault analysis and location in vehicle off-line inspection.

[0115] In the automobile production process, off-line inspection is one of the most critical quality control links, mainly including software upgrades, writing identification information, and calibration and standardization of key sensors. Traditional troubleshooting methods rely on the experience and manual operation of on-site engineers. This process is cumbersome and time-consuming, especially when encountering new faults, which often requires multiple information collection and analysis, seriously affecting production cycle and efficiency.

[0116] This embodiment aims to overcome the shortcomings of existing technologies by proposing an AI-based vehicle off-line inspection problem analysis system and method. This addresses the issues of excessive reliance on personnel, delayed information acquisition, and the manpower-intensive process of repetitive problem investigation during vehicle off-line inspection. By combining AI with a knowledge base, this embodiment automates fault analysis, reduces the need for on-site personnel, and rapidly locates problems and provides solutions through multi-round interactions, thereby significantly improving fault handling efficiency and production line cycle time.

[0117] Specifically, a flowchart illustrating an AI-based method for analyzing vehicle off-line inspection issues is shown below. Figure 2 As shown, it specifically includes:

[0118] S202, query the fault information recorded in the vehicle.

[0119] S204, based on an AI inference model and knowledge base, analyzes fault information and related information to determine the next step and interacts with the vehicle: The acquired fault content and information are input into the AI ​​inference model in a pre-defined format. The AI ​​inference model performs inference analysis based on the knowledge base content, obtaining output information and the next step operation method. The processing module interacts with the vehicle based on the operation method in the inference result and obtains the vehicle's return information.

[0120] S206, repeat S204 until the fault is resolved or the fault resolution fails.

[0121] S208-1, When the fault is resolved, the system displays that the fault has been resolved and updates the knowledge base content: The system displays that the fault has been resolved and automatically transmits the relevant information collected during the processing to the knowledge base update module to update the knowledge base content.

[0122] S208-2, In the event that the fault resolution fails, prompt for manual intervention: The display device will show the specific content that needs to be handled manually.

[0123] Specifically, a schematic diagram of the framework of an AI-based vehicle off-line inspection problem analysis system is shown below. Figure 3As shown, the fault acquisition module polls the vehicle for faults. When a fault is detected, it obtains fault identification information (such as fault codes) and sends it to the inference module. The inference module calls the inference model based on the knowledge base content to obtain the inference result, which is then sent to the operation parsing module. The operation parsing module parses the received information into a specific calling sequence and instructions for interacting with the device. It then calls the operation execution module to execute the specific instructions. The operation execution module interacts with the vehicle sequentially according to the operation sequence and instructions provided by the operation parsing module, and sends the acquired information to the data formatting processing module. After receiving the acquired information, the data formatting processing module formats the information for use by the inference module and sends the formatted data to the inference module. The above operations are repeated. If the operation execution module receives a message indicating that the fault has been resolved, it outputs "Proceed to the next test" to the display device. If the operation execution module receives a message indicating that manual intervention is required, it outputs "Manual intervention required" and the processing suggestion from the inference conclusion to the display device. After the above steps are completed, the collection module collects relevant information (fault information, operation steps in the inference result, and formatted data) and uploads the data to the cloud case library. Knowledge base maintainers retrieve newly added cases from the cloud case library, and after screening and review, update them in the cloud knowledge base.

[0124] To further illustrate, here is a flowchart of another AI-based method for analyzing vehicle off-line inspection issues, such as... Figure 4 The diagram illustrates the complete process from fault query to case update, with the specific steps broken down as follows:

[0125] 1. Fault Information Collection: Query the faults in the vehicle, obtain the basic fault information, and then input it into the inference model.

[0126] 2. Inference Model Calculation: The inference model generates preliminary inference results based on the knowledge base content; if additional data is needed, it will collect data from the vehicle according to the acquisition method in the inference results, and then re-input the new data into the inference model.

[0127] 3. Fault Handling Judgment: Is additional data required? If no, proceed to the next step; if yes, supplement the data and re-infer. Can the fault be recovered after performing a specific operation? If yes, perform the operation based on the inference result, automatically triggering a second detection, and then determine if the expected result has been achieved. If no, the display device will prompt a handling solution, requiring manual processing.

[0128] 4. Result Verification and Case Update: Did the expected result achieve the following: If no, return to the initial fault query stage for reprocessing; if yes, update the fault handling as a case to the knowledge base, and also incorporate new cases from other production / non-production environments to improve the knowledge base.

[0129] The embodiments provided in this application utilize AI and a knowledge base to perform preliminary analysis of problems, determine the next steps required, and automatically interact with vehicles to obtain information. After multiple rounds of interaction, the optimal solution is obtained, and problems can be solved automatically without human intervention. Solutions in different production lines or testing environments can be updated to the knowledge base and quickly synchronized to other production lines and testing environments, reducing duplicate problem investigations and saving time.

[0130] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to this application.

[0131] According to another aspect of the embodiments of this application, a vehicle off-line fault processing apparatus for implementing the above-described vehicle off-line fault processing method is also provided. For example... Figure 6 As shown, the device includes:

[0132] The acquisition unit 502 is used to acquire the fault code corresponding to the offline fault when a vehicle is detected to have an offline fault.

[0133] The first reasoning unit 504 is used to input the fault code and the fault knowledge base corresponding to the fault code into the fault reasoning model corresponding to the fault code to perform the first reasoning operation and obtain the first reasoning result. The first reasoning result is used to indicate multiple candidate fault events associated with the offline fault.

[0134] The determining unit 506 is used to determine the target fault event that causes the offline failure from multiple candidate fault events based on the verification information of multiple candidate fault events obtained from the vehicle.

[0135] The second reasoning unit 508 is used to input the target fault event and the fault knowledge base into the fault reasoning model to perform a second reasoning operation and obtain a second reasoning result. The second reasoning result is used to indicate the first fault recovery operation corresponding to the target fault event.

[0136] Recovery unit 510 is used to perform the first fault recovery operation on the vehicle.

[0137] As an optional solution, the device also includes:

[0138] The first determining module is used to determine whether the offline fault has been recovered based on the first operation result information of the first fault recovery operation obtained from the vehicle after performing the first fault recovery operation on the vehicle.

[0139] The first reasoning module is used to input the first fault recovery operation, the target fault event, and the fault knowledge base into the fault reasoning model to perform a third reasoning operation after the first fault recovery operation is performed on the vehicle, in the case that the offline fault has not been recovered, and obtain a third reasoning result. The third reasoning result is used to indicate the second fault recovery operation corresponding to the target fault event.

[0140] The first recovery module is used to perform a second fault recovery operation on the vehicle after performing a first fault recovery operation on the vehicle.

[0141] As an optional solution, the device also includes:

[0142] The extraction module is used to extract knowledge from the fault information associated with the offline fault after determining whether the offline fault has been recovered. If the offline fault has been recovered, the fault information includes the target fault event, the first fault recovery operation, and the first operation result information.

[0143] The storage module is used to store fault knowledge in the fault knowledge base after determining whether the offline fault has been recovered.

[0144] As an optional solution, the device also includes:

[0145] The filtering module is used to input the fault code and the fault knowledge base corresponding to the fault code into the fault reasoning model corresponding to the fault code for the first reasoning operation, and after obtaining the first reasoning result, filter at least two fault events from multiple candidate fault events based on the verification information, wherein the target fault event is the fault event among the at least two events.

[0146] The second determining module is used to perform a first reasoning operation by inputting the fault code and the fault knowledge base corresponding to the fault code into the fault reasoning model corresponding to the fault code, and after obtaining the first reasoning result, determine the first fault event with the highest priority from the at least two fault events based on the priority information of each fault event in the at least two fault events stored in the fault knowledge base.

[0147] The second recovery module is used to perform a third fault recovery operation on the vehicle after inputting the fault code and the fault knowledge base corresponding to the fault code into the fault reasoning model corresponding to the fault code to perform a first reasoning operation and obtain a first reasoning result, and then performing a third fault recovery operation corresponding to the first fault event through reasoning using the fault knowledge base and the fault reasoning model.

[0148] The third determination module is used to determine that the offline fault handling is completed after inputting the fault code and the fault knowledge base corresponding to the fault code into the fault reasoning model corresponding to the fault code to perform the first reasoning operation and obtain the first reasoning result, and when the second operation result information corresponding to the third fault recovery operation indicates that the offline fault has been recovered.

[0149] The first adjustment module is used to increase the priority of the first fault event stored in the fault knowledge base after inputting the fault code and the fault knowledge base corresponding to the fault code into the fault reasoning model corresponding to the fault code for the first reasoning operation and obtaining the first reasoning result.

[0150] As an optional solution, the device also includes:

[0151] The second adjustment module is used to reduce the priority of the first fault event stored in the fault knowledge base after the third fault recovery operation is performed on the vehicle, if the second operation result information indicates that the offline fault has not been recovered.

[0152] The fourth determination module is used to determine the second fault event with the highest priority from the remaining fault events of at least two fault events after the third fault recovery operation is performed on the vehicle.

[0153] The third recovery module is used to perform a fourth fault recovery operation on the vehicle after the third fault recovery operation has been performed on the vehicle, and after the fourth fault recovery operation corresponding to the second fault event has been obtained through the fault knowledge base and the fault reasoning model.

[0154] As an optional solution, the second inference unit 508 includes:

[0155] The second reasoning module is used to input the target fault event and the fault knowledge base into the fault reasoning model to perform the second reasoning operation, and obtain the first fault recovery sub-operation and the second fault recovery sub-operation corresponding to the target fault event. The first fault recovery operation includes the first fault recovery sub-operation and the second fault recovery sub-operation.

[0156] The recovery unit includes:

[0157] The fourth recovery module is used to perform a first fault recovery sub-operation on the vehicle and obtain the third operation result information corresponding to the first fault recovery sub-operation;

[0158] The fifth recovery module is used to perform a second fault recovery sub-operation on the vehicle if the third operation result information matches the expected operation result corresponding to the first fault recovery operation.

[0159] The first acquisition module is used to input the third operation result information, the target fault event, and the fault knowledge base into the fault reasoning model when the operation result information does not meet the expected operation result, and adjust the second fault recovery sub-operation to obtain the third fault recovery sub-operation.

[0160] The sixth recovery module is used to perform the third fault recovery sub-operation on the vehicle.

[0161] As an optional solution, the device also includes:

[0162] The second acquisition module is used to acquire the target fault code range to which the fault code belongs before inputting the fault code and the fault knowledge base corresponding to the fault code into the fault reasoning model corresponding to the fault code to perform the first reasoning operation and obtain the first reasoning result.

[0163] The fifth determining module is used to determine the fault knowledge base corresponding to the target fault code interval from multiple fault knowledge bases and the fault reasoning model corresponding to the target fault code interval from multiple fault reasoning models before inputting the fault code and the fault knowledge base corresponding to the fault code into the fault reasoning model corresponding to the fault code for the first reasoning operation and obtaining the first reasoning result. Each fault code interval corresponds to one fault knowledge base and one fault handling model.

[0164] Optionally, in this embodiment, the implementation of each of the above-mentioned unit modules can be referred to the above-mentioned method embodiments, which will not be repeated here.

[0165] According to another aspect of the embodiments of this application, an electronic device for implementing the above-described method for handling vehicle off-line faults is also provided. This electronic device may be... Figure 6 The terminal device or server shown. This embodiment uses this electronic device as an example for illustration. Figure 6 As shown, the electronic device includes a memory 602 and a processor 604. The memory 602 stores a computer program, and the processor 604 is configured to execute the steps in any of the above method embodiments via the computer program.

[0166] Optionally, in this embodiment, the aforementioned electronic device may be located in at least one of a plurality of network devices in a computer network.

[0167] Optionally, in this embodiment, the processor can be configured to perform the following steps via a computer program:

[0168] S1, if a vehicle is detected to have a failure to go offline, obtain the fault code corresponding to the failure to go offline;

[0169] S2, input the fault code and the fault knowledge base corresponding to the fault code into the fault reasoning model corresponding to the fault code to perform the first reasoning operation and obtain the first reasoning result. The first reasoning result is used to indicate multiple candidate fault events associated with the offline fault.

[0170] S3, based on the verification information of multiple candidate fault events obtained from the vehicle, determines the target fault event that caused the offline failure from the multiple candidate fault events;

[0171] S4, input the target fault event and fault knowledge base into the fault reasoning model to perform the second reasoning operation and obtain the second reasoning result, wherein the second reasoning result is used to indicate the first fault recovery operation corresponding to the target fault event;

[0172] S5, perform the first fault recovery operation on the vehicle.

[0173] Alternatively, as those skilled in the art will understand, Figure 6 The structure shown is for illustrative purposes only. Electronic devices can also be smartphones (such as Android phones, iOS phones, etc.), tablets, PDAs, mobile internet devices (MIDs), PADs, and other terminal devices. Figure 6 This does not limit the structure of the aforementioned electronic devices or electronic equipment. For example, electronic devices or electronic equipment may also include components that are more... Figure 6 The more or fewer components shown (such as network interfaces, etc.), or having the same Figure 6 The different configurations shown.

[0174] The memory 602 can be used to store software programs and modules, such as the program instructions / modules corresponding to the vehicle off-line fault handling method and device in this embodiment. The processor 604 executes various functional applications and data processing by running the software programs and modules stored in the memory 602, thereby realizing the aforementioned vehicle off-line fault handling method. The memory 602 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 602 may further include memory remotely located relative to the processor 604, and these remote memories can be connected to the terminal via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof. Specifically, the memory 602 may be used, but is not limited to, to store information such as first inference results and second inference results. As an example, such as Figure 6As shown, the memory 602 may include, but is not limited to, the acquisition unit 502, the first inference unit 504, the determination unit 506, the second inference unit 508, and the recovery unit 510 in the vehicle off-line fault processing device. Furthermore, it may include, but is not limited to, other module units in the vehicle off-line fault processing device, which will not be elaborated upon in this example.

[0175] Optionally, the transmission device 606 described above is used to receive or send data via a network. Specific examples of the network described above may include wired networks and wireless networks. In one example, the transmission device 806 includes a Network Interface Controller (NIC), which can be connected to other network devices and a router via a network cable to communicate with the Internet or a local area network. In one example, the transmission device 606 is a radio frequency (RF) module, used for wireless communication with the Internet.

[0176] In addition, the above-mentioned electronic device also includes: a display 608 for displaying the first inference result and the second inference result; and a connection bus 610 for connecting the various module components in the above-mentioned electronic device.

[0177] In other embodiments, the aforementioned terminal device or server can be a node in a distributed system, wherein the distributed system can be a blockchain system, which is a distributed system formed by connecting multiple nodes through network communication. The nodes can form a peer-to-peer (P2P) network, and any form of computing device, such as a server, terminal, or other electronic device, can become a node in the blockchain system by joining this peer-to-peer network.

[0178] According to one aspect of this application, a computer program product is provided, comprising a computer program / instructions containing program code for performing the methods shown in the flowchart. In such embodiments, the computer program can be downloaded and installed from a network via a communication component, and / or installed from a removable medium. When the computer program is executed by a central processing unit, it performs various functions provided in embodiments of this application.

[0179] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0180] According to one aspect of this application, a computer-readable storage medium is provided, wherein a processor of a computer device reads computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the aforementioned method for handling vehicle off-line failures.

[0181] Optionally, in this embodiment, the computer-readable storage medium may be configured to store a computer program for performing the following steps:

[0182] S1, if a vehicle is detected to have a failure to go offline, obtain the fault code corresponding to the failure to go offline;

[0183] S2, input the fault code and the fault knowledge base corresponding to the fault code into the fault reasoning model corresponding to the fault code to perform the first reasoning operation and obtain the first reasoning result. The first reasoning result is used to indicate multiple candidate fault events associated with the offline fault.

[0184] S3, based on the verification information of multiple candidate fault events obtained from the vehicle, determines the target fault event that caused the offline failure from the multiple candidate fault events;

[0185] S4, input the target fault event and fault knowledge base into the fault reasoning model to perform the second reasoning operation and obtain the second reasoning result, wherein the second reasoning result is used to indicate the first fault recovery operation corresponding to the target fault event;

[0186] S5, perform the first fault recovery operation on the vehicle.

[0187] Optionally, in this embodiment, those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be implemented by a program instructing the hardware related to the terminal device. The program can be stored in a computer-readable storage medium, which may include: flash drive, read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0188] If the integrated units in the above embodiments are implemented as software functional units and sold or used as independent products, they can be stored in the aforementioned computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or 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 one or more computer devices (which may be personal computers, servers, or network devices, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application.

[0189] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0190] In the several embodiments provided in this application, it should be understood that the disclosed client can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units described above is only a logical functional division, and 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 through some interfaces, indirect coupling or communication connection between units or modules, and may be electrical or other forms.

[0191] The units described above 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.

[0192] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0193] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A method for handling vehicle off-line failures, characterized in that, include: If a vehicle is detected to have a failure to be taken off the production line, obtain the fault code corresponding to the failure to be taken off the production line. The fault code and the fault knowledge base corresponding to the fault code are input into the fault reasoning model corresponding to the fault code to perform a first reasoning operation and obtain a first reasoning result. The first reasoning result is used to indicate multiple candidate fault events associated with the offline fault. Based on the verification information of the multiple candidate fault events obtained from the vehicle, the target fault event that caused the offline failure is determined from the multiple candidate fault events. The target fault event and the fault knowledge base are input into the fault reasoning model to perform a second reasoning operation to obtain a second reasoning result, wherein the second reasoning result is used to indicate the first fault recovery operation corresponding to the target fault event; Perform the first fault recovery operation on the vehicle.

2. The method according to claim 1, characterized in that, After performing the first fault recovery operation on the vehicle, the method further includes: Based on the first operation result information of the first fault recovery operation obtained from the vehicle, it is determined whether the offline fault has been recovered; If the offline fault is not recovered, the first fault recovery operation, the target fault event, and the fault knowledge base are input into the fault reasoning model to perform a third reasoning operation to obtain a third reasoning result, wherein the third reasoning result is used to indicate the second fault recovery operation corresponding to the target fault event; Perform the second fault recovery operation on the vehicle.

3. The method according to claim 2, characterized in that, After determining whether the offline fault has been recovered, the method further includes: When the offline fault has been recovered, knowledge extraction is performed on the fault information associated with the offline fault to obtain the fault knowledge corresponding to the offline fault, wherein the fault information includes the target fault event, the first fault recovery operation and the first operation result information; The fault knowledge is stored in the fault knowledge base.

4. The method according to claim 1, characterized in that, After inputting the fault code and the corresponding fault knowledge base into the fault reasoning model corresponding to the fault code for a first reasoning operation and obtaining a first reasoning result, the method further includes: Based on the verification information, at least two fault events are selected from the plurality of candidate fault events, wherein the target fault event is the fault event among the at least two fault events; Based on the priority information of each fault event among the at least two fault events stored in the fault knowledge base, the first fault event with the highest priority is determined from the at least two fault events; If the third fault recovery operation corresponding to the first fault event is obtained through the fault knowledge base and the fault reasoning model, the third fault recovery operation is performed on the vehicle. If the second operation result information corresponding to the third fault recovery operation indicates that the offline fault has been recovered, it is determined that the offline fault handling is complete. The priority of the first fault event stored in the fault knowledge base is increased.

5. The method according to claim 4, characterized in that, After performing the third fault recovery operation on the vehicle, the method further includes: If the second operation result information indicates that the offline fault has not been recovered, the priority of the first fault event stored in the fault knowledge base is reduced. The second fault event with the highest priority is determined from the remaining fault events of the at least two fault events; If the fourth fault recovery operation corresponding to the second fault event is obtained through the fault knowledge base and the fault reasoning model, the fourth fault recovery operation is performed on the vehicle.

6. The method according to any one of claims 1 to 5, characterized in that, The step of inputting the target fault event and the fault knowledge base into the fault reasoning model for a second reasoning operation to obtain a second reasoning result includes: The target fault event and the fault knowledge base are input into the fault reasoning model to perform the second reasoning operation, thereby obtaining the first fault recovery sub-operation and the second fault recovery sub-operation corresponding to the target fault event. The first fault recovery operation performed on the vehicle includes: Perform the first fault recovery sub-operation on the vehicle and obtain the third operation result information corresponding to the first fault recovery sub-operation; If the third operation result information matches the expected operation result corresponding to the first fault recovery operation, the second fault recovery sub-operation is performed on the vehicle; If the operation result information does not meet the expected operation result, the third operation result information, the target fault event, and the fault knowledge base are input into the fault reasoning model to adjust the second fault recovery sub-operation and obtain the third fault recovery sub-operation. The third fault recovery sub-operation is performed on the vehicle.

7. The method according to any one of claims 1 to 5, characterized in that, Before inputting the fault code and the corresponding fault knowledge base into the fault reasoning model corresponding to the fault code for the first reasoning operation and obtaining the first reasoning result, the method further includes: Obtain the target fault code range to which the fault code belongs; The fault knowledge base corresponding to the target fault code interval is determined from multiple fault knowledge bases, and the fault reasoning model corresponding to the target fault code interval is determined from multiple fault reasoning models, wherein one fault code interval corresponds to one fault knowledge base and one fault handling model.

8. A device for handling vehicle off-line faults, characterized in that, include: The acquisition unit is used to acquire the fault code corresponding to the offline fault when a vehicle is detected to have an offline fault. The first reasoning unit is used to input the fault code and the fault knowledge base corresponding to the fault code into the fault reasoning model corresponding to the fault code to perform the first reasoning operation and obtain the first reasoning result. The first reasoning result is used to indicate multiple candidate fault events associated with the offline fault. The determining unit is used to determine the target fault event that causes the offline failure from multiple candidate fault events based on the verification information obtained from multiple candidate fault events from the vehicle. The second reasoning unit is used to input the target fault event and the fault knowledge base into the fault reasoning model to perform a second reasoning operation and obtain a second reasoning result. The second reasoning result is used to indicate the first fault recovery operation corresponding to the target fault event. The recovery unit is used to perform the first fault recovery operation on the vehicle.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes a stored program, wherein the program, when executed, performs the method described in any one of claims 1 to 7.

10. An electronic device comprising a memory and a processor, characterized in that, The memory stores a computer program, and the processor is configured to execute the method described in any one of claims 1 to 7 through the computer program.

Images