Vehicle fault recovery method, electronic equipment and medium

Abstract

The invention relates to the field of vehicle diagnosis, in particular to a vehicle fault recovery method, electronic equipment and a medium. The vehicle fault recovery method comprises the following steps: acquiring first data; the first data comprises ECU parameter real-time values and second data; the second data comprises at least one of an ECU parameter preset safety threshold value, an ECU normal operation model and historical fault data; when it is determined that a fault exists according to the first data, a fault recovery strategy is controlled to be executed according to the fault type and the fault reason; and under the condition that it is determined that no fault exists according to the first data, the fault occurrence possibility is determined according to the ECU parameter real-time value and a fault prediction model. According to the method, the robustness can be improved, the adaptability and the recovery capability are enhanced, and the vehicle can still run safely and reliably in a complex environment.

Description

Technical Field

[0001] The present application relates to the field of vehicle diagnosis, and in particular to a vehicle fault recovery method, electronic equipment and medium. Background Art

[0002] With the rapid development of automotive electronic technology, the electronic control units (ECUs) of modern vehicles are taking on increasingly complex tasks. Fault diagnosis, as one of the core functions of the ECU, can monitor the status of the vehicle's electronic control system, detect faults, and perform corresponding diagnostic services to ensure vehicle safety and performance reliability. However, with the increasing complexity of vehicle electronic control systems, fault diagnosis faces many challenges during execution. For example, problems such as ECU configuration errors, hardware failures, and communication failures may cause the failure of fault diagnosis execution, thereby affecting the normal operation of the vehicle. When encountering such problems, traditional diagnostic modules usually simply return error information or stop the diagnostic process, resulting in a decrease in the robustness of the vehicle's electronic control system and even serious safety hazards.

[0003] In view of this, this application is hereby filed. Summary of the invention

[0004] The purpose of the present application is to provide a vehicle fault recovery method, electronic device and medium to solve the problem in the prior art that the robustness of the vehicle electronic control system is reduced and safety hazards occur due to simply returning error information or stopping the diagnostic process.

[0005] In order to achieve the above objectives, this application adopts the following technical solutions: In a first aspect, the present application provides a vehicle fault recovery method, comprising: Acquire first data; the first data includes a real-time value of an ECU parameter and second data; the second data includes at least one of a preset safety threshold of an ECU parameter, a normal operating model of the ECU, and historical fault data; In the case where it is determined according to the first data that a fault exists, controlling execution of a fault recovery strategy according to the type of fault and the cause of the fault; When it is determined that no fault exists according to the first data, it is determined that there is a possibility of a fault occurring according to the real-time value of the ECU parameter and the fault prediction model.

[0006] As a further preferred technical solution, the fault recovery strategy includes fault recovery means and execution priorities, and the fault recovery means include at least two of reloading, reconfiguration, selecting an alternate path, service degradation or restarting; the execution priorities of the reloading, the reconfiguration, the selection of an alternate path, the service degradation and the restarting are decreased in sequence.

[0007] As a further preferred technical solution, the possibility of failure includes at least one of the probability, frequency, type and impact range of the failure.

[0008] As a further preferred technical solution, the ECU normal operation model is determined according to the parameter values ​​and ECU usage scenarios under the normal operation state of the ECU; The fault prediction model is determined according to historical fault data.

[0009] As a further preferred technical solution, when it is determined that there is an ECU configuration abnormality, sensor abnormality, ECU load abnormality or communication abnormality based on the real-time values ​​of the ECU parameters and the preset safety thresholds of the ECU parameters, it is determined whether there is a fault based on the real-time values ​​of the ECU parameters, the normal operation model of the ECU and the historical fault data.

[0010] As a further preferred technical solution, the controlling and executing of the fault recovery strategy according to the fault type and fault cause includes: Obtaining a mapping relationship between a fault type, a fault cause, and a fault recovery strategy; the fault type includes at least one of an ECU configuration fault, a diagnostic service fault, a hardware fault, or an operating environment fault; According to the fault type, fault cause and the mapping relationship, the execution of the fault recovery strategy is controlled.

[0011] As a further preferred technical solution, the reloading includes at least one of reloading parameters, reloading dependent components, reloading drivers, or reloading communication protocols; The reconfiguration includes: determining configuration error parameters according to the fault type and the fault cause; updating configuration parameters according to the configuration error parameters, the current ECU usage scenario and the preset configuration template; The selecting of the backup path includes at least one of selecting a backup component, selecting backup component data, selecting a backup algorithm, or adjusting a diagnostic service process; The service degradation includes: simplifying the diagnostic service process according to the fault type; and gradually restoring to the original diagnostic service process when the fault is resolved; The restarting includes restarting after saving data when it is determined that the fault is real.

[0012] As a further preferred technical solution, after determining the possibility of a fault according to the real-time value of the ECU parameter and the fault prediction model, the method further includes: In the case where the possibility of a failure exceeding a preset threshold, the control performs at least one of reconfiguration, selection of an alternate path, service degradation, or issuing an inspection prompt.

[0013] As a further preferred technical solution, after determining that there is a possibility of a fault occurring, the method further includes: Record fault log information and pre-fault log information; According to the fault log information and the pre-fault log information, the preset safety threshold of the ECU parameters, the normal operation model of the ECU, the fault prediction model or the fault recovery strategy is optimized.

[0014] In a second aspect, the present application provides an electronic device, including: at least one processor, and a memory communicatively coupled to at least one of the processors; The memory stores instructions that can be executed by at least one of the processors, and the instructions are executed by at least one of the processors so that at least one of the processors can perform the above method.

[0015] In a third aspect, the present application provides a computer-readable storage medium, on which computer instructions are stored, and the computer instructions are used to enable a computer to execute the above method.

