Vehicle fault diagnosis self-repairing method and device, electronic equipment and product

Abstract

The present application relates to a kind of vehicle fault diagnosis self-repairing method, device, electronic equipment and product, involve vehicle fault diagnosis technical field, the method includes: in response to the vehicle data uploaded by received vehicle terminal, according to fault rule base, vehicle data is matched with fault;When vehicle data is fault data, vehicle data is added to fault information list;According to self-healing rule, the data in fault information list is analyzed, when the data in fault information list meets self-healing rule, vehicle data is added to self-healing list;The fault type of vehicle data in self-healing list is determined, and according to fault type, generate fault repair strategy, wherein, fault repair strategy is used to repair the fault of vehicle data corresponding, to reach the effect that the precise identification and efficient repair of vehicle fault are realized in combination with various data in vehicle.

Description

Technical Field

[0001] This invention relates to the technical field of vehicle fault diagnosis, and specifically to a self-repair method, device, electronic device, and product for vehicle fault diagnosis. Background Technology

[0002] With the rapid development of vehicle-to-everything (V2X) technology and the increasing intelligence of vehicles, onboard terminals can collect and upload vehicle operating data, fault codes, system logs, and other information in real time through sensors, communication modules, and software systems. This data covers the vehicle's hardware and software status. Existing vehicle fault diagnosis systems typically only categorize and summarize uploaded fault codes using static rules. However, when faced with massive amounts of heterogeneous data (such as logs and sensor data), they struggle to accurately identify the root cause of the fault and provide corresponding solutions. Therefore, how to combine various types of data from the vehicle to achieve accurate fault identification and efficient repair is an urgent problem to be solved. Summary of the Invention

[0003] One of the objectives of this invention is to provide a vehicle fault diagnosis and self-repair method, device, electronic device, and product to solve the problem in the prior art of how to combine various types of data in the vehicle to achieve accurate identification and efficient repair of vehicle faults.

[0004] To achieve the above objectives, the technical solution adopted by the present invention is as follows:

[0005] In a first aspect, embodiments of this application provide a vehicle fault diagnosis and self-repair method, the method comprising:

[0006] In response to the vehicle data uploaded by the vehicle terminal, fault matching is performed on the vehicle data according to the fault rule base; wherein, the vehicle data includes at least one of the following: basic vehicle information, vehicle operation data, fault codes, system resource information, and system logs;

[0007] When the vehicle data is fault data, add the vehicle data to the fault information list;

[0008] According to the self-healing rules, perform self-healing analysis on the data in the fault information list. When the data in the fault information list meets the self-healing rules, add the vehicle data to the self-healing list.

[0009] Determine the fault type of the vehicle data in the self-healing list, and generate a fault repair strategy based on the fault type. The fault repair strategy is used to repair the fault corresponding to the vehicle data.

[0010] Based on the above technical means, vehicle data is first matched using a fault rule base, then centrally managed through a fault information list, and faults suitable for automatic repair are filtered into the self-healing list through self-healing rules. Finally, targeted fault repair strategies are generated based on the identified fault types. Thus, in the vehicle cloud diagnostic scenario, combined with various data in the vehicle, accurate identification and efficient repair of vehicle faults are achieved, realizing the continuous connection between diagnostic results and automatic handling actions.

[0011] Furthermore, based on the fault type, a fault repair strategy is generated, including: when the fault type is a system resource shortage fault, a repair instruction is generated and sent to the corresponding vehicle terminal. The repair instruction is used to control the vehicle terminal to perform at least one of the following operations: release memory, clear temporary files, and restart the system.

[0012] Based on the aforementioned technical means, the cloud server generates control content for resource repair based on the fault type and sends it to the vehicle terminal, which then performs local resource processing. This allows faults such as insufficient system resources to be directly handled at the vehicle terminal, reducing manual intervention and enabling timely completion of resource recovery, temporary file cleanup, and system recovery. This improves fault handling efficiency and enhances the stability of the vehicle terminal's operating status.

[0013] Furthermore, based on the fault type, a fault repair strategy is generated, including:

[0014] When the fault type is a running fault, a repair script is generated and sent to the corresponding vehicle terminal. The repair script is used to repair the faulty process and / or faulty function program in the vehicle terminal. The faulty process and / or faulty function program is determined by vehicle data.

[0015] The method also includes: disabling faulty processes and / or faulty function programs based on the received repair script.

[0016] Based on the aforementioned technical methods, operational faults can be located to specific processes or functional programs through vehicle data. The cloud server then directly sends the corresponding repair script to the in-vehicle terminal for shielding and repair, enabling the in-vehicle terminal to handle abnormal faults without human intervention. Because a correspondence is established between the repair target and vehicle data, the fault handling process incorporates various types of data from the vehicle, achieving accurate identification and automated, efficient repair of vehicle faults. This ensures the generated repair scripts remain highly targeted and reduces manual intervention, thereby improving the efficiency and consistency of fault handling in vehicle-cloud diagnostic scenarios.

[0017] Furthermore, the method also includes: obtaining the system logs uploaded after the vehicle terminal runs the fault repair strategy; determining the first fault repair quality of the fault repair strategy based on the system logs, and generating a first quality report based on the first fault repair quality.

[0018] Based on the aforementioned technical means, the cloud server can objectively evaluate the fault repair effect based on the system logs after the actual execution of the vehicle terminal, and generate a traceable first quality report, so that the repair results have clear log basis and quality record, which facilitates the subsequent analysis and management of the effectiveness of the repair strategy.

[0019] Furthermore, based on the fault type, a fault repair strategy is generated, including:

[0020] When the fault type is a system-level fault, a repair code is generated based on the repair rule base, and a test version is generated based on the repair code;

[0021] Send the test version to the test terminal and obtain the test version's running logs on the test terminal;

[0022] When the test version has fixed the faults corresponding to the vehicle data based on the operation log, the fix code is added to the code repository. The code in the code repository is used to generate system software, and the system software is used to update the system of the vehicle terminal.

[0023] Based on the above technical means, system-related faults can form a closed-loop processing link between repair, verification and solidification. The repair results can be determined through the test terminal operation logs, and the verified code can be transferred to the system software through the code repository, thereby improving the consistency of system-related fault handling and the reliability of subsequent deployment.

[0024] Furthermore, the method also includes: determining the second fault repair quality of the test version based on the running logs of the test version in the test terminal, and generating a second quality report based on the second fault repair quality.

[0025] Based on the aforementioned technical means, the quality of the test version's second fault repair for system-related faults can be determined by analyzing the runtime logs of the test version running in the test terminal. A second quality report can then be generated, allowing the test verification results to be output and stored in a unified format. This provides a traceable evaluation basis for the repair effect before the system software update, while also providing clear log evidence and quality feedback for subsequent iterative adjustments to the repair code.

[0026] Furthermore, fault matching is performed on vehicle data according to the fault rule base, including:

[0027] Extract fault information from vehicle data, match the fault information according to the fault rule base, and calculate the fault credibility corresponding to the fault information.

[0028] When the confidence level of a fault is greater than or equal to the first confidence level threshold, the vehicle data is recorded as fault data.

[0029] Based on the above technical means, fault information in vehicle data is extracted in a standardized and rule-based manner, so that fault determination no longer depends on a single field or a single report result, but forms a credibility judgment based on the matching strength, and filters the results with a first credibility threshold, thereby making the data entering subsequent processing have higher fault consistency and manageability, and thus supporting the stable execution of subsequent self-repair analysis.

[0030] Furthermore, the method also includes: when the fault confidence level is less than a first confidence level threshold and greater than or equal to a second confidence level threshold, marking the vehicle data and generating corresponding manual annotation prompts, wherein the manual annotation prompts are used to prompt operators to manually annotate the marked vehicle data for faults.

[0031] Based on the above technical means, vehicle data near the automatic judgment boundary is transferred to manual processing, and the results of manual annotation can be used as input for subsequent fault rule correction and model training, thereby improving the consistency of fault data confirmation and enhancing the adaptability of diagnostic results to complex vehicle operation scenarios.

[0032] Furthermore, the method also includes updating the fault rule base based on the results of manual fault labeling.

[0033] Based on the above technical means, the fault rule base can be updated according to the results of manual fault labeling. This allows the fault rule base to continuously absorb the real fault features and false alarm features after manual review, so that the subsequent matching logic is consistent with the actual operating status of the vehicle. This improves the accuracy of fault identification and rule adaptation capability, and reduces the impact of repeated misjudgments on subsequent diagnosis and self-repair processing.

[0034] Furthermore, the method also includes discarding vehicle data when the fault confidence level is less than a second confidence level threshold.

