Domain controller power down control method, device, medium, and product

Abstract

The application relates to the technical field of vehicle control, in particular to a domain controller power-off control method, equipment, medium and product. When preset power-off trigger conditions are met, the method initiates a power-off request from a power management unit to a system management unit, and the power-off request is sequentially issued to an application unit by different state management modules in the system management unit. After the application unit and the system management unit complete the exit operation, the state information is fed back to the power management unit according to the predetermined link, and the power-off control is executed according to the feedback result. Thus, a closed-loop state transmission mechanism among the application, the system and the power supply is constructed, orderly exit of the domain controller and power-off decision according to the state are realized, controllability, reliability and abnormal scene adaptability of the power-off process are improved, and risks such as data loss, resource unreleased, controller unable to normally power on or function unable to activate and the like are reduced.

Description

Technical Field

[0001] This application relates to the field of vehicle control technology, and in particular to a domain controller power-down control method, device, medium, and product. Background Technology

[0002] In modern automotive electrical and electronic architectures, the domain controller serves as the core carrier of vehicle intelligence functions, undertaking the task of centralized management and control of multiple functional modules. The power-down control of the automotive domain controller is typically triggered by the power management unit based on vehicle status signals, and works in conjunction with system software to shut down the relevant functional modules.

[0003] However, existing solutions are mostly led by the power management unit to shut down the power, with insufficient coordination and status interaction between modules. The application layer often has difficulty in completing data saving and resource release before power failure, which can easily cause the power-down timing to be out of control, and the subsequent controller may not be able to power on normally or its functions may not be activated. Summary of the Invention

[0004] This application provides a domain controller power-down control method, device, medium, and product to solve the aforementioned technical problems. This solution coordinates the exit process of the system management unit and application unit after power-down is triggered, and controls the power-down process based on the execution status of each stage, thereby ensuring orderly exit, controllable status under abnormal scenarios, and overall power-down reliability during the domain controller power-down process.

[0005] In a first aspect, embodiments of this application provide a domain controller power-down control method, the method comprising:

[0006] When the preset power-down trigger condition is determined to be met, the control power management unit sends a power-down request to the system management unit. The system management unit includes a first state management module and a second state management module.

[0007] The first state management module sends an exit command to the second state management module based on the power-down request, so that the second state management module sends the exit command to the application unit;

[0008] In response to the determination that the power management unit has received status feedback information, the control domain controller is powered down based on the status feedback information. The status feedback information includes information that the application unit and the system management unit transmit to the power management unit in sequence after executing the exit operation based on the exit command.

[0009] In one possible embodiment, sending a power-down request includes:

[0010] The control power management unit sends a power-down request to the first status management module. The power-down request includes an instruction consisting of a power-down identifier and a power-down status code. The power-down identifier indicates the purpose of the instruction, and the power-down status code indicates the initiator of the request.

[0011] In one possible embodiment, it also includes:

[0012] The control application unit executes a preset exit process based on the exit command, and sends an exit status confirmation message to the second status management module after the execution is completed. The preset exit process includes data saving, peripheral communication interface closing, and resource release.

[0013] In one possible embodiment, it also includes:

[0014] After receiving the exit status confirmation information, the second status management module controls the second status management module to switch the running status to the post-running status and sends the first status switch confirmation information to the first status management module.

[0015] In one possible embodiment, it also includes:

[0016] After receiving the first state switching confirmation information, the control first state management module switches the running state to the post-running state and sends status feedback information to the power management unit. The status feedback information includes an instruction consisting of a running state identifier name and a running state code.

[0017] In one possible embodiment, after the control power management unit sends a power-down request to the system management unit, the system further includes:

[0018] Start the timer for the first preset duration;

[0019] If the power management unit does not receive status feedback information within the first preset time period, it will directly control the domain controller to power down.

[0020] In one possible embodiment, it also includes:

[0021] Obtain preset load status indicators from the system management unit, including at least one of processor utilization and memory usage.

[0022] The first preset duration is adjusted based on the preset load status.

[0023] In one possible embodiment, determining that a preset power-down trigger condition is met includes:

[0024] The power management unit monitors the sustain source signal and the new wake-up source signal.

[0025] If all sustain source signals are detected to be invalid and no new wake-up source signal is detected, then the preset power-down trigger condition is determined to be met.

[0026] In one possible embodiment, monitoring the sustaining source signal via the power management unit includes:

[0027] The control power management unit acquires sustain source signals through multiple preset sensors;

[0028] The validity of the acquired sustaining source signal is verified using preset state transition rules.

[0029] In one possible embodiment, it also includes:

[0030] Obtain the preset power-down strategy mapping table;

[0031] Based on the type of failure sustaining source signal, the target power-down process is determined from the preset power-down strategy mapping table.

[0032] In one possible embodiment, it also includes:

[0033] The control system management unit periodically sends heartbeat requests to the application unit;

[0034] If no response information is received from the application unit within the second preset time period, the control system management unit executes the forced exit process and sends the abnormal information to the power management unit.

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

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

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

[0038] Thirdly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the methods provided above.

[0039] Fourthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the method provided above.

[0040] The domain controller power-down control method, device, medium, and product provided in this application embodiment enable the application unit and the system management unit to execute the exit operation in an orderly manner according to the power-down process by having the power management unit initiate a power-down request when preset power-down trigger conditions are met, and having the first and second state management modules in the system management unit transmit exit instructions to the application unit step by step. By receiving the state feedback information sequentially transmitted by the application unit and the system management unit after executing the exit operation based on the exit instruction, and then controlling the domain controller to power down based on the state feedback information, it is possible to realize state confirmation and process constraints before power-down, thereby improving the reliability, security, and adaptability of the domain controller power-down in complex scenarios. Attached Figure Description

[0041] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0042] Figure 1 An application scenario diagram for a domain controller power-down control method provided in this application;

[0043] Figure 2 This is a flowchart illustrating a domain controller power-down control method provided in an embodiment of this application;

[0044] Figure 3 A schematic flowchart of a domain controller power-down control method provided in another embodiment of this application;

[0045] Figure 4 This is a schematic diagram of the structure of a domain controller power-down control device provided in an embodiment of this application;

[0046] Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0047] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0048] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0049] It should be noted that in the embodiments of this application, certain software, components, models and other existing solutions in the industry may be mentioned. These should be regarded as exemplary and are only intended to illustrate the feasibility of implementing the technical solution of this application. However, it does not mean that the applicant has used or necessarily used the solution.

[0050] To clearly understand the technical solution of this application, the solutions of the prior art will be described in detail first.

