A control method, a control system and a computer readable storage medium

Abstract

The application provides a control method, a control system and a computer readable storage medium, and belongs to the technical field of computers. The control method comprises the following steps: in response to a shutdown signal, triggering a functional component in an embedded system to generate a corresponding shutdown subtask; storing the shutdown subtask in an event pool in the embedded system, and in response to completion of execution of any shutdown subtask, removing the corresponding shutdown subtask from the event pool; and in the case where the number of shutdown subtasks in the event pool is zero, disconnecting the main power supply of the embedded system.

Description

Technical Field

[0001] This invention belongs to the field of computer technology, specifically relating to a control method, a control system, and a computer-readable storage medium. Background Technology

[0002] In multi-module, multi-power-domain embedded systems, shutdown processes are often constrained by fixed delays, sequential instructions, or energy budget policies. Traditional methods rely on preset delay times or reverse startup sequences. However, in actual robots and dynamic control systems, the shutdown tasks of various components have unpredictable completion time distributions; delays in mechanism reset, state saving, buffer refresh, and bus silencing can all exhibit randomness. If the fixed delay is too short, it can easily lead to data loss, inconsistent states, and incomplete mechanism reset; if the delay is too long, it increases power consumption and waiting time at the tail end, affecting user experience and energy efficiency. Summary of the Invention

[0003] In order to solve the above-mentioned technical problems, the purpose of this invention is to provide a control method, a control system, and a computer-readable storage medium.

[0004] The specific technical solution adopted is as follows: A control method, comprising: In response to a power-off signal, the functional components in the embedded system are triggered to generate a corresponding power-off subtask; The shutdown subtask is stored in the event pool of the embedded system, and in response to the completion of any shutdown subtask, the corresponding shutdown subtask is removed from the event pool. When the number of shutdown subtasks in the event pool is zero, disconnect the main power supply of the embedded system.

[0005] In some embodiments, it also includes: Based on the mapping relationship between multiple shutdown subtasks and multiple power domains in the event pool, multiple subtask sets are determined; each subtask set corresponds to a power domain, and each subtask set includes at least one shutdown subtask. If any subtask set is empty, disconnect the power domain corresponding to that subtask set.

[0006] In some embodiments, the plurality of power domains, including a target power domain, further include: When the set of subtasks corresponding to the target power domain is empty, keep the target power domain powered until the number of shutdown subtasks in the event pool is zero, and then cut off the target power domain.

[0007] In some embodiments, before triggering a functional component in the embedded system to generate a corresponding shutdown subtask, the method further includes: Determine if the embedded system is in the power-off process; If the system is not in the shutdown process, a shutdown version number is generated. The shutdown version number is used to identify the current shutdown process, and the system state is switched to the shutdown process. If the device is already in the process of shutting down, ignore the current shutdown signal.

[0008] In some embodiments, before storing the shutdown subtask in the event pool of the embedded system, the method further includes: Retrieve the version tag carried in each shutdown subtask; Determine whether the version tag is consistent with the shutdown version number; If they match, the corresponding shutdown subtask can be added to the event pool. If they are inconsistent, the corresponding shutdown subtask should not be added to the event pool.

[0009] In some embodiments, the shutdown subtask is stored in an event pool of the embedded system, and in response to the completion of any shutdown subtask, the corresponding shutdown subtask is removed from the event pool, including: Based on the registration requests of the shutdown subtasks of the obtained functional components, the corresponding shutdown subtasks are added to the event pool; Upon completion of the shutdown subtask, the corresponding shutdown subtask is removed from the event pool based on the obtained deregistration request for the shutdown subtask of the corresponding functional component.

[0010] In some embodiments, based on the registration request of the shutdown subtask of the acquired functional component, the corresponding shutdown subtask is added to the event pool, including: Based on the specific circumstances of the functional components, determine whether the generated shutdown subtask needs to be executed. If it is determined that execution is necessary, then a registration request for the shutdown subtask is initiated. If it is determined that no action is required, then the registration request for the shutdown subtask will not be initiated.

