Fault diagnosis and processing method and system for improving system robustness

Abstract

The invention provides a fault diagnosis and processing method and system for improving system robustness, and relates to the technical field of automobile electronic control. According to the method, fault monitoring, management and processing in dynamic operation of the system are realized on the basis of a UDS tool through the steps of multi-source detection, Detource strategy, dynamic threshold adjustment, self-adaptive processing mechanism and fault post-processing and recovery, so that the problems of false report and missing report caused by dependence on single data or a fixed threshold in a traditional diagnosis method are solved; and the fault diagnosis accuracy, the anti-interference capability of the system and the robustness of the system are improved.

Description

Technical Field

[0001] The present invention relates to the technical field of automotive electronic control, and in particular to a fault diagnosis and processing method and system for improving system robustness. Background Art

[0002] Currently, during the development of automotive lighting drivers, fault diagnosis processes and strategies are primarily based on Unified Diagnostics Services (UDS) tools. These tools are developed based on the customer's diagnostic questionnaire. Post-fault processing and recovery typically focus on basic functions, relying on fixed thresholds and detection methods. These strategies are poorly coupled with the controller's system capabilities. This often results in the system failing to diagnose or recover despite having the capability to do so. This leads to missed or false alarms and hinders post-fault troubleshooting.

[0003] In modern industrial control systems and automotive controller systems, system reliability and robustness are key performance indicators. However, due to factors such as increasing system complexity, external environmental interference, and equipment aging, system failures are inevitable. The UDS service tool effectively enables our systems to detect and record faults. However, traditional fault diagnosis methods often rely on single data or fixed thresholds, which are susceptible to noise interference, leading to false positives or false negatives, and reducing system robustness. Therefore, a fault diagnosis and processing strategy that can effectively improve system robustness is urgently needed. Summary of the Invention

[0004] The purpose of the present invention is to overcome at least one technical problem existing in the prior art and to provide a fault diagnosis and processing method and system for improving system robustness.

[0005] On the one hand, an embodiment of the present invention provides a fault diagnosis and processing method for improving system robustness, the method comprising: step S1, real-time synchronous acquisition of multi-source sensor data; step S2, analyzing and processing the multi-source sensor data based on cross-validation to obtain a potential fault signal; step S3, executing a Debounce strategy of multiple judgments on the potential fault signal on the basis of satisfying the fault tolerance time interval; step S4, judging whether the duration of the potential fault signal is greater than a preset time threshold; step S5, in response to the duration of the potential fault signal being greater than the preset time threshold, confirming that the potential fault signal is a valid fault signal and triggering fault processing; step S6, based on the current operating parameters of the system, dynamically calculating the fault diagnosis threshold through a preset environmental compensation model; step S7, obtaining the current operating parameter data of the system and comparing it with the fault diagnosis threshold to determine whether a fault exists; step S8, in response to the existence of a fault, dynamically adjusting the processing strategy according to the real-time monitored system status and abnormality type; step S9, evaluating the processing result, judging whether the processing strategy is effective, and adjusting the processing strategy based on the judgment result.

[0006] Furthermore, the step S2, analyzing and processing the multi-source sensor data based on cross-validation to obtain a fault signal includes: step S20, performing data preprocessing on the collected multi-source sensor data to eliminate interference and errors in the data transmission link; step S21, performing feature extraction based on the preprocessed data, including: extracting key feature quantities that can reflect the system status from the preprocessed data stream; step S22, cross-validating and fusing similar or related feature data from different sources to eliminate the limitations of single data; step S23, comparing the fused feature data with a preset normal feature model to identify whether there is a fault feature; step S24, outputting the identified fault feature in a standardized format in the form of a potential fault signal.

[0007] Furthermore, the step S22, cross-validating and fusing similar or related feature data from different sources to eliminate the limitations of single data, includes: step S220, comparing the value of the previous cycle read by the chip register with the value of the current cycle to obtain a first deviation; step S221, comparing the input value received by the next-level component with the output value of the current component to obtain a second deviation; step S222, comparing the first deviation and the second deviation with a preset deviation threshold corresponding thereto, and when the comparison result is less than the deviation threshold, fusing the multi-source sensor data.

[0008] Furthermore, the step S4, determining whether the duration of the potential fault signal is greater than a preset time threshold, includes: step S40, the system times the detected potential fault signal to determine whether its duration exceeds a time threshold pre-set in combination with the fault tolerance time interval.

[0009] Furthermore, the step S6, based on the current operating parameters of the system, dynamically calculates the fault diagnosis threshold through a preset environmental compensation model, including: step S60, collecting the current operating parameters of the system, including: one or a combination of real-time temperature, input voltage, working mode and operating time; step S61, based on the current system status, analyzing key environmental influencing factors, and quantifying the degree of influence of these environmental factors; step S62, dynamically updating the fault judgment threshold according to the quantified results of the degree of influence of environmental factors; step S63, applying the adjusted new threshold to the fault diagnosis logic of the system, replacing the original fixed threshold, as the judgment standard for real-time monitoring; step S64, after applying the new threshold, the system continues to collect data and performs fault judgment according to the updated fault judgment threshold.

[0010] Furthermore, the key environmental influencing factors include: the influence of temperature on resistance and / or the influence of voltage fluctuation on sensor accuracy.

[0011] Furthermore, the step S62, dynamically updating the fault judgment threshold according to the quantitative results of the influence degree of environmental factors, includes: step S620, updating the judgment threshold in real time or periodically using a sliding calculation method; step S621, selecting the corresponding judgment threshold through historical data analysis, real-time signal status monitoring or working condition judgment to update the threshold to adapt to the dynamic changes of system electrical parameters and the threshold drift caused by aging of components.

