Method for handling system failure and electronic device

Abstract

This invention discloses a method and electronic device for handling system faults. The method includes: monitoring the system to obtain fault events; classifying the fault events according to their attributes; determining the degree of impact of the fault events on system functionality based on their categories to obtain a severity level; and performing fault recovery processing according to a recovery strategy corresponding to the severity level in a predetermined graded recovery strategy. This application provides refined management of fault events by classifying them and offers diverse recovery strategies based on their severity levels, enabling dynamic selection of the optimal solution for fault repair and achieving accurate and efficient automatic repair of embedded system faults.

Description

Technical Field

[0001] This invention relates to the field of embedded systems, and more particularly to methods and electronic devices for handling system faults. Background Technology

[0002] The reliability and availability of automotive embedded systems are crucial for ensuring driving safety and user experience. Currently, such systems commonly employ a global reset mechanism based on a watchdog timer as the primary fault handling method, triggering a complete hardware restart and logging when a system malfunctions. However, this traditional approach has significant drawbacks. First, its "one-size-fits-all" reset strategy fails to differentiate handling based on fault severity (e.g., transient anomalies versus fatal errors), leading to unnecessary service interruptions. Second, the long global reset recovery time severely impacts system availability. Third, the lack of state tracking and management throughout the fault lifecycle hinders problem diagnosis and strategy optimization. Furthermore, the rigid recovery strategy prevents dynamic selection of better solutions such as partial restarts or degraded operation. Finally, insufficient real-time fault detection and response capabilities make it difficult to meet the requirements of high-real-time scenarios. Therefore, existing technologies struggle to accurately and efficiently monitor system faults and cannot enable self-recovery from system failures. Summary of the Invention

[0003] This invention provides a method and electronic device for handling system faults, which can achieve accurate and efficient automatic repair of embedded system faults.

[0004] In one aspect of the present invention, a method for handling system failures is provided. The method includes: monitoring the system to obtain failure events of the system; classifying the failure events into categories based on attributes of the failure events; determining the degree of impact of the failure events on system functionality based on the categories to obtain a severity level of the failure events; and performing failure recovery processing according to a recovery strategy corresponding to the severity level in a predetermined graded recovery strategy.

[0005] In another aspect of the invention, an electronic device is provided. The electronic device includes: a memory configured to store an executable program; and a processor configured to execute the program to perform the aforementioned method for handling system faults.

[0006] According to the technical solution of the present invention, system fault events are obtained by monitoring the system. Fault events are then categorized based on their attributes to achieve refined management. The severity level of each fault event is determined by its category and its impact on system functionality. Differentiated processing is applied based on the severity level, and fault recovery is performed according to a predetermined graded recovery strategy corresponding to the severity level. By providing diverse recovery strategies, dynamic selection of optimal solutions such as partial restarts and degraded operation is achieved to repair faults, enabling efficient and automatic fault repair of embedded systems. Attached Figure Description

[0007] Figure 1 This is a flowchart of a method for handling system faults according to an embodiment of the present invention; Figure 2 This is a flowchart illustrating the fault monitoring process of a method for handling system faults according to an embodiment of the present invention. Figure 3 This is a fault analysis flowchart of a method for handling system faults according to an embodiment of the present invention; Figure 4 This is a fault recovery flowchart of a method for handling system faults according to an embodiment of the present invention; Figure 5 This is a schematic diagram of the structure of an electronic device according to an embodiment of the present invention. Detailed Implementation

[0008] To explain in detail the technical content, objectives, and effects of the present invention, the following description is provided in conjunction with the embodiments and accompanying drawings.

[0009] In related technologies, in-vehicle embedded systems serve as the core carriers of vehicle control, infotainment, and driver assistance functions, and their reliability and availability directly affect driving safety and user experience. Currently, these systems generally employ hardware or software-based watchdog timers combined with global reset mechanisms as the primary fault handling method. Furthermore, fault recording is typically limited to log storage, lacking a systematic fault classification, status tracking, and tiered recovery mechanism. Most systems adopt a uniform fault response strategy, failing to perform differentiated recovery operations for different fault types.

[0010] As the functions of vehicle systems become increasingly complex and the integration level continues to improve, the existing fault handling mechanisms have exposed the following significant defects and limitations: (1) Crude fault handling: The existing solutions lack graded handling of fault severity and use system reset for non-critical faults (such as temperature warnings), resulting in service interruption; (2) Low recovery efficiency: The global reset method has a long recovery time, affecting system availability; (3) Lack of status tracking: It is impossible to record the fault life cycle (occurrence, confirmation, recovery), which is not conducive to problem diagnosis; (4) Lack of flexibility in recovery strategy: It is impossible to dynamically adjust the recovery strategy according to the fault type (such as retry, degraded operation, partial reset, etc.); (5) Insufficient real-time performance: The fault detection cycle is long and cannot meet the high real-time requirements of vehicle systems.