[0011] In some embodiments, it also includes: Receive timeout parameters and preset strategies associated with shutdown subtasks added to the event pool; If any shutdown subtask is not completed within the time limit specified by the timeout parameter, the shutdown subtask is marked as completed based on the preset strategy and removed from the event pool.

[0012] A control system, comprising at least: The control module is configured to, in response to a power-off signal, trigger a functional component in the embedded system to generate a corresponding power-off subtask, and disconnect the main power supply of the embedded system when the number of power-off subtasks in the event pool is zero.

[0013] The event pool module is configured to store shutdown subtasks; The task management module is configured to store the shutdown subtasks in an event pool in the embedded system, and to remove the corresponding shutdown subtask from the event pool in response to the completion of any shutdown subtask.

[0014] A computer-readable storage medium having stored thereon computer program instructions that, when executed by a processor, implement the control method described in any of the above embodiments.

[0015] The present invention has the following beneficial effects: The control method in this embodiment uses the zero number of shutdown sub-tasks in the event pool as the core condition for shutdown determination. This ensures that the system main power is cut off only after all shutdown sub-events are completed. There is no need for a fixed preset shutdown delay. This allows each functional component to complete the shutdown process autonomously before the system main power is cut off uniformly. This avoids the problems of abnormal status and data loss caused by excessively short delays, and also avoids unnecessary power consumption caused by excessively long delays. It effectively balances the reliability of the shutdown process and the energy efficiency of the system. Attached Figure Description

[0016] In drawings that are not necessarily drawn to scale, the same reference numerals may describe similar parts in different views. The drawings generally illustrate various embodiments by way of example rather than limitation and are used, together with the description and claims, to illustrate the disclosed embodiments. Where appropriate, the same reference numerals are used in all drawings to refer to the same or similar parts. Such embodiments are illustrative and not intended to be exhaustive or exclusive embodiments of the apparatus or method.

[0017] Figure 1 This is a flowchart of the control method provided in Embodiment 1 of the present invention; Figure 2 This is a flowchart of the control method provided in Embodiment 2 of the present invention; Figure 3 This is a flowchart of the control method provided in Embodiment 3 of the present invention; Figure 4 This is a flowchart of the control method provided in Embodiment 4 of the present invention; Figure 5 This is a diagram illustrating the composition of the control system provided in Embodiment 4 of the present invention. Detailed Implementation

[0018] To enable those skilled in the art to better understand the technical solution of this application, the application will be described in detail below with reference to the accompanying drawings and specific embodiments.

[0019] The following description, in conjunction with the accompanying drawings, details a specific scheme for a control method, a control system, and a computer-readable storage medium provided by the present invention.

[0020] Please see Figure 1 It shows a flowchart of a control method provided by an embodiment of the present invention.

[0021] This invention provides a control method, which includes: Step S100: In response to the power-off signal, trigger the functional components in the embedded system to generate the corresponding power-off subtask.

[0022] The shutdown signal can be a shutdown command actively triggered by the user (i.e., an externally generated shutdown signal) or a shutdown command automatically generated by the system based on the operating status (i.e., an internally generated shutdown signal). This embodiment does not impose specific restrictions on this.

[0023] When the system receives a shutdown signal from external sources (such as user operation or power management module) or internal sources (such as error status or policy determination), it can issue a one-time shutdown trigger event to all functional components. This shutdown trigger event is not a mandatory sequence of instructions, but rather a start signal to notify each functional component that the shutdown process has begun. Each functional component can generate a shutdown subtask adapted to its own current operating state. This shutdown subtask is used to complete customized shutdown operations such as saving its own operating state, refreshing cached data, and resetting mechanisms.

[0024] Step S200: Store the shutdown subtask in the event pool of the embedded system, and remove the corresponding shutdown subtask from the event pool in response to the completion of any shutdown subtask.

[0025] In this step, the event pool is a pre-set storage structure in the system used to uniformly manage all shutdown subtasks to be completed. Once any shutdown subtask is completed, it will be immediately removed from the event pool, and the number of remaining uncompleted shutdown subtasks in the event pool will be updated in real time.

