A detection processing method for hibernation exception of an automotive domain controller

Abstract

The application provides a kind of detection processing method of car domain controller hibernation exception, it is related to car electronic control technical field.The method comprises: in response to hibernation trigger instruction, the flow of system level chip enters low-power hibernation state is started;When detecting hibernation failure, the target resource and target module causing failure are identified by hibernation wake-up management process;Perform hierarchical recovery operation, and at least twice resource release notification of different priority is successively initiated to target module;If target resource is not released after hierarchical recovery operation, then send assistance request to external micro control unit by external communication module, and hardware level recovery operation is performed by external micro control unit.The application can effectively solve the problem of car domain controller hibernation exception by the multi-level processing mechanism of software hierarchical recovery combined with hardware forced intervention, avoid battery feed, and improve the reliability and safety of the system.

Description

Technical Field

[0001] This invention relates to the field of automotive electronic control technology, and in particular to a method for detecting and handling abnormal sleep patterns in automotive domain controllers. Background Technology

[0002] Currently, when an automotive domain controller enters a STR (Suspend-To-RAM) state, the process typically involves coordinated operations between upper-layer application software and lower-layer hardware drivers. The standard STR process requires all upper-layer applications to sequentially release system resources such as device locks and file handles they occupy, after which the lower-layer driver can successfully power down and enter a low-power state. However, in practical applications, this process faces the following pressing technical challenges:

[0003] The root cause of hibernation failure is difficult to pinpoint: When a domain controller fails to enter the target state after initiating hibernation, the system often only reports "hibernation failed," without being able to accurately determine which application(s), service(s), or driver(s) failed to release resources correctly. This "black box" state makes it difficult for both developers and the system itself to perform effective diagnosis and repair.

[0004] Abnormal deadlocks can cause system "hang-ups" and battery drain risks: If a critical lock fails to release due to software bugs, process anomalies, resource deadlocks, or other reasons, the domain controller will remain in a high-power "pseudo-sleep" state. After the vehicle is turned off and parked, this state will continuously consume the vehicle's battery power, potentially causing the vehicle to fail to start in the short term ("depleted battery"), and severely damaging battery life in the long term, posing significant safety hazards and user experience issues.

[0005] Insufficient system self-recovery capability: When faced with hibernation failure, existing solutions lack an automated, progressively escalating recovery mechanism. They typically rely on manual intervention (such as rebooting) or simple timeout resets, failing to intelligently attempt to unlock resource lockouts. Furthermore, even after the final recovery measure (such as a forced reboot) takes effect, there is a lack of retrying the hibernation process, which may lead to problem recurrence.

[0006] The fault handling mechanism is simplistic and crude: Existing technologies may directly take the highest level of reset or power-off measures after detecting hibernation failure. Although this "one-size-fits-all" approach can solve the risk of power failure, it will interrupt all services, may cause data loss, and does not give the system a chance to "self-repair", thus reducing the robustness and reliability of the system. Summary of the Invention

[0007] In view of the technical defects and drawbacks existing in the prior art, the present invention provides a method for detecting and processing abnormal sleep mode of automotive domain controllers to overcome the above problems or at least partially solve the above problems. The specific solution is as follows:

[0008] As a first aspect of the present invention, a method for detecting and handling abnormal sleep patterns in an automotive domain controller is provided, the method comprising the following steps:

[0009] In response to a sleep trigger command, the system-on-a-chip of the domain controller is controlled to start a process that enters a low-power sleep state;

[0010] After the hibernation process is started, if it is detected that the domain controller fails to enter the low-power hibernation state, the hibernation wake-up management process identifies the target resource that caused the hibernation failure and the target module holding the target resource.

[0011] The hibernation / wake-up management process performs a tiered recovery operation, which includes sequentially initiating at least two resource release notifications of different priorities to the target module.

[0012] If the target resource is still not released after the tiered recovery operation is completed, an assistance request is sent to the external microcontroller unit via the external communication module, and the external microcontroller unit performs a hardware-level recovery operation on the system-on-a-chip.

[0013] In some embodiments, the failure of the domain controller to successfully enter a low-power sleep state is detected through one or more of the following methods:

[0014] Method 1: After responding to the hibernation trigger command, start a first preset timer to keep track. If no confirmation signal indicating that the low-power hibernation state has been successfully entered is received from the system chip before the first preset timer expires, the hibernation is determined to have failed.

[0015] Method 2: If the system-on-a-chip is abnormally woken up during the process of entering the low-power sleep state, and it is determined by querying the wake-up source register that the wake-up source does not belong to the preset set of legal wake-up sources, then the sleep failure is determined.