[0035] Based on the above technical means, data with low fault reliability will no longer enter the subsequent diagnostic link, reducing the waste of computing power.

[0036] Furthermore, the method also includes: when the data in the fault information list does not conform to the self-healing rules, the vehicle data is marked and corresponding manual repair prompts are generated. The manual repair prompts are used to prompt the operators to manually repair the marked vehicle data.

[0037] Based on the aforementioned technical means, the cloud server can promptly transfer fault data that is not suitable for automatic processing to the manual repair channel, and maintain the correspondence between data tags and prompt information, making the objects of manual intervention clearly traceable, thereby improving the efficiency of fault handling and the accuracy of repair results.

[0038] Furthermore, the method also includes:

[0039] Generate a manual test version from the manual programming code corresponding to the manual fault repair, and send the manual test version to the test terminal;

[0040] Obtain the test logs of the manually tested version in the test terminal;

[0041] Based on the test logs, determine the third fault repair quality of the manually tested version, and generate a third quality report based on the third fault repair quality.

[0042] Based on the above technical means, the code corresponding to manual repair is built into a manual test version and verified in the test terminal. Then, a third fault repair quality and a third quality report are generated based on the test logs, so that the effect of manual repair can be uniformly recorded and quantitatively evaluated, thereby realizing the closed-loop confirmation of the manual repair results and providing a basis for subsequent fault tracking, manual review and rule optimization.

[0043] Secondly, embodiments of this application provide a vehicle fault diagnosis self-repair device, the device comprising:

[0044] The matching module is used to respond to the vehicle data uploaded by the vehicle terminal and perform fault matching on the vehicle data according to the fault rule base; wherein, the vehicle data includes at least one of the following: basic vehicle information, vehicle operation data, fault codes, system resource information, and system logs;

[0045] The module adds vehicle data to the fault information list when the vehicle data is fault data.

[0046] The addition module is also used to perform self-healing analysis on the data in the fault information list according to the self-healing rules. When the data in the fault information list meets the self-healing rules, the vehicle data is added to the self-healing list.

[0047] The generation module is used to determine the fault type of the vehicle data in the self-healing list, and generate a fault repair strategy based on the fault type. The fault repair strategy is used to repair the fault corresponding to the vehicle data.

[0048] Based on the above technical means, vehicle data is first matched using a fault rule base, then centrally managed through a fault information list, and faults suitable for automatic repair are filtered into the self-healing list through self-healing rules. Finally, targeted fault repair strategies are generated based on the identified fault types. Thus, in the vehicle cloud diagnostic scenario, combined with various data in the vehicle, accurate identification and efficient repair of vehicle faults are achieved, realizing the continuous connection between diagnostic results and automatic handling actions.

[0049] Furthermore, when the generation module generates a fault repair strategy based on the fault type, it is specifically used to: generate a repair instruction when the fault type is insufficient system resources, and send the repair instruction to the corresponding vehicle terminal. The repair instruction is used to control the vehicle terminal to perform at least one of the following operations: release memory, clean up temporary files, and restart the system.

[0050] Based on the aforementioned technical means, the cloud server generates control content for resource repair based on the fault type and sends it to the vehicle terminal, which then performs local resource processing. This allows faults such as insufficient system resources to be directly handled at the vehicle terminal, reducing manual intervention and enabling timely completion of resource recovery, temporary file cleanup, and system recovery. This improves fault handling efficiency and enhances the stability of the vehicle terminal's operating status.

[0051] Furthermore, when the generation module generates a fault repair strategy based on the fault type, it is specifically used to: generate a repair script when the fault type is a running fault, and send the repair script to the corresponding vehicle terminal. The repair script is used to repair the fault process and / or fault function program in the vehicle terminal, and the fault process and / or fault function program is determined by vehicle data.

[0052] The device also includes a shielding module for shielding faulty processes and / or faulty function programs based on the received repair script.

[0053] Based on the aforementioned technical methods, operational faults can be located to specific processes or functional programs through vehicle data. The cloud server then directly sends the corresponding repair script to the in-vehicle terminal for shielding and repair, enabling the in-vehicle terminal to handle abnormal faults without human intervention. Because a correspondence is established between the repair target and vehicle data, the fault handling process incorporates various types of data from the vehicle, achieving accurate identification and automated, efficient repair of vehicle faults. This ensures the generated repair scripts remain highly targeted and reduces manual intervention, thereby improving the efficiency and consistency of fault handling in vehicle-cloud diagnostic scenarios.

[0054] Furthermore, the device also includes:

[0055] The acquisition module is used to acquire system logs uploaded after the vehicle terminal implements the fault repair strategy;

[0056] The generation module is also used to determine the first fault repair quality of the fault repair strategy based on the system logs, and generate a first quality report based on the first fault repair quality.

[0057] Based on the aforementioned technical means, the cloud server can objectively evaluate the fault repair effect based on the system logs after the actual execution of the vehicle terminal, and generate a traceable first quality report, so that the repair results have clear log basis and quality record, which facilitates the subsequent analysis and management of the effectiveness of the repair strategy.

[0058] Furthermore, when the generation module generates a fault repair strategy based on the fault type, it is specifically used for:

[0059] When the fault type is a system-level fault, a repair code is generated based on the repair rule base, and a test version is generated based on the repair code;

[0060] Send the test version to the test terminal and obtain the test version's running logs on the test terminal;

[0061] When the test version has fixed the faults corresponding to the vehicle data based on the operation log, the fix code is added to the code repository. The code in the code repository is used to generate system software, and the system software is used to update the system of the vehicle terminal.

[0062] Based on the above technical means, system-related faults can form a closed-loop processing link between repair, verification and solidification. The repair results can be determined through the test terminal operation logs, and the verified code can be transferred to the system software through the code repository, thereby improving the consistency of system-related fault handling and the reliability of subsequent deployment.

[0063] Furthermore, the generation module is also used to: determine the second fault repair quality of the test version based on the running logs of the test version in the test terminal, and generate a second quality report based on the second fault repair quality.

[0064] Based on the aforementioned technical means, the quality of the test version's second fault repair for system-related faults can be determined by analyzing the runtime logs of the test version running in the test terminal. A second quality report can then be generated, allowing the test verification results to be output and stored in a unified format. This provides a traceable evaluation basis for the repair effect before the system software update, while also providing clear log evidence and quality feedback for subsequent iterative adjustments to the repair code.

[0065] Furthermore, the matching module specifically includes:

[0066] The calculation submodule is used to extract fault information contained in vehicle data, match the fault information according to the fault rule library, and calculate the fault credibility corresponding to the fault information.

[0067] The comparison submodule is used to record vehicle data as fault data when the fault confidence level is greater than or equal to the first confidence level threshold.

[0068] Based on the above technical means, fault information in vehicle data is extracted in a standardized and rule-based manner, so that fault determination no longer depends on a single field or a single report result, but forms a credibility judgment based on the matching strength, and filters the results with a first credibility threshold, thereby making the data entering subsequent processing have higher fault consistency and manageability, and thus supporting the stable execution of subsequent self-repair analysis.

[0069] Furthermore, the comparison submodule is also used to: mark vehicle data and generate corresponding manual annotation prompts when the fault confidence level is less than the first confidence level threshold and greater than or equal to the second confidence level threshold. The manual annotation prompts are used to prompt operators to manually annotate the marked vehicle data for faults.

[0070] Based on the above technical means, vehicle data near the automatic judgment boundary is transferred to manual processing, and the results of manual annotation can be used as input for subsequent fault rule correction and model training, thereby improving the consistency of fault data confirmation and enhancing the adaptability of diagnostic results to complex vehicle operation scenarios.

[0071] Furthermore, the device also includes an update module for updating the fault rule base based on the results of manual fault labeling.

[0072] Based on the above technical means, the fault rule base can be updated according to the results of manual fault labeling. This allows the fault rule base to continuously absorb the real fault features and false alarm features after manual review, so that the subsequent matching logic is consistent with the actual operating status of the vehicle. This improves the accuracy of fault identification and rule adaptation capability, and reduces the impact of repeated misjudgments on subsequent diagnosis and self-repair processing.

[0073] Furthermore, the comparison submodule is also used to discard vehicle data when the fault confidence level is less than the second confidence level threshold.

[0074] Based on the above technical means, data with low fault reliability will no longer enter the subsequent diagnostic link, reducing the waste of computing power.

[0075] Furthermore, the device also includes a marking module, which marks the vehicle data when the data in the fault information list does not conform to the self-healing rules, and generates corresponding manual repair prompts. The manual repair prompts are used to prompt operators to manually repair the marked vehicle data.