[0026] Step S300: When the number of shutdown subtasks in the event pool is zero, disconnect the main power supply of the embedded system.

[0027] In this embodiment, the main power supply of the embedded system is disconnected after all the shutdown subtasks of all functional components have been executed, thus completing the entire shutdown process.

[0028] The control method in this embodiment uses the zero number of shutdown sub-tasks in the event pool as the core condition for shutdown determination. This ensures that the system main power is cut off only after all shutdown sub-events are completed. There is no need for a fixed preset shutdown delay. This allows each functional component to complete the shutdown process autonomously before the system main power is cut off uniformly. This avoids the problems of abnormal status and data loss caused by excessively short delays, and also avoids unnecessary power consumption caused by excessively long delays. It effectively balances the reliability of the shutdown process and the energy efficiency of the system.

[0029] like Figure 2 As shown, in some embodiments, the control method may further include: Step S400: Based on the mapping relationship between multiple shutdown subtasks and multiple power domains preset in the event pool, determine multiple subtask sets; wherein, each subtask set corresponds to a power domain, and each subtask set includes at least one shutdown subtask. In this system, multiple functional components can be powered by a single power domain. For example, multiple interface functional components connected to the same communication bus can share a single power domain, and multiple drive components of the same motion control group can correspond to the same power domain.

[0030] In this step S400, multiple functional components sharing the same power domain can form a set of subtasks. The system can pre-establish a mapping relationship between shutdown subtasks and power domains. Therefore, the shutdown subtasks in the event pool can be directly assigned to the subtask set of the corresponding power domain according to the mapping relationship.

[0031] Step S500: If any subtask set is empty, disconnect the power domain corresponding to that subtask set.

[0032] When all the shutdown subtasks of all functional components in the subtask set under the corresponding power domain have been completed, the subtask set becomes an empty set. At this time, the power domain corresponding to the subtask set can be cut off in advance to remove loads that no longer need power. There is no need to wait for all shutdown subtasks to be completed before powering off the power in a unified manner, which can further shorten the duration of unnecessary power supply, thereby reducing power consumption and risks at the end of shutdown.

[0033] A power domain typically includes both core and non-core power domains. For non-core power domains (such as communication interface power domains, sensor power domains, etc.), power can be cut off in advance as long as the corresponding sub-task set becomes empty.

[0034] However, core power domains (such as the main processing unit power domain, main memory power domain, or critical communication module power domain) are responsible for handling the final cleanup of the shutdown process and therefore cannot be prematurely shut down. Therefore, these core power domains can be considered as target power domains. In some embodiments, when the set of subtasks corresponding to these target power domains is empty, these target power domains are not disconnected first. Instead, the target power domains are kept powered until all shutdown subtasks in the event pool are completed before the target power domains are disconnected. This ensures that the shutdown control process itself can be completed normally and avoids premature disconnection of the core power supply, which would cause the shutdown process to be interrupted.

[0035] It should be noted that in this embodiment, regardless of whether the core power domain or the non-core power domain is cut off, the main power supply of the embedded system is finally cut off only after all shutdown sub-tasks have been completed. The hierarchical cutting off of power domains only cuts off the power supply to different functional groups in advance, without affecting the determination logic of the final disconnection of the main power supply. This can further optimize energy utilization efficiency while ensuring the reliability of the shutdown process.

[0036] like Figure 3 As shown, in some embodiments, before triggering the functional component in the embedded system to generate the corresponding shutdown subtask, the following steps are also included: Step S600: Determine whether the embedded system is in the power-off process.

[0037] Step S700: If the system is not in the shutdown process state, a shutdown version number is generated, which is used to identify the current shutdown process, and the system state is switched to the shutdown process state; if the system is already in the shutdown process state, the current shutdown signal is ignored.

[0038] In this embodiment, when the system is in normal operation, it continuously monitors shutdown signals from the outside or inside. When a shutdown signal is received, it is necessary to first determine whether the system is in the process of shutting down.

[0039] If the system has not yet entered the shutdown process state, the system generates a new shutdown version number and switches the system state to the shutdown process state.