[0051] In the evolution of modern automotive electronic and electrical architecture towards domain-centralized architecture, domain controllers have become the core hardware carriers for vehicle intelligence and connectivity. They integrate the functions of various traditional independent electronic controllers, centrally managing and controlling all software and hardware functional modules of the vehicle. Power start-up, shutdown, and function switching under all operating conditions—driving, parking, and hibernation—are all uniformly scheduled by the domain controller. Therefore, stable and orderly power-down control logic is crucial to ensuring the reliable operation of the entire vehicle's electronic systems. Currently, mainstream domain controller power-down schemes generally rely on the power management unit (PMU) to independently lead the power-down process, lacking standardized collaborative interaction mechanisms and complete status feedback links between modules. After issuing a power-down command, the PMU cannot monitor the real-time operating status of system software and application modules, making it difficult to determine whether the application layer has completed its final tasks. This results in some applications being forcibly disconnected from power before completing critical data storage, communication interface closure, and hardware resource release operations. This not only easily leads to data loss, program anomalies, and peripheral damage but also causes power-down sequence chaos.

[0052] Therefore, to address the technical issues in existing technologies and unify the process entry point, the power management unit directly collects signals such as vehicle wake-up sources. It independently determines whether preset power-down trigger conditions are met. Once the conditions are met, a unified power-down request is sent out, standardizing the power-down startup logic from the source and avoiding disordered power-down triggering. After receiving the power-down request, the first state management module sends an exit command to the second state management module, which then transmits the exit command to the application unit, achieving an orderly power-down process through this layer-by-layer transmission. To address the problem in existing solutions where the application layer's operating status is unknown, leading to unsaved data and unreleased resources before power-down, the application unit and the two-level state management modules are required to sequentially transmit status information back to the power management unit after completing their exit operations. The power management unit only executes the final power-down action after receiving complete end-to-end status feedback. This ensures that all applications complete data storage, resource release, and interface closure, standardizing the power-down sequence. Simultaneously, the feedback link allows for timely detection of module response anomalies, preventing abnormal power consumption.

[0053] Figure 1 This is an application scenario diagram illustrating the domain controller power-down control method provided in this application, such as... Figure 1As shown in the diagram, the scenario corresponding to the domain controller power-down control method provided in this application includes a domain controller 101 and a power-down control device 102. It is understood that the domain controller 101 includes a power management unit, a system management unit, and an application unit; the power-down control device 102 integrates a power-down control unit. The domain controller 101 and the power-down control device 102 are communicatively connected.

[0054] Specifically, the domain controller 101 is connected to multiple wake-up sources, such as door switches, batteries, and brake switches. When all wake-up sources connected to the domain controller 101 fail, a preset power-down trigger condition is determined to be met. The power-down control device 102 controls the power management unit in the domain controller 101 to send a power-down request to the system management unit. The system management unit includes a first state management module and a second state management module. The first state management module then sends an exit command to the second state management module based on the power-down request, causing the second state management module to send the exit command to the application unit. After the power management unit receives the status feedback information, the power-down control device 102 controls the domain controller to power down based on the status feedback information.

[0055] Understandably, after receiving the exit command, the application unit executes the exit operation. Upon completion, the power-down control device 102 controls the application unit to report the exit to the second state management module. Upon receiving the feedback, the second state management module switches the system operating mode to Afterrun and reports the status switch to the first state management module. Upon receiving the feedback, the first state management module switches its own mode to Afterrun and sends a command to the power management unit, notifying it that the system has completed exit preparation.

[0056] Alternatively, the power-down control device can be directly integrated into the domain controller; this embodiment does not limit this.

[0057] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0058] Figure 2 This is a flowchart illustrating a domain controller power-down control method provided in an embodiment of this application, as shown below. Figure 2As shown, the execution entity in this embodiment is a domain controller power-down control device. This device can be implemented through a computer program, or through a medium storing the relevant computer program, such as a USB flash drive and / or optical disc, or through an electronic device integrating or installing the relevant computer program, such as a chip, server, or server cluster. The domain controller power-down control method provided in this embodiment includes the following steps:

[0059] S201. When it is determined that the preset power-down trigger condition is met, the control power management unit sends a power-down request to the system management unit. The system management unit includes a first state management module and a second state management module.

[0060] Among them, the power management unit is a functional unit in the domain controller that is responsible for power monitoring, wake-up source acquisition, and power supply on / off control. It directly connects to the power supply circuit and various wake-up signals, and can autonomously determine whether the vehicle has reached the standard for sleep power-off. At the same time, as the initiator of the entire power-off process, it is responsible for initiating the power-off request and finally executing the power-off operation.

[0061] The system management unit refers to the comprehensive functional unit within the domain controller that coordinates system operation, command flow, and status control. It receives various commands issued by the power management unit and connects to all business applications, playing a crucial role in relaying and controlling the system.

[0062] The first state management module is the first-level state management node within the system management unit. It is the upper-level module that interfaces with the power management unit. It is mainly responsible for receiving various request commands from the power management unit, completing command parsing and preliminary verification, and also undertaking the work of forwarding commands downward and summarizing and transmitting upper-level states back.

[0063] The second state management module is the second-level state management node within the system management unit. It is responsible for receiving instructions forwarded from upstream and accurately distributing them to the corresponding applications. At the same time, it collects the running status and execution results of all application units and summarizes and feeds them back upwards.

[0064] Among them, the preset power-down trigger condition refers to the pre-set power-down judgment criteria, such as all the domain controller's maintenance power supply signals are completely lost, and no new wake-up trigger signal is received within the specified monitoring period. Meeting this criterion means entering a safe sleep mode.

[0065] Among them, the power-down request refers to the notification signal issued by the power management unit to inform the system management unit that the power-down conditions have been met and to initiate the overall exit and power-off process of the domain controller. It is the starting instruction to formally start the power-down process.

[0066] Optionally, the wake-up source signal may include a sustaining source signal and a new wake-up source signal. The sustaining source signal may be an ignition signal, a key position signal, a network management hold signal, a parking status hold signal, etc.; the new wake-up source signal may be a door opening signal, a remote control wake-up signal, etc.

[0067] Optionally, the power management unit can acquire the wake-up source signal through GPIO (General Purpose Input / Output) sampling, CAN (Controller Area Network) bus message reception, LIN (Local Interconnect Network) bus status reading, Ethernet network management message recognition, ADC (Analog-to-Digital Converter) level detection, or interrupt input capture.

[0068] Understandably, in order to avoid misjudgment caused by transient jitter, the collected results can be continuously satisfied for a preset period before confirming that the power-down condition is met. This preset period can be set to hundreds of milliseconds to several seconds, determined by the vehicle's sleep strategy.

[0069] Specifically, after confirming that the preset power-down trigger conditions are met, the control power management unit generates a power-down request and sends it to the system management unit. The power-down request may carry information such as request type, initiation timestamp, power-down reason code, timeout control parameters, and session identifier. The request type can be in the form of Shutdown_Notify to indicate that the orderly power-down phase has begun, and the power-down reason code can indicate that it is triggered by reasons such as ignition shutdown, vehicle idling, remote session termination, or abnormal recovery.