[0016] Compared with the prior art, the beneficial effects of this application are: The vehicle fault recovery method provided by the present application controls the execution of the fault recovery strategy according to the fault type and fault cause when it is determined that there is a fault according to the specific first data; when it is determined that there is no fault according to the first data, the possibility of a fault is determined according to the real-time value of the ECU parameter and the fault prediction model. The method can accurately detect whether a fault has occurred, and adaptively handle the fault when it occurs, thereby significantly reducing downtime, reducing the complexity and error risk of human operation, and improving the overall stability and reliability of the vehicle electronic control system. At the same time, it also combines the real-time value of the ECU parameter and the fault prediction model to predict the possibility of a fault, so that preventive measures can be taken in time before the fault occurs, reduce the probability of the fault, reduce safety risks and extend the service life. The present application can improve robustness, enhance adaptability and recovery capabilities, and ensure that the vehicle can still operate safely and reliably in a complex environment.

[0017] Furthermore, the present application handles faults according to specific priorities and specific fault recovery methods, thereby optimizing resource utilization, minimizing the impact of faults on system performance, improving resource utilization, and ensuring that the system can still operate efficiently under fault conditions.

[0018] Furthermore, the present application records fault log information and pre-fault log information, and optimizes the ECU parameter preset safety threshold, ECU normal operation model, fault prediction model or fault recovery strategy based on the fault log information and pre-fault log information, thereby continuously improving the reliability of fault detection, pre-fault detection and fault repair in the present application. Engineers can make adaptive improvements to the system based on these log information. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] In order to more clearly illustrate the specific implementation methods of the present application or the technical solutions in the prior art, the drawings required for use in the specific implementation methods or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are some implementation methods of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0020] Figure 1 It is a flow chart of the vehicle fault recovery method provided by the present application; Figure 2 It is a structural schematic diagram of the vehicle fault recovery system provided by the present application; Figure 3 It is a structural schematic diagram of the electronic device provided by this application. DETAILED DESCRIPTION

[0021] The following is a description of exemplary embodiments of the present application in conjunction with the accompanying drawings, including various details of the embodiments of the present application to facilitate understanding, which should be considered as merely exemplary. Therefore, it should be recognized by those of ordinary skill in the art that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of the present application. Similarly, for the sake of clarity and conciseness, the description of well-known functions and structures is omitted in the following description.

[0022] Example 1 Figure 1 It is a flow chart of a vehicle fault recovery method provided in this embodiment. The method can be executed by a vehicle fault recovery device. The device can be composed of software and / or hardware and is generally integrated in an electronic device. The electronic device can be a vehicle controller or a body control unit. For ease of understanding, each step in the method of this embodiment takes the vehicle controller as the execution body.

[0023] like Figure 1 As shown, this embodiment provides a vehicle fault recovery method, comprising the following steps: S110, obtaining first data; the first data includes real-time values ​​of ECU parameters and second data; the second data includes at least one of preset safety thresholds of ECU parameters, normal operation models of ECU, and historical fault data.

[0024] Among them, "ECU parameter real-time value" refers to the real-time value of ECU parameters, including but not limited to ECU configuration parameters (such as diagnostic timeout configuration, function enable / disable parameters, module reset threshold), related component parameters (such as voltage, temperature), ECU load (such as ECU usage rate, communication load, sensor load), communication status parameters (such as packet loss rate, bus occupancy rate, signal delay time), etc., and related components such as sensors. Different ECU parameter real-time values ​​are not collected at the same time, but different collection frequencies are set according to the change characteristics of these parameters: for parameters that change slowly, such as temperature, the collection frequency can be appropriately reduced, while for parameters that fluctuate rapidly, such as voltage and current, the collection frequency needs to be increased accordingly to ensure that any potential anomalies can be detected at the first time. Data collection not only relies on sensors directly integrated into the ECU and diagnostic module, but also exchanges data with the ECU through a dedicated communication interface through an external acquisition module, ensuring that the collected data fully covers all key parts of the system, and through careful tracking of the fluctuation range and change speed of these parameters, ensuring that potential anomalies can be captured in time to support the subsequent diagnostic analysis and decision-making process of the fault detection module, thereby improving the reliability and safety of the system.

[0025] "ECU parameter preset safety threshold" refers to the threshold of ECU parameters set in advance in the vehicle fault recovery device to ensure that no fault will occur. "ECU normal operation model" refers to the model used to characterize the normal operation of the ECU. "Historical fault data" refers to the ECU parameter data at the time of and before the occurrence of a fault in the past. The correlation between the occurrence of a fault and the ECU parameters can be analyzed from the historical fault data.

[0026] The first data in this embodiment is more important. Based on the first data, whether there is a fault can be quickly detected. Real-time monitoring can be achieved based on the real-time value of the ECU parameter and the preset safety threshold of the ECU parameter, and abnormalities can be discovered in time. The accuracy and sensitivity of fault detection can be further improved based on the normal operation model of the ECU and historical fault data.

[0027] In an optional implementation, the following method is used to detect whether a fault exists: According to the real-time values ​​of ECU parameters and the preset safety thresholds of ECU parameters, detect whether there are abnormal ECU configuration, sensor abnormality, ECU load abnormality or communication abnormality; In the case of ECU configuration abnormality, sensor abnormality, ECU load abnormality or communication abnormality, it is detected whether there is a fault based on the real-time value of the ECU parameter, the normal operation model of the ECU and the historical fault data.

[0028] “ECU normal operation model” refers to a model that can characterize the normal operation of the ECU.