[0016] In some embodiments, identifying the target resource and target module that caused the hibernation failure specifically includes:

[0017] The resource status monitoring module of the hibernation and wake-up management process actively scans the system kernel status after determining that hibernation has failed in order to obtain resource status information related to the hibernation process. The resource status information includes one or more of the following: the holding status of the device lock, the open status of the file handle, the active status of the network connection, the occupancy status of the direct memory access channel, and the enabled status of the interrupt request line.

[0018] Based on the resource status information, specific resources that remain occupied or active after the system initiates a hibernation process, thereby preventing the system from entering a low-power hibernation state, are identified as the target resources; and further, applications or driver modules that hold or manage the target resources are identified as the target modules.

[0019] In some embodiments, the tiered recovery operation specifically includes a progressively escalating recovery strategy, which includes the following steps:

[0020] Level 1 recovery: Send a first priority release request signal to the target module and start a first waiting timer; if the target resource is detected to have been released before the first waiting timer expires, the hierarchical recovery operation ends; otherwise, proceed to Level 2 recovery.

[0021] Level 2 recovery: Send a second priority forced release signal to the target module, the second priority forced release signal having a higher priority than the first priority release request signal; start a second waiting timer, the duration of the second waiting timer being less than or equal to the duration of the first waiting timer; if the target resource is detected to have been released before the second waiting timer expires, the hierarchical recovery operation ends; otherwise, proceed to Level 3 recovery;

[0022] Level 3 recovery: Send a final release request signal to the target module and record a critical error event in the system log; if the target resource is still not released after sending the final release request signal, the leveled recovery operation is deemed to have failed.

[0023] In some embodiments, at least two of the first priority release request signal, the second priority forced release signal, and the final release request signal are sent through different communication mechanisms to reflect their priority differences; wherein, the communication mechanisms include, but are not limited to: operating system signals, simulated system calls, writing to a specific file system node, and inter-process communication bus messages.

[0024] In some embodiments, the hardware-level recovery operation is specifically a hard reboot operation, which includes the following steps:

[0025] Delay step: After receiving the assistance request from the external communication module, the external microcontroller starts a delay timer and waits for a fourth preset time;

[0026] Hard reboot execution steps: After the delay timer expires, the external microcontroller performs a hard reboot on the system-on-a-chip using any of the following methods:

[0027] Method 1: Control the reset pin of the system-on-a-chip to generate a reset signal;

[0028] Method 2: Control the power management chip connected to the system-on-a-chip to cut off and then reconnect the power supply to the system-on-a-chip.

[0029] In some embodiments, after the hard reboot operation is completed, a secondary hibernation trigger is further included, specifically including:

[0030] Startup status detection: The external microcontroller unit continuously monitors the startup status of the system-on-a-chip until it detects that the core functions of the system-on-a-chip have been successfully started.

[0031] Sleep signal trigger: After the core function is detected to have started, the external microcontroller unit waits for a fifth preset time and then sends a sleep trigger signal to the system-on-a-chip to trigger a new sleep process.

[0032] In some embodiments, the method further includes an ultimate protection step, which includes:

[0033] Counter maintenance: The external microcontroller maintains a sleep failure counter and starts a time window timer;

[0034] Counter accumulation condition: When the external microcontroller receives another assistance request from the sleep-wake management process after the second sleep triggering step, it is determined as a new sleep failure, and the value of the sleep failure counter is incremented by 1;

[0035] Ultimate protection trigger: If the value of the hibernation failure counter reaches or exceeds a preset threshold before the timer in the time window expires, the external microcontroller unit performs an ultimate protection operation, which is to cut off the power supply to the system-on-a-chip.

[0036] In some embodiments, the external microcontroller unit also executes an independent watchdog monitoring mechanism, the watchdog monitoring mechanism including:

[0037] Watchdog activation: Upon detecting a vehicle engine shutdown event, the external microcontroller activates a watchdog timer and anticipates receiving periodic heartbeat signals from the system-on-a-chip.

[0038] Watchdog maintenance: If the heartbeat signal is received before the watchdog timer expires, the external microcontroller unit resets the watchdog timer and continues to wait;

[0039] Watchdog timeout handling: If the watchdog timer times out, and neither a "successful hibernation" signal nor a "help request" signal is received from the hibernation / wake-up management process during this period, the external microcontroller unit autonomously determines that the system-on-a-chip has malfunctioned and actively performs any of the following operations:

[0040] Operation 1: Initiate the hardware-level recovery operation;

[0041] Operation 2: Initiate the ultimate protection operation.

[0042] In some embodiments, the method further includes a state recording step:

[0043] At at least one key node in the initiation of the hibernation process, the triggering of the hibernation failure detection, the sending of each notification of the hierarchical recovery operation, the execution of the hardware-level recovery operation, and the triggering of the ultimate protection operation, the corresponding event type, timestamp, and resource status information are recorded in non-volatile memory.

[0044] The present invention has the following beneficial effects:

[0045] This invention constructs a multi-layered, intelligent self-recovery system, greatly enhancing the system's robustness and reliability. The solution is designed with a tiered recovery process, from "gentle notification" to "forced restart" and finally to "ultimate power outage." This soft-to-hard approach provides the system with ample opportunity for self-repair, avoiding unnecessary restarts due to temporary faults, while also enabling decisive and effective measures to be taken in the face of serious faults, ensuring that the system remains in a controllable and safe state under any abnormal circumstances. Attached Figure Description

[0046] Figure 1 A flowchart illustrating a method for detecting and handling abnormal sleep patterns in an automotive domain controller, provided in an embodiment of the present invention.

[0047] Figure 2 This is a flowchart illustrating the process of identifying the target resources and target modules that cause hibernation failure, as provided in an embodiment of the present invention.

[0048] Figure 3 A flowchart illustrating the recovery strategy provided in an embodiment of the present invention;

[0049] Figure 4 This is a structural block diagram of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0050] To enable those skilled in the art to better understand the technical solutions of the present invention, exemplary embodiments of the present invention are described below in conjunction with the accompanying drawings, including various details of the embodiments of the present invention to aid understanding. These should be considered merely exemplary. Therefore, those skilled in the art should recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of the present invention. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0051] Where there is no conflict, the various embodiments of the present invention and the features thereof may be combined with each other.

[0052] As used herein, the term “and / or” includes any and all combinations of one or more related enumerated entries.

[0053] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the invention. As used herein, the singular forms “a” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will also be understood that when the terms “comprising” and / or “made of” are used in this specification, the presence of the stated feature, integral, step, operation, element, and / or component is specified, but the presence or addition of one or more other features, integrals, steps, operations, elements, components, and / or groups thereof is not excluded. Terms such as “connected” or “linked” are not limited to physical or mechanical connections but can include electrical connections, whether direct or indirect.

[0054] Unless otherwise specified, all terms used herein (including technical and scientific terms) have the same meaning as commonly understood by one of ordinary skill in the art. It will also be understood that terms such as those defined in commonly used dictionaries should be interpreted as having the meaning consistent with their meaning in the context of the relevant art and the invention, and will not be interpreted as having an idealized or overly formal meaning unless expressly so defined herein.

[0055] In the technical solution of this invention, the collection, storage, use, processing, transmission, provision, and disclosure of user personal information all comply with relevant laws and regulations and do not violate public order and good morals. The use of user data in this technical solution follows relevant national laws and regulations (e.g., the "Information Security Technology - Personal Information Security Specification"). For example: appropriate measures are taken for personal information access control; restrictions are imposed on the display of personal information; the purpose of using personal information does not exceed the scope of direct or reasonable association; and explicit identity targeting is eliminated when using personal information to avoid precisely locating a specific individual.

[0056] To address at least one of the technical problems existing in the aforementioned related technologies, the present invention provides a method for detecting and handling abnormal sleep patterns in automotive domain controllers. Figure 1 This is a flowchart illustrating a method for detecting and handling abnormal sleep patterns in an automotive domain controller, as provided in an embodiment of the present invention. The method includes the following steps:

[0057] Step S100: In response to the sleep trigger command, control the system-on-a-chip of the domain controller to start the process of entering a low-power sleep state;

[0058] Step S200: After the hibernation process is started, if it is detected that the domain controller fails to enter the low-power hibernation state, the hibernation wake-up management process identifies the target resource that caused the hibernation failure and the target module holding the target resource.

[0059] Step S300: The hibernation wake-up management process performs a tiered recovery operation, which includes sequentially initiating at least two resource release notifications of different priorities to the target module;

[0060] Step S400: If the target resource is still not released after the hierarchical recovery operation is completed, an assistance request is sent to the external microcontroller unit through the external communication module, and the external microcontroller unit performs a hardware-level recovery operation on the system-on-a-chip.

[0061] This invention establishes an intelligent self-recovery system that upgrades step-by-step from software to hardware. The solution first provides the system with ample opportunity for self-repair, attempting to resolve temporary, minor logical errors through gentle software notifications, avoiding unnecessary restarts. When software recovery fails, a separate hardware unit executes mandatory measures, ensuring effective power cut-off even under the most severe software failures. This completely eliminates the risk of battery drain due to hibernation failures. This method significantly enhances the system's robustness and reliability, minimizing service interruptions and data loss while ensuring safety.