[0011] To address at least the aforementioned technical problems, this disclosure provides a method for system fault status monitoring and self-recovery. According to the technical solution of this disclosure, firstly, when a fault event is received, it is categorized based on its attributes. Secondly, the severity level of the fault event is determined based on its impact on the core functions of the system. Based on the category and severity level of the fault event, a predefined hierarchical recovery strategy is matched and executed. In this manner, according to embodiments of this disclosure, by classifying fault events, refined management of fault events is provided, and diversified recovery strategies are offered based on the severity level of the fault events, enabling dynamic selection of the optimal solution to repair faults, thereby achieving accurate and efficient automatic repair of embedded system faults.

[0012] In the following, the technical solutions according to this disclosure will be described with reference to specific embodiments and in conjunction with the accompanying drawings.

[0013] Figure 1 This is a flowchart illustrating a method 100 for handling system failures according to an embodiment of the present disclosure. (Refer to...) Figure 1 The method 100 includes the following steps 102 to 108.

[0014] In step 102, the system is monitored to obtain fault events of the system.

[0015] In some embodiments, at least one of the following fault detection operations is performed on the system: initialization self-test, core low-frequency polling, time-triggered detection, and external core monitoring, in order to obtain system fault events.

[0016] In step 104, the fault events are classified according to their attributes.

[0017] In some embodiments, the category may include at least one of hardware failure, software failure, communication failure, power failure, environmental failure, system failure, driver failure, performance failure, and algorithm failure.

[0018] In step 106, the severity level of the fault event is obtained by determining the degree of impact of the fault event on the system function based on the category.

[0019] In some embodiments, the severity levels, from mild to severe, may include information level, warning level, error level, critical level, and fatal level.

[0020] In some embodiments, the information level indicates no functional impact, the warning level indicates minor functional impact, the error level indicates functional malfunction, the severity level indicates service interruption, and the fatal level indicates system crash.

[0021] In step 108, fault recovery processing is performed according to the recovery strategy corresponding to the severity level in the predetermined graded recovery strategy.

[0022] In some embodiments, the tiered recovery strategy may include performing recovery operations such as logging and generating diagnostic reports, logging warning status and initiating module-level or system-level degradation optimization operations, performing partial recovery operations, performing single-core reset operations, and performing system-level recovery operations.

[0023] In some embodiments, the method 100 may further include: receiving a recovery instruction sent through an external communication interface; parsing the recovery instruction and matching the corresponding target recovery function interface; and calling the target recovery function interface to perform fault recovery processing corresponding to the recovery instruction.

[0024] According to embodiments of this disclosure, by using partial recovery instead of global reset, system recovery time is shortened and fault recovery efficiency is improved. Basic functions are maintained under non-fatal faults, reducing the number of service interruptions, minimizing the impact, and enhancing system availability. Diagnostic efficiency is improved by fully recording the fault lifecycle (occurrence time, processing procedure, and recovery status). Unnecessary reset operations are reduced through differentiated processing strategies, optimizing resource consumption. Furthermore, by supporting runtime external calls to fault monitoring and processing functions, dynamic updates to recovery strategies, and multi-point dynamic recovery, flexibility is improved.

[0025] Figure 2 This is a fault monitoring flowchart illustrating a method for handling system faults according to an embodiment of the present disclosure. (Refer to...) Figure 2 In some embodiments, at least one of the following fault detection operations is performed on the system: initialization self-test, core low-frequency polling, time-triggered detection, and external core monitoring, in order to obtain system fault events.

[0026] For example, the chip's internal temperature sensor values ​​are read multiple times at preset time intervals to achieve chip temperature cycle detection. Chip memory cycle detection is achieved by monitoring heap memory fragmentation rate and detecting memory pool leaks. Furthermore, interactive core communication monitoring is achieved through inter-core communication mechanisms, such as shared memory mailboxes, that periodically (e.g., every 50ms) send heartbeat packets and confirm response timeouts.

[0027] In this way, initial self-test ensures the initial health of the system, low-frequency polling provides continuous monitoring of the system (such as resource leaks and temperature accumulation), event-triggered detection can instantly capture anomalies (such as hardware failures) with the fastest response, and external core monitoring solves the problem that a single core cannot report faults on its own. Through initial self-test, low-frequency core polling, time-triggered detection, and external core monitoring, the system's fault events are accurately and comprehensively obtained, greatly reducing the fault missed rate and providing timely and reliable fault event input data for the entire self-recovery system.