[0070] Optionally, the transmission path for the power-down request can be on-chip shared memory, inter-process message queue, socket communication, control bus message, or dedicated hardware interrupt line in conjunction with register writing.

[0071] Optionally, after receiving a power-down request, the system management unit may first perform a validity check to determine whether the message source, message integrity, and session validity meet the preset requirements. After the check passes, the system running status is switched from normal running state to pending exit state.

[0072] In one possible embodiment, the power management unit starts a timeout timer simultaneously with sending a power-down request. This timer monitors whether the system management unit returns status feedback information corresponding to the exit progress within a preset duration. The preset duration can be set based on factors such as the number of applications within the domain controller, data write-to-disk time, bus shutdown time, and peripheral termination time; for example, it can be set to 3 to 30 seconds. If no valid feedback is received by the timeout timer expires, the power management unit can record the abnormal event and enter a forced power-down preparation state to prevent the domain controller from remaining in standby power supply for an extended period, thus preventing continuous battery drain.

[0073] S202, the first state management module sends an exit command to the second state management module based on the power-down request, so that the second state management module sends the exit command to the application unit.

[0074] The application unit is a collection of functions in the domain controller that carries various vehicle control services. It runs specific vehicle application functions such as lights, windows, air conditioning, and power management. It is the underlying unit that directly executes vehicle functions and needs to complete a series of final actions such as data storage, communication shutdown, and hardware resource release before power-off.

[0075] Among them, the exit command is a control signal that carries the requirements to stop operation and perform closing operations. It is used to notify downstream modules and business units to stop the current work and start the safe exit process. It is also the core command that connects the system level and application units to complete the pre-power-down operation.

[0076] Specifically, upon receiving a power-down request, the first state management module can parse the session identifier, timeout duration, and power-down reason code in the request, and generate a corresponding exit instruction based on the pre-configured exit policy of the system. The exit instruction may include an exit stage identifier, target application scope, maximum response time limit, data retention requirements, peripheral device shutdown requirements, and feedback format definition, etc.

[0077] Optionally, if multiple application units are deployed within the domain controller, the first state management module can first arrange the exit order of each application unit based on the application dependency table, resource occupancy table, or functional safety priority table. For example, first notify the upper-layer business application to stop new service access, then notify the communication agent to end the network session, then notify the log recording module to complete data persistence to disk, and finally notify the peripheral control-related applications to release hardware resources.

[0078] Furthermore, upon receiving an exit command, the second state management module can break down the exit command, converting the unified system exit command into an exit message that can be recognized by each application unit. For example, for application processes running on Linux, an exit signal, socket command, or D-Bus (Desktop Bus) message can be sent through a daemon process. For runtime entities based on the AUTOSAR (AUTomotive Open System Architecture) architecture, the corresponding exit process can be triggered through runtime environment events, mode switching interfaces, or BswM (Basic Software ModeManager) coordination signals.

[0079] Understandably, after receiving an exit command, the application unit will no longer accept new business requests but will instead enter the exit operation phase. The exit operation may include writing cached data to non-volatile memory, closing the diagnostic session, disconnecting the CAN or Ethernet connection, closing the file handle, releasing shared memory, unregistering driver resources, stopping timers, and persisting internal states. For applications requiring a certain processing time, the application unit may first return to the intermediate state of having received the exit command, and then return to the final exit completion state after completing the actual exit.

[0080] In one possible embodiment, after sending the exit command, the first state management module continuously receives process feedback from the second state management module to determine whether it is currently in the application receiving stage, application execution stage, or application completion stage, and updates the global state of the system management unit based on the feedback results.

[0081] Correspondingly, after forwarding the exit command to the application unit, the second state management module can also initiate periodic heartbeat requests to the application unit to confirm whether the application unit is still in a responsive state. The heartbeat period can be set from 50 milliseconds to 500 milliseconds; if there is no response for several consecutive periods, the application unit is determined to be abnormal. For abnormal applications, the second state management module can execute a local forced exit process, such as stopping the forwarding of new requests to the application, canceling its access permissions to shared resources, notifying associated drivers to enter a protected state, and encapsulating the abnormal information into the uplink feedback data.

[0082] S203. In response to determining that the power management unit has received status feedback information, the power management unit controls the domain controller to power down based on the status feedback information. The status feedback information includes information that the application unit and the system management unit sequentially transmit to the power management unit after executing the exit operation based on the exit command.

[0083] Among them, the status feedback information is a set of confirmation information generated and uploaded from bottom to top by each level of the domain controller after completing safe exit, resource release and status switching. It is used to indicate that the current level has completed all the pre-power-down closing work and is the only basis for the power management unit to determine whether it is safe to disconnect the power.

[0084] Optionally, the status feedback information can be generated and supplemented step-by-step by the application unit, the second status management module, and the first status management module before being transmitted to the power management unit. The information reported by the application unit may include the application identifier, exit start time, exit completion time, data saving result, communication interface closure result, resource release result, and exception code.

[0085] Specifically, after receiving feedback from multiple application units, the second state management module can summarize the feedback to form an application layer exit summary result, such as fully completed, partially completed, timed out, or forced exit due to an abnormality. After obtaining the summary result from the second state management module, the first state management module can further supplement the system state information by combining it with the state switching results of the system management unit itself. This includes information such as whether the system service has stopped receiving new tasks, whether the internal state machine has switched to a power-off state, whether basic communication services have stopped, and whether critical guardian tasks have exited. The resulting complete state feedback information is then sent to the power management unit.

[0086] During the specific transmission process, the application unit can send the exit result through the dedicated feedback interface between it and the second state management module. The second state management module establishes a state table entry for each application according to the predefined feedback format, and after all applications return completion or reach the preset timeout condition, it encapsulates the state table entry into a summary feedback message and sends it to the first state management module.

[0087] Furthermore, the first state management module updates the system state of the system management unit based on the received summary feedback message and generates a final feedback message for the power management unit. Upon receiving this final feedback message, the power management unit compares the session identifier to confirm that the feedback corresponds to the current power-down request, and parses the allowed safe power-down flag, the abnormal application list, and the summary code to determine whether to enter the normal power-down path or the abnormal power-down path.

[0088] Optionally, when the status feedback indicates that both the application unit and the system management unit have completed the exit operation, the control power management unit performs safe power-down control. Safe power-down control may include shutting down non-held power outputs, pulling down the enable pin, notifying the board-level power chip to enter sleep mode, disconnecting the load switch, saving the reason for the last power-down, and shutting down the power domain connected to peripherals. If the domain controller has a partitioned power supply structure, the application processor power can be shut down first, followed by the high-speed communication module power, and finally the low-power wake-up monitoring circuit can be retained to ensure that it can be reactivated by a new wake-up source later. If the status feedback indicates that some applications are abnormal but the system management unit has completed the necessary isolation, it can decide whether to continue powering down based on the level of abnormality.