[0040] If the system is already in the shutdown process, the shutdown signal is considered a repeated trigger, and the system will not restart the shutdown process to maintain the idempotency and consistency of the shutdown process.

[0041] The system may experience multiple repeated shutdown signals being triggered, such as when a user accidentally clicks the shutdown button multiple times, or when multiple signal sources issue shutdown commands simultaneously. By adding a shutdown status judgment and version number marking mechanism, the system can effectively avoid repeatedly triggering the shutdown process and prevent process chaos caused by adding shutdown subtasks multiple times.

[0042] In some embodiments, before storing the shutdown subtask in the event pool of the embedded system, the method further includes: Step S201: Obtain the version tag carried in each shutdown subtask, and determine whether the version tag is consistent with the shutdown version number; Step S202: If they match, then the corresponding shutdown subtask is allowed to be added to the event pool; if they do not match, then the corresponding shutdown subtask is prohibited from being added to the event pool.

[0043] In this embodiment, the system generates a unique shutdown version number each time a valid shutdown process is initiated, serving as the identification boundary for that shutdown process. All shutdown subtasks must carry a version tag, and this version tag must be consistent with the shutdown version number generated when the system shuts down.

[0044] If they are inconsistent, it means that the shutdown subtask belongs to the previous shutdown process that was not completed or has been completed. It will not participate in the execution of the current shutdown process. This can further avoid the process abnormality caused by the mixing of shutdown subtasks from different batches and ensure the independence and correctness of a single shutdown process.

[0045] Therefore, if the system receives a shutdown signal again during the shutdown process, the signal will not lead to the generation of a new shutdown version number or repeated broadcast; instead, it will be treated as a redundant event and ignored. If a shutdown subtask of a functional component attempts to carry an expired version tag or a version tag that does not match the version number, the shutdown subtask of that functional component will be refused entry into the event pool to avoid residual or ghost subtasks polluting the event pool.

[0046] like Figure 4 As shown, in some embodiments, the control method may further include: Step S800: Receive the timeout parameters and preset strategies associated with the shutdown subtask added to the event pool; In step S800, each shutdown subtask can be configured with associated timeout parameters by the corresponding functional component based on its maximum allowable timeout duration. The timeout parameters are used to limit the maximum allowable execution time of the shutdown subtask. At the same time, the functional component can also pre-specify the preset processing strategy corresponding to the timeout.

[0047] Step S900: If any shutdown subtask is not completed within the time limit specified by the timeout parameter, the shutdown subtask is marked as completed based on the preset strategy and removed from the event pool.

[0048] To prevent the event pool from never converging due to abnormal states of shutdown subtasks of single functional components, in this embodiment, the system sets a timeout parameter when generating corresponding shutdown subtasks. The corresponding timeout timer starts running when a shutdown subtask is initiated. If the shutdown subtask is completed within the timeout period, it is removed from the event pool according to the normal process. If the component has not completed its shutdown subtask by the timeout period, it can be marked as completed according to a predefined strategy and released from the event pool.

[0049] For example, when the event pool module or control module receives and stores the shutdown subtask, it will start a corresponding timeout timer. The initial time of the timer is the preset timeout parameter value (e.g., 2 seconds, 5 seconds, etc.).

[0050] If the functional component completes the shutdown subtask normally during the timeout timer's operation, the control module stops the timer and removes the subtask normally from the event pool.

[0051] If the shutdown subtask is not completed within the timeout period (e.g., the functional component fails to send a cancellation request due to abnormal freezing, communication interruption, or task execution time exceeding expectations), the control module marks the shutdown subtask as completed (i.e., considered an acceptable degraded completion) based on a preset strategy when the timer expires, and forcibly removes it from the event pool, while generating an audit record. This record is used for subsequent compensation or status recovery processes after power restoration.

[0052] The audit record may include at least one of the following information: the subtask identifier that timed out, the corresponding functional component information, the timestamp of the timeout, the type of preset strategy, and the compensation instruction for subsequent power restoration or health check.