[0028] In some embodiments, the system initialization self-test includes: performing software module initialization self-tests, driver module initialization self-tests, communication module initialization self-tests, algorithm module initialization self-tests, and hardware status self-tests. Fault events triggered by the software module initialization self-test are classified as software faults. Fault events triggered by the driver module initialization self-test are classified as driver faults. Fault events triggered by the communication module initialization self-test are classified as communication faults. Fault events triggered by the algorithm module initialization self-test are classified as algorithm faults. Furthermore, fault events triggered by the hardware status self-test are classified as hardware faults.

[0029] For example, if the "sound effect configuration file" version loaded during audio service manager initialization is incompatible, this fault event is classified as a software fault. The system can then attempt to load an alternative configuration file or the default configuration, avoiding unnecessary hardware resets. For purely software configuration issues, "reset-free recovery" is implemented, ensuring system startup speed and availability. If the audio interface driver fails to read the codec chip during initialization, and the driver continuously reads back bus errors, clearly indicating a physical layer problem (such as a chip not being powered on, loose soldering, or a bus short circuit), this fault event is classified as a hardware fault. The system can then decide to adopt a degraded startup strategy (such as disabling the audio output and enabling mono mode). Through precise classification, the system may only require a degraded function rather than a global reset, improving fault recovery efficiency.

[0030] In this way, by performing an initial self-check on the system, the initial health of the system is ensured. Multiple dimensions, including software, drivers, communication, algorithms, and hardware, are detected and categorized to generate initialization fault records with clear category labels and generate detailed fault reports, providing a basis for selecting subsequent fault recovery strategies.

[0031] In some embodiments, the core low-frequency polling of the system includes: performing chip temperature cycle detection, chip power supply cycle detection, chip performance cycle detection, and chip memory cycle detection on the system; classifying fault events triggered by the chip temperature cycle detection as environmental faults; classifying fault events triggered by the chip power supply cycle detection as power supply faults; and classifying fault events triggered by the chip performance cycle detection and the chip memory cycle detection as performance faults.

[0032] For example, during summer sun exposure, the interior temperature of a vehicle is high, causing the chip to heat up too quickly. A temperature rise from 85 degrees Celsius to 98 degrees Celsius is detected within a 100ms cycle. This clearly environmentally-related fault event is categorized as an environmental fault. Subsequent optimization measures such as proactive frequency reduction and shutting down non-core circuits can be implemented. For overheating, "optimized cooling" is used instead of "brutal reset," eliminating risk while ensuring the continuity of core services, perfectly embodying the principle of "minimal intervention." At the moment of vehicle startup, the core voltage drops to 0.85V (below the threshold of 0.9V). This fault event from the vehicle's power supply system is categorized as a power failure. Emergency state saving and preparation for safe shutdown can be implemented. The 100ms-level rapid polling can promptly capture power transient drops and, by categorizing them as power failures, enable the system to take the most appropriate voltage protection action, preventing data corruption or hardware damage caused by power supply issues.

[0033] In this way, by continuously monitoring the system through low-frequency polling, early warnings and interventions can be triggered in advance by abnormal indicators such as resources, temperature, and voltage before the system fails completely. This allows for the triggering of completely different and most suitable system adjustment strategies for different physical indicator anomalies (environment / power supply / performance).

[0034] In some embodiments, the time-triggered detection of the system includes: detecting hardware abnormal interrupts, clock abnormal interrupts, and communication abnormal interrupts; classifying the fault events triggered by the hardware abnormal interrupt detection as hardware faults; classifying the fault events triggered by the clock abnormal interrupt detection as environmental faults; and classifying the fault events triggered by the communication abnormal interrupt detection as communication faults. For example, when a car audio system is playing music, if the system suddenly emits a piercing noise and then goes silent, a data bus error hardware interrupt of the chip is immediately triggered. Upon inspection, it is found that the audio DMA (Direct Memory Access) controller attempted to read data from a freed memory address, triggering a hardware protection mechanism. The fault event of illegal hardware access is classified as a hardware fault, and the problematic DMA transfer can be immediately suspended to prevent the erroneous access from spreading. In this way, by performing time-triggered detection on the system, abnormalities can be captured instantaneously, allowing for rapid response and execution of recovery strategies.

[0035] In some embodiments, the external core monitoring of the system includes: monitoring the interactive core communication and the interactive core status of the system; classifying fault events triggered by the interactive core communication monitoring as communication faults; and classifying fault events triggered by the interactive core status monitoring as performance faults. For example, if the DSP (Digital Signal Processor) core no longer responds to the heartbeat packets of the ARM (Advanced RISC Machines) core, and the detection indicates a continuous heartbeat timeout on the ARM core side, it is determined to be a problem with the inter-core communication link. The fault event of the communication link problem is classified as a communication fault. The system may first attempt to restore the communication link; if this fails, it will escalate the judgment to a core freeze. In this way, by performing external core monitoring of the system, the problem of a single core failing to self-diagnose and report is solved.