[0012] Furthermore, the abnormality types include: minor abnormalities, moderate abnormalities and severe abnormalities; the processing strategy for the minor abnormalities is to adopt a simple retry mechanism; the processing strategy for the moderate abnormalities is to adopt a strategy of increasing the number of retries or extending the retry interval; the processing strategy for the severe abnormalities is to trigger an alarm, record a log and try to switch to a backup channel or controller.

[0013] Furthermore, in step S8, in response to a fault, the processing strategy is dynamically adjusted based on the real-time monitored system status and abnormality type, including: dynamically adjusting the number of retries, the retry interval, the segment size of data writing and the number of batches of batch writing, as well as the number of parallel channels for input and output control.

[0014] In a second aspect, an embodiment of the present invention provides a fault diagnosis and processing system for improving system robustness. The system is implemented using the above-mentioned fault diagnosis and processing method for improving system robustness. The system includes: a multi-source detection module, adapted to synchronously collect multi-source sensor data in real time; analyzing and processing the multi-source sensor data based on cross-validation to obtain a potential fault signal; a debounce module, adapted to perform a debounce strategy of multiple judgments on the potential fault signal on the basis of meeting a fault tolerance time interval; judging whether the duration of the potential fault signal is greater than a preset time threshold; in response to the duration of the potential fault signal being greater than the preset time threshold, confirming that the potential fault signal is a valid fault signal and triggering fault processing; a dynamic threshold calculation module, adapted to dynamically calculate a fault diagnosis threshold based on the current operating parameters of the system through a preset environmental compensation model; a fault judgment module, adapted to obtain the current operating parameter data of the system and compare it with the fault diagnosis threshold to determine whether a fault exists; an adaptive processing module, adapted to dynamically adjust the processing strategy in response to the existence of a fault based on the real-time monitored system status and abnormality type; and a post-fault processing module, adapted to evaluate the processing results, judge whether the processing strategy is effective, and adjust the processing strategy based on the judgment results.

[0015] In a third aspect, an embodiment of the present invention further provides an electronic device comprising: a memory, a processor, and a computer program stored on the memory and executable on the processor, wherein the computer program, when executed by the processor, implements the above-mentioned fault diagnosis and processing method for improving system robustness.

[0016] In a fourth aspect, an embodiment of the present invention further provides a readable storage medium, which, when the instructions in the storage medium are executed by a processor of an electronic device, enables the electronic device to perform the above-mentioned fault diagnosis and processing method for improving system robustness.

[0017] The beneficial effects of the present invention are: (1) The accuracy and robustness of fault diagnosis are improved through multi-source detection, debounce and dynamic threshold adjustment.

[0018] (2) Adopt an adaptive processing mechanism to enable the system to adapt to changes brought about by different working conditions.

[0019] (3) Through post-fault processing and recovery, the system can ensure safe shutdown in the event of some serious faults, can operate in limp mode according to the functional safety strategy in the event of moderate faults, and can achieve system self-recovery in the event of minor faults.

[0020] (4) At the same time, it reduces false alarms and missed alarms of system failures, and improves the reliability and operating efficiency of the system. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] The present invention will be further described below with reference to the accompanying drawings and examples.

[0022] Figure 1 This is a flowchart of a fault diagnosis and processing method for improving system robustness provided by Example 1 of the present invention.

[0023] Figure 2 This is a flow chart of a multi-source detection method provided in Example 1 of the present invention.

[0024] Figure 3 This is a flow chart of a method of collecting boost output voltage in a multi-source detection phase according to the first embodiment of the present invention.

[0025] Figure 4 This is a schematic diagram of a Debounce strategy involved in step S3 provided in Example 1 of the present invention.

[0026] Figure 5 This is a flow chart of a method for calculating a dynamic judgment threshold value involved in step S6 provided in Example 1 of the present invention.

[0027] Figure 6 This is a schematic diagram of a method for dynamically adjusting a processing strategy involved in step S8 provided in Example 1 of the present invention.

[0028] Figure 7 This is a structural diagram of a fault diagnosis and processing system for improving system robustness provided by Example 2 of the present invention.

[0029] Figure 8 This is a partial block diagram of an electronic device provided in Example 3 of the present invention. DETAILED DESCRIPTION

[0030] Before discussing the exemplary embodiments in more detail, it should be mentioned that some exemplary embodiments are described as processes or methods depicted as flow charts. Although the flow charts describe the various operations as sequential processes, many of the operations therein can be implemented in parallel, concurrently, or simultaneously. In addition, the order of the various operations can be rearranged. The process can be terminated when its operation is completed, but can also have additional steps not included in the accompanying drawings. The process can correspond to a method, function, procedure, subroutine, subprogram, etc.

[0031] It should be understood that although the terms "first," "second," and the like may be used herein to describe various elements, these elements should not be limited by these terms. These terms are used solely to distinguish one element from another. For example, a first element may be referred to as a second element, and similarly, a second element may be referred to as a first element, without departing from the scope of the exemplary embodiments. The term "and / or" as used herein includes any and all combinations of one or more of the listed associated items.

[0032] The present invention will now be described in detail with reference to the accompanying drawings. This figure is a simplified schematic diagram, which only illustrates the basic structure of the present invention in a schematic manner, and therefore only shows the components related to the present invention.