[0062] In some embodiments, the step S200 "detecting that the domain controller failed to enter a low-power sleep state" is implemented through any one or more of the following methods:

[0063] Method 1: After responding to the hibernation trigger command, start a first preset timer to keep track. If no confirmation signal indicating that the low-power hibernation state has been successfully entered is received from the system chip before the first preset timer expires, the hibernation is determined to have failed.

[0064] Method 2: If the system-on-a-chip is abnormally woken up during the process of entering the low-power sleep state, and it is determined by querying the wake-up source register that the wake-up source does not belong to the preset set of legal wake-up sources, then the sleep failure is determined.

[0065] The above embodiments significantly improve the accuracy and comprehensiveness of fault detection by clearly defining two specific hibernation failure scenarios: "timeout without entry" and "abnormal wake-up." Specifically, "timeout without entry" detection can effectively capture faults such as system process freezes or slow responses; while "abnormal wake-up" detection can identify unexpected exits caused by illegal interruptions or signal interference, covering more potential abnormal scenarios. This multi-dimensional detection mechanism provides accurate and reliable triggering basis for subsequent root cause analysis and recovery operations, and is the prerequisite and foundation for the correct initiation of the entire fault handling process.

[0066] refer to Figure 2 As shown, in some embodiments, step S200, "identifying the target resource and target module that caused the hibernation failure," specifically includes:

[0067] S201. The resource status monitoring module of the hibernation wake-up management process actively scans the system kernel status after determining that hibernation has failed in order to obtain resource status information related to the hibernation process; wherein, the resource status information includes one or more of the following: the holding status of the device lock, the open status of the file handle, the active status of the network connection, the occupancy status of the direct memory access channel, and the enabled status of the interrupt request line.

[0068] S202. Based on the resource status information, identify specific resources that remain occupied or active after the system initiates a hibernation process, thereby preventing the system from entering a low-power hibernation state, and determine them as the target resources; further associate and find the application or driver module that holds or manages the target resource, and determine it as the target module.

[0069] The above embodiments, by refining the scope of resource status monitoring and the method of root cause localization, transform the hibernation failure problem from a "black box" to a "white box," achieving precise localization of the root cause of hibernation failure and greatly improving the maintainability and debuggability of the system. Specifically, by actively scanning key resources such as device locks, file handles, DMA channels, and interrupt states, the "culprit" hindering hibernation and its responsible module can be quickly and accurately identified. This enables developers to quickly locate problematic code and shorten the debugging cycle; in production or after-sales stages, it also provides clear direction for fault diagnosis, significantly reducing maintenance costs and time, and solving the core pain point of traditional solutions that "only know that it failed, but don't know why it failed."

[0070] refer toFigure 3 As shown, in some embodiments, the "tiered recovery operation" in step S300 specifically includes a tiered recovery strategy, which includes the following steps:

[0071] Level 1 recovery: Send a first priority release request signal to the target module and start a first waiting timer; if the target resource is detected to have been released before the first waiting timer expires, the hierarchical recovery operation ends; otherwise, proceed to Level 2 recovery.

[0072] Level 2 recovery: Send a second priority forced release signal to the target module, the second priority forced release signal having a higher priority than the first priority release request signal; start a second waiting timer, the duration of the second waiting timer being less than or equal to the duration of the first waiting timer; if the target resource is detected to have been released before the second waiting timer expires, the hierarchical recovery operation ends; otherwise, proceed to Level 3 recovery;

[0073] Level 3 recovery: Send a final release request signal to the target module and record a critical error event in the system log; if the target resource is still not released after sending the final release request signal, the leveled recovery operation is deemed to have failed.

[0074] In the above embodiments, by designing a "tiered recovery execution step" that includes multiple notifications and progressive escalation, an intelligent and gradual software-level recovery strategy is provided. This improves the system's ability to autonomously resolve hibernation anomalies and avoids triggering violent forced restarts due to temporary or sporadic failures (such as process response delays or minor timing races). This progressive handling, from mild requests to mandatory warnings, gives applications the opportunity to self-correct, demonstrating the system's "fault tolerance" capability. Only when soft recovery methods are completely ineffective is higher-level hardware intervention initiated, thereby minimizing unnecessary service interruptions while ensuring ultimate reliability, thus guaranteeing user experience and data continuity.