[0036] Figure 3 This is a fault analysis flowchart illustrating a method for handling system faults according to an embodiment of the present disclosure. (Refer to...) Figure 3 The fault events are classified into hardware faults, software faults, communication faults, power supply faults, environmental faults, system faults, driver faults, performance faults, or algorithm faults.

[0037] The system runs continuously. When the fault management module receives a fault event, it first parses the event's attribute information. This attribute information includes at least the fault trigger source identifier, error code, location of occurrence (e.g., core number, module name), and a description of the phenomenon. Based on the fault event's attributes, it is categorized into a predefined fault category. For example, a communication timeout is categorized as a "communication fault"; memory shortage is categorized as a "performance fault"; and an out-of-limit reading from the chip temperature sensor is categorized as an "environmental fault." Each fault event belongs to only one category.

[0038] In this way, by analyzing and categorizing the attributes of fault events, a foundation is laid for matching subsequent fault recovery strategies. For example, for a fault event of "hardware failure + severity level," the matching recovery strategy is: single-core reset and hardware controller reinitialization; for a fault event of "communication failure + error level," the matching recovery strategy is: partial retry and communication protocol stack reset; for a fault event of "environmental failure + warning level," the matching recovery strategy is: frequency reduction operation and active heat dissipation control. Furthermore, by classifying fault events, a unified dimension is provided for the collection, analysis, and mining of fault data when generating subsequent fault reports. For example, by statistically analyzing the frequency of each type of fault within a period (e.g., a high proportion of communication faults), weak links in the system can be identified; by analyzing the temporal correlation of different types of faults (e.g., power failures are often followed by communication failures), hidden systemic design flaws can be discovered; and by using the trend changes of specific types of fault rates for early warning (e.g., environmental fault rates increase with rising temperature), data support is provided for preventative maintenance.

[0039] According to embodiments of this disclosure, the severity level of a fault event is determined by classifying it according to the degree of impact on system functionality. In some embodiments, if the fault event has no functional impact on the core system functionality, its severity level is determined to be informational; if the fault event has a minor functional impact, its severity level is determined to be warning; if the fault event causes system malfunction, its severity level is determined to be error; if the fault event causes system service interruption, its severity level is determined to be critical; and if the fault event causes system crash, its severity level is determined to be fatal. A detailed fault report is generated based on the fault event's category, including a description of the fault event's symptoms. The severity level of the fault event is then determined based on the symptom description.

[0040] For example, fault event A is described as occasional data fluctuations in non-critical sensors (within the tolerance range), while the system functions completely normally. In this case, fault event A is classified as information level. Fault event B is described as a temporary failure of the sampling rate fine-tuning algorithm for a non-primary audio channel due to unstable input. The system automatically switches to a backup simplified algorithm, and the main channel audio playback is unaffected. The function is temporarily undamaged, but the trend needs to be recorded. In this case, fault event B is classified as warning level. Fault event C is described as an unexpected exit of the protocol stack process responsible for Bluetooth audio connections, causing Bluetooth music playback to be interrupted. However, the system can still play USB or radio audio normally, but some functions are limited. In this case, fault event C is classified as error level. Fault event D is described as a fatal error in the DRMA (Dynamic Random Access Memory), the core responsible for main audio mixing and output, causing all audio outputs to be muted. The core function is damaged, and single-core operation is severely affected. In this case, fault event D is classified as critical level. The symptoms of fault event E are described as follows: an uncorrectable error occurs in the system memory management unit, the consistency of critical data areas between multiple cores is compromised, or a watchdog global reset is about to be triggered, resulting in loss of system function and possible system crash. In this case, fault event E is classified as fatal.

[0041] In this way, fault events are handled in a tiered manner, achieving optimal resource allocation: minor problems are addressed with in-depth recovery without wasting computing resources, while serious problems are dealt with decisively with strong intervention measures, thereby ensuring the overall availability and reliability of the system.

[0042] According to embodiments of this disclosure, fault recovery processing is performed based on a recovery strategy corresponding to the severity level in a predetermined graded recovery strategy. This approach avoids a crude, one-size-fits-all reset strategy, enabling the adoption of the most suitable initial processing measures for faults of different natures. This allows for a "minimal intervention" approach at the first moment of a fault occurrence, significantly improving the accuracy of initial fault handling and fault recovery efficiency. Furthermore, the differentiated strategy avoids unnecessary global resets, optimizes resource consumption, and ensures system security under severe faults.