[0053] Therefore, to prevent the event pool from never converging due to a single functional component's abnormal shutdown, thus blocking the entire shutdown process, even if individual functional components fail to complete their shutdown sub-tasks on time, the system can still force the event pool to converge to an "empty set" state through a preset strategy, thereby allowing the main power supply to be cut off and preventing the system from waiting indefinitely. At the same time, audit records provide a basis for subsequent fault diagnosis and state recovery.

[0054] In some embodiments, the shutdown subtask is stored in an event pool of the embedded system, and in response to the completion of any shutdown subtask, the corresponding shutdown subtask is removed from the event pool, including: Step S203: Based on the registration request of the shutdown subtask of the obtained functional component, add the corresponding shutdown subtask to the event pool; Step S204: If the shutdown subtask is completed, remove the corresponding shutdown subtask from the event pool based on the obtained deregistration request of the shutdown subtask of the corresponding functional component.

[0055] First, upon receiving a shutdown signal, the system sends a registration request for each shutdown subtask to the event pool module based on the actual needs of each functional component. This registration request includes at least the subtask's unique identifier, the corresponding functional component information, and the version number of the current shutdown process (if already generated). Upon receiving the registration request, the event pool adds the corresponding shutdown subtask to the event pool, indicating that the functional component has unfinished shutdown responsibilities.

[0056] Subsequently, after the functional component completes its local shutdown subtask (such as mechanism reset, state persistence, buffer refresh, etc.), the system sends a deregistration request for the corresponding subtask to the event pool module. Upon receiving the deregistration request, the event pool removes the shutdown subtask from the event pool, indicating that the functional component has released itself from its responsibility to block the main power supply cutoff.

[0057] In this embodiment, the registration and deregistration requests for the shutdown subtasks of functional components are executed atomically. This means the addition or removal process is uninterrupted; it either completes entirely or is not performed at all, ensuring data consistency in the event pool under a multi-tasking environment. Furthermore, the event pool only accepts the registration if the version number carried in the registration request matches the shutdown version number generated by the current shutdown process; if the version numbers do not match, registration is rejected, thus preventing residual events from the previous shutdown process from polluting the current event pool.

[0058] In some embodiments, the control method may further include: Step S205: The functional component determines whether it needs to execute the generated shutdown subtask based on its own situation.

[0059] In this step, the "self-condition" includes, but is not limited to: the current operating status of the functional component (whether it is busy, idle or erroneous), functional requirements (whether it is necessary to save status data, whether it is necessary to reset the hardware mechanism), and execution environment (current load, battery level, communication status, etc.).

[0060] For example, for a servo motor component, if it is currently in motion or not in its original position, the "retract servo" shutdown subtask needs to be executed; if it is already in the safe initial position, no action needs to be performed.

[0061] For file system components, if there is cached data that has not yet been written to disk, a shutdown subtask of "flushing the buffer and saving the file" needs to be executed; if there is no data to be written, this subtask is not required.

[0062] For the display component, if the backlight is still on or there is content in the display buffer, the shutdown subtask of "turn off backlight and clear screen" needs to be executed; if it is already off, it does not need to be executed.

[0063] In this embodiment, after receiving a shutdown trigger event, each functional component determines whether it needs to execute a shutdown subtask based on its current state and functional requirements. If a functional component determines that it does not need to perform any additional actions during the shutdown process (e.g., no state needs to be saved, no hardware needs to be reset), then the functional component does not create a shutdown subtask, nor does it affect the event pool state.

[0064] Step S206: If it is determined that execution is required, the functional component initiates a registration request for the shutdown subtask. If it is determined that execution is not required, the functional component does not initiate a registration request for the shutdown subtask.

[0065] In this step, if a functional component determines that a shutdown subtask needs to be executed, it will generate a corresponding subtask identifier and initiate a registration request to the event pool module, storing the subtask in the event pool to declare its responsibility for blocking the main power supply cutoff. If a functional component determines that no shutdown subtask needs to be executed, it will not initiate a registration request or add any record to the event pool; that is, the component will not affect the convergence judgment of the shutdown process.