[0075] In some embodiments, at least two of the first priority release request signal, the second priority forced release signal, and the final release request signal are sent through different communication mechanisms to reflect their priority differences; wherein, the communication mechanisms include, but are not limited to: operating system signals, simulated system calls, writing to a specific file system node, and inter-process communication bus messages.

[0076] The above embodiments provide concrete technical support for the concept of "priority" by limiting notifications of different priorities to use different communication mechanisms, ensuring that the hierarchical recovery strategy can be executed reliably and effectively. By utilizing the differences in timeliness and enforceability of different communication mechanisms such as operating system signals, system calls, and file node operations, the distinction of notification priorities can be substantially achieved. For example, high-priority notifications can be sent through lower-level, more difficult-to-ignore mechanisms, thereby ensuring that the target module can be effectively reached when needed.

[0077] In some embodiments, the "hardware-level recovery operation" in step S400 is specifically a hard reboot operation, which includes the following steps:

[0078] Delay step: After receiving the assistance request from the external communication module, the external microcontroller starts a delay timer and waits for a fourth preset time;

[0079] Hard reboot execution steps: After the delay timer expires, the external microcontroller performs a hard reboot on the system-on-a-chip using any of the following methods:

[0080] Method 1: Control the reset pin of the system-on-a-chip to generate a reset signal;

[0081] Method 2: Control the power management chip connected to the system-on-a-chip to cut off and then reconnect the power supply to the system-on-a-chip.

[0082] The above embodiments provide a safe and reliable hardware-level recovery method by specifically defining a "delay step" before performing a "hard reboot," achieving a forced reset of the system-on-a-chip (SoC). This effectively solves the most severe faults where the software is completely locked up and unable to respond to any soft recovery commands. Specifically, a brief delay is introduced before performing the hard reboot, providing the system with a final stabilization time, ensuring the preservation of critical logs and other information, and preventing accidental triggering when signals are unstable. By directly controlling the reset pin or power management chip, this operation bypasses the crashed software system, completely clearing the abnormal state at the hardware level, providing the system with a "clean" boot environment, which is a key guarantee for ensuring the system can recover from deep faults.

[0083] In some embodiments, after the hard reboot operation is completed, a secondary hibernation trigger is further included, specifically including:

[0084] Startup status detection: The external microcontroller unit continuously monitors the startup status of the system-on-a-chip until it detects that the core functions of the system-on-a-chip have been successfully started.

[0085] Sleep signal trigger: After the core function is detected to have started, the external microcontroller unit waits for a fifth preset time and then sends a sleep trigger signal to the system-on-a-chip to trigger a new sleep process.

[0086] The above embodiment improves the intelligence and success rate of the entire solution by adding a "secondary hibernation trigger," which immediately attempts to re-enter hibernation after a hard reboot. This proactively corrects hibernation failures caused by the increasing complexity of the application environment and the accumulation of abnormal resource states after long-term system operation. Specifically, a hard reboot clears all abnormal software states, and immediately triggering a secondary hibernation is equivalent to re-executing the hibernation process in a "clean" initial state, avoiding the specific application scenarios that previously caused the failure. This significantly reduces the risk of hibernation failures due to occasional and environmentally dependent issues, and prevents the system from remaining in a high-power state after a restart following a vehicle shutdown, further improving the reliability of the solution and the user experience.

[0087] In some embodiments, the method further includes an ultimate protection step, which includes:

[0088] Counter maintenance: The external microcontroller maintains a sleep failure counter and starts a time window timer;

[0089] Counter accumulation condition: When the external microcontroller receives another assistance request from the sleep-wake management process after the second sleep triggering step, it is determined as a new sleep failure, and the value of the sleep failure counter is incremented by 1;

[0090] Ultimate protection trigger: If the value of the hibernation failure counter reaches or exceeds a preset threshold before the timer in the time window expires, the external microcontroller unit performs an ultimate protection operation, which is to cut off the power supply to the system-on-a-chip.

[0091] The above embodiments establish a final safety barrier by introducing a "hibernation failure counter" and a "time window" as the ultimate protection step. This effectively prevents the system from falling into a vicious cycle of "restart-failure-restart" when encountering persistent and recurring serious faults, thus completely eliminating the risk of battery depletion. Specifically, this mechanism intelligently judges the number of consecutive hibernation failures within a short period of time, and only triggers the final forced power-off operation when the fault is indeed persistent and stubborn. This design avoids accidental power-off due to a single, occasional fault, and at the same time, it can decisively take the most thorough measures in the worst case, providing the ultimate safety guarantee for protecting battery life and ensuring vehicle startability.

[0092] In some embodiments, the external microcontroller unit also executes an independent watchdog monitoring mechanism, the watchdog monitoring mechanism including:

[0093] Watchdog activation: Upon detecting a vehicle engine shutdown event, the external microcontroller activates a watchdog timer and anticipates receiving periodic heartbeat signals from the system-on-a-chip.

[0094] Watchdog maintenance: If the heartbeat signal is received before the watchdog timer expires, the external microcontroller unit resets the watchdog timer and continues to wait;

[0095] Watchdog timeout handling: If the watchdog timer times out, and neither a "successful hibernation" signal nor a "help request" signal is received from the hibernation / wake-up management process during this period, the external microcontroller unit autonomously determines that the system-on-a-chip has malfunctioned and actively performs any of the following operations:

[0096] Operation 1: Initiate the hardware-level recovery operation;

[0097] Operation 2: Initiate the ultimate protection operation.

[0098] In the above embodiments, a redundant "double-insurance" system is created. Even if the SoC-side software completely crashes (including the sleep / wake-up management process itself), recovery can be triggered through a hardware-level watchdog mechanism. When the SoC "freezes" due to extreme failure and is unable to send any signals (including assistance requests) according to the normal process, the MCU's independent watchdog can autonomously detect the anomaly and actively intervene after a timeout. This compensates for the blind spots of pure software monitoring mechanisms, providing the system with the highest level of robustness and security.

[0099] In some embodiments, the method further includes a state recording step:

[0100] At at least one key node in the initiation of the hibernation process, the triggering of the hibernation failure detection, the sending of each notification of the hierarchical recovery operation, the execution of the hardware-level recovery operation, and the triggering of the ultimate protection operation, the corresponding event type, timestamp, and resource status information are recorded in non-volatile memory.

[0101] In the above embodiments, the "status recording step" throughout the entire process provides a solid data foundation for system maintainability and continuous optimization. Specifically, by recording events, timestamps, and resource status at key nodes, technicians can accurately reconstruct the system state at the time of a failure, quickly pinpoint the root cause, and greatly improve efficiency, whether for debugging during the development phase or troubleshooting after-sales issues. This detailed log data is a valuable asset for optimizing hibernation strategies and improving system stability, significantly reducing system maintenance costs.

[0102] Based on the same inventive concept, embodiments of the present invention also provide an electronic device. Figure 4 This is a structural block diagram of an electronic device provided in an embodiment of the present invention. Figure 4 As shown, an embodiment of the present invention provides an electronic device including: one or more processors 101, a memory 102, and one or more I / O interfaces 103. The memory 102 stores one or more programs, which, when executed by the one or more processors, enable the one or more processors to implement a detection and processing method for an abnormal sleep state of a vehicle domain controller as described in any of the above embodiments; the one or more I / O interfaces 103 are connected between the processor and the memory, configured to enable information interaction between the processor and the memory.

[0103] The processor 101 is a device with data processing capabilities, including but not limited to a central processing unit (CPU); the memory 102 is a device with data storage capabilities, including but not limited to random access memory (RAM, more specifically SDRAM, DDR, etc.), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), and flash memory (FLASH); the I / O interface (read / write interface) 103 is connected between the processor 101 and the memory 102, and can realize information interaction between the processor 101 and the memory 102, including but not limited to a data bus (Bus).

[0104] In some embodiments, the processor 101, memory 102, and I / O interface 103 are interconnected via bus 104, and thus connected to other components of the computing device.

[0105] In some embodiments, the one or more processors 101 include a field-programmable gate array.

[0106] This invention also provides a computer-readable medium. The computer-readable medium stores a computer program, which, when executed by a processor, implements the detection and handling method for an abnormal sleep state of any of the automotive domain controllers described in the above embodiments. The computer-readable storage medium can be volatile or non-volatile.

[0107] This invention also provides a computer program product, including computer-readable code, or a non-volatile computer-readable storage medium carrying computer-readable code. When the computer-readable code is run in the processor of an electronic device, the processor in the electronic device executes any of the above-described methods for detecting and handling automotive domain controller hibernation anomalies.

[0108] Those skilled in the art will understand that all or some of the steps, systems, and apparatuses disclosed above, and their functional modules / units, can be implemented as software, firmware, hardware, or suitable combinations thereof. In hardware implementations, the division between functional modules / units mentioned above does not necessarily correspond to the division of physical components; for example, a physical component may have multiple functions, or a function or step may be performed collaboratively by several physical components. Some or all physical components may be implemented as software executed by a processor, such as a central processing unit, digital signal processor, or microprocessor, or as hardware, or as an integrated circuit, such as an application-specific integrated circuit (ASIC). Such software can be distributed on a computer-readable storage medium, which may include computer storage media (or non-transitory media) and communication media (or transient media).