[0043] In some embodiments, when the severity level is informational, a recovery operation is performed to log and generate a diagnostic report. For example, when the fault severity level is informational, the corresponding function is called to write the structured information of the fault event (timestamp, fault category, severity level, phenomenon description) to a log file, and a diagnostic report is generated for external tools to read. In this way, for informational fault events, only logging operations are performed, so that minor problems are handled without wasting resources.

[0044] In some embodiments, when the severity level is warning, the warning status is recorded and module-level or system-level degradation optimization operations are initiated. For example, after the system has been running for a long time, due to application-layer memory leaks or fragmentation accumulation, the memory monitoring thread detects that the available contiguous blocks of heap memory are less than the safety threshold (e.g., 1MB). Core functions are not affected temporarily, but new memory allocation may fail. At this time, the fault event is classified as a performance fault and the level is determined to be warning. The handling process for warning-level fault events is as follows: record the memory pool status, fragmentation index, and information on modules that have recently failed to allocate memory; perform system-level degradation: actively clear the decoder's PCM (Pulse-Code Modulation) data cache and pre-read buffer; swap the temporary data of the background speech recognition model from DRAM (Dynamic Random Access Memory) to the compressed buffer; limit the frequency of new memory requests for non-critical modules (such as sound effect generators) or return simulation success (using a static backup buffer); through active memory reclamation and allocation limits, delay the occurrence of memory exhaustion and avoid sudden system crashes due to insufficient memory. In this way, by setting the recovery strategy for warning-level fault events to a "optimization over reset" processing mode, proactive intervention is made before the fault causes functional loss, preventing deterioration, significantly reducing unnecessary resets, reducing the scope of fault impact, achieving degradation, and improving user experience.

[0045] In some embodiments, when the severity level is error level, a partial recovery operation is performed. This partial recovery operation includes restoring the thread of the local module where the abnormal event occurred, configuring the driver hardware, restarting the algorithm, and resetting the application layer. For example, if the audio decoder thread is unresponsive, audio playback is interrupted, but other audio sources such as radios play normally, and the core functions of the system are partially restricted, this fault event is classified as a software fault, and the severity level is determined to be error level. The handling process for error-level fault events is as follows: First, an attempt is made to send a wake-up signal to the thread (up to 3 times). If this fails, a partial reset is performed: the decoder thread is safely terminated, all resources it occupies are released, and then the decoder instance is reinitialized and started according to the configuration. This process employs an application shielding mechanism to prevent the module from being accessed incorrectly again before the reset is complete. In this way, the impact of the fault is limited to the smallest functional unit, and targeted recovery operations are performed on specific fault root causes to ensure the normal operation of other parts of the system.

[0046] In some embodiments, when the severity level is critical, a single-core reset operation is performed. This single-core reset operation includes isolating and suspending the target core's operation, saving the target core's running state, resetting the target core, and reloading the target core's services. For example, a fault event might be a deadlock in the coprocessor core (DSP, Digital Signal Processor), resulting in impaired core audio processing functions, failure of all audio paths requiring DSP processing, and a severe degradation in system performance. This fault event is classified as a system fault, and its severity level is determined to be critical. The handling process for a critical fault event is as follows: First, the core is notified to enter a safe pause state via an inter-core interrupt, and its access to external critical buses is cut off. Second, the critical running state of the DSP core is extracted to a shared safe memory area using a debug access port or a pre-implanted state saving routine. Then, the core is hardware-reset via the system control unit. Furthermore, the master core guides the reset core to reload firmware, initialize, and synchronize necessary running state data. Throughout the reset process, an event log is recorded. In this way, serious system-level faults can be located and brought to a single core unit for processing, and physical isolation can be used to prevent faults in a single core (such as deadlock or memory trampling) from affecting other cores.

[0047] In some embodiments, when the severity level is critical, a system-level recovery operation is performed. This system-level recovery includes saving a system state snapshot, safely shutting down the system, and performing a system soft reset. Performing a system soft reset involves triggering a software reset pin or command on the chip, causing the entire chip to restart and reload the application. For example, if a system suddenly "freezes" and becomes unresponsive while playing car music, with the screen unresponsive, all buttons malfunctioning, and music playback stopping, this fault event is classified as a system fault with a critical severity level. The handling process for a critical fault event is as follows: First, within a controllable and extremely short time, critical registers and stack trace information that may have caused the fault are written to a dedicated area, such as saving the fault time, last played song, volume settings, and fault codes. Second, all peripherals are stopped in an orderly manner, the cache is refreshed, and unnecessary modules are powered down. Then, a system soft reset is performed. In this way, for critical faults that cause a complete system crash, a global recovery strategy is implemented. The fault snapshot provides effective diagnostic information for the analysis of complex and intermittent faults, a safe system shutdown can clear potentially accumulated complex state errors and memory pollution, and a soft reset can quickly restore the file system and critical services.