[0076] Based on the aforementioned technical means, the cloud server can promptly transfer fault data that is not suitable for automatic processing to the manual repair channel, and maintain the correspondence between data tags and prompt information, making the objects of manual intervention clearly traceable, thereby improving the efficiency of fault handling and the accuracy of repair results.

[0077] Furthermore, the generation module is also used to: generate a manual test version from the manual programming code corresponding to the manual fault repair, and send the manual test version to the test terminal;

[0078] The acquisition module is also used to: acquire test logs of the manually tested version in the test terminal;

[0079] The generation module is also used to: determine the third fault repair quality of the manually tested version based on the test logs, and generate a third quality report based on the third fault repair quality.

[0080] Based on the above technical means, the code corresponding to manual repair is built into a manual test version and verified in the test terminal. Then, a third fault repair quality and a third quality report are generated based on the test logs, so that the effect of manual repair can be uniformly recorded and quantitatively evaluated, thereby realizing the closed-loop confirmation of the manual repair results and providing a basis for subsequent fault tracking, manual review and rule optimization.

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

[0082] The memory stores the instructions that the computer executes;

[0083] The processor executes computer execution instructions stored in memory, causing the processor to perform the methods described above.

[0084] 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 methods provided above.

[0085] Fifthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the method described above.

[0086] The beneficial effects of this invention are:

[0087] The vehicle fault diagnosis self-repair method, device, electronic device, and product provided by this invention respond to vehicle data uploaded by the vehicle terminal, and perform fault matching on at least one type of vehicle data, including basic vehicle information, vehicle operation data, fault codes, system resource information, and system logs, according to a fault rule base. When the vehicle data is faulty, it is added to the fault information list. This allows for the effective aggregation and preliminary identification of vehicle fault information by combining various types of data in the vehicle. By performing self-healing analysis on the data in the fault information list according to self-healing rules, and adding the vehicle data to the self-healing list when it meets the self-healing rules, further screening of faults with self-repair conditions is achieved. Furthermore, a fault repair strategy is generated based on the fault type of the vehicle data in the self-healing list. This not only improves the accuracy of fault identification but also automatically provides a repair processing strategy for the fault identification result, thereby improving the fault processing efficiency and reliability of repair results in the vehicle cloud diagnostic scenario. Attached Figure Description

[0088] 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.

[0089] Figure 1 This is a flowchart illustrating the self-repair method for vehicle fault diagnosis of the present invention. Figure 1 ;

[0090] Figure 2 This is a flowchart illustrating the self-repair method for vehicle fault diagnosis of the present invention. Figure 2 ;

[0091] Figure 3 This is a schematic diagram of the structure of the vehicle fault diagnosis and self-repair device of the present invention. Figure 1 ;

[0092] Figure 4 This is a schematic diagram of the structure of the vehicle fault diagnosis and self-repair device of the present invention. Figure 2 ;

[0093] Figure 5 This is a schematic diagram of the electronic device of the present invention.

[0094] The accompanying drawings illustrate 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 particular embodiments. Detailed Implementation

[0095] The embodiments of the present invention will be described below with reference to the accompanying drawings and preferred embodiments. Those skilled in the art can easily understand other advantages and effects of the present invention from the content disclosed in this specification. The present invention can also be implemented or applied through other different specific embodiments, and various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of the present invention. It should be understood that the preferred embodiments are only for illustrating the present invention and not for limiting the scope of protection of the present invention.

[0096] It should be noted that the illustrations provided in the following embodiments are only schematic representations of the basic concept of the present invention. Therefore, the drawings only show the components related to the present invention and are not drawn according to the actual number, shape and size of the components in the actual implementation. In the actual implementation, the form, quantity and proportion of each component can be arbitrarily changed, and the layout of the components may also be more complex.

[0097] Existing vehicle cloud diagnostic solutions typically receive data uploaded from the vehicle terminal, match fault codes and logs according to a preset rule base, categorize and display the matching results, and then have humans review, dispatch, and handle the repairs based on experience. This type of solution primarily relies on static rules and can complete basic fault identification, but it lacks the ability to effectively utilize different vehicle states, operating environments, and contextual information.

[0098] Because this method of fault diagnosis relies on fixed rules and single-report results, it struggles to accurately distinguish between genuine faults and occasional false alarms, and it also makes it difficult to quickly filter out suitable problem types for automatic handling from the fault information. Furthermore, the fault handling process in this type of solution often remains at the stage of manual analysis and manual repair, lacking an automatic collection of fault information and a mechanism for connecting it to subsequent handling, resulting in low fault diagnosis efficiency and long processing cycles. These shortcomings further lead to untimely fault response, excessive repetitive work, and insufficient assurance of vehicle operational stability.

[0099] In view of this, how to combine various data in the vehicle to achieve accurate identification and efficient repair of vehicle faults has become an urgent technical problem to be solved.

[0100] To address the aforementioned issues, this application provides a vehicle fault diagnosis and self-repair method. Upon receiving vehicle data uploaded by the vehicle terminal, the method first performs fault matching according to a fault rule base and adds data identified as faulty to a fault information list. Then, it performs self-healing analysis on the data in the fault information list based on self-healing rules, adding data that conforms to the self-healing rules to a self-healing list. Subsequently, it determines the fault type of the vehicle data in the self-healing list and generates a fault repair strategy based on the fault type. By combining various types of data from the vehicle, it achieves accurate identification and automated, efficient repair of vehicle faults.

[0101] 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 now be described with reference to the accompanying drawings.

[0102] Figure 1 Flowchart of the vehicle fault diagnosis self-repair method provided in this application Figure 1 ,like Figure 1 As shown, the method includes:

[0103] S101: In response to the vehicle data uploaded by the vehicle terminal, perform fault matching on the vehicle data according to the fault rule base; wherein, the vehicle data includes at least one of the following: basic vehicle information, vehicle body operation data, fault codes, system resource information, and system logs.

[0104] For example, the in-vehicle terminal is used to collect and upload vehicle operation-related information. It can be a vehicle-to-everything (V2X) control unit installed on the vehicle or a communication processing module integrated into the vehicle's infotainment system. It establishes data connections with at least the vehicle bus, body control system, powertrain controller, storage module, and log output module. Vehicle data serves as the input data set for fault diagnosis and may contain only one of the aforementioned data types or multiple data types simultaneously.

[0105] Taking new energy electric vehicles as an example, basic vehicle information may include vehicle identification number, vehicle model, software version, hardware version, configuration code, and regional information; vehicle operation data may include vehicle speed, motor speed, power battery voltage, on-board terminal power supply voltage, power battery temperature, tire pressure, status of various sensors, and communication status; fault codes may include standard diagnostic fault codes and their trigger time, duration, and number of occurrences; system resource information may include CPU utilization, memory utilization, storage space utilization, number of threads, and process status; system logs may include exception logs, crash logs, service start / stop logs, and communication timeout logs.

[0106] The fault rule base is used for fault matching. It is essentially a set of rules that are pre-built and stored in a cloud server or diagnostic platform. The rule content includes fault feature items, matching conditions and association conditions. Fault matching is the process of identifying whether there is information in the vehicle data that can be classified as a fault.

[0107] In one example, the vehicle-mounted terminal collects vehicle data according to a pre-installed data collection program, based on the configured collection list and rules, and uploads the collected data to a cloud server. The cloud server receives the data packets uploaded by the vehicle-mounted terminal via a message queue interface, Hypertext Transfer Protocol (HTTP) interface, or a long-lived connection. Upon receiving the data packets, the cloud server first performs packet parsing, field validation, timestamp correction, and vehicle identity verification, and then generates a diagnostic record based on the vehicle identification number, upload time, and data type. For multi-source data uploaded at the same time, alignment can be performed based on a unified time window to form a corresponding vehicle data object for a single report from a single vehicle.

[0108] Subsequently, fault-related information is extracted from the vehicle data. This extraction may include fault codes, system resource parameters, operating parameters, and abnormal records in the system logs. Each rule in the fault rule base can consist of triggering conditions, joint conditions, and a judgment output. For example, fault codes, log characteristics, and resource usage status can be combined for matching. Alternatively, a rule set can be formed based on historical vehicle data, and joint judgments can be made based on the correlation between basic vehicle information and fault codes, system logs, and vehicle operating data. For instance, single-rule matching can be performed first to obtain initial matching results for each fault characteristic, and then cross-rule matching can be performed to determine whether the same vehicle meets the corresponding fault conditions within the current time window.