[0029] This optional implementation first detects whether there is an ECU configuration anomaly, sensor anomaly, ECU load anomaly or communication anomaly based on the real-time value of the ECU parameter and the preset safety threshold of the ECU parameter. Once the real-time value of a parameter is detected to be higher than the preset safety threshold, it is determined that an abnormal situation has occurred. The specific type of abnormality is determined based on the abnormal parameters. For example, if the temperature value of the temperature sensor is detected to exceed its safety threshold, it is determined to be a temperature sensor abnormality. For example, if one of the communication status parameters is detected to exceed its safety threshold, it is determined to be a communication abnormality. At the same time, these thresholds can be single values ​​or composite thresholds based on multiple variables. For example, the voltage threshold may be a fixed value, while the temperature threshold may be dynamically adjusted according to different operating states. Then, in the case of ECU configuration abnormality, sensor abnormality, ECU load abnormality or communication abnormality, detect whether there is a fault based on the real-time value of the ECU parameter, the normal operation model of the ECU and the historical fault data. The existence of the above abnormalities does not necessarily mean that a fault has occurred. It is necessary to further analyze the real-time value of the ECU parameter, the normal operation model of the ECU and the historical fault data. For example, when the above temperature sensor is abnormal, after analysis, the actual operating state of the ECU is significantly deviated from the normal operating state, and it is identified from the historical fault data that a fault has occurred at this temperature, then it is determined that a temperature sensor hardware fault has occurred. From the above content, it can be seen that this implementation method can actually not only detect whether there is a fault, but also detect the type of fault and the cause of the fault.

[0030] In the case of ECU configuration anomalies, sensor anomalies, ECU load anomalies, or communication anomalies, the actual operating state of the current system will be compared with the normal operating model of the ECU in real time. When the actual operating state of the system deviates significantly from the normal operating model of the ECU, this fault will be identified and the corresponding recovery process will be initiated. For example, if the power consumption of the ECU increases abnormally over a period of time and does not conform to the normal operating model of the ECU, the system may identify it as a potential hardware fault or configuration error, thereby triggering a fault recovery mechanism. In addition, after identifying the abnormal actual operating state, it will be classified and corresponding recovery measures will be taken according to different abnormality types. For example, communication anomalies may require reconfiguration of network parameters, while hardware anomalies may require the startup of redundant devices or backup paths. This classification process helps to improve the efficiency and accuracy of fault recovery.

[0031] In an optional implementation, the ECU normal operation model is determined according to parameter values ​​and ECU usage scenarios under the normal operation state of the ECU; The fault prediction model is determined according to historical fault data.

[0032] Among them, "parameter value of ECU under normal operating state" refers to the value of ECU parameter under normal operating state of ECU, and "ECU usage scenario" refers to the usage scenario of ECU, and the usage scenario includes but is not limited to high temperature usage scenario, normal temperature usage scenario, low temperature usage scenario, urban usage scenario, rural usage scenario, highway usage scenario, etc. The parameter values ​​of ECU under normal operating state are different in different usage scenarios. Therefore, the ECU normal operating model constructed by combining the parameter values ​​of ECU under normal operating state and ECU usage scenario in this embodiment can reflect the normal operating state of ECU under different usage scenarios. The ECU normal operating model includes but is not limited to the voltage, temperature, configuration parameters, communication status and other key performance indicators of ECU. The ECU normal operating model is a dynamic concept, which will be continuously updated as the use of the system and environmental conditions change to ensure the accuracy and applicability of the model. The fault prediction model constructed by historical fault data can be used to detect whether there is a pre-fault so that preventive measures can be taken in advance.

[0033] It should be noted that the present embodiment does not impose any particular restriction on the order of constructing the ECU normal operation model and constructing the fault prediction model. They can be performed sequentially or simultaneously as long as the corresponding model can be constructed.

[0034] In an optional implementation, the fault prediction model is constructed in the following manner: Determine the prediction data based on historical fault data and the model to be trained; The model to be trained is updated to reduce the loss between the predicted data and the historical fault data, and a fault prediction model is obtained, wherein the fault prediction model is used to predict the fault type, fault cause and fault occurrence rate according to the real-time value of the ECU parameter.

[0035] The "model to be trained" refers to the initial model used to predict faults, which can be a least squares training linear regression model or a support vector machine model. This implementation is based on historical fault data and the model to be trained, and obtains a fault prediction model by reducing the loss between the predicted data and the historical fault data, which can improve the model prediction accuracy. The essence of this model is to predict possible faults under specific conditions by learning the fault occurrence rules in the historical fault data.

[0036] This application will continuously collect various data during the operation of the system, including normal operation data and failure data. Through statistical analysis of these data, the system can identify common failure modes and their precursors. For example, by analyzing past failure events, the system may find that certain sensors are prone to failure when the temperature changes sharply, so that parameter adjustments or activation of backup sensors can be made in advance in similar situations in the future.

[0037] In the process of establishing the fault prediction model, the historical fault data is converted into a feature and label format acceptable to the model through a preprocessing step. Then, the linear regression model is trained using the least squares method to capture the relationship between load and faults. During the training process, the model minimizes the prediction error by continuously adjusting the weights, and finally generates a model that can predict the probability of fault occurrence. After the model training is completed, the probability value of the fault occurrence is calculated and predicted based on the workload of the current system. If the prediction result exceeds the set risk threshold, the system will generate an early warning signal to prompt the user to perform preventive maintenance. This process combines historical data analysis with real-time prediction. The model predicts possible failures of the system under specific conditions by learning the fault occurrence rules in historical data. For example, if a device often fails under a specific workload, the system can predict that the device may have problems again when the load increases next time, and perform preventive maintenance in advance.

[0038] Optionally, before determining the prediction data based on the historical fault data and the model to be trained, a step of preprocessing the historical fault data is also included, and the preprocessing includes converting the historical fault data into a feature and label format acceptable to the model to be trained.

[0039] Optionally, after detecting whether there is a fault, a step of generating a fault report may be included, and the fault report may include the fault type, fault cause, fault occurrence time, fault impact range, etc. The fault report may be recorded in the form of a log.

[0040] S120: When it is determined according to the first data that a fault exists, control execution of a fault recovery strategy according to the fault type and fault cause.