[0048] In some embodiments, after executing a predefined graded recovery strategy, the process further includes: verifying the status of the fault event; if the fault event has been recovered, updating the status of the fault event to recovered; if the fault event has not been recovered, escalating the severity level of the fault event, and performing fault recovery processing according to the recovery strategy corresponding to the escalated severity level in the predetermined graded recovery strategy, until the fault event has been recovered or the recovery strategy corresponding to the fatal level has been completed. For warning-level faults, after executing the warning-level processing procedure, if the fault has not been recovered, the fault level is escalated and an error-level processing procedure is executed. After the error-level processing procedure, if the fault has not been recovered, the fault level is escalated and a severity-level processing procedure is executed. After the severity-level processing procedure, if the fault has not been recovered, the fault level is escalated and a fatal-level processing procedure is executed. In this way, the core principle of fault recovery is "minimal intervention and step-by-step escalation". That is, the recovery measures with the least impact are given priority. If the verification is ineffective, a higher-level recovery action is automatically triggered until the fault is eliminated. After each recovery operation, the fault status is automatically verified. If the fault is not recovered, the processing strategy is upgraded, forming a closed-loop control flow of "detection-processing-verification-upgrade processing-re-verification", thereby maximizing system availability while ensuring reliability.

[0049] In some embodiments, a recovery command sent through an external communication interface is received; the recovery command is parsed, and a corresponding target recovery function interface is matched; the target recovery function interface is called to execute the fault recovery processing corresponding to the recovery command. External chips send recovery commands through communication interfaces such as SPI (Serial Peripheral Interface), UART (Universal Asynchronous Receiver / Transmitter), and CAN (Controller Area Network). Recovery commands include local parameter reset, controller reset, module reset, single-core reset, and system soft reset. After parsing the command, the fault processing center automatically matches the recovery strategy, automatically jumps to the preset recovery function interface, and executes the corresponding dynamic recovery operation. After the recovery operation is executed, the system immediately performs status verification to ensure that the fault has been effectively eliminated and feeds back the status result to the fault processing center in real time to form a complete closed-loop control loop. In this way, by supporting runtime external calls to fault monitoring and processing functions, the recovery strategy can be dynamically updated (upgrading or downgrading issues), improving the real-time performance and reliability of the system's self-recovery.

[0050] In some embodiments, if the system soft reset fails after a preset number of attempts, a full system reset is performed. If the full system reset fails to resolve the fault, a chip hardware replacement operation is performed. A full system reset involves erasing the current software system stored in memory and reloading the officially released software system into memory. When executing the fatal "system soft reset" strategy, an internal counter records the number of soft resets. If the fault persists after multiple soft resets (e.g., 3 times), the system will perform a full system reset. A full reset erases the current software system stored in memory and reloads the officially released software system into memory. If the fault persists after a full system reset (e.g., the system still cannot boot normally), a permanent hardware defect is identified. In this case, the system triggers a final recovery instruction: a chip hardware replacement operation is performed. In this way, by performing a full reset operation after a soft reset failure, and then performing a chip hardware replacement operation after a full reset failure, the system ensures that even in the most extreme and unrepairable hardware failure scenarios, there is a clear and controllable fault handling process. This provides the ultimate guarantee for the reliability of the entire fault handling solution and enables automatic diagnosis of whether the problem is a software configuration issue or a physical hardware failure.

[0051] Figure 4 This is a fault recovery flowchart illustrating a method for handling system faults according to an embodiment of the present invention. (Refer to...) Figure 4 For warning-level faults, the core of the system strategy is optimization rather than reset. Resources are reallocated by initiating module-level or system-level degradation optimizations, and continuous monitoring begins after recording the warning status. If monitoring finds that the fault has been recovered through fault checking, the process ends; otherwise, the fault level is escalated and the process jumps to the error-level handling procedure.

[0052] In the error-level handling process, the core strategy shifts to performing partial recovery, which involves resetting or reinitializing specific faulty modules, threads, or drivers. During this operation, a shielding mechanism is applied to prevent reset loops, followed by isolation and monitoring of the local module. Similarly, continuous fault checks determine the success of the partial recovery; if successful, the process ends; otherwise, it escalates back to the critical level.