[0109] Finally, the fault rule base can output the corresponding fault judgment result based on the rule matching result. For example, the cloud server can match fault codes, context logs, driving data and basic vehicle information based on the fault rule base to comprehensively judge the credibility of the fault, and then determine whether the current vehicle data is fault data based on the credibility.

[0110] Based on the above analysis, it can be seen that by matching at least one of the following: vehicle basic information, vehicle operation data, fault codes, system resource information, and system logs, rather than relying solely on a single data point, the accuracy of fault identification can be improved in the initial stage of fault diagnosis, and fault input can be provided for subsequent self-healing analysis.

[0111] S102: When the vehicle data is fault data, add the vehicle data to the fault information list.

[0112] For example, the fault information list is used for centralized management of data that has been identified as faulty. It can be a fault record table stored in a relational database, or a fault queue stored in a combined cache and persistent database structure. Each record in the fault information list includes at least the vehicle identifier, data reception time, fault rule hit result, fault confidence level, fault code, key operating parameters, system resource status summary, and log summary. Adding vehicle data to the fault information list signifies that the fault data identified by the fault rule base on the cloud server has been separated from the original data stream and transferred to the data set to be processed for subsequent self-healing analysis.

[0113] In one example, after obtaining the fault determination result in step S101, the cloud server generates a corresponding fault record item and establishes a mapping relationship between the original vehicle data and the corresponding fault before writing it into the fault information list. The writing process may include generating a unique fault event identifier, recording the first discovery time, recording the most recent reporting time, and the cumulative number of occurrences. For data from the same vehicle that is repeatedly reported within a preset time window and hits the same fault rule, the cloud server may not create a new fault event, but instead update the occurrence count, latest status, and additional log content on the original fault record item. For data from the same vehicle that hits different fault rules, the cloud server may generate multiple fault record items separately and form a chain of related events through vehicle identifiers and time sequence. To ensure a clear order of subsequent processing, the fault information list may also include a status field, which is used to identify at least the processing statuses such as pending self-healing analysis, in analysis, entered into the self-healing list, transferred to manual processing, and completed processing.

[0114] In another example, the fault information list can be indexed by fault category, vehicle identifier, or reception time to support rapid filtering and batch retrieval. The fault information list can also sort or label added vehicle data according to fault codes, the degree of abnormality in vehicle operating data, the level of abnormality in system resources, or the level of abnormality in logs. For example, records with CPU utilization consistently above a threshold and accompanied by service crash logs can be given higher priority, while records with only minor fluctuations in operating parameters can be given lower priority. For scenarios requiring tracking of the fault evolution process, the fault information list can also save contextual data fragments within a certain time range before and after the fault, so that subsequent self-healing rules can reference the continuous state change information of the same vehicle when determining whether automatic repair is suitable.

[0115] Based on the above analysis, it can be seen that adding vehicle data to the fault information list is not simply storage, but rather forming a searchable, updatable, and sortable set of faults to be processed. This allows confirmed fault data to enter a unified subsequent decision-making process, ensuring that the self-healing analysis targets real fault events that have been preliminarily identified.

[0116] S103: Based on the self-healing rules, perform self-healing analysis on the data in the fault information list. When the data in the fault information list meets the self-healing rules, add the vehicle data to the self-healing list.

[0117] For example, self-healing rules are used to determine whether fault data is suitable for automatic repair, while self-healing analysis is the process of performing an automatic repair feasibility assessment on each fault record in the fault information list. The self-healing list is used to store fault data that meets the automatic repair conditions. Its storage structure can be set independently from the fault information list, or it can be logically distinguished within the fault information list using status bits and list identifier fields. The judgment objects of self-healing rules include not only the fault codes themselves, but also related information such as basic vehicle information, vehicle operating data, system resource information, system logs, and the circumstances of the fault occurrence.

[0118] In one example, the cloud server reads fault records / vehicle data to be analyzed sequentially from the fault information list and performs rule item validation on each record. Self-healing rules can pre-establish a correspondence between fault types and self-healing conditions to determine whether a corresponding fault record meets the conditions for entering the automatic repair process. Only when a fault record meets the corresponding self-healing rule does the cloud server determine that it has the basis to enter the automatic repair process.

[0119] In another example, self-healing rules can be organized using a rule matrix. Rows in the matrix represent fault categories, columns represent decision factors, and matrix cells represent the decision thresholds or decision logic for the corresponding factors. For example, for faults involving abnormal system resource information, decision factors include the duration of memory usage, remaining storage space, abnormal process identifiers, and resource alarm keywords in the system logs; for faults involving abnormal operation, decision factors include the deviation of vehicle operation data, fault code reproduction, and execution failure records in the system logs; for system-related faults, decision factors include the service crash type, module version information, and recovery status after restart.

[0120] The cloud server compares the feature values ​​in the fault information list item by item according to the rule matrix. When all the necessary conditions are met, the corresponding vehicle data is written into the self-healing list, and the status in the fault information list is updated to "entered the self-healing list". When the self-healing rules are not met, the status is updated to "transfer to manual processing" and the system enters the corresponding work order system.

[0121] Based on the above analysis, it can be seen that the self-healing analysis step S103 plays a role in fault diversion in the overall scheme. It filters the confirmed faults through preset self-healing rules, separates the faults suitable for automatic processing from all faults, so that the subsequent repair strategy can generate fault data that meets the execution conditions, thereby enabling the automatic repair path to be connected with other handling paths within the cloud server.

[0122] S104: Determine the fault type of the vehicle data in the self-healing list, and generate a fault repair strategy based on the fault type, wherein the fault repair strategy is used to repair the fault corresponding to the vehicle data.

[0123] For example, fault types serve as the basis for selecting and generating repair strategies, while fault repair strategies are executable repair content formed for specific fault types. Fault types can be categorized into system resource insufficiency faults, operational faults, and system faults based on differences in self-healing objects and repair actions. System resource insufficiency faults correspond to issues such as abnormal resource usage, insufficient storage, and thread blocking; operational faults correspond to issues such as abnormal operating parameters, abnormal business process execution, or abnormal service interaction; and system faults correspond to issues such as program module crashes, system service failures, version anomalies, or corrupted configurations. Fault repair strategies can be stored using structured strategy objects, which at least include the target vehicle identifier, fault type, execution action, action parameters, execution order, receipt requirements, and failure rollback conditions.

[0124] In one example, after reading each record in the self-healing list, the cloud server can first perform fault type identification based on fault codes, resource metrics, log characteristics, and operational status characteristics. For example, it can initially classify fault codes and candidate fault types according to a preset mapping table, and then perform secondary correction by combining system resource information and system logs. If a fault code may correspond to both temporary resource shortages and service logic anomalies, the cloud server further determines whether there are resource characteristics such as high CPU usage, continuous memory growth, full disk, or abnormal thread accumulation. If the above resource characteristics exist, it is classified as a system resource shortage fault. If there are no resource anomalies, but there are situations such as interface call timeouts, task scheduling failures, or business process interruption logs, it is classified as an operational fault. Records with core service crashes, corrupted critical configuration files, or failed system module verifications are classified as system faults.

[0125] In another example, the cloud server can generate corresponding fault repair strategies for different fault types and store the generated strategies in a strategy queue to form tasks to be issued; alternatively, the strategies can be sent to the corresponding vehicle terminal via a communication channel, where the vehicle terminal will parse and execute them. To ensure that the strategy matches the fault, pre-execution checks and post-execution verification conditions can also be attached when the strategy is generated. For example, before execution, it can be confirmed that the vehicle is online and the power supply is stable; after execution, new system logs, system resource information, and fault code statuses can be sent back for review.

[0126] Based on the above analysis, it can be seen that by first determining the fault type of the vehicle data in the self-healing list, and then generating differentiated fault repair strategies according to the fault type, the same automatic repair process can output different execution content for faults of different natures, thereby completing the closed-loop processing from fault identification, fault screening to repair strategy generation.

[0127] It should be noted that the cloud server can also score the quality of fault repair strategies based on version analysis rules, and combine warning rules and repair rules to provide risk warnings and corresponding repair strategies.

[0128] In summary, this application provides a vehicle fault diagnosis and self-repair method, comprising: responding to received vehicle data uploaded by an in-vehicle terminal, performing fault matching on the vehicle data according to a fault rule base; when the vehicle data is fault data, adding the vehicle data to a fault information list; performing self-healing analysis on the data in the fault information list according to self-healing rules, and adding the vehicle data to a self-healing list when the data in the fault information list conforms to the self-healing rules; determining the fault type of the vehicle data in the self-healing list, and generating a fault repair strategy according to the fault type, wherein the fault repair strategy is used to repair the fault corresponding to the vehicle data.