[0089] In one possible embodiment, if the power management unit does not receive status feedback information within a preset time period, it is considered that the orderly exit link has not been closed on schedule, and a forced power-down can be directly executed to avoid continuous power supply to the domain controller. Before the forced power-down, a timeout fault code can be recorded, the current power status and the most recently received intermediate feedback can be saved for subsequent diagnostic analysis.

[0090] The domain controller power-down control method provided in this application embodiment controls the power management unit to initiate a power-down request when preset power-down trigger conditions are met. The first and second state management modules in the system management unit then sequentially transmit exit instructions to the application unit, enabling the application unit and system management unit to execute the exit operation in an orderly manner according to the power-down process. By receiving state feedback information sequentially transmitted by the application unit and system management unit after executing the exit operation based on the exit instruction, and then controlling the domain controller to power down based on the state feedback information, pre-power-down state confirmation and process constraints can be achieved, thereby improving the reliability, security, and adaptability of the domain controller power-down in complex scenarios.

[0091] As an optional implementation, based on the above embodiments, sending a power-down request includes:

[0092] The control power management unit sends a power-down request to the first status management module. The power-down request includes an instruction consisting of a power-down identifier and a power-down status code. The power-down identifier indicates the purpose of the instruction, and the power-down status code indicates the initiator of the request.

[0093] The power-down identifier is a unique name used in the instruction to define its function and purpose. It can intuitively distinguish the function of this instruction and differentiate it from other types of instructions such as heartbeat detection, fault reporting, and wake-up notification.

[0094] Among them, the power-down status code refers to a pre-agreed status code used to identify the source of this power-down request, thereby distinguishing power-down commands issued by different triggering entities.

[0095] Specifically, after determining that the domain controller meets the preset power-down trigger conditions, the control power management unit begins to organize and send a power-down request. First, according to predefined rules, a complete instruction is generated. The instruction contains two parts: one is a unique power-down identifier name, which clarifies the purpose of this signal to initiate power-down; the other part is the corresponding power-down status code, indicating that this request was initiated by the power management unit.

[0096] Furthermore, after completing the instruction combination, the power management unit sends the integrated power-down request to the first state management module. Upon receiving the signal, the first state management module first parses the instruction content, identifies it as a power-down related instruction through the power-down identifier, and then reads the power-down status code to confirm that the request originated from the power management unit. After completing information identification and verification, the first state management module confirms the instruction is legal and valid, and then, based on the power-down request, continues the process of forwarding the exit instruction to the second state management module.

[0097] The domain controller power-down control method provided in this application splits the instruction into two independent parts: a power-down identifier and a power-down status code, thus structuring the instruction content. By clearly defining the purpose of the instruction through the power-down identifier, the receiving module can quickly identify the signal type, avoiding confusion between the power-down instruction and other communication signals within the system, and reducing the possibility of misjudgment or incorrect execution of the instruction. By marking the initiating entity with a dedicated status code, power-down requests from different sources are differentiated and defined, providing support for subsequent fault diagnosis and differentiated process management. Because the request content has clear purpose and entity identifiers, the system can maintain stable parsing of the power-down instruction even when there is concurrent communication between multiple modules, frequent state switching, or strong communication interference. This facilitates the orderly execution of subsequent exit processes and reduces the risk of power-down anomalies caused by misidentification of instructions.

[0098] As an optional implementation, based on the above embodiments, it further includes:

[0099] The control application unit executes a preset exit process based on the exit command, and sends an exit status confirmation message to the second status management module after the execution is completed. The preset exit process includes data saving, peripheral communication interface closing, and resource release.

[0100] Among them, the preset exit process is a standardized closing process executed by the application unit before power-off, which is a set of predefined safe exit procedures.

[0101] Among them, the exit status confirmation information refers to the feedback signal generated after the application unit has fully executed the preset exit process. It is used to inform the upper-layer module that the current application business has been safely terminated, all cleanup work has been completed, and the application has reached a state where it can be powered off.

[0102] Specifically, after the second state management module issues the exit command to each application unit, all running application units immediately cease processing new business operations, stop responding to new function requests, and uniformly enter the preset exit process. The application units perform data saving operations, permanently storing the key state data, system configuration data, and fault log data generated during this vehicle operation. Then, the application units systematically close all external peripheral communication interfaces, proactively disconnecting communication with other vehicle controllers and peripheral devices, and terminating bus message transmission and signal interaction. Finally, the application units release system resources, proactively releasing the system processes, memory space, hardware port resources, and scheduling task resources occupied during operation.

[0103] Furthermore, after the entire preset exit process, including data saving, communication shutdown, and resource release, is completed, the application unit generates corresponding exit status confirmation information and actively uploads this confirmation information to the second status management module, thus completing the secure exit feedback for a single application.

[0104] The domain controller power-down control method provided in this application embodiment ensures that all application units complete a full cleanup operation before power-down through a unified and standardized exit process, avoiding the situation where applications are forcibly terminated directly in traditional power-down methods. The unified exit standard guarantees that all service exits are orderly and controllable, eliminating the problem of inconsistent power-down timing caused by different application exit progresses. By reporting exit status confirmation information, the application layer exit status is visualized, feedback-enabled, and traceable, allowing the upper-layer system management module to accurately grasp the exit completion status of each application, providing a basis for hierarchical status aggregation and the formation of a complete closed-loop feedback chain.

[0105] As an optional implementation, based on the above embodiments, it further includes:

[0106] After receiving the exit status confirmation information, the second status management module controls the second status management module to switch the running status to the post-running status and sends the first status switch confirmation information to the first status management module.

[0107] The post-running state refers to a dedicated running mode at the domain controller system level. After all application units have completed their exit operations, the system no longer processes new business requests, but retains only basic operating capabilities to complete the final system cleanup and status verification before power failure. It is a transitional state before the official power-off.

[0108] The first state switch confirmation information refers to the feedback signal generated by the second state management module after completing the state switch. It is used to inform the upper-level module that it has successfully switched to the post-run state and synchronously transmit the status information that the current system is ready to continue the power-down process.

[0109] In practical implementation, after receiving the exit status confirmation information, the second state management module first performs a consistency check on the status code, source address, or verification field in the information to confirm that the application unit has indeed completed the preset exit process. Once confirmed, the second state management module updates its internal state control logic from the original running state to the post-running state and generates a confirmation message corresponding to this state change. The confirmation message can carry the current state identifier, timestamp, and module identifier so that the first state management module can accurately identify the state transition result. The confirmation message is transmitted to the first state management module via the system management unit's internal communication interface. Upon receiving the message, the first state management module can then proceed to the next stage of state management control.

[0110] In some implementations, the second state management module can use a software state machine to complete state transitions. The input of the state machine is the exit state confirmation information, and the output is the first state transition confirmation information. Alternatively, task callbacks or message queues can be used to generate and forward confirmation information, thus adapting to the software architecture of different domain controllers.