[0109] As is known to those skilled in the art, the term computer storage medium includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information, such as computer-readable program instructions, data structures, program modules, or other data. Computer storage media includes, but is not limited to, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), static random access memory (SRAM), flash memory or other memory technologies, portable compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical disc storage, magnetic cartridges, magnetic tape, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and is accessible to a computer. Furthermore, it is known to those skilled in the art that communication media typically contain computer-readable program instructions, data structures, program modules, or other data in modulated data signals such as carrier waves or other transmission mechanisms, and may include any information delivery medium.

[0110] The computer-readable program instructions described herein can be downloaded from computer-readable storage media to various computing / processing devices, or downloaded via a network, such as the Internet, local area network, wide area network, and / or wireless network, to an external computer or external storage device. The network may include copper transmission cables, fiber optic transmission, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards them to the computer-readable storage media in the respective computing / processing device.

[0111] The computer program instructions used to perform the operations of this invention may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk, C++, etc., and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The computer-readable program instructions may be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving a remote computer, the remote computer may be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or may be connected to an external computer (e.g., via the Internet using an Internet service provider). In some embodiments, electronic circuitry, such as programmable logic circuitry, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), is personalized by utilizing state information from the computer-readable program instructions. This electronic circuitry can execute the computer-readable program instructions to implement various aspects of the invention.

[0112] The computer program product described herein can be implemented specifically through hardware, software, or a combination thereof. In one alternative embodiment, the computer program product is specifically embodied in a computer storage medium; in another alternative embodiment, the computer program product is specifically embodied in a software product, such as a software development kit (SDK), etc.

[0113] Various aspects of the present invention are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.

[0114] These computer-readable program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that, when executed by the processor of the computer or other programmable data processing apparatus, they create means for implementing the functions / actions specified in one or more blocks of the flowchart and / or block diagram. These computer-readable program instructions can also be stored in a computer-readable storage medium that causes a computer, programmable data processing apparatus, and / or other device to operate in a particular manner; thus, the computer-readable medium storing the instructions comprises an article of manufacture that includes instructions for implementing aspects of the functions / actions specified in one or more blocks of the flowchart and / or block diagram.

[0115] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable data processing apparatus, or other device to produce a computer-implemented process, thereby causing the instructions executed on the computer, other programmable data processing apparatus, or other device to perform the functions / actions specified in one or more boxes of a flowchart and / or block diagram.

[0116] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of an instruction, which contains one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions marked in the blocks may occur in a different order than those shown in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0117] Example embodiments have been disclosed herein, and while specific terminology has been used, it is for illustrative purposes only and should be construed as such, and is not intended to be limiting. In some instances, it will be apparent to those skilled in the art that features, characteristics, and / or elements described in conjunction with particular embodiments may be used alone, or in combination with features, characteristics, and / or elements described in conjunction with other embodiments, unless otherwise expressly indicated. Therefore, those skilled in the art will understand that various changes in form and detail may be made without departing from the scope of the invention as set forth in the appended claims.

Claims

1. A method for detecting and handling abnormal sleep states of an automotive domain controller, characterized in that, The method includes the following steps: In response to a sleep trigger command, the system-on-a-chip of the domain controller is controlled to start a process that enters a low-power sleep state; After the hibernation process is started, if it is detected that the domain controller fails to enter the low-power hibernation state, the hibernation wake-up management process identifies the target resource that caused the hibernation failure and the target module holding the target resource. The hibernation / wake-up management process performs a tiered recovery operation, which includes sequentially initiating at least two resource release notifications of different priorities to the target module. If the target resource is still not released after the tiered recovery operation is completed, an assistance request is sent to the external microcontroller unit via the external communication module, and the external microcontroller unit performs a hardware-level recovery operation on the system-on-a-chip.

2. The method according to claim 1, characterized in that, The domain controller was detected to have failed to enter a low-power sleep state, achieved through one or more of the following methods: Method 1: After responding to the hibernation trigger command, start a first preset timer to keep track. If no confirmation signal indicating that the low-power hibernation state has been successfully entered is received from the system chip before the first preset timer expires, the hibernation is determined to have failed. Method 2: If the system-on-a-chip is abnormally woken up during the process of entering the low-power sleep state, and it is determined by querying the wake-up source register that the wake-up source does not belong to the preset set of legal wake-up sources, then the sleep failure is determined.