[0041] Optionally, the fault recovery strategy includes fault recovery means and execution priorities, and the fault recovery means include at least two of reloading, reconfiguration, selecting an alternate path, service degradation or restarting; the execution priorities of the reloading, the reconfiguration, the selection of an alternate path, the service degradation and the restarting decrease in sequence.

[0042] This step executes the corresponding fault recovery strategy based on the fault type and fault cause, and the fault recovery strategy includes fault recovery means and execution priority. From the overall point of view, the execution priority of reloading, reconfiguration, selecting an alternative path, service degradation and restarting is reduced in sequence, so that the system resources can be maximized and the operating efficiency in the case of a fault can be improved. For a specific fault type and a specific fault cause, the selected fault recovery means are also different. The above-mentioned "execution priority" means that when a fault occurs, a means with a higher priority among the fault repair means is selected to repair it. If it can be repaired, the repair is stopped. If it cannot be repaired, the means with a lower priority are continued to be executed to repair it. For example, the fault repair means corresponding to a certain fault are reconfiguration, service degradation and restart. Then, in the actual repair, reconfigure first. If reconfiguration can repair the fault, the reconfigured system continues to run. If reconfiguration cannot repair the fault, service degradation is performed. If service degradation can repair the fault, the service degradation system continues to run. If service degradation cannot repair the fault, restart is performed.

[0043] In an optional implementation, controlling the execution of a fault recovery strategy according to the fault type and the fault cause includes: According to the fault type and fault cause, query the preset fault recovery database to control the execution of the fault recovery strategy; the preset fault recovery database includes the mapping relationship between the fault type, the fault cause and the fault recovery strategy; The fault type includes at least one of an ECU configuration fault, a diagnostic service fault, a hardware fault or an operating environment fault.

[0044] This embodiment can quickly query the fault recovery strategy corresponding to the fault type and fault cause by querying the preset fault recovery database. The preset fault recovery database can be stored in the vehicle fault recovery device, and the database can be obtained based on historical fault recovery data. Table 1 is an example of a preset fault recovery database. In addition to the fault causes listed in Table 1, there may be more fault causes, which will not be listed one by one in this article.

[0045] Table 1

[0046] The system has a series of built-in fault recovery strategies, including restart, reconfiguration, selection of backup paths, service degradation, etc. Each strategy has clear applicable conditions and execution steps.

[0047] For dynamic reconfiguration, when the system detects that the diagnostic service cannot be performed normally due to configuration parameter errors, the dynamic reconfiguration submodule will be started immediately. Its main task is to regenerate or update the configuration parameters required for diagnosis by cooperating with the dynamic configuration management module of the ECU. The specific execution steps are as follows: (1) Configuration error detection and response: When the fault detection module identifies a diagnostic service anomaly caused by a configuration parameter error, the system immediately starts the dynamic reconfiguration submodule. This submodule analyzes the current configuration error and identifies which specific parameters caused the diagnostic failure.

[0048] (2) Generation and update of configuration parameters: The dynamic reconfiguration submodule regenerates or updates the configuration parameters required for diagnosis by accessing the dynamic configuration management module of the ECU. This process may involve selecting a parameter combination suitable for the current diagnostic environment from a preset configuration template, or adjusting parameter settings based on real-time operating data.

[0049] (3) Configuration application and verification: Once the new configuration parameters are generated, the system will send a reconfiguration request to the ECU and ensure that these latest configuration parameters can be quickly applied to the current diagnostic process. After applying the new configuration, the system will also perform a quick self-check to verify whether the new configuration can solve the previous problem and ensure the normal recovery of the diagnostic service.

[0050] For backup path selection, if dynamic reconfiguration fails to successfully restore the diagnostic function, the system will automatically switch to the backup path selection submodule. The task of this submodule is to find an optimal alternative path or backup algorithm under the current system state to continue the diagnostic task. The specific execution steps are: (1) Fault analysis and path selection: When dynamic reconfiguration fails to restore the normal function of the system, the backup path selection submodule immediately analyzes the current fault type and the overall status of the system. Based on historical data and current environmental information, the system selects an alternate path. For example, if a sensor fails, the system can choose to use data from redundant sensors or extract diagnostic information from other available sensors through data fusion technology.

[0051] (2) Application of backup algorithms: The backup path selection submodule can also enable backup algorithms when the original algorithm fails. The backup algorithm may be a simplification or replacement of the original algorithm. For example, when hardware resources are limited, an algorithm with lower resource consumption can be used to complete part of the diagnostic task.

[0052] (3) Dynamic adjustment of diagnostic paths: Alternative path selection is not just a simple switch, but also includes dynamic adjustment of the diagnostic process. For example, in some cases, the system may skip some unnecessary diagnostic steps or adjust the diagnostic order to ensure that as many diagnostic tasks as possible can be completed.

[0053] In extreme cases, if dynamic reconfiguration and backup path selection fail to fully restore diagnostic services, the system will start the service degradation execution submodule. This submodule simplifies the diagnostic process and provides minimal diagnostic functions to ensure that the system can still operate under limited conditions. The specific execution steps are as follows: (1) Triggering of the downgrade strategy: When the system determines that the severity of the fault has exceeded the recoverable range, or the first two recovery methods fail to effectively solve the problem, the service downgrade execution submodule will automatically start. The system will immediately enable the preset downgrade strategy to ensure that the system continues to provide basic diagnostic services to the minimum extent.

[0054] (2) Simplify the diagnostic process: Service degradation will simplify the diagnostic process, which may shut down some diagnostic functions with high resource consumption, or reduce the frequency and scope of diagnostic data collection to reduce the system burden. For example, when it is impossible to obtain comprehensive diagnostic information, the system may only monitor key parameters and issue an alarm when there is an abnormality.