[0111] The domain controller power-down control method provided in this application embodiment allows the second state management module to promptly update its own state and report the state switching result to the first state management module after the application unit exits, thus forming a clear state loop within the system management unit. State switching clarifies the system's operational boundaries, blocks new service access, concentrates system resources for power-down cleanup, and prevents logical confusion caused by conflicts between old and new tasks. This improves the accuracy, continuity, and traceability of the power-down control process.

[0112] As an optional implementation, based on the above embodiments, it further includes:

[0113] After receiving the first state switching confirmation information, the control first state management module switches the running state to the post-running state and sends status feedback information to the power management unit. The status feedback information includes an instruction consisting of a running state identifier name and a running state code.

[0114] Among them, the running status identifier name is a custom-defined exclusive status field name, which is used to uniformly identify the current system operating condition of the domain controller and distinguish different system modes such as post-running status, normal working status, and abnormal fault status.

[0115] Among them, the running status code is a pre-standardized numerical code used to quantitatively characterize the current specific running status of the system. Different codes correspond to different system operating conditions, which allows the power management unit to quickly identify whether the system has completed application exit or entered the post-run ready state.

[0116] In practical implementation, upon receiving the first state transition confirmation information, the first state management module stops all routine business scheduling, instruction forwarding, and function control tasks, and simultaneously executes the system state transition operation, uniformly switching its normal operation mode to the post-running state. At this time, both levels of state modules in the entire system management unit have completed the state transition, and the entire domain no longer receives new services or executes new functional logic, only retaining the basic links for interaction between upper and lower level states, and maintaining the minimum operating resources required for the power-off closing process.

[0117] Furthermore, after the first state management module's own state transition stabilizes and there are no residual tasks in the system, it assembles and generates the final state feedback information according to preset standardized instruction rules. The feedback information includes a unique running state identifier name and a corresponding ready running state code, indicating that the current system has completed the exit of all applications, the system state transition is in place, and the conditions for safe power-down are met. The first state management module uploads the assembled standardized state feedback information to the power management unit, completing the final state receipt at the system level, and waits for the power management unit to execute the final power-down action.

[0118] Optionally, the running status identifier name can be implemented using a pre-agreed string, enumeration value, or identifier byte, and the running status code can be implemented using an integer code value, hexadecimal code value, or bit field encoding to improve information parsing efficiency and compatibility.

[0119] The domain controller power-down control method provided in this application embodiment involves the first state management module reporting a unified format of state feedback information to the power management unit after completing state synchronization. This ensures that the system exit state can be clearly identified by the power management unit, enabling it to execute a power-down decision accordingly. This improves the closed-loop performance, timing consistency, and power-down reliability of the domain controller exit process. By clearly defining the information type through the running status identifier, the power management unit can quickly distinguish system status feedback commands from other heartbeat, fault, and wake-up messages, avoiding signal confusion and misjudgment. Furthermore, the use of a dedicated running status code accurately quantifies the system readiness state, achieving digital and standardized transmission of system operating conditions.

[0120] As an optional implementation, based on the above embodiments, after the power management unit sends a power-down request to the system management unit, it further includes:

[0121] Start the timer for the first preset duration;

[0122] If the power management unit does not receive status feedback information within the first preset time period, it will directly control the domain controller to power down.

[0123] The first preset duration refers to the pre-configured fixed timeout waiting duration, which is the maximum allowable time for the system management unit and application unit to complete the entire exit process, state switching and information feedback. It is used to define the threshold for judging the normal power-down process and the abnormal dead process.

[0124] Optionally, the timer can be implemented by a timing module inside the power management unit, or by an independent clock unit that communicates with the power management unit, with the timing start time synchronized with the time when the power-down request is sent.

[0125] In actual control, a timer is started immediately after a power-down request is sent, and status feedback information is continuously monitored. When the system management unit, the first status management module, the second status management module, and the application unit can complete the exit confirmation and provide feedback step by step within a first preset time period, a controlled power-down can be executed based on this feedback. If no valid feedback is received within the preset time period due to software blocking, communication abnormalities, or status transmission failures, a power-down coordination abnormality is determined, and a shutdown control signal is directly output to the power supply circuit of the domain controller to cut off the power supply to the domain controller.

[0126] Optionally, directly controlling the domain controller to power down can be achieved by the power management unit driving a high-side switch, relay, or power distribution module, thereby cutting off the main power supply path to the domain controller. In some architectures, the auxiliary power supply branch maintaining communication and standby can be shut down first, followed by the main power supply branch, thus achieving a forced power-off of the domain controller. If a high-side switch is used, its low on-resistance and fast response speed make it suitable for vehicle power supply cut-off control. In practical applications, other models of this component can also be selected, and this application does not limit this.

[0127] The domain controller power-down control method provided in this application limits the feedback waiting time through a timer, thus establishing a clear boundary between normal coordinated power-down and abnormal timeout power-down. This ensures timely power-down of the domain controller even when the system management unit fails to return status feedback information on time, preventing continuous power occupation. This reduces the risk of prolonged power-on due to software anomalies, minimizes additional battery consumption, and improves the determinism and reliability of power-down control.

[0128] As an optional implementation, based on the above embodiments, it further includes:

[0129] Obtain preset load status indicators from the system management unit, including at least one of processor utilization and memory usage.

[0130] The first preset duration is adjusted based on the preset load status.

[0131] Among them, the preset load status index is a predefined hardware resource status parameter used to characterize the operating load of the domain controller system.

[0132] Optionally, the preset load status indicators can be collected in real time by the monitoring module inside the system management unit, or they can be read periodically by the control module that communicates with the system management unit. This application embodiment does not limit this.

[0133] Specifically, before or during the power management unit initiates a power-down request and starts a timer, the system management unit continuously collects its operating load status in real time, obtaining load status indicators such as processor utilization and memory usage. After obtaining the preset load status indicators of the system management unit, these indicators can be compared with a preset threshold range, and the first preset duration can be adjusted accordingly.

[0134] For example, when processor utilization or memory usage is high, it indicates that the system management unit is currently handling many exit tasks or is under heavy operating pressure. In this case, the first preset duration can be appropriately extended to allow sufficient time for state saving, resource release, and feedback transmission. When processor utilization or memory usage is low, it indicates that the system management unit is under light load, and the first preset duration can be appropriately shortened to reduce waiting time and improve power-down efficiency. The first preset duration can be implemented by a timer, and the timer's duration parameter can be updated in real time before or after the power-down request is issued to adapt to different load scenarios.