[0066] Therefore, the creation, execution, and cancellation of each functional component's shutdown subtask are not controlled sequentially by the control module, and their completion time and order can be arbitrarily distributed.

[0067] like Figure 5 As shown in the embodiments of this application, a control system is also provided, which includes at least a control module, an event pool module, and a task management module.

[0068] The control module is configured to, in response to a power-off signal, trigger a functional component in the embedded system to generate a corresponding power-off subtask, and disconnect the main power supply of the embedded system when the number of power-off subtasks in the event pool is zero.

[0069] The control module can be integrated into the main controller of the embedded system or used as a separate power management unit. When the user presses the power button or the system generates a power-off signal, the control module first sends a power-off trigger event to the task management module via the internal bus or signal line. This trigger event can be a one-time broadcast signal or a point-to-point command sent one by one according to the address of the functional components.

[0070] In this embodiment, upon receiving a shutdown signal, the control module issues a one-time shutdown trigger event to the task management module. This trigger event simply indicates that "the system is about to shut down" and does not include any mandatory task order, completion time, or execution strategy. After the shutdown trigger is issued, the control module no longer intervenes in the shutdown behavior of individual functional components, but only continuously monitors the aggregate state of the event pool. As long as there are still shutdown subtasks in the event pool that have not been cancelled or completed, the control module maintains a waiting state; once the event pool converges to empty, the control module determines that all shutdown responsibilities that need to be executed have been released, and immediately triggers an irreversible main power cut-off action to complete the system shutdown.

[0071] The event pool module is configured to store shutdown subtasks.

[0072] The event pool module can be implemented using a dedicated area in the embedded system's memory, such as a linked list, queue, or hash set, to dynamically record currently incomplete shutdown subtasks. Each shutdown subtask can include information such as a task identifier, the corresponding functional component number, and the task type. The event pool module provides atomic add and remove interfaces to ensure data consistency in a multi-tasking environment.

[0073] The task management module is configured to generate corresponding shutdown subtasks for functional components and store them in the event pool of the embedded system based on the shutdown trigger event, and remove the corresponding shutdown subtask from the event pool when any shutdown subtask is completed.

[0074] The task management module can be software middleware running on the embedded system's main control chip, or it can be distributed in the local firmware of each functional component. When the task management module receives a shutdown trigger event sent by the control module, it determines which components need to execute shutdown subtasks (such as saving state, resetting mechanisms, refreshing buffers, etc.) based on the current operating status, functional requirements, and execution environment of each functional component. It generates a unique subtask identifier for each task that needs to be executed and then calls the add interface of the event pool module to store it.

[0075] During the execution of the shutdown subtask, each functional component operates independently without interfering with others. When a functional component completes its shutdown subtask, the task management module receives a completion notification and then calls the removal interface of the event pool module to delete the subtask from the event pool. The control module continuously monitors the number of subtasks in the event pool module. Once the number becomes zero, it determines that all necessary shutdown operations have been completed. At this point, the control module disconnects the main power supply of the embedded system through the main power control interface (such as a power management chip, relay, or load switch).

[0076] In this embodiment, upon receiving a shutdown signal, the task management module atomically registers each shutdown subtask to the event pool submodule. If a functional component does not require any additional action during the shutdown process, it does not need to create or register a shutdown subtask. After the functional component completes its local shutdown subtask, the task management module sends a deregistration request for the corresponding shutdown subtask to the event pool module. Upon receiving the deregistration request, the event pool module removes the shutdown subtask from the event pool, indicating that the functional component has released itself from its responsibility to interrupt the main power supply.

[0077] This embodiment achieves a shutdown coordination mechanism that does not rely on fixed delays or fixed sequences through the division of labor and cooperation of the control module, event pool module and task management module. It ensures that the main power is cut off only after all critical shutdown tasks are actually completed, thereby avoiding data loss and component failure to reset, and also eliminating unnecessary waiting power consumption.

[0078] This application also provides a computer-readable storage medium storing computer program instructions thereon, which, when executed by a processor, implement the control method described in any of the above embodiments.