[0129] The above method first uses a fault rule base to match vehicle data, then manages the fault information list centrally, and filters faults suitable for automatic repair into the self-healing list through self-healing rules. Finally, it generates targeted fault repair strategies based on the identified fault types. Thus, in the vehicle cloud diagnostic scenario, it combines various data in the vehicle to achieve accurate identification and efficient repair of vehicle faults, realizing the continuous connection between diagnostic results and automatic handling actions.

[0130] In one possible implementation, a fault repair strategy is generated based on the fault type, including: when the fault type is a system resource shortage fault, a repair instruction is generated and sent to the corresponding vehicle terminal, wherein the repair instruction is used to control the vehicle terminal to perform at least one of the following operations: release memory, clear temporary files, and restart the system.

[0131] For example, after the cloud server determines that the fault type of the data in the self-healing list corresponds to a system resource shortage fault, it generates a repair instruction based on the system resource information reported by the vehicle terminal and sends the instruction to the corresponding vehicle terminal through the vehicle network communication link. After receiving the repair instruction, the vehicle terminal can parse the action parameters in it and perform at least one of the following operations according to the action parameters when appropriate: memory release / reclaim, temporary file deletion, or system restart.

[0132] To adapt to different vehicle terminals, this repair command can also generate different control parameters based on the software version and permission configuration of the vehicle terminal. In addition, the vehicle terminal can verify the legality of the command before executing it, and only execute the corresponding action parameters after the verification is successful.

[0133] During this process, the cloud server generates control content for resource repair based on the fault type and sends it to the vehicle terminal, which then performs local resource processing. This allows faults such as insufficient system resources to be handled directly on the vehicle terminal side, reducing manual intervention and enabling timely completion of resource recovery, temporary file cleanup, and system recovery. This improves fault handling efficiency and enhances the stability of the vehicle terminal's operating status.

[0134] In one possible implementation, a fault repair strategy is generated based on the fault type, including: when the fault type is a runtime fault, generating a repair script and sending the repair script to the corresponding vehicle terminal, wherein the repair script is used to repair the faulty process and / or faulty function program in the vehicle terminal, and the faulty process and / or faulty function program is determined by vehicle data; the method further includes: blocking the faulty process and / or faulty function program according to the received repair script.

[0135] For example, if a process keeps crashing or causes a persistent memory overflow, after determining that the fault type is a runtime fault, the cloud server can locate the process or function associated with the fault based on the process identifier, program identifier, abnormal call information and resource usage information recorded in the vehicle data, and generate a repair script that corresponds one-to-one with the object.

[0136] The repair script can be generated using a script format that can be parsed by the vehicle terminal. For example, it can construct a command sequence, control statements and parameter fields based on the vehicle terminal's operating environment, and write the parameter fields into the fault process name, program path, service name or process number so that the vehicle terminal can execute it accurately.

[0137] After receiving the repair script, the vehicle terminal can first verify and parse the script, and then perform blocking processing according to the object identifier specified in the script. This will suspend, terminate, redirect, or make the corresponding process unavailable, or isolate the corresponding functional program from the current running environment to avoid causing larger system problems.

[0138] The repair script can also carry version number, signature information and activation conditions simultaneously, so that the vehicle terminal will only execute when matching the current faulty object. In practical applications, the script format can also be selected from other models, which is not limited in this application.

[0139] Through the above methods, operational faults can be located to specific processes or functional programs via vehicle data. The cloud server then directly sends the corresponding repair script to the in-vehicle terminal for shielding and repair, enabling the in-vehicle terminal to handle abnormal faults without human intervention. Because a correspondence is established between the repair target and vehicle data, the fault handling process incorporates various types of vehicle data to achieve accurate identification and automated, efficient repair of vehicle faults. This ensures that the generated repair scripts remain highly targeted and reduces manual intervention, thereby improving the efficiency and consistency of fault handling in vehicle-cloud diagnostic scenarios.

[0140] In one possible implementation, the method further includes:

[0141] System logs uploaded after obtaining the fault repair strategy for the vehicle terminal;

[0142] Based on the system logs, determine the first fault repair quality of the fault repair strategy, and generate a first quality report based on the first fault repair quality.

[0143] For example, after the vehicle terminal completes the execution of the fault repair strategy, it uploads the system logs collected during the execution and some time after the repair to the cloud server. Upon receiving the system logs, the cloud server first performs timestamp alignment, field parsing, and abnormal segment extraction on the log content. Then, it compares and analyzes the key indicators in the logs against the target items of the fault repair strategy. These key indicators may include whether fault codes are cleared, whether the target process is restored, whether system resources have fallen back to the threshold range, and whether the same abnormality is triggered again. Based on the comparison results, the cloud server then determines the first fault repair quality of the fault repair strategy. If the system logs show that the fault codes have been cleared after the repair and the related abnormalities have not reappeared, the fault repair strategy can be judged to have a high first fault repair quality; if the system logs still show continuous errors or resource abnormalities, the first fault repair quality can be judged to be unqualified.

[0144] When generating the first quality report, the cloud server can write relevant information such as the quality of the first fault repair, the corresponding system log summary, log parsing results, and differences in state before and after the repair into a unified report data structure, and generate a quality report file for operation and maintenance analysis. This quality report file can be output in the form of structured data messages, database records, or visual reports, for subsequent use in tracking the effectiveness of repair strategies, reviewing past events, or rescheduling repair strategies. A correspondence is established between the first quality report and the system logs, allowing the quality evaluation results to be traced back to specific log evidence.

[0145] In this way, the cloud server can objectively evaluate the fault repair effect based on the system logs after the actual execution of the vehicle terminal, and generate a traceable first quality report. This provides clear log evidence and quality records for the repair results, making it easier to analyze and manage the effectiveness of the repair strategy in the future.

[0146] In one possible implementation, a fault repair strategy is generated based on the fault type, including: when the fault type is a system-level fault, generating repair code based on a repair rule base, and generating a test version based on the repair code; sending the test version to a test terminal and obtaining the test version's running logs on the test terminal; when it is determined from the running logs that the test version has repaired the fault corresponding to the vehicle data, adding the repair code to a code repository, where the code is used to generate system software, and the system software is used to update the system of the vehicle terminal.

[0147] For example, when the fault type is determined to be a system-level fault, the cloud server retrieves relevant information such as the repair template, call order, interface parameters, and configuration constraints corresponding to this type of fault from the repair rule base, and generates repair code by combining the fault codes, system logs, and resource status associated with the vehicle data. This repair code can be script code, configuration update code, or patch code, and its content corresponds one-to-one with the triggering conditions, recovery conditions, and verification conditions of the corresponding fault.

[0148] Subsequently, the cloud server builds a test version based on the fix code. The test version can be formed from an image package, container package, or installer package, and includes test cases and regression verification logic to verify the fix's effectiveness. After the test version is sent to the test terminal, the terminal loads and executes it according to various preset business environments, simultaneously collecting startup logs, execution logs, API return information, and resource usage information. This collected runtime log is then sent back to the cloud server. The cloud server then uses this runtime log to determine the effectiveness of the fix measures provided by the test version. If the fix is ​​confirmed to be effective, the fix code is transferred to the official code repository, the corresponding fix strategy is added to the fix rule base, the test version is added to the fix version repository, and a quality report is generated. This is used to assemble the official version for release at an appropriate time, addressing the relevant issues. If the fix is ​​confirmed to be ineffective or new issues arise, the fix rule base is updated as needed, and the fault collection process is restarted to attempt a new fix.

[0149] It should be noted that the cloud server can extract test versions, repair scripts, repair instructions, historical fault context logs, and fault information from the operation logs uploaded by the vehicle terminal as historical data. Using an AI model based on historical data, version targets, fault information from previous versions, and repair measures, combined with the operation log context, it determines whether previously issued repair instructions, repair scripts, or test versions are effective, thereby updating the repair rule base.

[0150] By adopting the above approach, a closed-loop processing link can be formed between repair, verification, and solidification of system-related faults. The repair results can be determined through the test terminal's runtime logs, and the verified code can be transferred to the system software through the code repository, thereby improving the consistency of system-related fault handling and the reliability of subsequent deployments.

[0151] In one possible implementation, the method further includes: determining a second fault repair quality of the test version based on the test version's running logs in the test terminal, and generating a second quality report based on the second fault repair quality.

[0152] For example, after obtaining the runtime logs of the test version during execution on the test terminal, the cloud server parses the startup status, runtime exception information, fault recovery information, and resource usage information in the runtime logs. The parsing results are then matched against preset quality evaluation rules to determine whether the test version is running stably, whether there are still abnormal behaviors related to the target fault, and whether the repair expectations are met. The quality evaluation rules can be composed of fault type, number of exceptions, duration of exceptions, and log alarm level. Based on these rules, the cloud server performs statistical analysis on the runtime logs to obtain the evaluation value or evaluation level of the second fault repair quality.