[0135] The domain controller power-down control method provided in this application adjusts the first preset duration based on a preset load state, enabling the power-down waiting time to dynamically adapt to the system load. This overcomes the shortcomings of traditional fixed timeout parameters that cannot adapt to all operating conditions, and is compatible with various operating scenarios such as high load, normal load, and low load. It makes the dual-branch logic of safe power-down and forced power-down over time more intelligent and fault-tolerant, significantly improving the power-down stability and robustness of the domain controller under complex operating conditions.

[0136] As an optional implementation, based on the above embodiments, determining whether a preset power-down trigger condition is met includes:

[0137] The power management unit monitors the sustain source signal and the new wake-up source signal.

[0138] If all sustain source signals are detected to be invalid and no new wake-up source signal is detected, then the preset power-down trigger condition is determined to be met.

[0139] The sustain source signal is a long-term effective signal used during the domain controller's sleep / standby phase to maintain basic power supply to the power management unit and ensure the normal operation of the wake-up monitoring function. It is the core reference signal for determining whether the domain controller needs to maintain its working state when the vehicle is in a static sleep state. When the sustain source signal is valid, it means that the vehicle still needs to maintain basic domain controller standby capability.

[0140] Among them, the newly added wake-up source signal is used to characterize a new wake-up event that may re-trigger system operation after the original maintenance conditions disappear.

[0141] Specifically, when any sustaining source signal remains valid, the power management unit maintains the current power supply state; when all sustaining source signals fail and no new wake-up source signal is detected, the power management unit outputs a judgment result that meets the preset power-down trigger condition.

[0142] Optionally, the power management unit can employ a monitoring mode combining interrupt sampling and periodic polling to reduce the impact of signal jitter on the judgment results. Internally, it can preset the signal validity threshold, validity duration, and failure confirmation duration, and determine whether the sustaining source signal has truly failed through jitter reduction processing. For newly added wake-up source signals, the power management unit can simultaneously detect them within the same monitoring window, or it can enter stricter monitoring after the sustaining source signal fails to avoid missing external sudden wake-up requests. In practical applications, other models of this component can also be selected; this application embodiment does not limit this.

[0143] The domain controller power-down control method provided in this application embodiment simultaneously monitors the sustain source signal and the new wake-up source signal to achieve dual judgment of the vehicle's duty status and functional requirement status, thereby providing a clear trigger basis for subsequent power-down control logic. The power management unit directly completes signal monitoring and condition judgment, without relying on system software and application layer status. Even if the upper-layer system experiences lag or abnormality, it can still accurately identify the actual power condition, ensuring the stability and reliability of the power-down trigger logic and achieving underlying hardware-level safety fallback.

[0144] As an optional implementation, based on the above embodiments, monitoring and sustaining source signals through a power management unit includes:

[0145] The control power management unit acquires sustain source signals through multiple preset sensors;

[0146] The validity of the acquired sustaining source signal is verified using preset state transition rules.

[0147] Among them, multiple preset sensors refer to hardware acquisition devices that are pre-configured in the domain controller power management link and are specifically used to sense and maintain the power supply status of the source. They can capture the voltage, path status and power supply continuity of the source in real time and provide raw acquisition signals to the power management unit.

[0148] Optionally, the power management unit can synchronously read the outputs of each sensor and timestamp the collected values ​​to improve the consistency of state identification. In practical applications, other sensor models can also be selected, and this application embodiment does not limit this.

[0149] Among them, the preset state transition rules are predefined signal state verification and switching logic specifications, used to identify whether the acquired sustain source signal is real and valid, and to filter abnormal signals such as transient interference, level jitter, and brief circuit break.

[0150] Optionally, the preset state transition rules can filter out instantaneous fluctuations by means of state duration, number of consecutive changes, and amplitude threshold.

[0151] After obtaining the multi-channel acquisition results, the power management unit performs matching verification against the preset state transition rules. When the outputs of multiple sensors simultaneously meet the state transition conditions, the source signal is confirmed to be valid. When only a single path shows an abnormal change while other paths remain stable, the abnormal change is judged as invalid interference to avoid erroneously triggering the power-down decision.

[0152] Specifically, the power management unit first synchronously acquires the sustain source signal through multiple preset sensors. After obtaining the multi-channel acquisition results, it performs matching verification against preset state transition rules. When the outputs of multiple sensors simultaneously meet the state transition conditions, the sustain source signal is confirmed to be valid. When only a single path experiences an abnormal change while other paths remain stable, the abnormal change is determined to be invalid interference.

[0153] The domain controller power-down control method provided in this application employs multi-sensor collaborative acquisition of sustain source signals, overcoming the problems of easy failure and missed detection in traditional single-point acquisition, and improving the comprehensiveness and integrity of sustain source signal acquisition. It can comprehensively monitor the sustain source power supply path status, avoiding signal acquisition errors caused by single sensor failure or single-point line abnormalities, and improving the hardware redundancy and reliability of signal acquisition. Through standardized status verification rules, the raw signal is filtered and de-jittered, effectively suppressing signal jitter, transient interference, and pulse noise in the complex electromagnetic environment of an in-vehicle environment, avoiding false signals that cause misjudgments of the sustain source status.

[0154] As an optional implementation, based on the above embodiments, it further includes: obtaining a preset power-down strategy mapping table; and determining a target power-down process from the preset power-down strategy mapping table based on the type of failure sustaining source signal.

[0155] Among them, the preset power-down strategy mapping refers to the set of pre-fixed strategy correspondences, which stores the matching relationship between different types of maintenance source signal failure states and corresponding power-down execution processes. It is used to match the power-down control logic differently according to the actual failure scenario, so as to realize scenario-based and hierarchical power-down management.

[0156] Among them, failure sustaining source signals refer to a type of sustaining source signal whose state changes from valid to invalid during the monitoring process and is confirmed as a real failure after signal verification.

[0157] Among them, the target power-down process refers to the differentiated power-down execution method determined for different wake-up source failure scenarios.

[0158] Specifically, after completing the acquisition and validity verification of the sustaining source signal, confirming the existence of a sustaining source signal failure and meeting the basic power-down conditions, the locally stored preset power-down strategy mapping table is retrieved. The specific type of the currently failed sustaining source signal is identified, distinguishing the power supply attributes, monitoring functions, and failure scenarios corresponding to different sustaining sources. Based on the type characteristics of the failed sustaining source, the corresponding power-down control logic is matched in the preset power-down strategy mapping table to determine the specific target power-down procedure to be executed under the current operating condition.

[0159] In one implementation, the preset power-down strategy mapping table can be pre-stored in non-volatile memory within the power management unit (Power Management Unit) or in an external storage unit communicatively connected to the Power Management Unit. This mapping table can consist of an identification field, a type field, and a process field. The identification field distinguishes different failure sustaining source signals, the type field records the failure category to which the signal belongs, and the process field records the target power-down process corresponding to that category.