[0079] This application is described with reference to flowchart illustrations and / or block diagrams of methods and apparatus according to embodiments of this application. It will 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 program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes. These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes. These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1The steps of the function specified in one or more boxes.

[0080] The above embodiments are merely exemplary embodiments of this application and are not intended to limit this application. Those skilled in the art can make various modifications or equivalent substitutions to this application within the scope and nature of this application, and such modifications or equivalent substitutions should also be considered to fall within the scope of protection of this application.

Claims

1. A control method, characterized in that, include: In response to a power-off signal, the functional components in the embedded system are triggered to generate a corresponding power-off subtask; The shutdown subtask is stored in the event pool of the embedded system, and in response to the completion of any shutdown subtask, the corresponding shutdown subtask is removed from the event pool. When the number of shutdown subtasks in the event pool is zero, disconnect the main power supply of the embedded system.

2. The control method as described in claim 1, characterized in that, Also includes: Based on the mapping relationship between multiple shutdown subtasks and multiple power domains in the event pool, multiple subtask sets are determined; each subtask set corresponds to a power domain, and each subtask set includes at least one shutdown subtask. If any subtask set is empty, disconnect the power domain corresponding to that subtask set.

3. The control method as described in claim 2, characterized in that, The plurality of power domains include the target power domain, and further include: When the set of subtasks corresponding to the target power domain is empty, keep the target power domain powered until the number of shutdown subtasks in the event pool is zero, and then cut off the target power domain.

4. The control method as described in claim 1, characterized in that, Before triggering the corresponding shutdown subtask generated by the functional component in the embedded system, the following steps are also included: Determine if the embedded system is in the power-off process; If the system is not in the shutdown process, a shutdown version number is generated. The shutdown version number is used to identify the current shutdown process, and the system state is switched to the shutdown process. If the device is already in the process of shutting down, ignore the current shutdown signal.

5. The control method as described in claim 4, characterized in that, Before storing the shutdown subtask in the event pool of the embedded system, the following steps are also included: Retrieve the version tag carried in each shutdown subtask; Determine whether the version tag is consistent with the shutdown version number; If they match, the corresponding shutdown subtask can be added to the event pool. If they are inconsistent, the corresponding shutdown subtask should not be added to the event pool.

6. The control method as described in claim 1, characterized in that, The shutdown subtask is stored in the event pool of the embedded system, and in response to the completion of any shutdown subtask, the corresponding shutdown subtask is removed from the event pool, including: Based on the registration requests of the shutdown subtasks of the obtained functional components, the corresponding shutdown subtasks are added to the event pool; Upon completion of the shutdown subtask, the corresponding shutdown subtask is removed from the event pool based on the obtained deregistration request for the shutdown subtask of the corresponding functional component.

7. The control method as described in claim 6, characterized in that, Based on the registration requests for shutdown subtasks of the acquired functional components, the corresponding shutdown subtasks are added to the event pool, including: Based on the specific circumstances of the functional components, determine whether the generated shutdown subtask needs to be executed. If it is determined that execution is necessary, then a registration request for the shutdown subtask is initiated. If it is determined that no action is required, then the registration request for the shutdown subtask will not be initiated.

8. The control method as described in claim 1, characterized in that, Also includes: Receive timeout parameters and preset strategies associated with shutdown subtasks added to the event pool; If any shutdown subtask is not completed within the time limit specified by the timeout parameter, the shutdown subtask is marked as completed based on the preset strategy and removed from the event pool.

9. A control system, characterized in that, At least including: The control module is configured to, in response to a power-off signal, trigger a functional component in the embedded system to generate a corresponding power-off subtask, and disconnect the main power supply of the embedded system when the number of power-off subtasks in the event pool is zero. The event pool module is configured to store shutdown subtasks; The task management module is configured to store the shutdown subtasks in an event pool in the embedded system, and to remove the corresponding shutdown subtask from the event pool in response to the completion of any shutdown subtask.

10. A computer-readable storage medium having computer program instructions stored thereon, characterized in that, When the computer program instructions are executed by the processor, they implement the control method according to any one of claims 1 to 8.

Images