[0153] When the test version's runtime logs on the test terminal indicate that it can continuously complete the target function without triggering the corresponding fault again, the cloud server judges the second fault repair quality as qualified, meeting the requirements. If the runtime logs still show errors, crashes, retry failures, or abnormal resource usage related to the target fault, the second fault repair quality is judged as unqualified. Subsequently, the cloud server generates a second quality report based on the second fault repair quality. The second quality report includes at least the test version identifier, test terminal identifier, log analysis results, quality evaluation conclusion, and corresponding verification time information. It can also further record log fragments corresponding to failed items for subsequent review and repair iterations.

[0154] By analyzing the runtime logs of the test version running in the test terminal, the quality of the test version's second fault repair for system-related faults can be determined, and a second quality report can be generated accordingly. This allows the test verification results to be output and stored in a unified format, thus providing a traceable evaluation basis for the repair effect before the system software update. At the same time, it provides clear log evidence and quality feedback for subsequent iterative adjustments to the repair code.

[0155] In one possible implementation, fault matching of vehicle data is performed according to a fault rule base, including:

[0156] Extract fault information from vehicle data, match the fault information according to the fault rule base, and calculate the fault credibility corresponding to the fault information.

[0157] When the confidence level of a fault is greater than or equal to the first confidence level threshold, the vehicle data is recorded as fault data.

[0158] For example, after receiving vehicle data uploaded by the vehicle terminal, the cloud server can first parse the text logs, fault codes, operating parameters and status flags, then extract the fault-related content according to the preset field template, and map the extraction results into standardized fault information.

[0159] Subsequently, the cloud server compares the standardized fault information with each rule in the fault rule base. When the fault information meets the key conditions of a certain rule, it records the hit rule, the hit field, and the matching strength, and calculates the fault credibility corresponding to the fault information by combining the weight of each field. When multiple rule items are hit at the same time, the matching results of each rule item can be weighted and summarized to form a unified credibility result.

[0160] If the fault confidence level is greater than or equal to the first confidence level threshold, the vehicle data is marked as fault data and output to the subsequent fault information list for use in self-healing analysis and fault repair strategy generation; if the fault confidence level is lower than the first confidence level threshold, it will not enter the subsequent fault handling link.

[0161] By using the matching method described in this application embodiment, fault information in vehicle data is extracted in a standardized and rule-based manner, so that fault determination no longer depends on a single field or a single report result, but forms a credibility judgment based on the matching strength, and filters the results with a first credibility threshold, thereby making the data entering subsequent processing have higher fault consistency and manageability, and thus supporting the stable execution of subsequent self-repair analysis.

[0162] In one possible implementation, the method further includes: when the fault confidence level is less than a first confidence level threshold and greater than or equal to a second confidence level threshold, marking the vehicle data and generating corresponding manual annotation prompt information, wherein the manual annotation prompt information is used to prompt the operator to manually annotate the marked vehicle data for faults.

[0163] For example, if it cannot be confirmed whether the fault is reliable, that is, the fault reliability is less than the first reliability threshold and greater than or equal to the second reliability threshold, the cloud server writes an identification field to the corresponding vehicle data. The identification field is used to indicate that the vehicle data enters the manual labeling queue in the work order system. The label content may include vehicle identification, data timestamp, fault information summary and fault reliability.

[0164] Simultaneously, the cloud server generates manual annotation prompts and pushes them to annotation terminals, maintenance terminals, or task management interfaces. Operators then determine whether the annotation indicates a fault. The prompts may include the source of the data to be annotated, associated fault codes, recommended abnormal log snippets, and the fault category to be confirmed. Upon receiving the prompts, operators can manually annotate the vehicle data based on the actual fault symptoms, context logs, and historical handling records, and then send the annotation results back to the cloud server.

[0165] It should be noted that regardless of whether the labeling result is a fault, the relevant operators need to label the characteristic information of the vehicle data (such as key logs or driving data context) to supplement the fault rule base.

[0166] After using the above-described method in this application embodiment, vehicle data near the automatic determination boundary is transferred to manual processing, and the manual annotation results can be used as input for subsequent fault rule correction and model training, thereby improving the consistency of fault data confirmation and enhancing the adaptability of diagnostic results to complex vehicle operation scenarios.

[0167] In one possible implementation, the method further includes updating the fault rule base based on the results of manual fault labeling.

[0168] For example, after receiving the manual fault labeling results, the cloud server first associates and stores the manual fault labeling results with the fault codes, system log fragments, and operating status parameters in the corresponding vehicle data. Then, it adjusts the original matching rules according to the fault categories confirmed by the manual labeler. When the manual fault labeling results indicate that there is a stable correspondence between a certain type of fault feature and the target fault, the cloud server writes the feature into a new rule item in the fault rule base, or updates the matching conditions, threshold parameters, and weight coefficients of existing rule items.

[0169] When manual fault labeling results indicate that a certain feature is unrelated to the fault or is a source of false alarms, the cloud server will block, downgrade, or delete the corresponding rule item. The fault rule base can be stored in the form of database tables, rule files, or rule engine configuration items. When updated, the rule version number is incremented synchronously so that the latest rule can be called when matching faults in the future.

[0170] In one example, the cloud server can statistically analyze the frequency, confirmation probability, and false alarm probability of a certain fault feature based on manual fault labeling results, and map the statistical results to a credibility coefficient in the rules, thereby dynamically correcting the fault rule base. The updated fault rule base is then used again for fault matching and fault credibility calculation of vehicle data, enabling subsequent input data to be identified according to the corrected rules.

[0171] It should be noted that the cloud server can use an AI model to determine whether the extracted fault information is a fault based on historical data according to a preset period, and update the fault rule base according to the judgment result. The specific process will not be described in detail.

[0172] The fault rule base can be updated based on the results of manual fault labeling through the above-described method in this application embodiment. This allows the fault rule base to continuously absorb the real fault features and false alarm features after manual review, so that the subsequent matching logic is consistent with the actual operating state of the vehicle. This improves the accuracy of fault identification and the rule adaptation capability, and reduces the impact of repeated misjudgments on subsequent diagnosis and self-repair processing.

[0173] In one possible implementation, the method further includes discarding vehicle data when the fault confidence level is less than a second confidence level threshold.

[0174] For example, when the fault confidence calculated based on the fault matching results is lower than the second confidence threshold, the cloud server determines that the fault characteristics corresponding to the vehicle data are insufficient to support subsequent manual annotation and repair analysis, or can identify the vehicle data as invalid data. Therefore, it no longer writes it into the fault information list, nor generates manual annotation prompts. Instead, it directly performs a cleanup operation from the pending queue. The cleanup operation includes deleting the data record from the cache, message queue, or temporary storage unit, and simultaneously clearing the index information associated with it. This processing method prevents data with low fault confidence from entering the subsequent diagnostic process, reducing unnecessary computation.

[0175] Figure 2 Flowchart of the vehicle fault diagnosis self-repair method provided in this application Figure 2 ,like Figure 2 As shown, in this embodiment... Figure 1 Based on the embodiments, the self-repair method for vehicle fault diagnosis is further described, which includes:

[0176] S201: In response to the vehicle data uploaded by the vehicle terminal, perform fault matching on the vehicle data according to the fault rule base; wherein, the vehicle data includes at least one of the following: basic vehicle information, vehicle operation data, fault codes, system resource information, and system logs.

[0177] S202: When the vehicle data is fault data, add the vehicle data to the fault information list.

[0178] S203: Based on the self-healing rules, perform self-healing analysis on the data in the fault information list. When the data in the fault information list meets the self-healing rules, add the vehicle data to the self-healing list.

[0179] S204: Determine the fault type of the vehicle data in the self-healing list, and generate a fault repair strategy based on the fault type, wherein the fault repair strategy is used to repair the fault corresponding to the vehicle data.

[0180] S205: When the data in the fault information list does not conform to the self-healing rules, the vehicle data is marked and a corresponding manual repair prompt is generated. The manual repair prompt is used to prompt the operator to manually repair the marked vehicle data.

[0181] For example, the cloud server first performs a self-healing condition judgment on the data entering the fault information list. When the fault type, context environment or repair constraints corresponding to the data do not meet the automatic repair rules, the cloud server will no longer issue the automatic repair strategy. Instead, it will mark the vehicle data and transfer it to the manual work order system, generate a manual repair prompt message bound to the data, and send the prompt message to the operator so that the operator can intervene.