[0160] The domain controller power-down control method provided in this application establishes a mapping relationship between the type of failure sustaining source signal and the target power-down process. This enables the power management unit to quickly select a matching power-down strategy after identifying the failure category, avoiding the problems of false power-off or delayed power-down caused by using a single fixed strategy. Since the target power-down process can be configured differently according to the failure type, the targeting and stability of power-down control can be improved, and the power management capability of the domain controller in complex vehicle conditions can be enhanced.

[0161] As an optional implementation, based on the above embodiments, it further includes:

[0162] The control system management unit periodically sends heartbeat requests to the application unit;

[0163] If no response information is received from the application unit within the second preset time period, the control system management unit executes the forced exit process and sends the abnormal information to the power management unit.

[0164] Among them, the heartbeat request is a status detection signal periodically issued by the system management unit. It is used to monitor the running activity and working status of the lower-level application units in real time, and to confirm whether the application units are running normally, whether they are stuck or crashed. It is an active detection mechanism for the system layer to monitor the health status of the application layer.

[0165] The second preset duration refers to the pre-configured maximum waiting time for the heartbeat response, which serves as a time threshold for determining whether the application unit is abnormal, and is used to distinguish between normal application response, short-term delayed response, and stuck and unresponsive conditions.

[0166] The response information refers to the response signal sent back by the application unit after receiving the heartbeat request, which is used to prove to the system management unit that its process is normal, the task is running normally, and no deadlock has occurred.

[0167] The forced exit process refers to the exception handling process triggered when an application unit times out and becomes unresponsive. It is used to forcibly terminate the abnormal application task, reclaim system resources, and forcibly refresh the state machine, so that the abnormal application can get out of the stuck state and restore the system to a controllable state.

[0168] Among them, abnormal information refers to the status record information generated by the system management unit after detecting application freezing or heartbeat timeout. It is used to transmit abnormal operating conditions upward and inform the power management unit that there is an application abnormality in the current power-down process.

[0169] Specifically, the system management unit can send heartbeat requests to the application unit at preset intervals via a timer. The heartbeat request can carry a heartbeat identifier, the current session identifier, and the sending time information, so that the application unit can match and confirm the received request. After receiving the heartbeat request, the application unit returns response information to the system management unit. The response information may include a response identifier, an application status code, and verification information corresponding to the heartbeat request, thereby indicating that the application unit is still in a state where it can normally process the exit transaction.

[0170] Understandably, in the actual control process, the system management unit starts the corresponding timeout countdown after sending the heartbeat request. If no response information is received from the application unit within the second preset time period, it is determined that the application unit has been blocked, lost connection, or exited abnormally, and then the forced exit process is executed.

[0171] Optionally, the forced exit process can be initiated by the system management unit sending a forced termination command to the application unit, or by directly releasing resource usage, communication handles, and task control associated with the application unit, to avoid prolonged suspension of exit control. Exception information may include a timeout flag indicating no response, exception type, time of occurrence, and application unit identifier, and is sent to the power management unit via the system management unit.

[0172] The domain controller power-down control method provided in this application uses periodic heartbeat checks combined with fixed-duration thresholds to monitor the application unit's operating status in real time. This allows for accurate identification of anomalies such as process freezes and communication interruptions, avoiding misjudgments caused by signal interference. For unresponsive applications, a forced exit operation is performed to reclaim system resources, preventing single-point failures from blocking the power-down process and causing abnormal vehicle power consumption. Simultaneously, anomaly information is reported upwards, enabling status traceability and facilitating the power management unit to differentiate operating conditions and adjust control strategies, thus comprehensively enhancing the stability and fault tolerance of the power-down process.

[0173] Figure 3 This is a flowchart illustrating a domain controller power-down control method according to another embodiment of this application, as shown below. Figure 3 As shown, the domain controller power-down control method provided in this embodiment includes the following steps:

[0174] S301, the control power management unit collects sustain source signals and new wake-up source signals through multiple preset sensors.

[0175] S302. Verify the validity of the acquired sustain source signal and the newly added wake-up source signal using preset state transition rules.

[0176] S303. If all sustain source signals are detected to be invalid and no new wake-up source signal is detected, then the preset power-down trigger condition is determined to be met.

[0177] S304. Obtain the preset power-down strategy mapping table.

[0178] S305. Based on the type of failure sustaining source signal, determine the target power-down procedure from the preset power-down strategy mapping table.

[0179] S306. The control power management unit sends a power-down request to the first state management module. The power-down request includes an instruction consisting of a power-down identifier and a power-down status code. The power-down identifier is used to indicate the purpose of the instruction, and the power-down status code is used to indicate the initiator of the request.

[0180] S307. While sending the power-down request, obtain the preset load status indicators of the system management unit. The preset load status indicators include at least one of processor utilization and memory usage.

[0181] S308. Adjust the first preset duration based on the preset load state and start the timer for the first preset duration.

[0182] S309. The first state management module sends an exit command to the second state management module based on the power-down request, so that the second state management module sends the exit command to the application unit.

[0183] S310, the control application unit executes a preset exit process based on the exit command, and sends an exit status confirmation message to the second status management module after the execution is completed. The preset exit process includes data saving, peripheral communication interface closing, and resource release.

[0184] S311. While the application unit executes the preset exit procedure, the control system management unit periodically sends heartbeat requests to the application unit.

[0185] S312. If no response information is received from the application unit within the second preset time period, the control system management unit executes the forced exit process and sends the abnormal information to the power management unit.

[0186] S313. If a response message sent by the application unit is received within the second preset time period and an exit status confirmation message is received, the second status management module is controlled to switch the running status to the post-running status and send the first status switch confirmation message to the first status management module.

[0187] S314. After receiving the first state switching confirmation information, the control first state management module switches the running state to the post-running state and sends state feedback information to the power management unit. The state feedback information includes an instruction consisting of a running state identifier name and a running state code.

[0188] S315. If it is determined that the power management unit receives status feedback information within the first preset time period, the domain controller is powered down based on the status feedback information.

[0189] S316. If it is determined that the power management unit has not received status feedback information within the first preset time period, the domain controller is directly powered down.

[0190] It should be noted that the execution order of S306 and S307-S308 is not important; the execution order of S310 and S311 is not important; and the execution order of S315 and S316 is not important.

[0191] In this embodiment, the implementation method and technical effect of S301-S316 are similar to those of the corresponding solutions in the above embodiments, and will not be repeated here.

[0192] Figure 4 This is a schematic diagram of the power-down control device for the domain controller provided in this application, as shown below. Figure 4 As shown, the domain controller power-down control device 40 provided in this embodiment includes: a control module 41.

[0193] The control module 41 is used to control the power management unit to send a power-down request to the system management unit when it is determined that the preset power-down trigger conditions are met. The system management unit includes a first state management module and a second state management module. The control module 41 controls the first state management module to send an exit command to the second state management module based on the power-down request, so that the second state management module sends the exit command to the application unit. In response to determining that the power management unit has received the state feedback information, the control module 41 controls the domain controller to power down based on the state feedback information. The state feedback information includes information that the application unit and the system management unit transmit to the power management unit in sequence after executing the exit operation based on the exit command.