[0055] (3) Warning signals and notifications: When the service is degraded, the system will send a warning signal to notify maintenance personnel, informing them that the current system has entered a degraded mode and that there may be potential risks. The system will also record a detailed fault log for maintenance personnel to refer to in subsequent maintenance.

[0056] (4) Continuous monitoring and recovery: Even in a service degradation state, the system will not stop monitoring the recovery conditions. Once the fault is resolved or system resources are restored, the service degradation execution submodule will try to restore some or all diagnostic services until the system is fully restored to normal.

[0057] For system restart, when the system detects that a critical process cannot continue to execute and other recovery measures (such as dynamic reconfiguration, backup path selection, and service degradation execution) cannot effectively solve the problem, the system will determine that a restart is required. The specific execution steps are as follows: (1) Fault confirmation and pre-restart judgment: When the system detects a fault that meets the restart conditions, it will first confirm the fault. The system will reconfirm the authenticity of the fault through redundant detection means to avoid false triggering of restart. Then, the system enters the pre-restart judgment phase to check whether the currently running task is likely to be completed or terminated to prevent adverse consequences such as data loss or unfinished operations during the restart process.

[0058] (2) Data preservation and log recording: After confirming that a restart is about to take place, the system will first perform a data preservation operation. Critical data and the current system status will be written to non-volatile memory so that these data can be restored after the restart. In addition, the system will also record log information before the restart, including the cause of the failure, the current system status, the tasks being executed, etc., to provide a basis for subsequent failure analysis.

[0059] (3) Execution of the system restart command: After all preparations are completed, the system will issue a restart command. This command will be executed through hardware interrupts or software calls, and the restart process will begin. The system will reload all core modules, reinitialize the system, and perform a complete self-test.

[0060] (4) System self-check and recovery: After the restart is complete, the system will automatically perform a self-check procedure to check the hardware status, configuration parameters and system integrity. After a successful self-check, the system will load the previously saved data and restore to the operating state before the failure. If the self-check fails, the system will issue a fault alarm and enter the fault protection mode.

[0061] In an optional embodiment, the reloading includes at least one of reloading parameters, reloading dependent components, reloading drivers, or reloading communication protocols; The reconfiguration includes: determining configuration error parameters according to the fault type and the fault cause; updating configuration parameters according to the configuration error parameters, the current ECU usage scenario and the preset configuration template; The selecting of the backup path includes at least one of selecting a backup component, selecting backup component data, selecting a backup algorithm, or adjusting a diagnostic service process; The service degradation includes: simplifying the diagnostic service process to reduce the diagnostic service burden and issuing a warning according to the fault type; continuously judging whether the fault is resolved, and gradually restoring to the original diagnostic service process when the fault is resolved; Before the restart, the method also includes a step of judging the authenticity of the fault. If the fault is real, the system restarts after saving the data.

[0062] This implementation optimizes the contents or execution steps of various fault repair methods. During actual fault recovery, it is necessary to determine which specific fault repair method to use in combination with the specific fault type and fault cause.

[0063] Among them, "Reload parameters" means reloading ECU configuration parameters. "Reload dependent components" means reloading components related to the fault, including temperature sensors, pressure sensors, etc. "Reload drivers" means reloading drivers of related hardware. "Reload communication protocols" means reloading related communication protocols when network communication fails.

[0064] Reconfiguration first determines the configuration error parameters according to the fault type and fault cause, that is, identifies which or which parameters are configured incorrectly. Since the configuration error parameters are related to the ECU usage scenario, the configuration parameters are updated in combination with the current ECU usage scenario and the preset configuration template. The "preset configuration template" includes the mapping relationship between the ECU usage scenario and the ECU configuration parameters under normal operating conditions, that is, the numerical conditions of the ECU configuration parameters that ensure normal operation in each ECU usage scenario. The preset configuration template includes but is not limited to high temperature configuration template, normal temperature configuration template, low temperature configuration template, urban configuration template, rural configuration template, highway configuration template, etc. In some examples, if the engine temperature is abnormal in S110, the fault type determined is the operating environment fault, and the fault cause is the excessively high ambient temperature (that is, the current ECU usage scenario is a high temperature usage scenario), then the configuration error parameters are determined to be cooling system parameters, ignition advance angle or air-fuel ratio parameters, etc., and then the values ​​of the configuration parameters are updated according to the high temperature configuration template in the preset configuration template to adapt to the current ECU usage scenario. After reconfiguration, the system can continue to operate efficiently in the high temperature usage scenario, avoiding false alarms, missed alarms or delayed responses to faults due to parameters not being suitable for the usage scenario. It should be noted that reconfiguration also includes a variety of specific configuration methods, such as reconfiguring hardware connections, reconfiguring communication parameters, reconfiguring power parameters, reconfiguring environmental parameters, etc. Some configuration errors may be caused by problems with hardware connections, so before reconfiguring specific parameter values, you need to reconfigure the hardware connection first.

[0065] "Selecting a backup component" means selecting other optional components, for example, when a temperature sensor hardware fails, selecting other redundant temperature sensors in the system. "Selecting backup component data" means selecting data of other optional components, for example, when a temperature sensor hardware fails, selecting data of other redundant temperature sensors in the system. If there are multiple redundant sensors, the data can be processed by data fusion before being used. "Selecting a backup algorithm" means selecting other optional algorithms, for example, when the original algorithm fails, selecting a backup algorithm. The backup algorithm can be a simplification or replacement of the original algorithm. For example, when hardware resources are limited, using an algorithm with lower resource consumption to complete part of the diagnostic task. "Adjusting the diagnostic service process" means changing the order of the diagnostic service process or simplifying the diagnostic service process so that the diagnostic service can be completed within the specified time. For example, when diagnosing multiple modules, if the data acquisition speed of a module is slow, the diagnostic order of each module can be adjusted (such as adjusting the diagnostic order of the module with slow data acquisition speed backward) so that the diagnostic service can be completed within the specified time.