[0182] Operators can manually analyze, remotely confirm, or handle on-site vehicle data based on the prompts. For hardware faults, the faulty parts are replaced; for software faults, repair code is created manually, submitted to the code repository to form a test version, and then tested using a test terminal.

[0183] By adopting the above-described method in this application embodiment, the cloud server can promptly transfer fault data that is not suitable for automatic processing to the manual repair channel, and maintain the correspondence between data tags and prompt information, making the objects of manual intervention clearly traceable, thereby improving the efficiency of fault handling and the accuracy of repair results.

[0184] In one possible implementation, the method further includes:

[0185] Generate a manual test version from the manual programming code corresponding to the manual fault repair, and send the manual test version to the test terminal;

[0186] Obtain the test logs of the manually tested version in the test terminal;

[0187] Based on the test logs, determine the third fault repair quality of the manually tested version, and generate a third quality report based on the third fault repair quality.

[0188] For example, after receiving manually programmed code corresponding to manual fault repair, the cloud server can first perform syntax validation, dependency checks, and build environment matching on the code. Then, it calls a compiler or interpreter to convert the manually programmed code into a manually tested version that can be executed in the test environment. This manually tested version can be an executable file, a script package, or a containerized test image, and is associated with the corresponding fault identifier through a version number.

[0189] After the build is completed, the cloud server will distribute the manual test version to the test terminal that matches the target vehicle model and target software environment. The test terminal can be a bench test equipment, a simulation test node, or an in-vehicle software and hardware debugging terminal. The test terminal runs the manual test version under preset working conditions and collects program output, resource usage, abnormal interruption and fault recovery status during the operation, forming test logs and uploading them to the cloud server.

[0190] After obtaining the test logs, the cloud server parses the test log content, extracts the judgment items related to fault repair, and calculates the third fault repair quality according to the preset quality evaluation rules. The quality evaluation rules may include whether the fault has been eliminated, whether the anomaly has been reproduced, whether the key interface has been restored, whether the operation is stable, and whether new alarm information has been generated.

[0191] The cloud server can quantify and score the quality of the third fault repair based on the weight of each judgment item, or directly output the evaluation results according to levels such as qualified, unqualified, and pending review. Subsequently, the cloud server associates and stores the quality of the third fault repair with the manual programming code identifier, test terminal identifier, test time, test log summary, and fault association information to generate a third quality report. The third quality report can be output in the form of a text report, structured record, or electronically signed document.

[0192] By using the above-described method in this application embodiment, the code corresponding to manual repair is constructed into a manual test version and verified in the test terminal. Then, a third fault repair quality and a third quality report are generated based on the test log, so that the effect of manual repair can be uniformly recorded and quantitatively evaluated, thereby achieving closed-loop confirmation of the manual repair results and providing a basis for subsequent fault tracking, manual review and rule optimization.

[0193] Figure 3 Schematic diagram of the vehicle fault diagnosis self-repair device provided in this application Figure 1 ,like Figure 3 As shown, the device 30 includes:

[0194] The matching module 301 is used to respond to the vehicle data uploaded by the vehicle terminal and perform fault matching on the vehicle data according to the fault rule base; wherein, the vehicle data includes at least one of the following: basic vehicle information, vehicle body operation data, fault codes, system resource information, and system logs;

[0195] The addition module 302 is used to add vehicle data to the fault information list when the vehicle data is fault data; the addition module 302 is also used to perform self-healing analysis on the data in the fault information list according to the self-healing rules, and add the vehicle data to the self-healing list when the data in the fault information list meets the self-healing rules.

[0196] The generation module 303 is used to determine the fault type of the vehicle data in the self-healing list, and generate a fault repair strategy based on the fault type. The fault repair strategy is used to repair the fault corresponding to the vehicle data.

[0197] The vehicle fault diagnosis self-repair device 30 provided in this embodiment can execute the method provided in the above-described method embodiment. Through the matching module 301, it performs fault matching on multi-source vehicle data continuously uploaded by the vehicle terminal, initially identifying the vehicle's operating status and effectively distinguishing abnormal data from normal data. Then, the adding module 302 collects the fault data into a fault information list and further analyzes it according to self-healing rules. It can filter out suitable faults for automatic processing from the identified faults, thus distinguishing between occasional false alarms and self-healable faults. The generation module 303 determines the fault type for the vehicle data in the self-healing list and generates corresponding fault repair strategies, thereby achieving automatic connection between diagnostic results and repair procedures. Therefore, it can improve the accuracy of fault identification and the efficiency of repair processing, shorten the processing cycle, and enhance the ability to ensure vehicle operational stability in the context of the Internet of Vehicles.

[0198] Figure 4 Schematic diagram of the vehicle fault diagnosis self-repair device provided in this application Figure 2 ,like Figure 4 As shown, in this embodiment... Figure 3 Based on the embodiments, the vehicle fault diagnosis self-repair device is described in detail. The device 40 includes:

[0199] The matching module 401 is used to respond to the vehicle data uploaded by the vehicle terminal and perform fault matching on the vehicle data according to the fault rule base; wherein, the vehicle data includes at least one of the following: basic vehicle information, vehicle body operation data, fault codes, system resource information, and system logs;

[0200] The addition module 402 is used to add vehicle data to the fault information list when the vehicle data is fault data; the addition module 402 is also used to perform self-healing analysis on the data in the fault information list according to the self-healing rules, and add the vehicle data to the self-healing list when the data in the fault information list meets the self-healing rules.

[0201] The generation module 403 is used to determine the fault type of the vehicle data in the self-healing list, and generate a fault repair strategy based on the fault type, wherein the fault repair strategy is used to repair the fault corresponding to the vehicle data.

[0202] In one possible implementation, when the generation module 403 generates a fault repair strategy based on the fault type, it is specifically used to: generate a repair instruction when the fault type is a system resource shortage fault, and send the repair instruction to the corresponding vehicle terminal, wherein the repair instruction is used to control the vehicle terminal to perform at least one of the following operations: release memory, clean up temporary files, and restart the system.

[0203] In one possible implementation, when the generation module 403 generates a fault repair strategy according to the fault type, it is specifically used to: when the fault type is a running fault, generate a repair script and send the repair script to the corresponding vehicle terminal, wherein the repair script is used to repair the fault process and / or fault function program in the vehicle terminal, and the fault process and / or fault function program is determined by vehicle data.

[0204] The device 40 also includes a shielding module 404, used to shield faulty processes and / or faulty function programs according to the received repair script.

[0205] In one possible implementation, the device 40 further includes:

[0206] Module 405 is used to acquire system logs uploaded after the vehicle terminal implements the fault repair strategy;

[0207] The generation module 403 is also used to determine the first fault repair quality of the fault repair strategy based on the system log, and generate a first quality report based on the first fault repair quality.

[0208] In one possible implementation, when generating a fault repair strategy based on the fault type, the generation module 403 is specifically used for:

[0209] When the fault type is a system-level fault, a repair code is generated based on the repair rule base, and a test version is generated based on the repair code;

[0210] Send the test version to the test terminal and obtain the test version's running logs on the test terminal;

[0211] When the test version has fixed the faults corresponding to the vehicle data based on the operation log, the fix code is added to the code repository. The code in the code repository is used to generate system software, and the system software is used to update the system of the vehicle terminal.

[0212] In one possible implementation, the generation module 403 is further configured to: determine the second fault repair quality of the test version based on the running log of the test version in the test terminal, and generate a second quality report based on the second fault repair quality.

[0213] In one possible implementation, the matching module 401 specifically includes:

[0214] The calculation submodule 4011 is used to extract fault information contained in vehicle data, match the fault information according to the fault rule library, and calculate the fault credibility corresponding to the fault information.

[0215] The comparison submodule 4012 is used to record vehicle data as fault data when the fault confidence level is greater than or equal to the first confidence level threshold.

[0216] In one possible implementation, the comparison submodule 4012 is further configured to: mark the vehicle data and generate corresponding manual annotation prompt information when the fault confidence level is less than a first confidence level threshold and greater than or equal to a second confidence level threshold, wherein the manual annotation prompt information is used to prompt the operator to manually annotate the marked vehicle data.

[0217] In one possible implementation, the device 40 further includes an update module 406, used to update the fault rule base based on the results of manual fault labeling.

[0218] In one possible implementation, the comparison submodule 4012 is further configured to discard vehicle data when the fault confidence level is less than a second confidence level threshold.

[0219] In one possible implementation, the device 40 further includes a marking module 407, which marks the vehicle data when the data in the fault information list does not conform to the self-healing rules, and generates corresponding manual repair prompt information, wherein the manual repair prompt information is used to prompt the operator to manually repair the marked vehicle data.