[0053] Critical fault handling targets deeper system problems, and its core strategy involves performing a high-level single-core reset. This operation comprises a rigorous sequence: from isolating the target core, saving its state, and suspending operation, to having other cores log events and perform a hardware reset, and finally reloading the service and synchronizing the state. After the reset is complete, the system re-enters a continuous monitoring and fault checking phase. If the fault persists, it is ultimately escalated to the highest level, critical.

[0054] Furthermore, lethal recovery is the last resort for system restoration, and its strategy involves performing a comprehensive system-level recovery. This process first attempts to save a snapshot of the system state, then performs a safe shutdown and initiates a soft reset. After the system restarts, its operational status is continuously monitored. If a system-level soft reset fails to resolve the issue, the process moves to the final hardware recovery solution, which involves physical replacement operations such as replacing hardware chips to fundamentally restore system functionality.

[0055] In this way, the principle of "minimum intervention and step-by-step escalation" is adopted. Local recovery replaces global reset, which shortens the system recovery time, improves the efficiency of fault recovery, maintains basic function operation under non-fatal faults, reduces the number of service interruptions, reduces the scope of impact, enhances system availability, and reduces unnecessary reset operations by differentiated processing strategies, thereby reducing resource consumption during the fault recovery process.

[0056] According to another aspect of the invention, Figure 5 This is a schematic diagram illustrating the structure of an electronic device 400 according to an embodiment of the present invention. (Refer to...) Figure 5 The electronic device 400 includes a plurality of physical display modules 402, a memory 404, and a processor 406. The physical display modules 402 are electrically coupled to the processor 406 and configured to recover from faults. The memory 404 is configured to store information associated with fault events and executable programs. The processor 406 is electrically coupled to the memory 404 and configured to execute the programs to perform the steps of the method for handling system faults described above.

[0057] In summary, the fault detection provided by this invention, which involves initialization self-test, core low-frequency polling, time-triggered detection, and external core monitoring, accurately and comprehensively acquires system fault events, greatly reducing the fault missed rate and providing timely and reliable fault event input data for the entire self-recovery system.

[0058] By classifying and handling fault events, optimal resource allocation is achieved: minor problems are addressed with in-depth recovery without wasting computing resources, while serious problems are addressed with decisive and strong intervention measures, thereby ensuring the overall availability and reliability of the system.

[0059] By matching corresponding recovery strategies to different categories and levels of fault events, the "one-size-fits-all" approach to brute-force reset strategies is avoided. The most suitable initial handling measures can be taken for faults of different natures, thereby using a "minimum intervention" approach at the first moment of a fault occurrence. This significantly improves the accuracy of initial fault handling and fault recovery efficiency. Furthermore, the differentiated strategy avoids unnecessary global resets, optimizes resource consumption, and ensures system security under severe faults.

[0060] By adopting the core principle of "minimum intervention and step-by-step escalation" for fault recovery, priority is given to recovery measures with the least impact. If the verification is ineffective, a higher-level recovery action is automatically triggered until the fault is eliminated. After each recovery operation, the fault status is automatically verified. If the fault is not recovered, the processing strategy is upgraded, forming a closed-loop control flow of "detection-processing-verification-upgrade processing-re-verification", thereby maximizing system availability while ensuring reliability.

[0061] By supporting runtime external calls to fault monitoring and handling functions, the system can dynamically update recovery strategies (upgrade or downgrade problem handling), thereby improving the real-time performance, reliability, and flexibility of system self-recovery.

[0062] Furthermore, by performing a full reset operation after a soft reset failure, and then replacing the chip hardware after a full reset failure, the system ensures that even in the most extreme and unrepairable hardware failure scenarios, there is a clear and controllable fault handling process. This provides the ultimate guarantee for the reliability of the entire fault handling solution and enables automatic diagnosis of whether the problem is a software configuration issue or physical hardware damage.

[0063] The above description is merely an embodiment of the present invention and does not limit the patent scope of the present invention. Any equivalent modifications made based on the content of the present invention's specification and drawings, or direct or indirect applications in related technical fields, are similarly included within the patent protection scope of the present invention.

Claims

1. A method for handling system faults, characterized in that, include: Monitor the system to obtain fault events of the system; The fault events are categorized based on their attributes; The severity level of a fault event is determined by assessing its impact on system functionality based on the category. as well as Fault recovery processing is performed according to the recovery strategy corresponding to the severity level in the predetermined graded recovery strategy.

2. The method according to claim 1, characterized in that, Monitoring the system to detect system failure events includes: The system is subjected to at least one of the following fault detection operations: initialization self-test, core low-frequency polling, time-triggered detection, and external core monitoring, in order to obtain system fault events.