[0194] The domain controller power-down control device provided in this embodiment can execute... Figure 2 and Figure 3 The implementation principles and technical effects of the methods shown are similar, and will not be repeated here.

[0195] Optionally, when the control module 41 sends a power-down request from the power management unit to the system management unit, it is specifically used to: control the power management unit to send a power-down request to the first state management module. The power-down request includes an instruction consisting of a power-down identifier and a power-down status code. The power-down identifier is used to indicate the purpose of the instruction, and the power-down status code is used to indicate the initiating entity of the request.

[0196] Optionally, the control module 41 is also used to control the application unit to execute a preset exit process based on the exit command, and send exit status confirmation information to the second status management module after the execution is completed. The preset exit process includes data saving, peripheral communication interface closing, and resource release.

[0197] Optionally, the control module 41 is further configured to control the first state management module to switch the running state to the post-running state after receiving the first state switching confirmation information, and to send state feedback information to the power management unit. The state feedback information includes an instruction consisting of a running state identifier name and a running state code.

[0198] Optionally, the domain controller power-down control device provided in this embodiment further includes a startup module.

[0199] Correspondingly, the startup module starts a timer for a first preset duration; the control module 41 is also used to directly control the domain controller to power down if it is determined that the power management unit has not received status feedback information within the first preset duration.

[0200] Optionally, the domain controller power-down control device provided in this embodiment further includes an acquisition module and an adjustment module.

[0201] Correspondingly, the acquisition module is used to acquire the preset load status indicators of the system management unit, which include at least one of processor utilization and memory usage; the adjustment module is used to adjust the first preset duration based on the preset load status indicators.

[0202] Optionally, the domain controller power-down control device provided in this embodiment further includes a determination module.

[0203] Correspondingly, the determination module is used to monitor the sustain source signal and the new wake-up source signal through the power management unit; if all sustain source signals are detected to be invalid and no new wake-up source signal is detected, then it is determined that the preset power-down trigger condition is met.

[0204] Optionally, the determination module is also used to control the power management unit to acquire sustain source signals through multiple preset sensors; and to verify the validity of the acquired sustain source signals using preset state transition rules.

[0205] Optionally, the acquisition module is further configured to acquire a preset power-down strategy mapping table; the determination module is further configured to determine the target power-down process from the preset power-down strategy mapping table based on the type of failure sustaining source signal.

[0206] Optionally, the control module 41 is also used to control the system management unit to periodically send heartbeat requests to the application unit; if no response information is received from the application unit within a second preset time period, the system management unit executes a forced exit process and sends the abnormal information to the power management unit.

[0207] Figure 5 A schematic diagram of the structure of the electronic device provided in this application. Figure 5 As shown, the electronic device 50 provided in this embodiment includes a processor 51 and a memory 52. ​​The processor 51 and the memory 52 are connected via a bus and communicate with each other.

[0208] In the specific implementation process, the processor 51 executes the computer execution instructions stored in the memory 52, causing the processor 51 to perform the above-described method.

[0209] The specific implementation process of processor 51 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0210] In the above embodiments, it should be understood that the processor 51 can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

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

[0212] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0213] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0214] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the above-described method.

[0215] The aforementioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0216] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the processor and the readable storage medium can exist as discrete components in the device.

[0217] The division of units is merely a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

[0218] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0219] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0220] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0221] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0222] Finally, it should be noted that other embodiments of the invention will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This invention is intended to cover any variations, uses, or adaptations of the invention that follow the general principles of the invention and include common knowledge or customary techniques in the art not disclosed herein, and is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of the invention is limited only by the appended claims.

Claims

1. A power-down control method for a domain controller, characterized in that, The method includes: When it is determined that the preset power-down trigger condition is met, the control power management unit sends a power-down request to the system management unit, which includes a first state management module and a second state management module. The first state management module sends an exit command to the second state management module based on the power-down request, so that the second state management module sends the exit command to the application unit; In response to determining that the power management unit has received status feedback information, the domain controller is powered down based on the status feedback information. The status feedback information includes information that the application unit and the system management unit sequentially transmit to the power management unit after executing an exit operation based on an exit command.

2. The method according to claim 1, characterized in that, Send a power-down request, including: The control power management unit sends a power-down request to the first status management module. The power-down request includes an instruction consisting of a power-down identifier and a power-down status code. The power-down identifier indicates the purpose of the instruction, and the power-down status code indicates the initiator of the request.

3. The method according to claim 1, characterized in that, Also includes: The control application unit executes a preset exit process based on the exit command, and sends an exit status confirmation message to the second status management module after the execution is completed. The preset exit process includes data saving, peripheral communication interface closing, and resource release.

4. The method according to claim 3, characterized in that, Also includes: After receiving the exit status confirmation information, the second status management module controls the second status management module to switch the running status to the post-running status and sends the first status switch confirmation information to the first status management module.

5. The method according to claim 4, characterized in that, Also includes: After receiving the first state switching confirmation information, the control first state management module switches the running state to the post-running state and sends status feedback information to the power management unit. The status feedback information includes an instruction consisting of a running state identifier name and a running state code.

6. The method according to claim 1, characterized in that, After the control power management unit sends a power-down request to the system management unit, it also includes: Start the timer for the first preset duration; If the power management unit does not receive status feedback information within the first preset time period, it will directly control the domain controller to power down.

7. The method according to claim 6, characterized in that, Also includes: Obtain preset load status indicators of the system management unit, wherein the preset load status indicators include at least one of processor utilization and memory occupancy. The first preset duration is adjusted based on the preset load status.

8. The method according to claim 1, characterized in that, The determination that the preset power-down trigger condition is met includes: The power management unit monitors the sustain source signal and the new wake-up source signal. If all sustain source signals are detected to be invalid and no new wake-up source signal is detected, then the preset power-down trigger condition is determined to be met.

9. The method according to claim 8, characterized in that, Monitoring the sustain source signal via the power management unit includes: The control power management unit acquires sustain source signals through multiple preset sensors; The validity of the acquired sustaining source signal is verified using preset state transition rules.

10. The method according to claim 8, characterized in that, Also includes: Obtain the preset power-down strategy mapping table; Based on the type of failure sustaining source signal, the target power-down process is determined from the preset power-down strategy mapping table.

11. The method according to claim 1, characterized in that, Also includes: The control system management unit periodically sends heartbeat requests to the application unit; If no response information is received from the application unit within the second preset time period, the control system management unit executes the forced exit process and sends the abnormal information to the power management unit.

12. An electronic device, characterized in that, include: Memory, processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory, causing the processor to perform the method as described in any one of claims 1-11.

13. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1-11.

14. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method as described in any one of claims 1-11.

Images