[0066] Service downgrade first simplifies the diagnostic service process according to the fault type to reduce the burden of diagnostic services, and issues a warning. Simplifying the diagnostic service process to reduce the burden of diagnostic services is the embodiment of service downgrade. For example, some diagnostic functions with high resource consumption are turned off, or the frequency and range of ECU parameter collection are reduced (such as only collecting certain key parameters) to reduce the system burden. The warning is mainly to remind maintenance personnel that the current system has entered the downgrade mode and there may be potential risks; then continue to judge whether the fault is resolved. If the fault is resolved, gradually restore to the original diagnostic service process. After the service is downgraded, continue to monitor whether the fault is resolved. Once the fault is resolved, try to restore part or all of the diagnostic services until it is restored to the original diagnostic service process. It should be noted that the simplified diagnostic service process in service downgrade is to reduce the burden of diagnostic services, while the simplified diagnostic service process involved in adjusting the diagnostic service process is to complete the diagnostic service within the specified time. The two have different purposes, so the specific simplification methods are also different.

[0067] Restarting is the last of all fault recovery methods, that is, it is used when other fault recovery methods cannot effectively solve the fault problem. It can also be regarded as a bottom-line measure, so it needs to be cautious. Adding a step to determine the authenticity of the fault before restarting can avoid misjudgment. If the fault really exists, then keep the data before restarting to prevent the adverse consequences of data loss or unfinished operations during the restart process. Optionally, after restarting, a self-check step is also included. If the self-check is successful, the system will load the previously saved data and restore to the operating state before the fault; if the self-check fails, the system will issue a fault unrecovered alarm and enter the fault protection mode.

[0068] Based on the information in the fault report, the system matches a set of possible recovery plans from the policy library. The matching process is based on factors such as the type of fault, the scope of impact, and the system load to ensure that the selected recovery strategy can effectively solve the current fault problem. Once the optimal recovery strategy is determined, the system will decompose the strategy into specific tasks and schedule the tasks through the scheduler. The specific implementation steps are as follows: (1) Recovery operation scheduling The system breaks down the selected recovery strategy into a series of specific operational tasks. These tasks include system restart, configuration recovery, backup path selection, service degradation execution, etc. Each task has clear execution steps and parameter settings. The task scheduler reasonably arranges the execution order and time of tasks according to the priority of the task and the current load of the system to ensure that the tasks are completed smoothly according to the predetermined plan.

[0069] (2) Recovery operation execution Each task is executed in sequence according to the scheduling plan. The execution of the recovery operation needs to follow certain rules and processes, such as saving the current state before the system restarts, checking the compatibility of the new module when replacing the module, etc. If an error occurs during the execution of the recovery task, the system will immediately record the error information and take emergency measures. For example, if the module replacement fails, the system can reselect a spare module for replacement, or restore to the previous state to prevent the system from crashing.

[0070] (3) State writeback and synchronization After the recovery operation is completed, the system will write the recovery status back to the database or log file. This information includes the results of the recovery operation, the current system status, etc. The status write-back helps with subsequent fault analysis and system optimization. After the recovery operation is completed, the system needs to synchronize the current status with other submodules to ensure the consistency of the overall system status. For example, if the status of a submodule is restored to normal, but other submodules have not been updated, the system may be in an inconsistent state.

[0071] It should be noted that the historical fault data and historical fault recovery data in the present embodiment may adopt the relevant historical data of the present vehicle model. If there is no relevant historical data of the present vehicle model (for example, in the development stage of a new vehicle model), the relevant historical data of related or similar vehicle models may be adopted. As the subsequent data of the present vehicle model is accumulated, the relevant historical data of related or similar vehicle models may be gradually replaced.

[0072] S130. When it is determined that no fault exists according to the first data, determine that there is a possibility of a fault occurring according to the real-time value of the ECU parameter and a fault prediction model.

[0073] Optionally, the possibility of a failure includes at least one of a probability, frequency, type, and impact range of a failure. For example, the probability, frequency, type, and impact range of a failure, the probability and frequency of a failure, the probability, type, and impact range of a failure, the frequency, type, and impact range of a failure, etc.

[0074] In order to enhance the foresight of fault detection, this embodiment further combines the real-time value of the ECU parameter and the fault prediction model to determine the possibility of a fault when it is detected that there is no fault, so as to take preventive measures. Since the fault prediction model can predict the fault type, fault cause and fault occurrence rate according to the real-time value of the ECU parameter, it is only necessary to input the real-time value of the ECU parameter into the model. When the possibility of a fault is higher than a preset threshold, it is considered that there is a pre-fault. The preset threshold can be determined based on experience or historical pre-fault prediction data. For example, if the historical pre-fault prediction data shows that when the predicted fault occurrence rate is lower than a certain value, a certain fault will not actually occur in the end, and when it is higher than the value, the fault will actually occur, then the value is used as the preset threshold for the fault and the fault cause. It can be understood that the preset threshold is actually different according to the different fault types and fault causes.

[0075] Optionally, after determining the possibility of a fault occurring according to the real-time value of the ECU parameter and the fault prediction model, the method further includes: In the case where the possibility of a failure exceeding a preset threshold, the control performs at least one of reconfiguration, selection of an alternate path, service degradation, or issuing an inspection prompt.

[0076] The specific contents of reconfiguration, selection of backup paths and service degradation have been described in the fault repair means. When dealing with pre-faults, it is only necessary to deal with them accordingly in combination with the type and cause of the pre-faults, which will not be described in detail in this embodiment. The main purpose of issuing inspection reminders is to remind maintenance personnel to conduct inspections in a timely manner. Inspection reminders can be issued through the vehicle computer and can also be uploaded to the cloud. Maintenance personnel can obtain the inspection reminders on the vehicle side or in the cloud at the same time. Inspection reminders may include the time, type and cause of the pre-faults, as well as the handling methods.