3. The method according to claim 2, characterized in that, The initialization self-test of the system includes: The system performs software module initialization self-test, driver module initialization self-test, communication module initialization self-test, algorithm module initialization self-test, and hardware status self-test. The core low-frequency polling of the system includes: performing chip temperature cycle detection, chip power supply cycle detection, chip performance cycle detection, and chip memory cycle detection. The time-triggered detection of the system includes: hardware abnormal interruption detection, clock abnormal interruption detection, and communication abnormal interruption detection. External core monitoring of the system includes: monitoring the interactive core communication and monitoring the interactive core status of the system.

4. The method according to claim 3, characterized in that, The categories of fault events based on their attributes include: The fault events triggered by the initialization self-test of the software module are classified as software faults. The fault events triggered by the driver module initialization self-test are classified as driver faults. The fault events triggered by the initialization self-test of the communication module are classified as communication faults. The fault events triggered by the algorithm module's initialization self-test are categorized as algorithm faults; and The fault events triggered by the hardware status self-test are classified as hardware faults.

5. The method according to claim 3, characterized in that, The categories of fault events based on their attributes include: The fault events triggered by the chip's temperature cycle detection are classified as environmental faults; The fault events triggered by the chip's power supply cycle detection are classified as power supply faults; and The fault events triggered by the chip performance cycle detection and the chip memory cycle detection are classified as performance faults.

6. The method according to claim 3, characterized in that, Classifying the fault events based on their attributes also includes: The fault events triggered by the aforementioned hardware abnormal interrupt detection are classified as hardware faults. The fault events triggered by the aforementioned clock abnormality interrupt detection are classified as environmental faults; and The fault events triggered by the abnormal communication interruption detection are classified as communication faults.

7. The method according to claim 3, characterized in that, Classifying the fault events based on their attributes also includes: The fault events triggered by the core communication monitoring are classified as communication faults; and The fault events triggered by the core interactive status monitoring are classified as performance faults.

8. The method according to claim 1, characterized in that, Determining the severity level of a fault event by classifying its impact on system functionality includes: If the fault event has no functional impact on the system, the severity level of the fault event is determined to be information level. If the impact of the fault event on the system function is a minor functional impact, the severity level of the fault event will be determined as a warning level; If the impact of the fault event on the system function is such that it causes abnormal system function, the severity level of the fault event is determined to be error level; If the impact of the fault event on system functionality is such that it causes system service interruption, the severity level of the fault event is determined to be severe; and If the failure event affects the system function to the point of causing system crash, the severity level of the failure event is determined to be fatal.

9. The method according to claim 1, characterized in that, Performing fault recovery processing according to the recovery strategy corresponding to the severity level in the predetermined graded recovery strategy includes: When the severity level is informational, perform a recovery operation that logs the data and generates a diagnostic report. When the severity level is a warning level, the warning status is recorded and a module-level or system-level degradation optimization operation is initiated. When the severity level is error level, a partial recovery operation is performed, which includes restoring the threads of the local module where the abnormal event occurred, configuring the driver hardware, restarting the algorithm, and resetting the application layer. When the severity level is critical, a single-core reset operation is performed. This single-core reset operation includes isolating and pausing the target core's operation, saving the target core's running state, resetting the target core, and reloading the target core services. When the severity level is critical, a system-level recovery operation is performed, which includes saving a snapshot of the system state, safely shutting down the system, and performing a soft reset of the system.

10. The method according to claim 1, characterized in that, After performing fault recovery processing, the following is also included: Verify the status of the fault event; if the fault event has been resolved, update the status of the fault event to "resolved"; and If the fault event is not recovered, the severity level of the fault event is escalated, and fault recovery processing is performed according to the recovery strategy corresponding to the escalated severity level in the predetermined graded recovery strategy, until the fault event is recovered or the recovery strategy corresponding to the fatal level is completed.

11. The method according to claim 1, characterized in that, Also includes: Receive recovery commands sent through an external communication interface; Parse the recovery command and match the corresponding target recovery function interface; as well as The target recovery function interface is invoked to perform fault recovery processing corresponding to the recovery instruction.

12. The method according to claim 9, characterized in that, Also includes: If the system soft reset fails after a preset number of attempts, a full system reset is performed. as well as If the system full reset operation fails to resolve the fault event, then a chip hardware replacement operation is performed.

13. The method according to claim 9, characterized in that, Performing a system soft reset includes: Triggering the chip's software reset pin or a command will restart the entire chip and reload the application.

14. The method according to claim 12, characterized in that, Performing a full system reset includes: Erase the current software system stored in memory and reload the officially released software system into memory.

15. An electronic device, characterized in that, include: The memory is configured to store executable programs; as well as A processor is configured to execute the program to implement the method according to any one of claims 1 to 14.

Images