[0220] In one possible implementation, the generation module 403 is further configured to: generate a manual test version from the manual programming code corresponding to the manual fault repair, and send the manual test version to the test terminal;

[0221] Module 405 is also used to: obtain test logs of the manually tested version in the test terminal;

[0222] The generation module 403 is also used to: determine the third fault repair quality of the manually tested version based on the test logs, and generate a third quality report based on the third fault repair quality.

[0223] The vehicle fault diagnosis self-repair device 40 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.

[0224] Figure 5 A schematic diagram of the structure of the electronic device provided in this application. Figure 5 As shown, the electronic device 50 provided in this embodiment includes at least one processor 501 and a memory 502. Optionally, the electronic device 50 further includes a communication component 503. The processor 501, memory 502, and communication component 503 are connected via a bus 504.

[0225] In the specific implementation process, at least one processor 501 executes computer execution instructions stored in memory 502, causing at least one processor 501 to execute the above-described vehicle fault diagnosis self-repair method. For the specific implementation process, please refer to the above method embodiment.

[0226] In this embodiment, the electronic device 50 can be deployed on a cloud server. The memory is used to store the program instructions, fault rule base, self-healing rules and repair strategy data corresponding to the vehicle fault diagnosis self-repair method. After the processor calls and executes the instructions, it can perform fault matching, self-healing analysis, fault type determination and repair strategy generation on the vehicle basic information, vehicle body operation data, fault codes, system resource information and system logs uploaded by the vehicle terminal. This connects fault identification, self-healing screening and repair handling into a continuous processing process, enabling the electronic device to automatically complete diagnosis and self-repair decisions in a large number of online vehicle scenarios, thereby improving the accuracy of fault identification and processing efficiency. Therefore, it helps to reduce the pressure of manual review, shorten the fault response cycle and improve the stability of vehicle operation.

[0227] 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.

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

[0229] 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.

[0230] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described vehicle fault diagnosis and self-repair method.

[0231] In this embodiment, the computer program product can be stored on a cloud server, cloud platform node, or a readable medium on a diagnostic terminal. Upon processor invocation, it executes processes such as vehicle data reception, fault rule matching, fault information list construction, self-healing rule analysis, self-healing list filtering, fault type determination, and fault repair strategy generation, thereby solidifying the vehicle fault diagnosis and self-repair logic in a programmatic manner. Through program execution, multi-source data continuously uploaded by the vehicle terminal can be uniformly analyzed, enabling fault identification to move beyond manual review. This allows for further filtering of matched faults suitable for automatic processing and the output of targeted repair strategies, thus improving the automation level, fault identification accuracy, and repair efficiency in vehicle-to-the-world diagnostic scenarios.

[0232] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the aforementioned vehicle fault diagnosis and self-repair method.

[0233] In this embodiment, by pre-storing the computer-executable instructions for implementing the vehicle fault diagnosis self-repair method in a computer-readable storage medium, the processor can directly call and execute the corresponding process on the vehicle cloud diagnostic platform, server, or related devices. This enables processing such as vehicle data reception, fault rule matching, fault information list construction, self-healing rule analysis, self-healing list generation, fault type determination, and fault repair strategy generation. This allows the method to be stably deployed and repeatedly run in the form of software instructions, thereby improving the convenience and consistency of system implementation. Therefore, in large-scale vehicle network operation and maintenance scenarios, it can balance fault identification accuracy, self-repair processing efficiency, and result reliability.

[0234] 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.

[0235] 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.

[0236] 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.

[0237] 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.

[0238] 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.

[0239] 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.

[0240] 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.

[0241] The above embodiments are merely preferred embodiments provided to fully illustrate the present invention, and the scope of protection of the present invention is not limited thereto. Equivalent substitutions or modifications made by those skilled in the art based on the present invention are all within the scope of protection of the present invention.

Claims

1. A vehicle failure diagnosis self-repairing method characterized by, The method includes: In response to the vehicle data uploaded by the vehicle terminal, fault matching is performed on the vehicle data according to the fault rule base; wherein, the vehicle data includes at least one of the following: basic vehicle information, vehicle operation data, fault codes, system resource information, and system logs; When the vehicle data is fault data, the vehicle data is added to the fault information list; According to the self-healing rules, the data in the fault information list is subjected to self-healing analysis. When the data in the fault information list meets the self-healing rules, the vehicle data is added to the self-healing list. The fault types of vehicle data in the self-healing list are determined, and a fault repair strategy is generated based on the fault types, wherein the fault repair strategy is used to repair the faults corresponding to the vehicle data.

2. The method according to claim 1, characterized in that, The step of generating a fault repair strategy based on the fault type includes: When the fault type is a system resource shortage fault, a repair instruction is generated and sent to the corresponding vehicle terminal. The repair instruction is used to control the vehicle terminal to perform at least one of the following operations: release memory, clear temporary files, and restart the system.

3. The method according to claim 1, characterized in that, The step of generating a fault repair strategy based on the fault type includes: When the fault type is a running fault, a repair script is generated and the repair script is sent to the corresponding vehicle terminal. The repair script is used to repair the fault process and / or fault function program in the vehicle terminal. The fault process and / or the fault function program is determined by the vehicle data. The method further includes: Based on the received repair script, the faulty process and / or the faulty function program are disabled.

4. The method according to claim 2 or 3, characterized in that, The method further includes: Obtain the system log uploaded by the vehicle terminal after running the fault repair strategy; Based on the system logs, determine the first fault repair quality of the fault repair strategy, and generate a first quality report based on the first fault repair quality.

5. The method according to claim 1, characterized in that, The step of generating a fault repair strategy based on the fault type includes: When the fault type is a system-level fault, a repair code is generated based on the repair rule base, and a test version is generated based on the repair code. Send the test version to the test terminal and obtain the running log of the test version on the test terminal; When it is determined from the operation log that the test version has fixed the fault corresponding to the vehicle data, the fix code is added to the code repository. The code in the code repository is used to generate system software, and the system software is used to update the system of the vehicle terminal.

6. The method according to claim 5, characterized in that, The method further includes: Based on the running logs of the test version in the test terminal, determine the second fault repair quality of the test version, and generate a second quality report based on the second fault repair quality.

7. The method according to claim 1, characterized in that, The fault matching of the vehicle data according to the fault rule base includes: Extract the fault information contained in the vehicle data, match the fault information according to the fault rule base, and calculate the fault credibility corresponding to the fault information; When the confidence level of the fault is greater than or equal to the first confidence level threshold, the vehicle data is recorded as the fault data.

8. The method according to claim 7, characterized in that, The method further includes: When the confidence level of the fault is less than the first confidence level threshold and greater than or equal to the second confidence level threshold, the vehicle data is marked and a corresponding manual annotation prompt is generated. The manual annotation prompt is used to prompt the operator to manually annotate the marked vehicle data.

9. The method according to claim 8, characterized in that, The method further includes: The fault rule base is updated based on the results of manual fault labeling.

10. The method according to claim 8, characterized in that, The method further includes: When the fault confidence level is less than the second confidence level threshold, the vehicle data is discarded.

11. The method according to claim 1, characterized in that, The method further includes: When the data in the fault information list does not conform to the self-healing rule, the vehicle data is marked and a corresponding manual repair prompt is generated. The manual repair prompt is used to prompt the operator to manually repair the marked vehicle data.

12. The method according to claim 11, characterized in that, The method further includes: Generate a manual test version from the manual programming code corresponding to the manual fault repair, and send the manual test version to the test terminal; Obtain the test logs of the manually tested version on the test terminal; Based on the test logs, the third fault repair quality of the manually tested version is determined, and a third quality report is generated based on the third fault repair quality.

13. A vehicle fault diagnosis and self-repair device, characterized in that, The device includes: The matching module is used to respond to the vehicle data uploaded by the vehicle terminal and perform fault matching on the vehicle data according to the fault rule base; wherein the vehicle data includes at least one of the following: basic vehicle information, vehicle operation data, fault codes, system resource information, and system logs. An add module is used to add the vehicle data to the fault information list when the vehicle data is fault data; The adding module is also used to perform self-healing analysis on the data in the fault information list according to the self-healing rules, and when the data in the fault information list meets the self-healing rules, add the vehicle data to the self-healing list. A generation module is used to determine the fault type of vehicle data in the self-healing list, and generate a fault repair strategy based on the fault type, wherein the fault repair strategy is used to repair the fault corresponding to the vehicle data.

14. 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-12.

15. 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-12.

16. 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-12.

Images