[0033] Example 1 For ease of understanding, the overall inventive concept of the present invention is explained here: The present invention aims to provide a fault diagnosis and processing method that improves the robustness of the system, so as to improve the accuracy of fault diagnosis and the anti-interference ability of the system, and reduce false alarms and missed alarms. The method is based on the automobile headlight controller and includes multi-source detection, Debounce strategy, dynamic threshold adjustment, adaptive processing mechanism and post-fault processing and recovery steps, which are as follows: Multi-source detection: Collect multi-source data such as temperature, position, current, etc., and verify the reliability of the data by comparing the previous cycle value of the chip register with the current cycle value, and comparing the next-level element input value with the current element output value. For example, in the BOOST+BUCK voltage regulation circuit, the output voltage is determined by combining the Boost chip self-test voltage value, the hardware circuit ADC sampling value and the BUCK end detection input voltage value; Debounce strategy: Continuously monitor the pre-processed signal, and confirm a valid fault if the signal duration exceeds the threshold, while considering Taking into account ECU task scheduling and CPU load, fault detection and reporting time, processing time, and FTTI time are maintained. Dynamic threshold adjustment: Based on historical data, current system status, and environmental parameters, thresholds are updated in real time or periodically using a sliding calculation method to adapt to parameter changes caused by temperature fluctuations, voltage fluctuations, and component aging. Adaptive processing: Fault type is identified. Minor faults are treated as simple retries. Moderate faults increase the number of retries or extend the interval. Severe faults trigger alarms, logs, and attempt to switch to a backup channel or controller, while optimizing the parameter model. Post-fault processing and recovery: Severe faults ensure safe system shutdown, moderate faults enter limp mode, and minor faults achieve self-recovery, while recording fault codes and reporting information. Multi-source detection, debounce strategies, and dynamic threshold adjustment improve the accuracy and robustness of fault diagnosis, reducing false positives and missed negatives. The adaptive processing mechanism enables the system to adapt to varying operating conditions. Post-fault processing and recovery ensure safe system operation and recovery under varying fault severity, improving system reliability and efficiency.

[0034] The specific implementation is as follows: like Figure 1 FIG. 1 is a flow chart of a fault diagnosis and processing method for improving system robustness provided by the present invention.

[0035] As an example, the method includes: step S1, real-time synchronous collection of multi-source sensor data; step S2, analyzing and processing the multi-source sensor data based on cross-validation to obtain a potential fault signal; step S3, executing a Debounce strategy of multiple judgments on the potential fault signal based on satisfying the fault tolerance time interval; step S4, judging whether the duration of the potential fault signal is greater than a preset time threshold; step S5, in response to the duration of the potential fault signal being greater than the preset time threshold, confirming that the potential fault signal is a valid fault signal and triggering fault processing; step S6, based on the current operating parameters of the system, dynamically calculating the fault diagnosis threshold through a preset environmental compensation model; step S7, obtaining the current operating parameter data of the system and comparing it with the fault diagnosis threshold to determine whether a fault exists; step S8, in response to the existence of a fault, dynamically adjusting the processing strategy according to the real-time monitored system status and abnormality type; step S9, evaluating the processing results, judging whether the processing strategy is effective, and adjusting the processing strategy based on the judgment result.