[0077] It is understandable that, in the absence of a pre-failure, no processing is required and the previous operation can be maintained.

[0078] Optionally, after detecting whether a fault exists, the method further comprises: Record fault log information and pre-fault log information; According to the fault log information and the pre-fault log information, the preset safety threshold of the ECU parameters, the normal operation model of the ECU, the fault prediction model or the fault recovery strategy is optimized.

[0079] Among them, "fault log information" refers to log information related to faults, including but not limited to fault time, fault type, fault cause, fault repair strategy, fault impact range, etc. "Pre-fault log information" refers to log information related to pre-faults, including but not limited to pre-fault time, pre-fault type, pre-fault cause, pre-fault handling method, pre-fault impact range, etc.

[0080] By recording fault log information and pre-fault log information, engineers can fully understand the frequency and type of faults and their impact on the system. According to the fault log information and pre-fault log information, engineers can optimize the preset safety threshold of ECU parameters, the normal operation model of ECU, the fault prediction model or the fault recovery strategy, which can further improve the accuracy and reliability of fault detection, pre-fault detection and fault repair.

[0081] The above-mentioned vehicle fault recovery method controls the execution of the fault recovery strategy according to the fault type and fault cause when it is determined that there is a fault according to the specific first data; when it is determined that there is no fault according to the first data, the possibility of a fault is determined according to the real-time value of the ECU parameter and the fault prediction model. This method can accurately detect whether a fault has occurred, and adaptively handle the fault when it occurs, thereby significantly reducing downtime, reducing the complexity and error risk of human operation, and improving the overall stability and reliability of the vehicle electronic control system. At the same time, it also combines the real-time value of the ECU parameter and the fault prediction model to predict the possibility of a fault, so that preventive measures can be taken in time before the fault occurs, reduce the probability of the fault, reduce safety risks and extend the service life. This application can improve robustness, enhance adaptability and recovery capabilities, and ensure that the vehicle can still operate safely and reliably in a complex environment.

[0082] Furthermore, the present application handles faults according to specific priorities and specific fault recovery methods, thereby optimizing resource utilization, minimizing the impact of faults on system performance, improving resource utilization, and ensuring that the system can still operate efficiently under fault conditions.

[0083] Furthermore, the present application records fault log information and pre-fault log information, and optimizes the ECU parameter preset safety threshold, ECU normal operation model, fault prediction model or fault recovery strategy based on the fault log information and pre-fault log information, thereby continuously improving the reliability of fault detection, pre-fault detection and fault repair in the present application. Engineers can make adaptive improvements to the system based on these log information.

[0084] Example 2 like Figure 2 As shown, this embodiment provides a vehicle fault recovery system, including: A fault detection module 201 is used to detect whether there is a fault according to first data; the first data includes a real-time value of an ECU parameter and second data; the second data includes at least one of a preset safety threshold of an ECU parameter, a normal operating model of the ECU, and historical fault data; A recovery strategy selection module 202, configured to select a fault recovery strategy according to the fault type and fault cause when it is determined according to the first data that a fault exists; The recovery strategy execution module 203 includes: a reconfiguration execution submodule 2031 for executing reconfiguration; a backup path selection execution module 2032 for executing backup path selection; a service degradation execution submodule 2033 for executing service degradation; The log recording and tracking module 204 is used to record fault log information and pre-fault log information; based on the fault log information and the pre-fault log information, optimize the ECU parameter preset safety threshold, the ECU normal operation model, the fault prediction model or the fault recovery strategy.

[0085] The system is used to execute the above method, and thus has at least functional modules and beneficial effects corresponding to the above method.

[0086] Example 3 like Figure 3 As shown, this embodiment provides an electronic device, including: at least one processor; and a memory communicatively connected to at least one of the processors; wherein, The memory stores instructions executable by at least one of the processors, and the instructions are executed by at least one of the processors to enable at least one of the processors to perform the above method. At least one processor in the electronic device can perform the above method, and thus has at least the same advantages as the above method.

[0087] Optionally, the electronic device also includes interfaces for connecting various components, including high-speed interfaces and low-speed interfaces. The various components are connected to each other using different buses and can be installed on a common mainboard or installed in other ways as needed. The processor can process instructions executed in the electronic device, including instructions stored in or on a memory to display graphical information of a GUI (Graphical User Interface) on an external input / output device (such as a display device coupled to an interface). In other embodiments, if necessary, multiple processors can be used together with multiple memories, and / or multiple buses can be used together with multiple memories. Similarly, multiple electronic devices can be connected (for example, as a server array, a group of blade servers, or a multi-processor system), and each device provides some necessary operations. Figure 3 A processor 301 is taken as an example.

[0088] The memory 302 is a computer-readable storage medium that can be used to store software programs, computer executable programs and modules, such as program instructions / modules corresponding to the vehicle fault recovery method in the embodiment of the present application. The processor 301 executes various functional applications and data processing of the device by running the software programs, instructions and modules stored in the memory 302, that is, implementing the above-mentioned vehicle fault recovery method.

[0089] The memory 302 may mainly include a program storage area and a data storage area, wherein the program storage area may store an operating system and at least one application required for a function; the data storage area may store data created according to the use of the terminal, etc. In addition, the memory 302 may include a high-speed random access memory, and may also include a non-volatile memory, such as at least one disk storage device, a flash memory device, or other non-volatile solid-state storage device. In some instances, the memory 302 may further include a memory remotely arranged relative to the processor 301, and these remote memories may be connected to the device via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0090] The electronic device may further include: an input device 303 and an output device 304. The processor 301, the memory 302, the input device 303 and the output device 304 may be connected via a bus or other means. Figure 3 The example of connecting through bus is taken in the following.