3. The method according to claim 1, characterized in that, Identify the target resources and modules that caused the hibernation failure, specifically including: The resource status monitoring module of the hibernation and wake-up management process actively scans the system kernel status after determining that hibernation has failed in order to obtain resource status information related to the hibernation process. The resource status information includes one or more of the following: the holding status of the device lock, the open status of the file handle, the active status of the network connection, the occupancy status of the direct memory access channel, and the enabled status of the interrupt request line. Based on the resource status information, specific resources that remain occupied or active after the system initiates a hibernation process, thereby preventing the system from entering a low-power hibernation state, are identified as the target resources; and further, applications or driver modules that hold or manage the target resources are identified as the target modules.

4. The method according to claim 1, characterized in that, The tiered recovery operation specifically includes a progressively escalating recovery strategy, which comprises the following steps: Level 1 recovery: Send a first priority release request signal to the target module and start a first waiting timer; if the target resource is detected to have been released before the first waiting timer expires, the hierarchical recovery operation ends; otherwise, proceed to Level 2 recovery. Level 2 recovery: Send a second priority forced release signal to the target module, the second priority forced release signal having a higher priority than the first priority release request signal; start a second waiting timer, the duration of the second waiting timer being less than or equal to the duration of the first waiting timer; if the target resource is detected to have been released before the second waiting timer expires, the hierarchical recovery operation ends; otherwise, proceed to Level 3 recovery; Level 3 recovery: Send a final release request signal to the target module and record a critical error event in the system log; if the target resource is still not released after sending the final release request signal, the leveled recovery operation is deemed to have failed.

5. The method according to claim 4, characterized in that, At least two of the first priority release request signal, the second priority forced release signal, and the final release request signal are sent through different communication mechanisms to reflect their priority differences; wherein, the communication mechanisms include, but are not limited to: operating system signals, simulated system calls, writing to a specific file system node, and inter-process communication bus messages.

6. The method according to claim 1, characterized in that, Hardware-level recovery is specifically a hard reboot, which includes the following steps: Delay step: After receiving the assistance request from the external communication module, the external microcontroller starts a delay timer and waits for a fourth preset time; Hard reboot execution steps: After the delay timer expires, the external microcontroller performs a hard reboot on the system-on-a-chip using any of the following methods: Method 1: Control the reset pin of the system-on-a-chip to generate a reset signal; Method 2: Control the power management chip connected to the system-on-a-chip to cut off and then reconnect the power supply to the system-on-a-chip.

7. The method according to claim 6, characterized in that, After the hard reboot operation is completed, a secondary hibernation trigger is also included, specifically including: Startup status detection: The external microcontroller unit continuously monitors the startup status of the system-on-a-chip until it detects that the core functions of the system-on-a-chip have been successfully started. Sleep signal trigger: After the core function is detected to have started, the external microcontroller unit waits for a fifth preset time and then sends a sleep trigger signal to the system-on-a-chip to trigger a new sleep process.

8. The method according to claim 7, characterized in that, The method further includes a final protection step, which includes: Counter maintenance: The external microcontroller maintains a sleep failure counter and starts a time window timer; Counter accumulation condition: When the external microcontroller receives another assistance request from the sleep-wake management process after the second sleep triggering step, it is determined as a new sleep failure, and the value of the sleep failure counter is incremented by 1; Ultimate protection trigger: If the value of the hibernation failure counter reaches or exceeds a preset threshold before the timer in the time window expires, the external microcontroller unit performs an ultimate protection operation, which is to cut off the power supply to the system-on-a-chip.

9. The method according to claim 8, characterized in that, The external microcontroller unit also executes an independent watchdog monitoring mechanism, which includes: Watchdog activation: Upon detecting a vehicle engine shutdown event, the external microcontroller activates a watchdog timer and anticipates receiving periodic heartbeat signals from the system-on-a-chip. Watchdog maintenance: If the heartbeat signal is received before the watchdog timer expires, the external microcontroller unit resets the watchdog timer and continues to wait; Watchdog timeout handling: If the watchdog timer times out, and neither a "successful hibernation" signal nor a "help request" signal is received from the hibernation / wake-up management process during this period, the external microcontroller unit autonomously determines that the system-on-a-chip has malfunctioned and actively performs any of the following operations: Operation 1: Initiate the hardware-level recovery operation; Operation 2: Initiate the ultimate protection operation.

10. The method according to any one of claims 1 to 9, characterized in that, The method also includes a status recording step: At at least one key node in the initiation of the hibernation process, the triggering of the hibernation failure detection, the sending of each notification of the hierarchical recovery operation, the execution of the hardware-level recovery operation, and the triggering of the ultimate protection operation, the corresponding event type, timestamp, and resource status information are recorded in non-volatile memory.

Images