[0036] Preferably, the multi-source sensor data collected synchronously in real time includes parameters such as temperature, position, and current. Temperature sensors (to monitor the temperature of the MCU and power chip), current sensors (to detect the current in the LED light group circuit), position sensors (to record the position of the headlight adjustment motor), and voltage sensors (to collect input voltage, Boost output voltage, and Buck output voltage) are deployed in the headlight controller circuit to ensure that each type of parameter corresponds to at least one main sensor and one redundant sensor (e.g., key voltage parameters are connected to both the chip's built-in ADC and an external independent ADC). Sensor data is transmitted to the MCU via differential signals (to reduce transmission interference), and a CRC check circuit is added at the hardware layer to perform real-time verification of the raw data and analog-to-digital conversion (ADC) results, directly filtering out obviously erroneous data (e.g., abnormal values ​​that exceed the physical range).

[0037] In some feasible embodiments, combined with Figure 2As shown, the step S2, analyzing and processing the multi-source sensor data based on cross-validation to obtain a fault signal includes: step S20, performing data preprocessing on the collected multi-source sensor data to eliminate interference and errors in the data transmission link; step S21, performing feature extraction based on the preprocessed data, including: extracting key feature quantities that can reflect the system state from the preprocessed data stream; step S22, cross-validating and fusing similar or related feature data from different sources to eliminate the limitations of single data; step S23, comparing the fused feature data with a preset normal feature model to identify whether there is a fault feature; step S24, outputting the identified fault feature in a standardized format in the form of a potential fault signal.

[0038] Preferably, since the vehicle controller is based on the data collected by various sensors, the main data source for diagnosis is the data collected by various sensors. There are multiple risks of failure in the link between the collected data and the MCU, such as raw data collection errors, analog-to-digital conversion errors, and transmission errors. Therefore, it is necessary to fuse the received multi-source data to obtain potential fault signals.

[0039] Preferably, step S22, cross-validating and fusing similar or related feature data from different sources to eliminate the limitations of single data, includes: step S220, comparing the value read from the chip register in the previous cycle with the value in the current cycle to obtain a first deviation; step S221, comparing the input value received by the next-level component with the output value of the current component to obtain a second deviation; and step S222, comparing the first and second deviations with a preset deviation threshold corresponding thereto. When the comparison result is less than the deviation threshold, fusing the multi-source sensor data. Specifically, step S2 includes the following steps: Collecting multi-source sensor data: This is the starting point of the process. The core is to obtain key system operation parameters from multiple independent sources, including temperature (such as headlight controller chip temperature and ambient temperature), position (such as light adjustment motor position), and current (such as headlight drive current). Data sources include various sensors (such as temperature sensors, Hall effect sensors, current sensors) and internal chip registers. This multi-channel collection avoids information loss caused by failure of a single data source and provides basic data support for subsequent diagnosis. Data preprocessing: Preliminary processing of collected raw data aims to eliminate or reduce interference and errors in the data transmission link. This includes addressing issues such as raw data acquisition errors (e.g., sensor accuracy deviations), analog-to-digital conversion errors (e.g., quantization errors in the A / D converter), and transmission errors (e.g., noise interference in the communication link). Filtering (e.g., low-pass filtering to remove high-frequency noise) and calibration (e.g., sensor zero-point calibration) are employed to improve data accuracy and stability, providing reliable "clean data" for subsequent analysis. Feature extraction: Key features that reflect system status are extracted from the preprocessed data stream. For example, "temperature change rate" is extracted from temperature data to determine rapid temperature rise; "peak current" and "average current" are extracted from current data to determine overcurrent. These features serve as the core basis for subsequent fault identification, simplifying data dimensions and focusing on key information relevant to the fault. Multi-source data fusion analysis: Cross-validation and comprehensive analysis of similar or related feature data from different sources eliminates the limitations of single data. For example: compare the temperature value of the previous cycle stored in the chip register with the temperature value collected by the current sensor; compare the output current of the current module with the input current of the next module to verify whether there is any transmission loss anomaly; through multi-dimensional comparison, improve the credibility of the data and reduce the risk of misjudgment. Fault feature identification: compare the fused feature data with the preset normal feature model to identify whether there are fault features. For example: if the current feature shows "continuously exceeding 1.2 times the rated value" and the temperature feature simultaneously shows "rapid heating", it is judged as an "overcurrent fault"; if the deviation between the position sensor data and the motor feedback data continues to exceed the threshold, it is judged as a "position detection anomaly"; this step uses logical judgment to clarify the type and degree of the fault.Output diagnostic results: The identified fault type, severity, and other information are output in a standardized format (such as fault code and status identifier) ​​and passed to subsequent fault processing modules (such as the debounce strategy link). This provides a clear diagnostic basis for the next step of debounce judgment and threshold adjustment.

[0040] Specifically, combined Figure 3 As shown in the figure, in the BOOST+BUCK voltage regulation circuit, the Boost chip's output voltage can be determined by combining the chip's self-test voltage value, the ADC sampling value in the hardware circuit, and the input voltage detected by the BUCK terminal. This diagnostic-based signal source is compared across multiple inputs, improving fault detection accuracy.

[0041] In some feasible implementations, the step S4, determining whether the duration of the potential fault signal is greater than a preset time threshold, includes: step S40, the system times the detected potential fault signal to determine whether its duration exceeds the time threshold pre-set in combination with the fault tolerance time interval.

[0042] In some feasible embodiments, combined with Figure 4 As shown, signal processing involves two aspects. First, preprocessing the collected data involves denoising, filtering, and feature extraction. This calibrates the signal's accuracy. Second, there's the issue of time. Continuous filtering shouldn't be done blindly to improve data accuracy. System fault diagnosis responses must be timely, and the most important time threshold is the fault tolerant time interval (FTTI). Breaking down the time required for fault diagnosis is even more demanding. Conventional fault diagnosis uses preprocessed data as the diagnostic criterion to meet the fault detection time. To improve system robustness, this embodiment implements a debounce mechanism within the fault detection strategy, performing multiple judgments based on the fault detection time. This strategy serves two purposes. First, detection time should be considered during hardware circuit design or selection. For chips that rely on chip self-test, the fault detection time of the fault register should be considered during chip selection. Sampling circuits or sensor designs should also consider fault detection time. Second, software design should consider an appropriate task scheduling mechanism to place fault detection tasks within appropriate task cycles.

[0043] Optimally, the debounce strategy implementation process includes: FTTI (Fault Detection, Isolation, and Recovery Time) determination: According to automotive functional safety requirements (such as ISO 26262), the FTTI (Fault Detection, Isolation, and Recovery Time) for headlight controller fault diagnosis must be ≤ 100ms. Therefore, the fault diagnosis cycle is set to 20ms (ensuring diagnosis completion within 5 cycles). Software task scheduling: In the MCU's RTOS system, the "fault detection task" is assigned a high priority (higher than normal control tasks) and triggered every 20ms. After detecting a potential fault signal, three consecutive tests are performed (for a total of 60ms). If all three tests exceed the threshold, the fault is confirmed. If one of the tests returns to normal, it is considered a "transient interference" and monitoring continues. The number of samples for a single fault detection is limited (to a maximum of 5) to avoid excessive CPU resource consumption (controlled within 10%). A "dynamic adjustment of the detection interval" is also configured: during normal system operation, the detection interval is set to 20ms. During high load conditions (such as when switching between high and low beam headlights), the interval is temporarily extended to 50ms to prioritize control functionality.

[0044] In some feasible embodiments, combined with Figure 5 As shown, the step S6, based on the current operating parameters of the system, dynamically calculates the fault diagnosis threshold through a preset environmental compensation model, including: step S60, collecting the current operating parameters of the system, including: one or a combination of real-time temperature, input voltage, working mode and operating time; step S61, based on the current system status, analyzing key environmental influencing factors, and quantifying the degree of influence of these environmental factors; step S62, dynamically updating the fault judgment threshold according to the quantified result of the degree of influence of environmental factors; step S63, applying the adjusted new threshold to the fault diagnosis logic of the system, replacing the original fixed threshold, as the judgment standard for real-time monitoring; step S64, after applying the new threshold, the system continues to collect data and performs fault judgment according to the updated fault judgment threshold.

[0045] Preferably, in conventional ECU diagnostic systems, the diagnostic thresholds are usually defined by the electrical properties of the hardware, such as open and short circuits, overvoltage and undervoltage of the hardware loop. Taking into account the dynamic changes in electrical parameters under the ECU operating state, and even the threshold drift of ECU components after durability and aging, a dynamic threshold calculation logic should be set in the software. Usually, the input source of the diagnosis is the signal collected by the ADC or the signal input by the sensor, so a sliding calculation method is used here to update the threshold in real time or periodically to adapt to system changes. For example, temperature changes and voltage fluctuations will affect the resistance of sensors and circuits. In some working conditions, the voltage value collected may be close to the fault threshold, resulting in misjudgment. Therefore, dynamic threshold calculation can further reduce the risk of misjudgment. There are many ways to calculate dynamic thresholds. One can analyze historical data and select appropriate thresholds. Another approach involves real-time monitoring of signal status. If anomalous differences in signal values ​​between previous and subsequent cycles are detected, the collected values ​​can be considered unreliable. If the overall value is offset, it can be considered that the electrical properties of the hardware are drifting, necessitating an update of the threshold. Different thresholds can be designed based on different operating conditions, allowing the appropriate threshold to be selected based on these conditions. Furthermore, thresholds for different conditions can be pre-stored, and the system can calculate the thresholds using a lookup table or interpolation method. Therefore, dynamic adjustment of open and short-circuit thresholds can be achieved through a variety of methods, including environmental compensation, adaptive algorithms, real-time monitoring, multiple threshold settings, and software implementation, ensuring system stability and reliability under varying conditions.

[0046] Preferably, step S62, dynamically updating the fault judgment threshold based on the quantified results of the degree of environmental influence, includes: step S620, updating the judgment threshold in real time or periodically using a sliding calculation method; and step S621, selecting a corresponding judgment threshold through historical data analysis, real-time signal status monitoring, or operating condition determination, and updating the threshold to accommodate dynamic changes in system electrical parameters and threshold drift caused by component aging. Specifically, the implementation process for dynamic threshold calculation includes: historical data calibration: During the product testing phase, normal parameter ranges under different operating conditions (such as cold start, high temperature operation, and voltage fluctuations of 12V±3V) are recorded to establish a basic threshold table (e.g., the normal range of Boost output voltage: 9V-16V input, relaxed to 8.5V-16.5V at -40°C). Operating condition identification logic: The MCU monitors the current system status (input voltage, ambient temperature, headlight operating mode) in real time, matches the corresponding operating condition (such as "low temperature + high voltage" or "normal temperature + normal voltage") through a table lookup, and calls the dynamic threshold for that operating condition. Drift Compensation: Sensor data is analyzed hourly for drift trends (such as zero-point drift in temperature sensors due to aging). If the average deviation of the same parameter exceeds 1% for three consecutive times, the upper and lower thresholds are automatically expanded by 0.5% each (but not exceeding the maximum safety range). Abnormal Trigger Update: When a parameter is detected approaching the current threshold (for example, within 1% of the lower threshold) and remains within this range for five consecutive cycles, the threshold is temporarily relaxed by 2% (for one minute) to prevent misjudgments due to momentary fluctuations. The original threshold is then automatically restored.

[0047] In some feasible embodiments, combined with Figure 6 As shown, the abnormality types include: minor abnormality, medium abnormality and serious abnormality; the processing strategy for the minor abnormality is to adopt a simple retry mechanism; the processing strategy for the medium abnormality is to adopt a strategy of increasing the number of retries or extending the retry interval; the processing strategy for the serious abnormality is to trigger an alarm, record a log and try to switch to a backup channel or controller.

[0048] The core concept of the adaptive processing mechanism is to dynamically adjust the processing strategy based on the real-time monitored system status and anomaly type, rather than adopting a fixed approach. This mechanism can effectively cope with complex operating environments and changing anomalies, thereby improving the system's adaptability and diagnostic efficiency. First, the system should monitor the operating status, including communication status, controller response time, data write success rate, control operation success rate, and other factors. This information, combined with data detected from multiple sources, can be analyzed to determine the system's current operating state and state machine, thereby determining the appropriate handling method. The anomaly information is then classified. Detected abnormal behaviors, such as communication anomalies, controller unresponsiveness, and control failure, are categorized by severity, typically into minor, moderate, and major anomalies. For example, if a communication anomaly occurs while the controller is in quiescence or hibernation, resulting in an inability to wake up and causing the controller to become unresponsive, this can be considered a major anomaly, requiring upstream power cycles and other attempts to recover. If a data storage or erase error occurs during controller operation due to voltage fluctuations or other factors, but does not affect current functionality, this can be considered a minor anomaly. When faced with different exceptions, the software should implement different strategies. For example, for minor exceptions, a simple retry mechanism can be used. For moderate exceptions, the strategy of increasing the number of retries or extending the retry interval can be adopted. For severe exceptions, an alarm can be triggered and detailed logs can be recorded, while also attempting to switch to an alternative communication channel or controller. Finally, after accumulating sufficient testing experience, the parameter model should be optimized. For example, dynamic adjustment of the number of retries and retry intervals, optimization of the data write segment size and batch size, and adjustment of the number of parallel channels for input and output control can be carried out.

[0049] Preferably, the implementation process of the adaptive processing mechanism specifically includes: Status monitoring indicators: MCU tracks the following indicators in real time: ① The response time of the communication bus (such as LIN / CAN) (normal ≤5ms), ② The success rate of data writing to Flash (normal ≥99%), and ③ The completion rate of the headlight adjustment motor (normal ≥95%). Abnormality classification standard: Minor abnormality: Single data writing failure (successful after retry), motor action delay ≤10ms (no impact on function). Medium abnormality: 2 consecutive communication timeouts, motor action delay ≥20ms but ≤50ms (function is slightly affected). Severe abnormality: Communication bus interruption ≥100ms, motor stuck (action failure), LED drive current exceeds the safe range (may burn components). Grading processing strategies include: Minor abnormality: Execute 1 retry (such as resending data, restarting motor action), do not record DTC, only mark in the internal log. Moderate abnormality: Increase the number of retries to 3 times and extend the retry interval (from 10ms to 50ms); if it still fails, record the "moderate fault" DTC and reduce the operating frequency of the corresponding module (such as reducing the motor adjustment from 10Hz to 5Hz). Severe abnormality: Immediately trigger an alarm (send the fault code through the bus) and record a detailed log (including a snapshot of the parameters 100ms before the fault); if it is a communication failure, switch to the backup communication channel (such as switching from LIN to the backup GPIO signal); if it is a drive circuit failure, turn off the corresponding LED light group and enable the redundant light group (such as if the main low beam fails, switch to the auxiliary low beam). The parameter optimization iterative process includes: Self-learning logic: After the system has run for 100 hours, it analyzes historical fault data and automatically adjusts parameters: for example, the retry interval for minor abnormalities is optimized from 10ms to 20ms (reducing resource consumption from frequent retries); when writing data to Flash, adjust the batch write from 50 / batch to 30 / batch (reducing the write failure rate).

[0050] In some feasible implementations, step S9, evaluating the processing results and determining whether the processing strategy is effective, and adjusting the processing strategy based on the determination result, includes: assuming that a fault is still detected despite strict implementation of the aforementioned diagnostic strategy, then a system failure has indeed occurred. The system should then take appropriate action, such as issuing an alarm, degrading operation, or automatically repairing the fault, based on the fault type and severity, while also recording the fault. An effective approach is to develop a set of corresponding action measures for all types of faults. For example, for temperature alarms during operation, a degraded operation strategy should be developed within regulatory limits, shutting down non-functional energy-consuming elements or de-rating existing functions. Furthermore, in the event of an overtemperature shutdown (chip behavior), the shutdown should occur within a safe time and state, and the controller function should not be suddenly lost without any warning or action. Furthermore, after a fault occurs, the chip's fault register should be queried, or if a set threshold has been exceeded, a fault DTC should be stored and the fault information reported. Taking automotive lighting controllers as an example, under certain operating conditions, if there are power fluctuations, sudden power outages followed by recovery, or sudden overvoltage or undervoltage conditions, it is important to prevent light flickering and sudden extinguishing. The hardware circuitry should include appropriate capacitor discharges to allow the MCU sufficient time to perform shutdown operations and fault storage in these situations. The software should reinitialize the lighting link after detecting voltage recovery to ensure functional recovery.

[0051] Specifically, post-fault handling measures include: Overtemperature handling: When the MCU or power chip temperature is ≥120°C (safety threshold 150°C), a degradation strategy is initiated: the headlight welcome mode and delayed shutdown function (not mandatory by law) are disabled, and the LED drive current is reduced to 80% of the rated value. If the temperature rises to 140°C, an overtemperature shutdown is triggered, gradually cutting off the power supply within 500ms (to avoid sudden shutdown), while maintaining the MCU power supply to complete fault recording. Power supply abnormality recovery: When designing the hardware circuit, add a capacitor of sufficient capacity to the power input (to ensure that the MCU can still run for 100ms after power failure). In the event of a power failure, an interrupt is immediately triggered, and the MCU completes fault storage within 100ms (recording the voltage and current values ​​before the power failure). After the voltage recovers, the MCU reinitializes all modules, first lighting the low-power indicator light (to confirm that the system is normal), and then gradually restoring the headlights to normal brightness (to avoid current surges). DTC Storage: After a fault occurs, the MCU immediately reads the fault registers of the relevant chips (such as the overcurrent flag of the Boost chip and the short-circuit flag of the LED driver chip). Combined with real-time parameters (the specific value exceeding the threshold and the duration of the fault), it generates a DTC (such as "P1234: Boost output overvoltage") and stores it in non-volatile memory (which supports power-off preservation). Reporting Mechanism: Minor faults are only stored locally. Moderate and higher faults are reported to the Body Controller Unit (BCM) in real time via the CAN bus. Severe faults also trigger the instrument panel warning light (such as the headlight malfunction indicator).

[0052] For ease of understanding, the above implementation is described here with a specific example: Multi-source detection: Three data sources are collected simultaneously: 1. The headlight operating current (current value: 1.8A) monitored in real time by the current sensor; 2. The previous cycle current value (1.2A) stored in the chip register; and 3. The boost chip self-test voltage (13.2V), the hardware ADC sampling value (13.1V), and the buck input voltage (13.3V) in the voltage regulation circuit. Comparison revealed a 0.6A error between the two cycles (exceeding the ±0.3A logical range), indicating an anomaly in the current data. The three voltage values, however, all within 0.2V, confirm the reliability of the data. A debounce strategy was implemented: the fault detection interval (FTTI) was set to 15ms, and the abnormal current signal was detected three times within 10ms. The first detection detected a sudden current spike of 2.1A, the second 1.9A, and the third 2.0A. The signal duration exceeded the 5ms threshold, confirming that it was not a transient disturbance and was therefore identified as a valid fault. The system also detected that the ECU's CPU load was currently 60%, indicating that the task scheduling interval met the detection requirements and that no resource usage alarms were triggered. Dynamic threshold calculation: Based on current environmental parameters (outside temperature 35°C, 10°C higher than normal), the current threshold is adjusted using a sliding algorithm. The maximum allowable current is 2.0A at normal temperature, dynamically reduced to 1.8A at high temperatures (due to increased line resistance caused by the temperature increase). The current value of 2.0A exceeded the adjusted threshold, further confirming the fault. Adaptive handling mechanism: The fault type was analyzed as "moderate abnormality" (current fluctuations did not cause the headlights to turn off, but there was a risk of flickering). The corresponding strategy was implemented: the current sampling frequency was increased (from 10ms / time to 5ms / time), the retry interval was extended to 200ms, and three consecutive attempts were made to correct the output current. Post-fault processing and recovery: After three adjustments, the current stabilized at 1.7A (below the 1.8A threshold), and the headlight flickering stopped. The system automatically records the fault DTC (code P1352), including fault time, ambient temperature, and current fluctuation curve, and reports it to the vehicle system. Simultaneously, the software reinitializes the lighting circuit to ensure that there is no further flickering after voltage restoration.

[0053] In the above implementation, multi-source data cross-validation eliminates single sensor false alarms, the dynamic threshold adapts to temperature changes, and the adaptive strategy quickly corrects anomalies, avoiding the risk of headlight failure.

[0054] Example 2 See also Figure 7 , this embodiment provides a structural diagram of a fault diagnosis and processing system for improving system robustness.

[0055] As an example, the system is implemented using the fault diagnosis and processing method for improving system robustness described in Example 1. The system includes: The multi-source detection module 710 is adapted to synchronously collect multi-source sensor data in real time and to analyze and process the multi-source sensor data based on cross-validation to obtain potential fault signals.

[0056] The debounce module 720 is adapted to execute a debounce strategy for performing multiple judgments on the potential fault signal on the basis of satisfying a fault tolerance time interval; to determine whether the duration of the potential fault signal is greater than a preset time threshold; and in response to the duration of the potential fault signal being greater than the preset time threshold, to confirm that the potential fault signal is a valid fault signal and to trigger fault processing.

[0057] The dynamic threshold calculation module 730 is adapted to dynamically calculate the fault diagnosis threshold based on the current operating parameters of the system through a preset environmental compensation model.

[0058] The fault judgment module 740 is adapted to obtain current operating parameter data of the system and compare the data with the fault diagnosis threshold to determine whether a fault exists.

[0059] The adaptive processing module 750 is adapted to dynamically adjust the processing strategy in response to a fault according to the real-time monitored system status and anomaly type.

[0060] The post-fault processing module 760 is adapted to evaluate the processing result, determine whether the processing strategy is effective, and adjust the processing strategy based on the determination result.

[0061] It is not difficult to find that this embodiment is a system embodiment corresponding to the first embodiment, and this embodiment can be implemented in conjunction with the first embodiment. The relevant technical details mentioned in the first embodiment are still valid in this embodiment, and to reduce repetition, they are not repeated here. Accordingly, the relevant technical details mentioned in this embodiment can also be applied to the first embodiment.

[0062] It is worth noting that all modules involved in this embodiment are logical units. In actual applications, a logical unit can be a physical unit, a part of a physical unit, or a combination of multiple physical units. Furthermore, to highlight the innovations of this invention, this embodiment does not include units that are not closely related to solving the technical problems proposed by this invention. However, this does not mean that other units do not exist in this embodiment.

[0063] Example 3 See also Figure 8 An embodiment of the present invention further provides an electronic device, comprising: a memory and a processor; the memory stores at least one program instruction; the processor implements the fault diagnosis and processing method for improving system robustness provided in Example 1 by loading and executing the at least one program instruction.

[0064] The memory 702 and processor 701 are connected using a bus. The bus can include any number of interconnected buses and bridges, connecting various circuits of one or more processors 701 and memory 702. The bus can also connect various other circuits such as peripheral devices, voltage regulators, and power management circuits. These are all well known in the art and, therefore, are not described further herein. The bus interface provides an interface between the bus and the transceiver. The transceiver can be a single component or multiple components, such as multiple receivers and transmitters, providing a unit for communicating with various other devices over a transmission medium. Data processed by the processor 701 is transmitted over a wireless medium via an antenna. Furthermore, the antenna receives data and transmits it to the processor 701.

[0065] The processor 701 is responsible for managing the bus and general processing, and can also provide various functions, including timing, peripheral interfaces, voltage regulation, power management, and other control functions. The memory 702 can be used to store data used by the processor 701 when performing operations.

[0066] Example 4 An embodiment of the present invention further provides a storage medium storing a method for fault diagnosis and treatment for improving system robustness. When executed by a processor, the program for fault diagnosis and treatment for improving system robustness implements the steps of the method for fault diagnosis and treatment for improving system robustness described above. Because this storage medium incorporates all the technical solutions of all the aforementioned embodiments, it possesses at least all the beneficial effects brought about by the technical solutions of the aforementioned embodiments, and therefore will not be further elaborated upon here.

[0067] The above is only an embodiment of the present invention. Common knowledge such as the known specific structures and characteristics in the scheme is not described in detail here. Ordinary technicians in the field are aware of all common technical knowledge in the technical field of the invention before the application date or priority date, can obtain all existing technologies in the field, and have the ability to apply conventional experimental means before that date. Ordinary technicians in the field can improve and implement this scheme in combination with their own abilities under the inspiration given by this application. Some typical known structures or known methods should not become obstacles for ordinary technicians in the field to implement this application. It should be pointed out that for those skilled in the art, without departing from the structure of the present invention, several variations and improvements can be made, which should also be regarded as the scope of protection of the present invention. These will not affect the effect of the implementation of the present invention and the practicality of the patent. The scope of protection required by this application shall be based on the content of its claims, and the specific implementation methods and other records in the specification can be used to interpret the content of the claims.

Claims

1. A fault diagnosis and processing method for improving system robustness, characterized in that: The method comprises: Step S1, real-time synchronous acquisition of multi-source sensor data; Step S2: analyzing and processing the multi-source sensor data based on cross-validation to obtain potential fault signals; Step S3: On the basis of satisfying the fault tolerance time interval, a Debounce strategy is executed for the potential fault signal to perform multiple judgments; Step S4: determining whether the duration of the potential fault signal is greater than a preset time threshold; Step S5: In response to the potential fault signal duration being greater than a preset time threshold, confirming the potential fault signal as a valid fault signal and triggering fault processing; Step S6: Based on the current operating parameters of the system, dynamically calculate the fault diagnosis threshold through a preset environmental compensation model; Step S7: obtaining the current operating parameter data of the system and comparing it with the fault diagnosis threshold to determine whether a fault exists; Step S8: In response to a fault, dynamically adjust the processing strategy based on the real-time monitored system status and abnormality type; Step S9: Evaluate the processing result, determine whether the processing strategy is effective, and adjust the processing strategy based on the determination result.

2. The fault diagnosis and processing method for improving system robustness according to claim 1, characterized in that: The step S2 of analyzing and processing the multi-source sensor data based on cross-validation to obtain a fault signal includes: Step S20: preprocessing the collected multi-source sensor data to eliminate interference and errors in the data transmission link; Step S21: extracting features based on the preprocessed data, including: extracting key features that can reflect the system status from the preprocessed data stream; Step S22: cross-validate and fuse similar or related feature data from different sources to eliminate the limitations of single data; Step S23: Compare the fused feature data with a preset normal feature model to identify whether there are fault features; Step S24: Output the identified fault characteristics in a standardized format in the form of potential fault signals.

3. The fault diagnosis and processing method for improving system robustness according to claim 2, characterized in that: The step S22 of cross-validating and fusing similar or related feature data from different sources to eliminate the limitations of single data includes: Step S220: Compare the value of the previous cycle read from the chip register with the value of the current cycle to obtain a first deviation; Step S221: Compare the input value received by the next-level component with the output value of the current component to obtain a second deviation; Step S222: Compare the first deviation and the second deviation with a preset corresponding deviation threshold; when the comparison result is less than the deviation threshold, fuse the multi-source sensor data.

4. The fault diagnosis and processing method for improving system robustness according to claim 1, characterized in that: The step S4, determining whether the duration of the potential fault signal is greater than a preset time threshold, includes: Step S40: The system times the detected potential fault signal to determine whether its duration exceeds a time threshold pre-set in combination with the fault tolerance time interval.

5. The fault diagnosis and processing method for improving system robustness according to claim 1, characterized in that: The step S6 of dynamically calculating the fault diagnosis threshold using a preset environmental compensation model based on the current operating parameters of the system includes: Step S60: collecting the current operating parameters of the system, including: real-time temperature, input voltage, operating mode and operating time, or a combination thereof; Step S61: Analyze key environmental factors based on the current system status and quantify the impact of these environmental factors; Step S62: Dynamically update the fault judgment threshold according to the quantified result of the impact degree of the environmental factors; Step S63: Apply the adjusted new threshold to the system's fault diagnosis logic, replacing the original fixed threshold as a judgment standard for real-time monitoring; Step S64: After applying the new threshold, the system continues to collect data and performs fault judgment according to the updated fault judgment threshold.

6. The fault diagnosis and processing method for improving system robustness according to claim 5, characterized in that: The key environmental influencing factors include: the influence of temperature on resistance and / or the influence of voltage fluctuation on sensor accuracy.

7. The fault diagnosis and processing method for improving system robustness according to claim 5, characterized in that: The step S62 of dynamically updating the fault judgment threshold according to the quantified result of the degree of influence of the environmental factors includes: Step S620: Update the judgment threshold in real time or periodically using a sliding calculation method; Step S621: select a corresponding judgment threshold through historical data analysis, real-time signal status monitoring or working condition judgment to update the threshold to adapt to the dynamic changes of system electrical parameters and threshold drift caused by component aging.

8. The fault diagnosis and processing method for improving system robustness according to claim 1, characterized in that: The abnormality types include: mild abnormality, moderate abnormality and severe abnormality; The handling strategy for the minor exceptions is to adopt a simple retry mechanism; The handling strategy for the medium exception is to increase the number of retries or extend the retry interval; The handling strategy for the serious anomaly is to trigger an alarm, record a log, and try to switch to a backup channel or controller.

9. The fault diagnosis and processing method for improving system robustness according to claim 8, characterized in that: The step S8, in response to a fault, dynamically adjusting the processing strategy based on the real-time monitored system status and abnormality type, includes: Dynamically adjust the number of retries, retry interval, segment size for data writing, number of batches for bulk writing, and number of parallel channels for input and output control.

10. A fault diagnosis and processing system for improving system robustness, wherein the system is implemented by the fault diagnosis and processing method for improving system robustness according to any one of claims 1 to 9, characterized in that: The system comprises: A multi-source detection module is adapted to synchronously collect multi-source sensor data in real time; and to analyze and process the multi-source sensor data based on cross-validation to obtain potential fault signals; A debounce module is adapted to execute a debounce strategy for the potential fault signal to be judged multiple times based on a fault tolerance time interval; to judge whether the duration of the potential fault signal is greater than a preset time threshold; and in response to the duration of the potential fault signal being greater than the preset time threshold, to confirm that the potential fault signal is a valid fault signal and trigger fault processing; Dynamic threshold calculation module, suitable for dynamically calculating fault diagnosis thresholds based on the current operating parameters of the system through a preset environmental compensation model; A fault judgment module is adapted to obtain current operating parameter data of the system and compare it with the fault diagnosis threshold to determine whether a fault exists; Adaptive processing module, adapted to respond to the presence of a fault and dynamically adjust the processing strategy based on the real-time monitoring of system status and anomaly type; The post-fault processing module is adapted to evaluate the processing result, determine whether the processing strategy is effective, and adjust the processing strategy based on the determination result.

Images