[0091] The input device 303 can receive input digital or character information, and the output device 304 can include a display device, an auxiliary lighting device (e.g., LED), and a tactile feedback device (e.g., a vibration motor), etc. The display device can include, but is not limited to, a liquid crystal display (LCD), a light emitting diode (LED) display, and a plasma display. In some embodiments, the display device can be a touch screen.

[0092] Example 4 This embodiment provides a computer-readable storage medium, on which computer instructions are stored, and the computer instructions are used to enable a computer to execute the above method. The computer instructions on the computer-readable storage medium are used to enable a computer to execute the above method, and thus have at least the same advantages as the above method.

[0093] The medium in this application may adopt any combination of one or more computer-readable media. The medium may be a computer-readable signal medium or a computer-readable storage medium. The medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or device, or any combination thereof. More specific examples of the medium (a non-exhaustive list) include: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination thereof. In this document, the medium may be any tangible medium containing or storing a program, which may be used by or in combination with an instruction execution system, device, or device.

[0094] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, which carry computer-readable program code. Such propagated data signals may take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. Computer-readable signal media may also be any computer-readable medium other than a computer-readable storage medium, which may send, propagate, or transmit a program for use by or in conjunction with an instruction execution system, apparatus, or device.

[0095] The program code contained on the computer-readable medium can be transmitted using any appropriate medium, including but not limited to wireless, wire, optical cable, RF (Radio Frequency), etc., or any suitable combination of the above.

[0096] Computer program code for performing the operation of the present application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages, such as Java, Smalltalk, C++, and conventional procedural programming languages, such as "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a separate software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the case of a remote computer, the remote computer can be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or can be connected to an external computer (e.g., using an Internet service provider to connect through the Internet).

[0097] It should be understood that the various forms of processes shown above can be used to reorder, add or delete steps. For example, the steps recorded in this application can be executed in parallel, sequentially or in different orders, as long as the expected results of the technical solution disclosed in this application can be achieved, and this document is not limited here.

[0098] The above specific implementations do not constitute a limitation on the protection scope of this application. It should be understood by those skilled in the art that various modifications, combinations, sub-combinations and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions and improvements made within the spirit and principles of this application should be included in the protection scope of this application.

Claims

1. A vehicle fault recovery method, characterized in that: include: Acquire first data; the first data includes a real-time value of an ECU parameter and second data; the second data includes at least one of a preset safety threshold of an ECU parameter, a normal operating model of the ECU, and historical fault data; In the case where it is determined according to the first data that a fault exists, controlling execution of a fault recovery strategy according to the type of fault and the cause of the fault; When it is determined that no fault exists according to the first data, it is determined that there is a possibility of a fault occurring according to the real-time value of the ECU parameter and the fault prediction model.

2. The vehicle failure recovery method according to claim 1, characterized in that: The fault recovery strategy includes fault recovery means and execution priority, and the fault recovery means include at least two of reloading, reconfiguration, selecting an alternate path, service degradation or restarting; the execution priorities of the reloading, the reconfiguration, the selecting an alternate path, the service degradation and the restarting are decreased in sequence.

3. The vehicle failure recovery method according to claim 1, characterized in that: The possibility of a failure includes at least one of a probability, a frequency, a type, and an impact range of the failure.

4. The vehicle failure recovery method according to claim 1, characterized in that: The ECU normal operation model is determined according to the parameter values ​​under the normal operation state of the ECU and the ECU usage scenario; The fault prediction model is determined according to historical fault data.

5. The vehicle failure recovery method according to claim 1, characterized in that: When it is determined that there is an ECU configuration abnormality, sensor abnormality, ECU load abnormality or communication abnormality based on the real-time values ​​of the ECU parameters and the preset safety thresholds of the ECU parameters, determine whether there is a fault based on the real-time values ​​of the ECU parameters, the normal operating model of the ECU and the historical fault data.

6. The vehicle failure recovery method according to claim 1, characterized in that: The controlling and executing of the fault recovery strategy according to the fault type and fault cause includes: Obtaining a mapping relationship between a fault type, a fault cause, and a fault recovery strategy; the fault type includes at least one of an ECU configuration fault, a diagnostic service fault, a hardware fault, or an operating environment fault; According to the fault type, fault cause and the mapping relationship, the execution of the fault recovery strategy is controlled.

7. The vehicle failure recovery method according to claim 2, characterized in that: The reloading includes at least one of reloading parameters, reloading dependent components, reloading drivers, or reloading communication protocols; The reconfiguration includes: determining configuration error parameters according to the fault type and the fault cause; updating configuration parameters according to the configuration error parameters, the current ECU usage scenario and the preset configuration template; The selecting of the backup path includes at least one of selecting a backup component, selecting backup component data, selecting a backup algorithm, or adjusting a diagnostic service process; The service degradation includes: simplifying the diagnostic service process according to the fault type; and gradually restoring to the original diagnostic service process when the fault is resolved; The restarting includes restarting after saving data when it is determined that the fault is real.

8. The vehicle failure recovery method according to claim 1, characterized in that: After determining the possibility of a fault occurring according to the real-time value of the ECU parameter and the fault prediction model, the method further includes: In the case where the possibility of a failure exceeding a preset threshold, the control performs at least one of reconfiguration, selection of an alternate path, service degradation, or issuing an inspection prompt.

9. The vehicle failure recovery method according to claim 8, characterized in that: After determining that there is a possibility of a failure, the method further includes: Record fault log information and pre-fault log information; According to the fault log information and the pre-fault log information, the preset safety threshold of the ECU parameters, the normal operation model of the ECU, the fault prediction model or the fault recovery strategy is optimized.

10. An electronic device, characterized in that: include: at least one processor, and a memory communicatively coupled to at least one of the processors; The memory stores instructions executable by at least one of the processors, and the instructions are executed by at least one of the processors so that the at least one processor can execute the method according to any one of claims 1 to 8.

Images