Vehicle task execution method and device, vehicle controller and vehicle

Abstract

The application relates to a vehicle-mounted task execution method and device, a vehicle-mounted controller and a vehicle. The method comprises the following steps: obtaining a first expected execution time of a first reserved task located at a top of a memory priority queue; the memory priority queue is used for storing registration requests of different reserved tasks; the registration request comprises an expected execution time of the reserved task and a client identifier of a client for executing the reserved task; determining a wake-up duration of the first reserved task based on the first expected execution time and a current first time; writing the wake-up duration into a wake-up register; and in response to an interrupt signal generated by the wake-up register, broadcasting the first reserved task to clients in the vehicle which subscribe to a first target client identifier corresponding to the first reserved task, so that the first target client in the clients executes the first reserved task; and the interrupt signal is an interrupt signal generated by the wake-up register when the wake-up duration reaches after the wake-up register is written with the wake-up duration. The application can realize low-power wake-up of a task.

Description

Technical Field

[0001] This invention relates to the field of vehicle networking technology, specifically to an in-vehicle task execution method, an in-vehicle task execution device, an in-vehicle controller, and a vehicle. Background Technology

[0002] With the development of vehicle-to-everything (V2X) technology, vehicles need to handle a large number of timed tasks with precise timing requirements, such as OTA upgrades, timed charging, and vehicle wake-up. This requires scheduling and execution of these tasks.

[0003] In related technologies, a dynamic priority timer combined with a multi-level time wheel structure can be used to schedule and execute tasks by hierarchical management and preemptive scheduling. However, in this approach, the time wheel algorithm in the multi-level time wheel structure needs to push the pointer to rotate at a fixed frequency periodically. Even if no task has expired, the CPU needs to be woken up at a fixed frequency, resulting in a large number of invalid wake-ups and wasted resources. Summary of the Invention

[0004] One objective of this invention is to provide an in-vehicle task execution method to solve the problem of frequent invalid wake-ups and wasted CPU resources during in-vehicle timed task scheduling in the prior art; a second objective is to provide an in-vehicle task execution device; a third objective is to provide an in-vehicle controller; and a fourth objective is to provide a vehicle.

[0005] To achieve the above objectives, the technical solution adopted by the present invention is as follows: A vehicle-mounted task execution method, applied to a vehicle-mounted controller, includes: obtaining a first expected execution time for a first scheduled task located at the top of a memory priority queue; wherein the memory priority queue is used to store registration requests for different scheduled tasks; the registration request includes the expected execution time of the scheduled task and an identifier of the client executing the scheduled task; determining a wake-up duration for the first scheduled task based on the first expected execution time and the current first time; writing the wake-up duration into a wake-up register, and in response to an interrupt signal generated by the wake-up register, broadcasting the first scheduled task to clients in the vehicle that subscribe to the first target client identifier corresponding to the first scheduled task, so that the first target client in the client executes the first scheduled task; the interrupt signal is an interrupt signal generated by the wake-up register from the start of the wake-up duration being written until the wake-up duration is reached.

[0006] Based on the above technical means, by obtaining the first expected execution time of the task at the top of the memory priority queue, and calculating the wake-up duration based on this time and the current system time, writing the wake-up duration into the wake-up register, and using the wake-up register to generate an interrupt signal at a precise time, the invalid wake-up overhead caused by the periodic advancement of the time wheel in the prior art can be avoided, thereby achieving low-power wake-up of tasks and reducing the static power consumption of the whole vehicle.

[0007] In some embodiments, obtaining the first expected execution time of the first reservation task located at the top of the memory priority queue includes: receiving a registration request for the reservation task sent by the vehicle's client; and, if the registration request is inserted into the memory priority queue based on the expected execution time of the registration request, obtaining the first expected execution time of the first reservation task located at the top of the memory priority queue.

[0008] Based on the above technical means, by using a memory priority queue with a min-heap data structure to maintain the scheduled tasks, it is possible to use the expected execution time of each scheduled task in the memory priority queue as the sorting key, ensuring that the top of the memory priority queue is always the earliest expiring task. This can reduce the time complexity of the scheduled task insertion operation, improve the efficiency of task registration and scheduling, and reduce system overhead.

[0009] In some embodiments, broadcasting the first reservation task to a client in the vehicle that subscribes to the first target client identifier corresponding to the first reservation task includes: in response to an interrupt signal generated by a wake-up register, obtaining the current second time; when the first expected execution time is less than or equal to the current second time, determining that the first reservation task has expired, broadcasting the first reservation task to the client in the vehicle that subscribes to the first target client identifier corresponding to the first reservation task; when the first expected execution time is greater than or equal to the current second time, determining that the first reservation task has not expired, re-determining the wake-up duration based on the first expected execution time and writing it into the wake-up register, and controlling the vehicle controller to enter a sleep state.

[0010] Based on the aforementioned technical methods, by verifying the relationship between the expected execution time of a task and the current time, it is possible to accurately determine whether a task has expired, thus avoiding false or missed wake-ups due to time drift or abnormal adjustments. Furthermore, for tasks that have not yet expired, the wake-up duration is recalculated and written to the wake-up register, and the vehicle controller is controlled to enter sleep mode, maximizing low-power operation time.

[0011] In some embodiments, the registration request further includes a task type for the reservation task, the task type including a periodic task; based on the expected execution time of the registration request, inserting the registration request into a memory priority queue based on a min-heap data structure includes: if the first reservation task is a periodic task, and the reservation task corresponding to the registration request is broadcast, obtaining the preset execution interval of the first reservation task from the registration request of the first reservation task; determining the next second expected execution time of the first reservation task based on the first expected execution time and the preset execution interval, and updating the registration request of the first reservation task based on the second expected execution time; inserting the updated registration request of the first reservation task into the memory priority queue based on the second expected execution time.

[0012] Based on the above technical means, for periodic tasks, after they expire and are broadcast, the next execution time can be automatically calculated, and the updated task can be re-inserted into the priority queue without the need for business modules to participate in the re-registration process. This avoids the problem of time drift caused by the time consumption of task execution or the uncertainty of the re-registration timing, and ensures the time determinism of periodic tasks.

[0013] In some embodiments, the method further includes: when the expected execution time of multiple second reservation tasks in the memory priority queue is less than or equal to the time difference between the expected execution time and the first expected execution time, the multiple second reservation tasks are popped from the priority queue in sequence until the expected execution time of the top task is greater than the current system time or the queue is empty; and the multiple second reservation tasks are broadcast to the clients that subscribe to the second target client identifiers corresponding to the multiple second reservation tasks.

[0014] Based on the aforementioned technical methods, when multiple tasks expire at the same time or within a very short period, continuously popping up and broadcasting these tasks can prevent omissions due to task density, thereby improving the completeness and timeliness of task processing. Furthermore, batch processing of tasks nearing their expiration date can reduce the overhead of repeated wake-ups and resource scheduling, improving the overall scheduling efficiency of vehicle reservation tasks.

[0015] In some embodiments, the registration request further includes a task identifier for the reservation task; obtaining the first expected execution time of the first reservation task located at the top of the heap in a memory priority queue for storing registration requests for different reservation tasks includes: receiving a task cancellation request sent by a client, the task cancellation request being used to request the cancellation of at least one registered reservation task, the task cancellation request including a target task identifier of the reservation task to be cancelled; setting a cancellation flag for the reservation task to be cancelled in the memory priority queue according to the target task identifier; if a cancellation flag is detected for the first reservation task, deleting the first reservation task and determining a new first reservation task from multiple reservation tasks in the memory priority queue; obtaining the first expected execution time of the new first reservation task.

[0016] Based on the aforementioned technical methods, by setting a cancellation flag in the tasks to be cancelled, the task is only actually deleted when it becomes the top of the heap and is popped. This avoids the time complexity overhead of traversal searching and improves the efficiency of task cancellation operations. Simultaneously, when the task to be cancelled becomes the top task, an RTC reconfiguration is immediately triggered, ensuring the accuracy of system scheduling.

[0017] In some embodiments, the method further includes: storing registration requests for different reservation tasks in the non-volatile memory of the vehicle controller; and, when broadcasting the first reservation task to a client in the vehicle that subscribes to the first target client identifier corresponding to the first reservation task, marking the registration request corresponding to the first reservation task stored in the non-volatile memory as executed.

[0018] Based on the aforementioned technical methods, by synchronously writing the registration requests of different reservation tasks into non-volatile memory, it can be ensured that the reservation tasks will not be lost after the vehicle's control system is reset, power is lost, or OTA upgrade restarts, thus improving the reliability of task scheduling. Simultaneously, marking the task as executed after broadcast facilitates subsequent task status management.

[0019] In some embodiments, the method further includes: when the vehicle controller starts, reading all unexecuted registration requests by scanning non-volatile memory; for each unexecuted registration request, if the expected execution time of the unexecuted registration request is later than the current third time, re-inserting the unexecuted registration request into the memory priority queue; if the expected execution time of the unexecuted registration request is earlier than or equal to the current third time, deleting the unexecuted registration request.

[0020] Based on the aforementioned technical means, when the vehicle controller starts up, it can automatically recover unexecuted tasks from non-volatile memory, rebuild the priority queue, and ensure the reliable execution of critical scheduled tasks such as timed charging and timed wake-up. Simultaneously, expired tasks are cleaned up to prevent invalid tasks from consuming system resources, thereby improving system operating efficiency.

[0021] In some embodiments, the method further includes: controlling the vehicle controller to enter a sleep state when the wake-up duration is written to the wake-up register, until an interrupt signal sent by the wake-up register is received.

[0022] Based on the aforementioned technical means, the RTC hardware wake-up mechanism allows the vehicle's control system to enter a deep sleep state when no tasks need to be processed, maintaining only the RTC circuitry. This significantly reduces the vehicle's static power consumption and extends battery life. Furthermore, the wake-up process is directly triggered by hardware, resulting in fast response and low latency, ensuring timely task execution.

[0023] An in-vehicle task execution device includes: an acquisition module for acquiring a first expected execution time of a first scheduled task located at the top of a memory priority queue; wherein the memory priority queue is used to store registration requests for different scheduled tasks, the registration request including the expected execution time of the scheduled task and the client identifier for executing the scheduled task; a determination module for determining the wake-up duration of the first scheduled task based on the first expected execution time and the current first time; and a broadcast module for writing the wake-up duration into a wake-up register and, in response to an interrupt signal generated by the wake-up register, broadcasting the first scheduled task to clients in the vehicle that have subscribed to the first target client identifier corresponding to the first scheduled task, so that the first target client in the client executes the first scheduled task, wherein the interrupt signal is an interrupt signal generated by the wake-up register from the start of the wake-up duration being written until the wake-up duration is reached.

[0024] An on-board controller is provided for implementing on-board task execution methods.

[0025] A vehicle, the vehicle including an onboard controller.

[0026] The beneficial effects of this invention are: By obtaining the first expected execution time of the top task in the memory priority queue and calculating the wake-up duration based on this time and the current system time, and writing the wake-up duration into the wake-up register, the wake-up register can generate an interrupt signal at a precise moment. This avoids the invalid wake-up overhead caused by the periodic advancement of the time wheel in the existing technology, thereby achieving low-power wake-up of tasks and reducing the static power consumption of the whole vehicle. Attached Figure Description

[0027] Figure 1 This is a schematic flowchart of an in-vehicle task execution method provided in an embodiment of this application; Figure 2 This is a schematic diagram of the structure of a vehicle-mounted task execution device provided in an embodiment of this application; Figure 3 This is a schematic flowchart of another vehicle-mounted task execution method provided in an embodiment of this application; Figure 4 This is a flowchart illustrating a method for scheduling and executing vehicle-mounted tasks according to an embodiment of this application; Figure 5 This is a schematic diagram illustrating an application of a priority queue based on a min-heap data structure provided in an embodiment of this application; Figure 6 This is an execution interaction flowchart of an on-board controller provided in an embodiment of this application; Figure 7 This is a schematic diagram of the software architecture of an on-board controller performing task scheduling according to an embodiment of this application; Figure 8This is a schematic diagram of a task recovery and initialization process provided in an embodiment of this application; Figure 9 This is a schematic diagram of an end-to-end interaction process of an on-board controller executing a scheduled charging task, provided in an embodiment of this application. Detailed Implementation

[0028] The embodiments of the present invention will be described below with reference to the accompanying drawings and preferred embodiments. Those skilled in the art can easily understand other advantages and effects of the present invention from the content disclosed in this specification. The present invention can also be implemented or applied through other different specific embodiments, and various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of the present invention. It should be understood that the preferred embodiments are only for illustrating the present invention and not for limiting the scope of protection of the present invention.

[0029] It should be noted that the illustrations provided in the following embodiments are only schematic representations of the basic concept of the present invention. Therefore, the drawings only show the components related to the present invention and are not drawn according to the actual number, shape and size of the components in the actual implementation. In the actual implementation, the form, quantity and proportion of each component can be arbitrarily changed, and the layout of the components may also be more complex.

[0030] Currently, with the development of vehicle-to-everything (V2X) technology, vehicles need to handle a large number of timed tasks with precise timing requirements, such as OTA upgrades, timed charging, and vehicle wake-up. This requires scheduling and execution of these tasks; timed task scheduling must simultaneously meet the dual requirements of low-power sleep and high-precision wake-up.

[0031] In related technologies, a scheduling scheme based on multi-level time wheels and dynamic priority preemption can be adopted. Specifically, regardless of whether there are any timed tasks about to be triggered in the current task pool, an interrupt can be forcibly triggered once in each interrupt cycle through a hardware timer with a fixed frequency. This forces the CPU (Central Processing Unit) to exit from a low-power state, check the linked list in the current time slot, and migrate expired tasks to the next level, and then recalculate the current time pointer. Using this method, even if the task pool is empty or the most recent trigger time is much greater than the current interrupt interval, these cascading operations are still executed indiscriminately, resulting in the number of invalid wake-ups of the CPU per unit time being proportional to the interrupt frequency. In addition, multi-level time wheels have non-uniform latency when handling cross-level task insertion: when high-precision tasks (such as microsecond-level) are mapped to fine-grained time slots, if overflow cascading occurs at the level where the slot is located, it is necessary to re-hash the tasks in multiple upper-level slots to the lower level at once. The execution time of this operation is approximately linearly related to the cascading scale, causing sudden jitter in scheduling latency.

[0032] To address the aforementioned technical problems, this application provides an in-vehicle task execution method, an in-vehicle task execution device, an in-vehicle controller, and a vehicle. By obtaining the first expected execution time of the task at the top of the memory priority queue, calculating the wake-up duration based on this time and the current system time, and writing the wake-up duration into the RTC wake-up register, the RTC hardware generates an interrupt signal at a precise moment. This avoids the invalid wake-up overhead caused by the periodic advancement of the time wheel in the prior art, thereby achieving low-power wake-up of tasks and reducing the static power consumption of the entire vehicle.

[0033] To clearly understand the technical solution of this application, the following key concepts are explained below: 1) Min-heap: A special binary tree data structure where the value of each node is no greater than the value of its child nodes, therefore the root node (heap top) is always the smallest element in the entire set. In this application, a min-heap is used to construct a memory priority queue, using the expected execution time of tasks as the sorting key to ensure that the top element of the heap is the earliest expiring task in the entire system. The time complexity of inserting a new task is O(log n), and the time complexity of retrieving the top element of the heap is O(1), providing efficient priority management capabilities.

[0034] 2) Real-Time Clock Wakeup Register (RTC WakeupRegister): A configurable register located in the Real-Time Clock (RTC) hardware module, used to set the alarm time. When the RTC timer reaches the set value, a hardware interrupt signal is generated, waking up the main processor or related modules. This application calculates the difference between the current time and the expected execution time of the earliest expiring task, and writes this difference as the wakeup duration into the RTC wakeup register, thereby achieving precise and low-power timed wakeup.

[0035] 3) Event Broadcast Mechanism: An asynchronous communication mode in which the scheduling core (such as the expiration handling module) does not directly call the business module to execute a task after detecting its expiration. Instead, it broadcasts a task expiration event to all business modules in the system that have subscribed to the corresponding client identifier through the interface module. Each business module pre-registers a listener callback and decides whether to handle the event upon receiving it. This mechanism achieves loose coupling between the scheduling core and the business modules, supports independent compilation, deployment, and upgrades of modules, and effectively isolates the impact of business execution failures on the scheduling system.

[0036] Figure 1 This is a schematic flowchart of an in-vehicle task execution method provided in an embodiment of this application. The following will be combined with... Figure 1The steps shown are explained below. The vehicle task execution method provided in the embodiments of this application can be applied to a vehicle controller, which may be a body domain controller, a smart cockpit domain controller, an autonomous driving domain controller, or a vehicle remote communication terminal TBOX, etc. This vehicle controller can be used to schedule and execute multiple scheduled tasks.

[0037] Step S101: Obtain the first expected execution time of the first scheduled task located at the top of the heap in the memory priority queue.

[0038] The memory priority queue can be used to store registration requests for different scheduled tasks. Each registration request includes the expected execution time of the scheduled task and the identifier of the client executing the task.

[0039] In this embodiment, the memory priority queue can be a memory-based data structure that includes multiple nodes. Each node stores a registration request for a scheduled task. The nodes can be organized into a min-heap structure according to the expected execution times of the scheduled tasks. Since the min-heap structure satisfies the condition that the expected execution time of any parent node is no greater than the expected execution time of its child nodes, the expected execution time of the top node is the minimum among all nodes. Therefore, the first scheduled task at the top of the memory priority queue is the earliest task to be executed among all current registration requests.

[0040] A registration request is a scheduled task creation instruction submitted by a client (such as an in-vehicle application, remote service platform, or in-vehicle diagnostic module) to the in-vehicle controller. Each registration request includes at least the expected execution time of the scheduled task and the identifier of the client executing the scheduled task. The expected execution time indicates the specific time the client expects the scheduled task to be triggered; the client identifier uniquely identifies the client requesting the task, such as in charging management services, OTA upgrade services, or timed heating services. The client identifier serves as a marker of task ownership and is used for subsequent event broadcasting and task execution matching.

[0041] For example, a user can set a charging reservation task to start charging at 8:00 the next day through an in-vehicle application. The in-vehicle application can send the registration request corresponding to the charging reservation task to the vehicle controller. The registration request corresponding to the charging reservation task includes the expected execution time (e.g., 08:00:00 the next day) and the client identifier (e.g., the process identifier pointing to the charging management service). Then, the registration request corresponding to the charging reservation task can be added to the memory priority queue.

[0042] In practice, the first expected execution time of the first scheduled task at the top of the memory priority queue can be obtained by directly accessing the root node of the min-heap. Specifically, the pointer to the top node of the memory priority queue can point to the node with the shortest expected execution time among all current registration requests, allowing the vehicle controller to obtain the first expected execution time of the first scheduled task without traversing the queue.

[0043] In some embodiments, if the scheduled task at the top of the memory priority queue changes, the first expected execution time of the first scheduled task at the top of the memory priority queue can be obtained.

[0044] In one possible implementation, upon receiving a new registration request for a scheduled task from a client, the registration request can be inserted into a memory priority queue. In this case, if the scheduled task at the top of the memory priority queue is changed to the registration request of the newly inserted scheduled task, or if the memory priority queue only contains the registration request of the newly inserted scheduled task, the first expected execution time of the current top-of-the-heap task can be obtained to calculate the wake-up duration and write it to the wake-up register.

[0045] In another possible implementation, if the initial scheduled task at the top of the memory priority queue has been processed, the initial scheduled task can be popped from the memory priority queue. The task with the shortest expected execution time among the remaining scheduled tasks in the memory priority queue becomes the new top task. In this case, the first expected execution time of the current top task is obtained, used to calculate the wake-up duration, and written to the wake-up register to configure the next wake-up. If the priority queue becomes empty after popping the initial scheduled task, there is no need to obtain the first expected execution time; the vehicle controller can enter indefinite sleep mode, waiting for a new task registration event.

[0046] Step S102: Determine the wake-up duration of the first scheduled task based on the first expected execution time and the current first time.

[0047] Here, "current first time" can be the current time obtained by the vehicle controller when performing this step. "Wake-up duration" can refer to the time difference between the current time obtained by the vehicle controller when performing this step and the expected execution time of the first scheduled task.

[0048] In this step, the wake-up duration of the first scheduled task can be determined from the time difference between the current time obtained by the vehicle controller when performing this step and the expected execution time of the first scheduled task.

[0049] Step S103: Write the wake-up duration into the wake-up register, and in response to the interrupt signal generated by the wake-up register, broadcast the first reservation task to the client in the vehicle that subscribes to the first target client identifier corresponding to the first reservation task, so that the first target client in the client executes the first reservation task.

[0050] The interrupt signal is the interrupt signal generated when the wake-up register starts counting from the start of the wake-up duration and the wake-up duration is reached. The wake-up register can be implemented using an RTC wake-up register. The RTC can be a hardware timing module with independent power supply, continuous timing and programmable wake-up interrupt capability. The RTC can be integrated into the vehicle controller or it can be an external independent chip.

[0051] In this embodiment, the wake-up register may further include a timer. The wake-up register can be used to store the wake-up duration written to the vehicle controller as a preset alarm time value, and the timer can maintain power supply and timing functions even when the vehicle controller is in sleep mode. The wake-up register is used to precisely control the wake-up timing of scheduled tasks, avoiding power waste and time errors caused by software polling. For example, when the vehicle is parked with the engine off, the vehicle controller system can set the wake-up duration to 10 hours, and the RTC wake-up register will generate an interrupt after 10 hours to precisely wake up the scheduling core processing task.

[0052] An interrupt signal can be an electrical signal actively emitted by the wake-up register when the preset alarm time is reached. It notifies the vehicle controller that the first expected execution time of the first scheduled task has arrived. The interrupt signal is directly transmitted to the vehicle controller's processor via a hardware interrupt mechanism, featuring high priority and low latency, ensuring timely response to tasks within milliseconds. The generation of the interrupt signal does not rely on software polling, fundamentally eliminating the unnecessary wake-up overhead of periodic checks and significantly reducing system power consumption. For example, in a TBOX remote scheduled charging scenario, the interrupt signal is generated precisely at 8:00 AM the next day, waking the system to execute the charging task without frequently waking the CPU during the waiting period.

[0053] In this embodiment, when the vehicle controller writes the wake-up duration into the wake-up register, the wake-up register can store the wake-up duration written by the vehicle controller as a preset alarm time value. When the timer's count value is equal to the preset alarm time value stored in the wake-up register, it triggers an internal comparator to generate a matching event, and the interrupt control logic of the wake-up register generates a hardware interrupt signal. This interrupt signal can directly wake up the vehicle controller, which is in a deep sleep state, through the interrupt controller. The vehicle controller can then respond to the interrupt signal generated by the wake-up register from the start of the wake-up duration writing until the wake-up duration is reached, and broadcast the first scheduled task to the client in the vehicle that subscribes to the first scheduled task corresponding to the first target client identifier, so that the first target client in the client executes the first scheduled task.

[0054] In practical implementation, after the vehicle controller writes the wake-up duration to the timer in the wake-up register, it can enter a deep sleep state. In this state, the main CPU clock of the vehicle controller stops, most peripherals are powered off, and only the RTC hardware module in the wake-up register and the necessary CAN bus wake-up circuit are powered. The timer continuously increments under independent power supply. When its count reaches the preset alarm time value stored in the wake-up register, the comparator inside the wake-up register triggers a matching event, and the interrupt control logic of the wake-up register generates a hardware interrupt signal. This interrupt signal wakes the main CPU of the vehicle controller from deep sleep through the interrupt controller. The CPU resumes its clock and powers on again. The top-ranked scheduled task in the memory priority queue can be popped. The vehicle controller can broadcast the expiration event to the clients that have subscribed to the client identifier corresponding to the first scheduled task through the interface module, and the corresponding client executes the first scheduled task.

[0055] In some embodiments, the client and the vehicle controller can interact using a subscription-broadcast communication mechanism. Specifically, each client can pre-register to listen for a specific client identifier through the task expiration subscription interface provided by the interface module. After the vehicle controller is woken up by a wake-up register interrupt and pops the top task, it can broadcast a first scheduled task expiration event to all clients. The broadcast content includes at least the client identifier executing the first scheduled task and the unique identifier of the first scheduled task. Upon receiving the broadcast event, each client determines whether the client identifier executing the first scheduled task carried in the event matches its own pre-registered identifier. If a match is found, the corresponding business processing logic is invoked to execute the task.

[0056] In some embodiments, when the wake-up duration is written to the wake-up register, the vehicle controller is controlled to enter a sleep state until an interrupt signal sent by the wake-up register is received.

[0057] Based on the above technical means, by obtaining the first expected execution time of the task at the top of the memory priority queue, and calculating the wake-up duration based on this time and the current system time, writing the wake-up duration into the wake-up register, and using the wake-up register to generate an interrupt signal at a precise time, the invalid wake-up overhead caused by the periodic advancement of the time wheel in the prior art can be avoided, thereby achieving low-power wake-up of tasks and reducing the static power consumption of the whole vehicle.

[0058] In some embodiments, step S101 described above can be implemented by the following steps.

[0059] Step S1011: Receive the registration request for the reservation task sent by the vehicle's client.

[0060] A registration request refers to a task reservation application initiated by an internal or external client (such as an in-vehicle application, remote service platform, diagnostic module, etc.) to the in-vehicle controller. A registration request may include, but is not limited to, the expected execution time of the reserved task, the client identifier for executing the reserved task, the unique identifier of the reserved task, and the task payload data.

[0061] In practical applications, users can set a charging reservation task to start charging at 8:00 the next day through the vehicle application. The vehicle application can send the registration request corresponding to the charging reservation task to the vehicle controller. The registration request corresponding to the charging reservation task includes at least the expected execution time (e.g., 08:00:00 the next day), the client identifier (e.g., the process identifier pointing to the charging management service), and the task payload data (e.g., the target battery percentage, charging power limit, etc.).

[0062] After receiving the registration request, the interface module of the vehicle controller can generate a globally unique task identifier based on the task payload data in the registration request, and combine the task identifier with the data of each field in the registration request to form task metadata.

[0063] Step S1012: Based on the expected execution time of the registration request, insert the registration request into a memory priority queue based on a min-heap data structure, and obtain the first expected execution time of the first reservation task located at the top of the heap in the memory priority queue.

[0064] In some embodiments, registration requests can first be inserted into a memory priority queue based on a min-heap data structure, based on the expected execution time of the registration request.

[0065] In this embodiment, the memory priority queue uses a min-heap as its underlying data structure. Each node in the memory priority queue stores a registration request for a scheduled task, and the expected execution time in the registration request is used as the sorting key. When inserting a registration request into the memory priority queue, the new registration request can be added as a new node to the end of the heap. Then, through a floating-up operation, the expected execution time of the new node is compared with that of its parent node. If the time of the new node is less than that of its parent node, their positions are swapped until the heap property is restored, that is, the time of any parent node is no greater than that of its child node.

[0066] Thus, the time complexity of inserting a registration request into the memory priority queue is O(log n), where n is the number of tasks currently stored in the priority queue. After insertion, the top node of the heap is the task with the shortest expected execution time among all current registration requests, which is the first scheduled task. At this point, the time complexity of obtaining the expected execution time of the top node is O(1). Compared to the O(n) time complexity caused by the existing centralized management scheme requiring traversal of the global linked list or array to find the nearest task, this scheme can still obtain the nearest trigger time in constant time when the task scale increases, significantly reducing the computational overhead on the scheduling hot path and avoiding scheduling delay jitter caused by a surge in the number of tasks.

[0067] In a practical application scenario, if the currently scheduled task at the top of the memory priority queue is an OTA upgrade at 3:00 AM the next day, and a user adds an emergency diagnostics scheduled task at 2:45 AM the next day, the vehicle controller, upon receiving the registration request for the emergency diagnostics scheduled task, can insert it into the memory priority queue according to its expected execution time. Since 2:45 AM is earlier than the execution time of the original scheduled task at the top of the queue, 3:00 AM, the newly added scheduled task becomes the new scheduled task at the top of the queue.

[0068] Based on the above technical means, by using a memory priority queue with a min-heap data structure to maintain the scheduled tasks, it is possible to use the expected execution time of each scheduled task in the memory priority queue as the sorting key, ensuring that the top of the memory priority queue is always the earliest expiring task. This can reduce the time complexity of the scheduled task insertion operation, improve the efficiency of task registration and scheduling, and reduce system overhead.

[0069] Considering that during the actual operation of the vehicle-mounted embedded system, the RTC hardware timing may experience clock drift due to the cumulative error caused by crystal oscillator temperature drift, or the system clock may jump due to manual adjustment, network time synchronization, or abnormal reset, in some embodiments, the above step S103 can be implemented by the following steps.

[0070] Step S1031: In response to the interrupt signal generated by the wake-up register, obtain the current second time.

[0071] The second time can also refer to the current time obtained by the vehicle controller when performing this step.

[0072] It should be noted that the first time is the system time read by the vehicle controller when it obtains the first expected execution time. The purpose of the first time is to serve as a benchmark for calculating the wake-up duration. At this time, the vehicle controller has not yet entered sleep mode and is in normal operation. The current time value can be obtained through the system clock or the timer in the wake-up register. The second time is the current time read by the vehicle controller after it is woken up. The second time is the actual time used for verification after wake-up. At this time, the vehicle controller recovers from deep sleep mode and can obtain the current time value again through the system clock or the timer.

[0073] Step S1032: When the first expected execution time is less than or equal to the current second time, determine that the first reservation task has expired, and broadcast the first reservation task to the client in the vehicle that subscribes to the first target client identifier corresponding to the first reservation task.

[0074] The first expected execution time is the specific time point at which the client will execute the first scheduled task, as specified by the business layer during task registration. This first expected execution time serves as the basis for task scheduling, determining when the first scheduled task is deemed due. For example, in a task where a user schedules charging for 8:00 AM the next day, the first expected execution time is 8:00 AM the next day. The vehicle controller uses this time as a reference to calculate the wake-up duration and configure the RTC register.

[0075] In this step, when the first expected execution time is less than or equal to the current second time, that is, when the current time of the vehicle controller (i.e. the current second time) has reached or exceeded the set first expected execution time, it indicates that the scheduled task should be processed immediately.

[0076] For example, if the current second time of the vehicle controller is 8:00 the next day, and the first expected execution time of the first reservation task is also 8:00 the next day, then the vehicle controller determines that the first reservation task has expired and broadcasts the first reservation task to the client in the vehicle that subscribes to the first target client identifier corresponding to the first reservation task.

[0077] Step S1033: When the first expected execution time is greater than or equal to the current second time, it is determined that the first scheduled task has not expired. The wake-up duration is re-determined based on the first expected execution time and written into the RTC wake-up register. The vehicle controller is then controlled to enter a sleep state.

[0078] In this step, if the first expected execution time is greater than or equal to the current second time, it indicates that the execution time set for the first scheduled task has not yet arrived, and the vehicle controller needs to continue waiting. At this time, the vehicle controller will not immediately process the first scheduled task but needs to reschedule the next wake-up time to avoid unnecessary resource consumption. For example, if the current time is 7:59 the next day, and the first expected execution time is 8:00 the next day, the vehicle controller determines that the first scheduled task has not expired and needs to wait for the remaining 1 minute.

[0079] In one possible implementation, if the first scheduled task has not expired, the wake-up duration can be redefined based on the first expected execution time and written into the RTC wake-up register, and the vehicle controller can be controlled to enter a sleep state.

[0080] In practice, the second time obtained after the interrupt wake-up can be compared with the first expected execution time of the first scheduled task. If the first expected execution time is greater than or equal to the second time, the task is determined not to have expired. At this time, the vehicle controller does not perform any event broadcasting or task dispatching operations, but directly uses the first expected execution time as the target time and calculates the difference between it and the second time as the new wake-up duration. This new wake-up duration is then rewritten into the wake-up register, overwriting the original alarm setting. After configuration, the vehicle controller enters deep sleep mode again, the main CPU clock stops, and only the RTC module and necessary wake-up circuits are powered, waiting for the next interrupt.

[0081] It should be noted that since the first scheduled task remains the top task in the memory priority queue, its expected execution time has not changed. Therefore, during wake-up reconfiguration, no insertion, deletion, or adjustment operations need to be performed on the priority queue. The wake-up duration only needs to be recalculated based on the expected execution time of the current top task. If a new registration request is inserted during the hibernation period and its expected execution time is earlier than the current top task, the new task will become the new top task. In this case, RTC reconfiguration will be triggered according to the rules in step S1012, using the expected execution time of the new top task as the benchmark.

[0082] Based on the aforementioned technical methods, by verifying the relationship between the expected execution time of a task and the current time, it is possible to accurately determine whether a task has expired, thus avoiding false or missed wake-ups due to time drift or abnormal adjustments. Furthermore, for tasks that have not yet expired, the wake-up duration is recalculated and written to the wake-up register, and the vehicle controller is controlled to enter sleep mode, maximizing low-power operation time.

[0083] Considering that most scheduled tasks are not executed once, but need to be triggered periodically at fixed time intervals (such as daily scheduled wake-up, weekly scheduled charging, hourly scheduled vehicle status reporting, etc.), if the periodic tasks are re-registered each time by actively reporting the registration request by the client, the client needs to calculate the next trigger time and re-initiate the registration request. This will cause the client to not only focus on its own business logic, but also manage the scheduling logic such as periodic calculation and task registration interface calls, which increases the development complexity and error probability of the business module. Moreover, if the client crashes or exits abnormally due to software defects, the re-registration process of the periodic tasks will be interrupted, resulting in the permanent loss of subsequent periodic tasks. Therefore, in some embodiments, the above step S101 may include the following steps.

[0084] Step S1013: If the first reservation task is a periodic task, and the reservation task corresponding to the registration request is broadcast, obtain the preset execution interval of the first reservation task from the registration request of the first reservation task.

[0085] In this embodiment, the registration request also includes the task type of the scheduled task, which includes periodic tasks. The task type can be used to identify the execution mode of the scheduled task, and the execution mode can include, but is not limited to, one-time tasks and periodic tasks. Among them, one-time tasks are triggered only once at the set expected execution time and become invalid after completion; periodic tasks are executed repeatedly at preset time intervals after the first execution. For example, in an in-vehicle system, timed charging can be set as a one-time task (such as charging at 8:00 tomorrow), while timed silent restart can be set as a periodic task (such as restarting at 3:00 every morning).

[0086] In practical applications, when a client submits a scheduled task, the task type information can be added to the registration request. For example, the remote diagnostics service module can submit a periodic task that executes every 24 hours to check the vehicle status; while the OTA upgrade service module typically submits a one-time task that is triggered only when a specific version update is released.

[0087] If the first reservation task is determined to be a periodic task, and the reservation task corresponding to the registration request is broadcast, the preset execution interval of the first reservation task can be obtained from the registration request of the first reservation task.

[0088] The preset execution interval refers to the time difference between two consecutive executions of a periodic task. The preset execution interval can be specified by the client when registering the periodic task, such as every 15 minutes or 3:00 AM every day.

[0089] In actual execution, the preset execution interval can be stored in the registration request of the first scheduled task and used as a benchmark parameter for calculating the next execution time. For example, if the expected execution time of a task is 08:00 on April 5, 2025, and the preset execution interval is 24 hours, then its next execution time should be 08:00 on April 6, 2025. In the vehicle controller, when the first scheduled task is broadcast (i.e., determined to have expired), the vehicle controller can extract the preset execution interval from the registration request of the first scheduled task.

[0090] Step S1014: Determine the next second expected execution time of the first scheduled task based on the first expected execution time and the preset execution interval, and update the registration request of the first scheduled task based on the second expected execution time.

[0091] The second expected execution time can refer to the absolute time when the first scheduled task is a periodic task, after the current execution cycle ends, when it should be triggered next. For example, if the expected execution time of the current task is 08:00 on April 5, 2025, and the preset execution interval is 24 hours, then the second expected execution time is 08:00 on April 6, 2025.

[0092] In this embodiment, after the second expected execution time is calculated, the vehicle controller can update the registration request of the first scheduled task based on the second expected execution time. Specifically, the expected execution time field in the registration request can be replaced with the second expected execution time, and the executed flag of the first scheduled task can be removed, making it participate in subsequent scheduling as a new task to be executed.

[0093] Step S1015: Based on the second expected execution time, insert the updated registration request of the first scheduled task into the memory priority queue.

[0094] In this step, the updated registration request is sorted by the second expected execution time and re-enters the memory priority queue through a min-heap insertion operation. Since the second expected execution time is necessarily later than the current time, the task will be inserted into an appropriate position in the heap and will not immediately become the top of the heap. After the insertion is completed, if the newly inserted task becomes the new top of the heap (i.e., its second expected execution time is earlier than the current top task), the wake-up reconfiguration process is triggered; otherwise, the system remains in its current sleep state, waiting for the existing top task to expire.

[0095] Based on the above technical means, for periodic tasks, after they expire and are broadcast, the next execution time can be automatically calculated, and the updated task can be re-inserted into the priority queue without the need for business modules to participate in the re-registration process. This avoids the problem of time drift caused by the time consumption of task execution or the uncertainty of the re-registration timing, and ensures the time determinism of periodic tasks.

[0096] Considering that in practical automotive applications, there may be situations where the expected execution times of multiple scheduled tasks differ very little, if the conventional process of processing only one task at the top of the stack during each interruption and reconfiguring for the next wake-up is followed, the vehicle controller would recalculate the wake-up duration and go back to sleep after processing each task, only to be woken up again after several seconds or even milliseconds, leading to a surge in invalid wake-up overhead. In some embodiments, the method further includes the following steps.

[0097] Step S104: If the expected execution time of multiple second scheduled tasks in the memory priority queue is less than or equal to the time difference between the expected execution time of the first scheduled task and the expected execution time of the first scheduled task, then the multiple second scheduled tasks are popped out of the priority queue in sequence until the expected execution time of the top task is greater than the current system time or the queue is empty.

[0098] The preset duration threshold can be used to determine the width of the time window when scheduled tasks expire simultaneously. The preset duration threshold can be set according to the real-time requirements and power consumption budget of the vehicle controller, for example, it can be set to 1 millisecond, 10 milliseconds or 100 milliseconds, etc., and this application does not limit it in this regard.

[0099] In this step, after the vehicle controller is woken up by a single interrupt, while processing the first scheduled task popped from the memory priority queue, it does not immediately configure the next wake-up. Instead, it continues to check the relationship between the expected execution time of the new top-of-the-heap task (i.e., the second scheduled task) and the current system time (i.e., the second time). If the difference between the expected execution time of the second scheduled task and the current system time is less than or equal to a preset duration threshold, it can be determined that the second scheduled task and the first scheduled task belong to the same expiration batch and should be processed together in this round of wake-up.

[0100] After the second scheduled task is popped from the memory priority queue, the vehicle controller can continue to check the next new top task and repeat the above judgment and popping operation until the expected execution time of the top task is greater than the current system time (i.e., it exceeds the time window) or the priority queue is empty.

[0101] Step S105: Broadcast multiple second reservation tasks to the clients that subscribe to the second target client identifiers corresponding to the multiple second reservation tasks.

[0102] In this step, the vehicle controller can perform the same expiration broadcast operation as the first reservation task for each popped-up second reservation task. Specifically, for each second reservation task, the vehicle controller can broadcast an expiration event to all clients, and the broadcast content must include at least the client identifier and task unique identifier of the second reservation task. After receiving the broadcast event, each client matches its registered listener callback according to the client identifier, and the successfully matched client independently executes the business logic corresponding to the second reservation task.

[0103] It should be noted that all broadcast operations for the second scheduled tasks are completed within the same RTC interrupt handling context, and there is no issue of subsequent task triggering delays caused by the broadcasting time of the preceding task. Furthermore, if a second scheduled task is a periodic task, after broadcasting the task, the expiration processing module, following the automatic re-registration process of steps S1013 to S1015, calculates the next trigger time based on its expected execution time and preset execution interval, and re-inserts the updated registration request into the memory priority queue.

[0104] After all expired tasks (including the first scheduled task and all second scheduled tasks) have completed broadcasting and periodic re-registration, the expiration processing module checks whether the priority queue is empty: if the queue is not empty, the next wake-up is configured based on the expected execution time of the current top task; if the queue is empty, the system enters indefinite hibernation, waiting for the next task registration event.

[0105] Based on the aforementioned technical methods, when multiple tasks expire at the same time or within a very short period, continuously popping up and broadcasting these tasks can prevent omissions due to task density, thereby improving the completeness and timeliness of task processing. Furthermore, batch processing of tasks nearing their expiration date can reduce the overhead of repeated wake-ups and resource scheduling, improving the overall scheduling efficiency of vehicle reservation tasks.

[0106] In some embodiments, the registration request may also include a task identifier for the scheduled task; step S101 above may also be implemented through the following steps.

[0107] Step S1016: Receive a task cancellation request sent by the client.

[0108] The task cancellation request is used to request the cancellation of at least one registered scheduled task. The task cancellation request includes the target task identifier of the scheduled task to be cancelled; the task identifier can be used to uniquely identify the scheduled task.

[0109] In practical applications, users can cancel previously scheduled charging tasks via a mobile app. For example, if a user originally planned to start charging at 8:00 AM the next day but needs to cancel due to a change in travel plans, the user can send a cancellation command via the mobile app. This command is forwarded to the vehicle controller via the vehicle networking platform, carrying the target task identifier of the charging reservation task to be canceled. After receiving the task cancellation request, the vehicle controller can parse the target task identifier from the cancellation request.

[0110] Step S1017: Based on the target task identifier, set the cancellation flag for the scheduled tasks to be cancelled in the memory priority queue.

[0111] In this step, after the vehicle controller parses the target task identifier, it can determine the target node corresponding to the target task identifier from the memory priority queue through a preset mapping relationship. After locating the target node, a cancellation flag can be set in the data structure of the target node to indicate that the task has been cancelled. In this case, the target node still physically exists in the memory priority queue and has not been removed; the min-heap structure and sorting properties of the memory priority queue remain unchanged.

[0112] Step S1018: If a cancellation flag is detected for the first reservation task, the first reservation task is deleted, and a new first reservation task is determined from multiple reservation tasks in the memory priority queue.

[0113] The first scheduled task refers to the current top task of the heap.

[0114] In this step, after the vehicle control module is interrupted and woken up, when broadcasting the first reservation task to the client corresponding to the first target client identifier that subscribed to the first reservation task in the vehicle, if the cancellation flag bit of the current top task node in the memory priority queue is detected to be true, it is determined that the first reservation task has been cancelled and no broadcasting or dispatching operation should be performed.

[0115] If it is determined that the first scheduled task has been cancelled, the node can be physically removed from the min-heap, releasing the memory resources it occupies. After deletion, the heap structure is automatically adjusted, and the task with the next minimum expected execution time at the original heap top becomes the new heap top, i.e., the new first scheduled task. If multiple consecutively cancelled nodes still exist in the heap after deletion, the above detection and deletion process is repeated until the task at the heap top no longer has a cancellation flag or the queue is empty.

[0116] This ensures that canceled tasks are actually cleaned up when they become the top of the heap, avoiding invalid expiration processing and guaranteeing that only valid tasks awaiting execution are always scheduled in the heap.

[0117] Compared to existing technologies, task cancellation operations typically require traversing the global task list or array to find the target node of the task to be cancelled and physically delete it, resulting in a time complexity of O(n), where n is the total number of tasks in the task pool. When the task size is large, each cancellation operation requires a linear scan of the entire task pool, leading to a significant increase in latency on the scheduling hot path. Moreover, existing solutions often employ an immediate deletion strategy, meaning that once a cancellation request is received, the node is immediately removed from the data structure, triggering heap adjustments or linked list reorganization operations. In scenarios with frequent task cancellations (such as users repeatedly modifying charging plans or OTA upgrade tasks being rescheduled multiple times), this strategy can lead to substantial heap adjustment overhead, and each adjustment may trigger unnecessary reconfiguration, increasing system power consumption.

[0118] By adopting the above technical solution, the cancellation operation only involves one lookup and flag assignment, without triggering heap structure adjustment, which can avoid the O(log n) heap adjustment overhead caused by immediate deletion in the traditional solution; moreover, RTC reconfiguration is only triggered when the canceled top heap task is actually popped, instead of recalculating the wake-up time after each cancellation operation, reducing unnecessary RTC register write operations and system wake-up times.

[0119] Step S1019: Obtain the first expected execution time of the new first scheduled task.

[0120] The specific execution method in this step can be referred to step S101, and the specific steps will not be repeated here.

[0121] Based on the aforementioned technical methods, by setting a cancellation flag in the tasks to be cancelled, the task is only actually deleted when it becomes the top of the heap and is popped. This avoids the time complexity overhead of traversal searching and improves the efficiency of task cancellation operations. Simultaneously, when the task to be cancelled becomes the top task, an RTC reconfiguration is immediately triggered, ensuring the accuracy of system scheduling.

[0122] In some embodiments, the method further includes the following steps.

[0123] Step S106: Store the registration requests for different reservation tasks into the non-volatile memory of the vehicle controller.

[0124] Non-volatile memory refers to storage media that can retain data after power failure or system reset. In vehicle controllers, it is usually implemented using technologies such as eMMC, UFS, or dedicated Flash partitions.

[0125] In practical applications, when a client initiates a reservation task registration request, the vehicle controller generates a globally unique task identifier and combines this identifier with fields from the registration request to form task metadata. Subsequently, the vehicle controller can synchronously write the task metadata to a designated partition of non-volatile memory. For example, when a user sets a reservation charging task for 8:00 AM the next day via a mobile app, upon receiving the registration request for that reservation charging task, the vehicle controller can write the corresponding task metadata to the non-volatile memory.

[0126] This ensures that registration request data for scheduled tasks is not lost in the event of system malfunction or restart, thereby enabling reliable task recovery and continuous scheduling, and ultimately improving the overall stability of the vehicle system and the user experience.

[0127] In step S107, when broadcasting the first reservation task to the client that subscribes to the first target client identifier corresponding to the first reservation task in the vehicle, the registration request corresponding to the first reservation task stored in the non-volatile memory is marked as executed.

[0128] In this step, after the reservation task is successfully broadcast and the business module is triggered to execute, the vehicle controller can update the task status of the executed reservation task to avoid duplicate execution or waste of resources.

[0129] Specifically, when broadcasting the first reservation task to a client in the vehicle that subscribes to the first target client identifier corresponding to the first reservation task, if the first reservation task is a one-time task, the registration request corresponding to the first reservation task can be marked as executed in non-volatile memory. This marking process can be achieved by adding a status field to the task's metadata or by recording the identifier ID of the executed task in a specific index table.

[0130] In actual implementation, when the charging management service receives a scheduled task expiration event and begins executing the charging logic, the vehicle controller can update the task metadata status corresponding to the registration request of the first scheduled task to "executed". For example, in the TBOX system, the status field in the task metadata of TASK_001 can be changed from pending to executed, and synchronously written back to non-volatile memory.

[0131] Based on the aforementioned technical methods, by synchronously writing the registration requests of different reservation tasks into non-volatile memory, it can be ensured that the reservation tasks will not be lost after the vehicle's control system is reset, power is lost, or OTA upgrade restarts, thus improving the reliability of task scheduling. Simultaneously, marking the task as executed after broadcast facilitates subsequent task status management.

[0132] In some embodiments, when the vehicle controller starts, it can first read all unexecuted registration requests by scanning the non-volatile memory; then for each unexecuted registration request, if the expected execution time of the unexecuted registration request is later than the current third time, the unexecuted registration request is reinserted into the memory priority queue; if the expected execution time of the unexecuted registration request is earlier than or equal to the current third time, the unexecuted registration request is deleted.

[0133] In actual implementation, when the vehicle controller restarts due to power failure, OTA upgrade, or MCU reset, it can initiate a scanning process. Specifically, it can locate the task persistence area through a preset file system path or partition identifier and read the records in the task persistence area one by one to obtain all unexecuted registration requests. Each record contains key fields such as the expected execution time of the unexecuted registration request, client identifier, task unique identifier, task type flag, and task payload.

[0134] For each registration request that is restored, the vehicle controller can verify the relationship between its expected execution time and the current third time (i.e., the current system time restored when the system starts). If the expected execution time is later than the current third time, it indicates that the trigger time for the task has not yet arrived, and it is a valid future task. In this case, the registration request can be passed to the priority queue module, which will then reinsert it into the min-heap-based memory priority queue in O(log n) time complexity, restoring its position in the scheduling system. If the expected execution time is earlier than or equal to the current third time, it indicates that the task should have been triggered during system hibernation or shutdown, but has now timed out.

[0135] For such timed-out tasks, one possible implementation is to directly delete the task record and clear it from non-volatile memory to prevent it from remaining in the system as invalid data. Another possible implementation is to treat it as an expired task, immediately trigger an expiration broadcast, and let the corresponding client decide whether to re-execute it. For example, if a timed wake-up task has expired, it can skip this execution and wait for the next cycle; while if a timed charging task has expired, it can immediately perform the charging operation.

[0136] After all recovered records have been processed, the vehicle controller can check if the memory priority queue is empty. If the queue is not empty, the wake-up configuration process is triggered based on the expected execution time of the current top task, so that the vehicle controller sets the correct wake-up time before the first hibernation. If the queue is empty, the system enters indefinite hibernation, waiting for new task registration events.

[0137] Based on the aforementioned technical means, when the vehicle controller starts up, it can automatically recover unexecuted tasks from non-volatile memory, rebuild the priority queue, and ensure the reliable execution of critical scheduled tasks such as timed charging and timed wake-up. Simultaneously, expired tasks are cleaned up to prevent invalid tasks from consuming system resources, thereby improving system operating efficiency.

[0138] Figure 2 This is a schematic diagram of the structure of a vehicle-mounted task execution device provided in an embodiment of this application, as shown below. Figure 2 As shown, the vehicle-mounted task execution device 200 includes an acquisition module 201, a determination module 202, and a broadcast module 203.

[0139] The acquisition module 201 is used to acquire the first expected execution time of the first scheduled task located at the top of the heap in the memory priority queue; wherein, the memory priority queue is used to store registration requests for different scheduled tasks; the registration request includes the expected execution time of the scheduled task and the client identifier for executing the scheduled task; The determination module 202 is used to determine the wake-up duration of the first scheduled task based on the first expected execution time and the current first time; The broadcast module 203 is used to write the wake-up duration into the wake-up register and, in response to the interrupt signal generated by the wake-up register, broadcast the first reservation task to the client in the vehicle that subscribes to the first reservation task corresponding to the first target client identifier, so that the first target client in the client executes the first reservation task. The interrupt signal is the interrupt signal generated by the wake-up register from the start of the wake-up duration writing until the wake-up duration is reached.

[0140] The description of the above device-side embodiments is similar to the description of the above method embodiments, and has similar beneficial effects. For technical details not disclosed in the device embodiments of this application, please refer to the description of the method embodiments of this application for understanding.

[0141] The following describes the application of the vehicle-mounted task execution provided in the embodiments of this application in a real-world scenario, mainly involving a multi-process scheduled task processing method based on priority queues and RTC wake-up.

[0142] With the rapid development of intelligent connected vehicles and autonomous driving technologies, the in-vehicle application layer and middleware layer need to manage a large number of timed tasks with strict timing requirements. Typical scenarios include: timed wake-up checks, timed execution of OTA upgrades, timed charging, timed silent restarts, timed heating, and timed parking.

[0143] One implementation uses a dynamic priority timer combined with a multi-level time wheel structure to manage tasks hierarchically and improve responsiveness through preemptive scheduling. This scheme leverages the collaborative work of a dynamic priority timer, a dynamic linked list task pool, and a preemptive scheduling engine to address issues such as resource waste in scheduled task scheduling, inefficiency in handling periodic tasks, and poor real-time performance of high-priority tasks. Specifically, the dynamic priority timer includes multi-level time wheels and a priority queue to achieve hierarchical task management and prioritized triggering.

[0144] However, this approach suffers from low wake-up accuracy and high overhead. Specifically, the time wheel algorithm detects task expiration by periodically ticking the wheel pointer. Regardless of whether any tasks in the time wheel are about to expire, the system needs to wake up the CPU at a fixed frequency to drive the pointer. This mechanism generates a large number of invalid wake-up events when the number of tasks is large but the task density is sparse, resulting in unnecessary CPU resource consumption.

[0145] In another implementation, a centralized timed task management system can be used. The timed task manager obtains the time difference between the time of the next timed task and the current global time and sends it to the timer, and then enters sleep mode. The timer responds to the time difference to set a timed alarm. When the alarm is reached, a timed interrupt is sent to wake up the timed task manager to execute the task.

[0146] However, this approach requires maintaining an additional thread for managing scheduled tasks, and when there are a large number of tasks, the time complexity for registering a new task and finding the next scheduled task when a scheduled task expires is O(n). Furthermore, the scheduled task management and execution logic remain coupled in this scheme.

[0147] Moreover, both of the above implementation methods exhibit varying degrees of coupling in the architectural relationship between the scheduling core and the task execution body. The scheduling thread often directly undertakes or waits for the task execution logic, resulting in severe compilation dependencies, high coupling between modules, and difficulty in system expansion and maintenance. When task execution involves time-consuming operations (such as network I / O or complex calculations), it will block the triggering of subsequent tasks, leading to increased task triggering latency jitter.

[0148] In summary, there is an urgent need for a high-performance, general-purpose timed task scheduling solution in existing vehicle-mounted timed task scheduling technologies that can achieve high-precision triggering at the millisecond level, keep runtime overhead at an extremely low level, and fully decouple the scheduling core from the task execution logic.

[0149] Based on the above-mentioned technical problems, this application proposes an in-vehicle task execution method to solve the following technical problems: (1) How to reduce system overhead while ensuring millisecond-level trigger accuracy. In the prior art, one solution uses a time wheel to periodically advance the pointer. This solution continues to advance the pointer even when there is no task, resulting in idle power consumption. Another solution uses a centralized search for the earliest task and then sets a single wake-up. When there are many tasks, the process of searching for the earliest task consumes a lot of computing resources, resulting in limited search efficiency.

[0150] (2) How to achieve complete decoupling between the scheduling core and the task execution body in the automotive heterogeneous multi-core SoC architecture. In the existing solution, there is a tight coupling between the scheduling module and the execution module. This coupling relationship leads to mutual dependence during compilation, which increases the cost of system expansion and maintenance. Furthermore, when a blockage occurs during task execution, it will directly affect the accuracy of task triggering.

[0151] In some embodiments, the vehicle controller for executing the vehicle task execution method may include a priority queue module (i.e., the memory priority queue in the above embodiments), an expiration processing module, a task persistence module, and an interface module.

[0152] The priority queue module employs a minheap data structure to implement the priority queue. Each node in the queue stores a scheduled task object, which includes at least the expected execution time of the scheduled task, the client identifier, the task's unique identifier, and a task type flag (one-time task or periodic task). The priority queue is sorted according to the expected execution time of the tasks, with the first element (top element of the heap) being the earliest expiring task in the entire queue.

[0153] The expiration handling module is responsible for handling the expiration logic of scheduled tasks. First, it broadcasts the scheduled task expiration event, with the broadcast content being the client identifier. Then, it retrieves the expected execution time of the top-of-the-heap task from the priority queue module, calculates the difference between this time and the current system time as the wake-up duration, and writes the wake-up duration into the RTC wake-up register via the system interface.

[0154] The task persistence module is responsible for the non-volatile storage management of task metadata. All registered scheduled tasks are synchronously written to the vehicle controller's non-volatile memory before entering the priority queue or when the task status changes. When the system restarts due to abnormal reset, power failure, or OTA upgrade, the task persistence module is responsible for recovering unexpired tasks from the vehicle controller's non-volatile memory and rebuilding the priority queue.

[0155] The interface module is used to provide a unified appointment task management API to the business layer (i.e., the client in the above embodiment), including task creation, task cancellation, task update interfaces, and task expiration subscription interfaces.

[0156] Figure 3 This is a schematic diagram of another vehicle-mounted task execution method provided in an embodiment of this application, such as... Figure 3 As shown, the method includes the following steps.

[0157] Step S301: Receive the appointment task registration request from the client through the interface module.

[0158] The registration request includes at least the following fields: expected execution time, client identifier, task unique identifier, task type flag (one-time task or periodic task), and task payload data.

[0159] Step S302: Generate a globally unique task identifier for each registration request through the interface module, and combine the task identifier with the fields in the registration request to form task metadata.

[0160] Step S303: The task metadata is synchronously written to the non-volatile memory of the vehicle controller through the task persistence module.

[0161] Step S304: Pass the task metadata to the priority queue module through the task persistence module.

[0162] In this step, the priority queue module inserts the task into a memory priority queue implemented using a min-heap data structure. The time complexity of the insertion operation is O(log n), where n is the number of tasks currently stored in the priority queue. The sorting key of the min-heap is the expected execution time of the task, and the first element of the queue (the top element of the heap) is always the task with the earliest expected execution time in the entire system.

[0163] If the priority queue module determines that the newly inserted task becomes the top task of the heap or the priority queue was originally empty and the new task becomes the only top task of the heap, then step S305 is executed. If the priority queue module determines that the newly inserted task will not become the top task of the heap, the task registration process ends and the system continues to maintain its current sleep or standby state.

[0164] Step S305: Write the wake-up duration into the wake-up register through the timer configuration module.

[0165] In this step, the expected execution time of the current top task and the current system time can be obtained from the priority queue module. The wake-up duration can be calculated based on the time difference between the expected execution time of the current top task and the current system time. Then, the wake-up duration can be written to the wake-up register through the timer configuration module.

[0166] Step S306: A hardware interrupt signal is generated by the wake-up register to wake up the main CPU and scheduling core of the vehicle controller.

[0167] In this step, when the RTC hardware timer reaches the preset alarm time (i.e., wake-up duration), the RTC generates a hardware interrupt signal to wake up the main CPU and scheduling core.

[0168] Step S307: Obtain and pop the top task from the priority queue module through the expiration processing module.

[0169] In this step, after the expiration handling module is awakened, it retrieves and pops the top task from the priority queue module. It then verifies the relationship between the task's expected execution time and the current system time: if the expected execution time is less than or equal to the current system time, the task is determined to have expired.

[0170] Step S308: Broadcast the expiration event through the expiration processing module.

[0171] In this step, the scheduled task expiration event can be broadcast to all business modules in the system that have subscribed to the client identifier. The broadcast content must include at least the client identifier and the task's unique identifier.

[0172] Step S309: Periodic task processing is performed through the expiration processing module.

[0173] In this step, the task type flag of the currently expiring task can be checked through the expiration handling module. If the task is a periodic task, the expiration handling module will immediately calculate the next expected execution time of the task after the broadcast event, and then call the task update process after the calculation is completed.

[0174] Step S310: Process other tasks that expire at the same time in the queue through the expiration processing module.

[0175] In this step, since multiple tasks may have the same or very close expected execution time, the expiration handling module continues to check new top-of-the-heap tasks. If their expected execution time is also less than or equal to the current system time, the expiration event is popped up and broadcast together until the expected execution time of the top-of-the-heap task is greater than the current system time or the queue is empty.

[0176] In step S311, if the top task retrieved from the priority queue has not yet expired after verification, the expiration handling module does not broadcast the event, but directly triggers the wake-up register based on the expected execution time of the task.

[0177] In step S312, the client responds to the expiration event and executes the reservation task.

[0178] In this step, each client pre-registers a listener callback for a specific client identifier through the task expiration subscription interface provided by the interface module. When a client receives a scheduled task expiration event broadcast by the expiration handling module, it determines whether the event it needs to handle is the client identifier carried in the event. If it is determined to be the client's assigned identifier, the corresponding business logic is invoked. The client executes the task by invoking the corresponding business logic based on the task type.

[0179] If the priority queue is determined to be non-empty by the expiration processing module, proceed to step S305; If the priority queue is determined to be empty by the expiration processing module, the expiration processing module will no longer configure RTC wake-up, and the system will enter indefinite hibernation until the next task registration event will wake up the system.

[0180] Step S313: When the vehicle controller starts up after a reset, power failure restart or OTA upgrade, the task metadata in the non-volatile memory is restored through the task persistence module.

[0181] In this step, when the vehicle controller starts after a reset, power failure restart, or OTA upgrade, the task persistence module first scans the task persistence area in the non-volatile memory. The task persistence module reads all persistent but not yet executed or canceled task metadata records. For each recovered task record, it verifies the relationship between its expected execution time and the current system time. If the expected execution time is earlier than the current system time, the task is marked as a timeout task and can be handled according to a preset strategy (such as immediately triggering an expiration broadcast or directly discarding it); if the expected execution time is later than the current system time, it is passed to the priority queue module and re-inserted into the memory priority queue.

[0182] If the priority queue is determined to be non-empty by the expiration processing module, proceed to step S305; If the priority queue is determined to be empty by the expiration processing module, the expiration processing module will no longer configure RTC wake-up, and the system will enter indefinite hibernation until the next task registration event will wake up the system.

[0183] This application embodiment, on the one hand, can fundamentally eliminate the invalid wake-up overhead caused by periodic polling by using a precise wake-up mechanism based on a min-heap priority queue and RTC hardware collaboration, while ensuring millisecond-level triggering accuracy. Furthermore, the top element of the priority queue can always maintain the earliest expiring task, and the system is only woken up by the RTC hardware at the actual expiration time of the top task, reducing the number of invalid wake-ups to a theoretical minimum. The min-heap data structure achieves O(log n) time complexity for task enqueueing and O(1) time complexity for top-of-the-heap retrieval, resulting in significant performance advantages in large-scale task scenarios. Simultaneously, events such as new task registration, task cancellation, or updates only trigger RTC reconfiguration when they affect the top task, further reducing unnecessary system wake-ups and RTC register operations.

[0184] On the other hand, a fully decoupled scheduling-execution architecture can be achieved based on event broadcasting and business callbacks. An interface module provides a task expiration subscription interface to the business layer. The expiration handling module is only responsible for task expiration determination and event broadcasting. Business modules receive expiration events through pre-registered listener callbacks and independently execute their business logic. There are no compilation dependencies between the scheduling core and business modules, allowing for independent compilation, deployment, and upgrades, meeting the actual needs of modular development and OTA upgrades for in-vehicle software. When task execution involves time-consuming operations, it does not block the scheduling core's expiration determination and RTC configuration for subsequent tasks, significantly reducing task trigger latency jitter.

[0185] On the other hand, task persistence and system startup recovery capabilities can be achieved based on non-volatile storage. The task persistence module synchronously writes task metadata to non-volatile storage during task registration and state changes. When the system restarts after a reset, power failure, or OTA upgrade, the task persistence module can fully recover unexpired scheduled tasks from NVM and rebuild the priority queue, ensuring the reliable execution of critical scheduled operations (such as timed wake-up and timed charging), meeting the stringent reliability requirements of automotive scenarios.

[0186] Fourthly, combining RTC hardware wake-up with deep system sleep can reduce the vehicle's static power consumption. Specifically, in scenarios where the vehicle is parked for extended periods after the engine is off, the scheduling core completes RTC configuration and the control system enters deep sleep mode. The main CPU and most peripherals cease operation, with only the RTC circuit maintaining microamp-level current consumption. The system is only woken up by an RTC hardware interrupt when a task expires. After processing, it immediately configures the next wake-up and re-enters sleep mode, maximizing the low-power sleep duration and significantly extending battery life.

[0187] Fifthly, this application can completely encapsulate the calculation and registration of the next execution time of periodic tasks within the server-side expiration handling module. The next trigger time is calculated based on an absolute time base, eliminating cumulative drift and ensuring the time determinism of periodic tasks. Simultaneously, business modules do not need to understand the concept of a period; they only need to focus on the business logic of a single execution, reducing the development complexity of the business layer.

[0188] This application provides an embodiment, which uses a vehicle-mounted remote communication terminal (TBOX) as an example for illustration. Specifically, it includes a user setting a scheduled charging task for 8:00 AM the next day via a mobile APP, with the vehicle currently in a parked, off-center state.

[0189] First, task registration and persistence can be performed.

[0190] After a user sets up a scheduled charging task via a mobile app, the cloud platform sends a task registration request to TBOX. This registration request includes the following fields: the expected execution time is 8:00 AM the next day, the client identifier is "Charging Management Service", the task type is a one-time task (e.g., TASK_001), and the task payload data includes the target battery capacity and charging power limit.

[0191] Upon receiving the registration request, the TBOX interface module first generates a globally unique task identifier and combines this identifier with the fields in the registration request to form task metadata. Subsequently, the interface module calls the task persistence module to synchronously write the task metadata into the non-volatile partition of the TBOX's built-in eMMC, ensuring that the scheduled task will not be lost even if a momentary power outage or MCU reset occurs during the subsequent waiting period.

[0192] After persistence is complete, the interface module calls the priority queue module to insert the task metadata into a memory priority queue implemented using a min-heap data structure. The time complexity of the insertion operation is O(log n), where n is the number of tasks currently stored in the priority queue. The sorting key of the min-heap is the expected execution time of the task; therefore, the top element of the heap is always the task with the earliest expected execution time in the entire system. Since there are currently no other scheduled tasks in the system, TASK_001 becomes the only task node in the priority queue, i.e., the top task of the heap.

[0193] The interface module determines that the insertion operation has changed the top task of the heap (from empty to existing), thus meeting the conditions for triggering RTC reconfiguration. The interface module then directly calls the timer configuration module to initiate an RTC wake-up reconfiguration request.

[0194] Secondly, you can configure RTC wake-up.

[0195] After receiving the configuration request, the timer configuration module retrieves the expected execution time (8:00 AM the next day) of the current top task from the priority queue module and obtains the current system time (assuming it is 10:00 PM that day). The timer configuration module calculates the wake-up duration based on the difference between the expected execution time and the current system time, converts the wake-up duration into an alarm clock time value recognizable by the RTC hardware through the RTC driver interface provided by the operating system, and writes it to the RTC wake-up register.

[0196] After configuration, the TBOX main processor executes the WFI instruction to enter a deep sleep state. In this state, the main CPU clock stops, most peripherals are powered off, and only the RTC hardware module and the necessary CAN bus wake-up circuit are powered. The TBOX's quiescent current drops from tens of milliamps in the running state to hundreds of microamps in the sleep state.

[0197] Then, RTC interrupt wake-up and expiration handling can be performed.

[0198] After a 10-hour wait, at 8:00 AM the following day, the RTC hardware timer reached the preset alarm time, generating a hardware interrupt signal. This interrupt signal directly woke up the expiration processing module.

[0199] After the expiration handling module is awakened, it immediately retrieves and pops the top task TASK_001 from the priority queue module. The expiration handling module checks the relationship between the expected execution time of the task and the current system time: since T_target (8:00 the next day) ≤ T_now (8:00 the next day), it determines that the task has expired.

[0200] For expired tasks, the expiration handling module first broadcasts the scheduled task expiration event to the business modules within the system that have subscribed to the client identifier "Charging Management Service" through the interface module. The broadcast content includes at least the client identifier and the task's unique identifier. Since this task is a one-time task, it does not trigger the re-registration logic for periodic tasks.

[0201] Subsequently, the expiration handling module checks if the priority queue is empty. Since TASK_001 has been popped and there are no other tasks, the priority queue is empty. Therefore, the expiration handling module does not send another configuration request to the timer configuration module, and the system enters indefinite sleep, waiting for the next task registration event.

[0202] Finally, the client can respond to the expiration event and execute the task logic.

[0203] The charging management service module pre-registers a listener callback for the client identifier "charging management service" through the task expiration subscription interface provided by the interface module when the system starts. When the module receives an expiration event broadcast by the expiration processing module, it identifies the client identifier in the event and matches it with its own registered identifier, then reads the task payload data corresponding to TASK_001 from the task persistence module.

[0204] Based on the target battery capacity and charging power limit parameters in the task payload, the business module invokes the charging management logic and sends a charging command to the battery management system via the CAN bus. After the battery management system executes the charging operation and returns confirmation, the business module writes the execution result (including success status, execution completion time, etc.) back to the task execution log area in the eMMC through the interface module, so that users can query it later via the mobile APP.

[0205] This embodiment fully demonstrates the core advantages of the present invention in long-delay reservation scenarios: during a waiting period of up to 10 hours, the main processor remains in a deep sleep state throughout, with zero invalid wake-ups. Upon task expiration, it is precisely woken up via RTC hardware, with trigger latency controlled at the millisecond level. The scheduling core (including the interface module, priority queue module, timer configuration module, and expiration processing module) is completely decoupled from the charging management business module through an event broadcast mechanism; the execution time or abnormal crash of the business module will not affect the normal operation of the scheduling core.

[0206] This embodiment fully demonstrates the core advantages of the present invention in long-delay reservation scenarios: during a waiting period of up to 10 hours, the main processor remains in a deep sleep state throughout, with zero invalid wake-ups. When a task expires, it is precisely woken up via RTC hardware, with trigger latency controlled at the millisecond level. The scheduling core (interface module, priority queue module, timer configuration module, and expiration processing module) is completely decoupled from the charging management business module through an event broadcast mechanism; the execution time or abnormal crash of the business module will not affect the operation of the scheduling core.

[0207] This application also provides an embodiment of multi-task concurrency and fault isolation in a smart cockpit, which is illustrated using a smart cockpit domain controller as an example. The system manages multiple scheduled tasks simultaneously: OTA upgrade task (executed at 2:00 the next day, a one-time task), scheduled silent restart task (executed at 3:00 the next day, a periodic task with a 24-hour interval), and scheduled heating task (executed at 7:30 the next day, a one-time task).

[0208] Each business module (i.e., the client in the above embodiment) registers the three reservation tasks through the interface module. The interface module performs the following operations in sequence for each registration request: generates a task identifier, calls the task persistence module to write the task metadata to non-volatile memory, and calls the priority queue module to insert the task into a memory priority queue based on a min-heap.

[0209] The priority queue module maintains a min-heap property during each insertion. Using the expected execution times of the three tasks as the sorting key, after insertion, the top task is the OTA upgrade task (expected execution time 2:00), followed by the silent restart task (expected execution time 3:00) and the timed heating task (expected execution time 7:30). After each insertion, the interface module checks if the top of the heap has changed: upon the first insertion, the queue changes from empty to exist, triggering timer configuration; for subsequent insertions, if the expected execution time of the newly inserted task is not earlier than the current top task, reconfiguration is not triggered.

[0210] After registering the OTA upgrade task and determining that it is at the top of the heap, the interface module directly calls the timer configuration module. The timer configuration module obtains the expected execution time (2:00) of the top task, calculates the difference between it and the current time as the wake-up duration, and writes it to the RTC wake-up register. The system then enters a deep sleep state.

[0211] At 2:00 AM the following day, an RTC hardware interrupt wakes up the expiration handling module. The expiration handling module pops the top task (OTA upgrade task) from the priority queue, verifies its expiration, and broadcasts the expiration event through the interface module. Upon receiving this event, the OTA upgrade service module begins executing the upgrade logic. This process involves downloading and verifying large files and is expected to take approximately 50 minutes.

[0212] Since the OTA upgrade task is a one-time task, the expiration handling module does not trigger the re-registration logic for periodic tasks. Subsequently, the expiration handling module checks the new top-of-the-stack task (silent restart task, expected execution time 3:00), determines it has not expired, and stops the popping operation. After processing the current batch, the expiration handling module checks that the priority queue is not empty, and then sends the next configuration request to the timer configuration module, calculating the wake-up duration (1 hour) based on the expected execution time of the silent restart task and writing it to the RTC wake-up register. The system then enters deep sleep mode again.

[0213] It should be noted that the expiration handling module completes its scheduling work immediately after the broadcast event and does not wait for the execution result of the OTA upgrade business module. The time-consuming OTA upgrade operation is performed independently in the business module process and is completely decoupled from the scheduling core.

[0214] Suppose that at 2:30, a user adds an emergency diagnostic task via the mobile app, with an expected execution time of 2:45. The business layer calls the interface module to register this task. After completing the persistence and enqueue operations, the interface module determines that the new task's expected execution time (2:45) is earlier than the current top-of-the-heap task (silent restart task, expected execution time 3:00), satisfying the top-of-the-heap change condition. The interface module immediately calls the timer configuration module to initiate a reconfiguration request. The timer configuration module cancels the original RTC alarm setting, recalculates the wake-up duration based on the new top-of-the-heap task's expected execution time of 2:45, and writes it to the RTC wake-up register.

[0215] At 2:45, the RTC wakes up the expiration handling module on time, and the emergency diagnostic task is popped up and broadcast. After processing, the expiration handling module checks the top of the heap again. At this time, the top of the heap is restored to the silent restart task (expected execution time 3:00), and the next RTC wake-up is configured based on this task. The system enters deep sleep state again.

[0216] In this embodiment, it is assumed that the OTA upgrade service module crashes due to a software defect at 2:40. Since this service module runs in an independent process, its crash will not affect any module in the scheduling core. The expiration processing module, interface module, priority queue module, and timer configuration module are all unaffected. The emergency diagnosis task is still woken up on time at 2:45 and broadcast to the corresponding service module, and the silent restart task is also triggered on time at 3:00.

[0217] If the silent restart task is a periodic task (within 24 hours), the expiration handling module will pop up the task and broadcast it at 3:00 AM. Immediately afterwards, the module will calculate the next expected execution time (3:00 AM the following day), generate a new task instance, call the priority queue module to re-enqueue the task, and call the task persistence module to write it to non-volatile memory. This automatic re-registration process is completely transparent to the business modules. The business modules only need to focus on the execution logic of a single restart operation and do not need to understand the concept of a period.

[0218] Suppose that during the OTA upgrade execution (2:40), the vehicle's MCU resets due to a momentary drop in battery voltage. After the reset, the system restarts, and the task persistence module scans the task persistence area in non-volatile memory, reading the metadata records for the unexecuted silent restart task (expected execution time 3:00) and the timed heating task (expected execution time 7:30). For each record, the task persistence module verifies the relationship between its expected execution time and the current system time (recovered via GNSS). Since the expected execution times of both tasks are later than the current time, the task persistence module passes them to the priority queue module and re-inserts them into the min-heap.

[0219] After recovery, the interface module detected that the priority queue was not empty and triggered the timer configuration module to configure RTC wake-up based on the top task (silent restart task, expected execution time 3:00). The system then entered a deep sleep state and woke up precisely at 3:00 to execute the silent restart task, and the scheduling process was fully restored to normal.

[0220] This embodiment fully demonstrates the comprehensive advantages of the present invention in various complex scenarios such as multi-task concurrency, dynamic insertion of new tasks, task execution time, business module failure, and system abnormal reset: the minimum heap priority queue ensures that the expected execution time of the earliest task can be obtained in O(1) time complexity; unified coordination of interface modules ensures accurate timing of RTC reconfiguration; precise RTC wake-up eliminates the overhead of periodic polling; the event broadcast mechanism realizes complete decoupling and fault isolation between the scheduling core and business modules; and the task persistence and automatic recovery mechanism ensure the reliability and self-healing capability of the system.

[0221] Figure 4 This is a flowchart illustrating a method for scheduling and executing vehicle-mounted tasks according to an embodiment of this application, as shown below. Figure 4 As shown, the specific steps are as follows.

[0222] Step S401: Start recovery and initialization.

[0223] After the system is powered on or reset, the startup recovery process is executed first. The system rebuilds the priority queue in memory by scanning the task persistence area in non-volatile memory (NVM).

[0224] Step S402, Task change monitoring and RTC reconfiguration triggering.

[0225] If a task registration and persistence request is received, and the registered task becomes the top of the heap, or if a task cancellation and update request is received, and the top task changes, or if the priority queue is not empty after reconstruction, the timer configuration can be triggered.

[0226] Upon receiving a task registration and persistence request, if the registered task does not become the top of the heap, the system remains in sleep / standby mode; upon receiving a task cancellation and update request, if the top task remains unchanged, the system maintains its current state; if the priority queue is empty, the system will remain in sleep indefinitely and wait for a new task registration.

[0227] Step S403, timer configuration.

[0228] Get the target execution time of the top task in the current priority queue, calculate the time difference between the target execution time and the current system time, write the time difference into the RTC wake-up register through the RTC driver interface, and configure the alarm time for the next precise wake-up.

[0229] Step S404: After configuration, the main processor executes the WFI instruction to enter a deep sleep state, cutting off power to most peripherals to reduce static power consumption.

[0230] Step S405: When the RTC hardware timer reaches the preset alarm time, the RTC is woken up by an interrupt.

[0231] Step S406: Scheduled task expiration and verification.

[0232] The expiration handling module pops the top task from the priority queue and verifies whether the expected execution time of the task is less than or equal to the current system time.

[0233] If the task has not expired (an abnormal situation), discard the task and proceed directly to step S403 to check for new tasks; if the task has expired, proceed to step S407.

[0234] Step S407, broadcast event.

[0235] Broadcast a "scheduled task expiration event" to the business modules that have subscribed to the client identifier.

[0236] Step S408: Is the task a periodic task?

[0237] If yes, calculate the next expected execution time locally, generate a new task instance, re-enqueue and persist it, and then check the new heap top; if not, check the new heap top directly.

[0238] Step S409: Check if the current priority queue is empty.

[0239] If the queue is not empty, proceed to step S403 to reconfigure the RTC wake-up time and go to sleep again; if the queue is empty, proceed to step S401 to enter an indefinite sleep state and wait for the next task registration.

[0240] Figure 5 This is a schematic diagram illustrating an application of a priority queue based on a min-heap data structure, as provided in an embodiment of this application. Figure 5As shown, each node represents a scheduled task, and the T value before the node indicates the expected execution time of that task. As shown, the top node of the heap is task A (T=100), which has the shortest expected execution time and is therefore scheduled first. Tasks B (T=250) and C (T=180), as children of task A, are located at the second level. Tasks D (T=350) and E (T=420), as children of task B, are located at the third level. The entire tree structure strictly satisfies the min-heap property, meaning that the T value of any parent node is no greater than the T value of its child nodes. This structure is stored in array form, with indices 0 to 4 corresponding to tasks A to E respectively. The dashed arrows illustrate the mapping relationship between array indices and tree nodes. In this patented solution, the min-heap serves as the underlying implementation of the memory priority queue. The scheduler can obtain the top task of the heap (i.e., the earliest expiring task) in O(1) time complexity and complete the insertion of new tasks or the deletion of expired tasks in O(log n) time complexity. This ensures millisecond-level triggering accuracy while avoiding the O(n) search overhead brought by traditional centralized linked list traversal.

[0241] Figure 6 This is a flowchart illustrating the execution interaction of an onboard controller according to an embodiment of this application. Figure 6 As shown, the vehicle controller includes an interface module, a priority queue module, a timer configuration module, RTC hardware, an expiration processing module, and a service module.

[0242] First, the business module sends a task registration request to the interface module. After receiving the request, the interface module first calls the persistence module to write the task metadata to non-volatile memory (NVM) to ensure that it is not lost when power is lost. Then, the task is passed to the priority queue module. The priority queue module inserts the task into the memory priority queue based on the min-heap data structure and determines whether RTC reconfiguration needs to be triggered based on the change of the top of the heap.

[0243] If a new task becomes the top of the heap or the queue changes from empty to non-empty, the interface module directly calls the timer configuration module. The timer configuration module obtains the expected execution time of the current top task from the priority queue module, calculates the difference between it and the current system time as the wake-up duration, and writes the wake-up duration into the wake-up register of the RTC hardware. After the configuration is completed, the entire system enters a deep sleep state. At this time, the main CPU clock stops, most peripherals are powered off, and only the RTC module and the necessary wake-up circuit are powered.

[0244] When the RTC hardware timer reaches the preset alarm time, its internal comparator triggers a matching event and generates a hardware interrupt signal, which directly wakes up the expiration handling module. After being woken up, the expiration handling module immediately pops the top task from the priority queue module, verifies the relationship between its expected execution time and the current system time, and if it has expired, broadcasts the timed task expiration event to the business modules that have subscribed to the corresponding client identifier through the interface module. The broadcast content includes at least the client identifier and the task's unique identifier. After receiving the event, the business module matches its registered listening callback according to the client identifier in the event and calls the corresponding business logic to execute the task (such as sending a charging command to the battery management system via the CAN bus).

[0245] If the task is a periodic task, the expiration handling module will calculate the next expected execution time locally after broadcasting the event (based on the current expected execution time plus the preset execution interval), generate a new task instance and call the priority queue module to re-enqueue it, and at the same time call the persistence module to write it to NVM. The whole process is completely transparent to the business module.

[0246] After processing all due tasks, the due processing module checks if the priority queue is empty: if the queue is not empty, it calls the timer configuration module again to calculate the wake-up duration based on the new top task and writes it to the RTC register, and then the system enters deep sleep again; if the queue is empty, the system enters indefinite sleep, waiting for the next task registration event.

[0247] Throughout the process, the scheduling core (interface module, priority queue module, timer configuration module, and expiration processing module) is completely decoupled from the business module through an event broadcasting mechanism. The execution time or abnormal crash of the business module will not affect the normal operation of the scheduling core, thus realizing a low-power, high-precision, and highly reliable closed-loop scheduling of vehicle reservation tasks.

[0248] Figure 7 This is a schematic diagram of the software architecture for a vehicle controller to perform task scheduling, as provided in an embodiment of this application. Figure 7 As shown, the software architecture can adopt a design approach that separates the scheduling core layer from the business layer. The entity corresponding to the business layer can be a business module, i.e., a client, which can be the carrier of specific business logic (such as remote vehicle control and data reporting).

[0249] On the business layer side, the business module, as the execution carrier of specific business logic, needs to initiate a subscription registration request to the interface module in the scheduling core layer when accessing the scheduling system in order to establish a communication relationship between the two.

[0250] Within the scheduling core layer, the priority queue module, based on a min-heap data structure, is responsible for sorting and managing all tasks to be executed; the task persistence module ensures the non-volatile storage of task metadata in the event of system power failure or abnormal reset; the timer configuration module is responsible for calculating the time interval for the next system wake-up and sending the configuration parameters to the RTC wake-up register; and the expiration handling module is responsible for triggering and distributing tasks after they expire. After popping the expired task from the priority queue, it publishes the expiration event to the event broadcast bus through the interface module.

[0251] The interface module acts as a communication intermediary between the scheduling core layer and the business layer in the whole architecture. On the one hand, it receives the expiration events from the expiration processing module and pushes them to the event broadcast bus. On the other hand, it routes and distributes the events on the bus according to the subscription information pre-registered by the business modules, so that the corresponding business modules can trigger callback execution.

[0252] Through the unified scheduling and event routing mechanism of the above interface modules, combined with clear unidirectional dependencies, the business logic and the underlying scheduling mechanism are completely decoupled. Each module can be compiled, deployed and upgraded independently, effectively reducing the coupling between system modules and the maintenance cost.

[0253] Figure 8 This is a schematic diagram of a task recovery and initialization process provided in an embodiment of this application, such as... Figure 8 As shown, upon system startup, the system first scans the persistent task region in non-volatile memory (NVM) to reconstruct a snapshot of the tasks in memory. Subsequently, the system enters a loop read process, reading historical task records in the NVM one by one and performing conditional checks. If the reading is complete, the system determines whether to trigger a timer configuration process to enter low-power sleep mode or directly enter an indefinite sleep state to wait for new task registration, depending on whether the current priority queue is empty. If the reading is not complete, the system further checks whether the expected execution time in the task record has expired (i.e., the expected time is less than or equal to the current time): if it has expired, the task is marked as a timed-out task and processed immediately according to a predetermined strategy; if it has not expired, the task is re-inserted into the min-heap priority queue to ensure its participation in subsequent scheduling management. This entire logic ensures that the system can accurately recover unfinished scheduled tasks after a power outage and restart, maintaining business continuity and reliability.

[0254] Figure 9 This is a schematic diagram of an end-to-end interaction process for an onboard controller to execute a scheduled charging task, as provided in an embodiment of this application. Figure 9As shown, this interaction process involves multiple collaborative entities, including the cloud platform, charging management business module, task persistence module, priority queue module, timer configuration module, RTC hardware, expiration processing module, and battery management system (BMS).

[0255] First, the cloud platform sends a registration request for the scheduled charging task to the charging management business module. This request includes the expected execution time (e.g., 8:00 AM the next day), the client identifier (pointing to the charging management service), and task payload data containing the target battery level and charging power limits. Upon receiving the registration request, the charging management business module, to ensure the task is not lost even when the vehicle is turned off and parked, or in the event of an unexpected power outage, first calls the task persistence module to synchronously write the task metadata to non-volatile memory (NVM), completing persistent storage.

[0256] The task metadata is then passed to the priority queue module, which inserts the task into the memory priority queue based on a min-heap data structure. The insertion operation has a time complexity of O(log n). Since there are no other scheduled tasks in the system, this task becomes the only top-of-the-heap node, meeting the conditions for triggering RTC reconfiguration. The priority queue module then calls the timer configuration module. The timer configuration module obtains the expected execution time of the current top-of-the-heap task (8:00 the next day) from the priority queue module and obtains the current system time (assumed to be 22:00 the current day), calculates the wake-up duration to be 10 hours, and writes this duration into the wake-up register of the RTC hardware through the RTC driver interface provided by the operating system. After configuration, the entire system enters a deep sleep state. At this time, the main CPU clock stops, most peripherals are powered off, and only the RTC module and the necessary CAN bus wake-up circuit are powered. The static current drops from tens of milliamps in the running state to hundreds of microamps in the sleep state.

[0257] After a 10-hour wait, at 8:00 AM the following day, the incrementing timer inside the RTC hardware reached the preset value stored in the wake-up register. The comparator triggered a matching event, and the RTC's interrupt control logic generated a hardware interrupt signal, directly waking up the expiration handling module. Upon being woken up, the expiration handling module immediately popped the top task from the priority queue module, verified the relationship between its expected execution time and the current system time, and determined that the task had expired (expected execution time ≤ current system time). Subsequently, it broadcast the timed task expiration event to the business modules within the system that had subscribed to the client identifier "Charging Management Service" via the interface module. The broadcast content included at least the client identifier and the task's unique identifier. Upon receiving the expiration event, the charging management business module identified the client identifier in the event and matched it with its pre-registered identifier. It then read the corresponding task payload data from the task persistence module, and based on the target energy level and charging power limit parameters in the payload, invoked the charging management logic to send a charging start command to the battery management system (BMS) via the CAN bus. After the BMS executes the charging operation and returns a confirmation signal, the charging management business module writes the execution result of this task (including success status, actual execution completion time, etc.) back to the task execution log area in NVM through the interface module, so that users can query it later through the mobile APP.

[0258] At this point, a complete closed-loop scheduling of the scheduled charging task has been completed. The system then decides whether to enter the next sleep cycle or remain in sleep indefinitely based on whether the priority queue is empty. This process fully demonstrates the precise wake-up mechanism based on the collaboration between the min-heap priority queue and RTC hardware, as well as the architectural advantages of the complete decoupling between the scheduling core and business modules through event broadcasting.

[0259] It should be noted that the descriptions of the various embodiments above tend to emphasize the differences between them, while their similarities or commonalities can be referred to interchangeably. The descriptions of the above device product embodiments are similar to those of the above method embodiments, and have similar beneficial effects. For technical details not disclosed in the device product embodiments of this application, please refer to the descriptions of the method embodiments of this application for understanding.

[0260] This application also provides an in-vehicle controller, which is used to implement the methods described in the above embodiments.

[0261] This application also provides a vehicle, which includes the vehicle controller described in the above embodiments.

[0262] It should be understood that the phrase "one embodiment" or "an embodiment" throughout the specification means that a specific feature, structure, or characteristic related to the embodiment is included in at least one embodiment of this application. Therefore, "in one embodiment" or "in an embodiment" appearing throughout the specification does not necessarily refer to the same embodiment. Furthermore, these specific features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. It should be understood that in the various embodiments of this application, the sequence numbers of the above steps / processes do not imply a sequential order of execution; the execution order of each step / process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application. The sequence numbers of the above embodiments of this application are merely descriptive and do not represent the superiority or inferiority of the embodiments.

[0263] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0264] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods, such as: multiple units or components can be combined, or integrated into another system, or some features can be ignored or not executed. In addition, the coupling, direct coupling, or communication connection between the various components shown or discussed can be through some interfaces, and the indirect coupling or communication connection between devices or units can be electrical, mechanical, or other forms.

[0265] The units described above as separate components may or may not be physically separate. The components shown as units may or may not be physical units. They may be located in one place or distributed across multiple network units. Some or all of the units may be selected to achieve the purpose of this embodiment according to actual needs.

[0266] In addition, each functional unit in the various embodiments of this application can be integrated into one processing unit, or each unit can be a separate unit, or two or more units can be integrated into one unit; the integrated unit can be implemented in hardware or in the form of hardware plus software functional units.

[0267] The above description is merely an embodiment of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application.

Claims

1. A vehicle-mounted task execution method, characterized in that, The method is applied to an on-board controller, and the method includes: Obtain the first expected execution time of the first scheduled task located at the top of the heap in the memory priority queue; wherein, the memory priority queue is used to store registration requests for different scheduled tasks; the registration request includes the expected execution time of the scheduled task and the client identifier for executing the scheduled task; Based on the first expected execution time and the current first time, determine the wake-up duration of the first scheduled task; The wake-up duration is written into the wake-up register, and in response to the interrupt signal generated by the wake-up register, the first reservation task is broadcast to the client in the vehicle that subscribes to the first target client identifier corresponding to the first reservation task, so that the first target client in the client executes the first reservation task. The interrupt signal is the interrupt signal generated by the wake-up register from the start of the wake-up duration being written until the wake-up duration is reached.

2. The method according to claim 1, characterized in that, The process of obtaining the first expected execution time of the first scheduled task located at the top of the heap in the memory priority queue includes: Receive the registration request for the reservation task sent by the vehicle's client; If the registration request is inserted into the memory priority queue based on the min-heap data structure based on the expected execution time of the registration request, the first expected execution time of the first scheduled task located at the top of the heap in the memory priority queue is obtained.

3. The method according to claim 1, characterized in that, The step of broadcasting the first reservation task to the client in the vehicle that subscribes to the first target client identifier corresponding to the first reservation task includes: In response to the interrupt signal generated by the wake-up register, the current second time is obtained; When the first expected execution time is less than or equal to the current second time, the first reservation task is determined to have expired, and the first reservation task is broadcast to the client in the vehicle that subscribed to the first target client identifier corresponding to the first reservation task. When the first expected execution time is greater than or equal to the current second time, it is determined that the first scheduled task has not expired. The wake-up duration is re-determined based on the first expected execution time and written into the wake-up register. The vehicle controller is then controlled to enter a sleep state.

4. The method according to claim 2, characterized in that, The registration request also includes the task type of the scheduled task, which includes a periodic task; inserting the registration request into the memory priority queue based on the expected execution time of the registration request includes: If the first reservation task is a periodic task, and the reservation task corresponding to the registration request is broadcast, the preset execution interval of the first reservation task is obtained from the registration request of the first reservation task. Based on the first expected execution time and the preset execution interval, determine the next second expected execution time of the first scheduled task, and update the registration request of the first scheduled task based on the second expected execution time; Based on the second expected execution time, the updated registration request for the first scheduled task is inserted into the memory priority queue.

5. The method according to any one of claims 1-4, characterized in that, The method further includes: If the expected execution time of multiple second scheduled tasks in the memory priority queue is less than or equal to the time difference between the expected execution time of the first scheduled task and the expected execution time of the first scheduled task, the multiple second scheduled tasks are popped out of the priority queue in sequence until the expected execution time of the top task is greater than the current system time or the queue is empty. The multiple second reservation tasks are broadcast to the clients that subscribe to the second target client identifiers corresponding to the multiple second reservation tasks.

6. The method according to any one of claims 1-4, characterized in that, The registration request also includes the task identifier of the reservation task; obtaining the first expected execution time of the first reservation task located at the top of the heap in the memory priority queue used to store registration requests for different reservation tasks includes: Receive a task cancellation request sent by a client, the task cancellation request being used to request the cancellation of at least one registered scheduled task, the task cancellation request including the target task identifier of the scheduled task to be cancelled; Based on the target task identifier, set a cancellation flag for the scheduled tasks to be cancelled in the memory priority queue; If a cancellation flag is detected in the first reservation task, the first reservation task is deleted, and a new first reservation task is determined from the plurality of reservation tasks in the memory priority queue. Obtain the first expected execution time for the new first scheduled task.

7. The method according to any one of claims 1-4, characterized in that, The method further includes: Registration requests for different reservation tasks are stored in the non-volatile memory of the vehicle controller; When broadcasting the first reservation task to a client in the vehicle that subscribes to the first target client identifier corresponding to the first reservation task, the registration request corresponding to the first reservation task stored in the non-volatile memory is marked as executed.

8. The method according to claim 7, characterized in that, The method further includes: When the vehicle controller starts, it reads all unexecuted registration requests by scanning the non-volatile memory; For each of the unexecuted registration requests, if the expected execution time of the unexecuted registration request is later than the current third time, the unexecuted registration request will be reinserted into the memory priority queue. If the expected execution time of the unexecuted registration request is earlier than or equal to the current third time, the unexecuted registration request is deleted.

9. The method according to any one of claims 1-4, characterized in that, The method further includes: When the wake-up duration is written to the wake-up register, the vehicle controller is controlled to enter a sleep state until the interrupt signal sent by the wake-up register is received.

10. A vehicle-mounted task execution device, characterized in that, The device includes: The acquisition module is used to acquire the first expected execution time of the first scheduled task located at the top of the memory priority queue; wherein, the memory priority queue is used to store registration requests for different scheduled tasks; the registration request includes the expected execution time of the scheduled task and the client identifier for executing the scheduled task; The determination module is used to determine the wake-up duration of the first scheduled task based on the first expected execution time and the current first time; The broadcast module is used to write the wake-up duration into the wake-up register and, in response to an interrupt signal generated by the wake-up register, broadcast the first reservation task to the client in the vehicle that subscribes to the first target client identifier corresponding to the first reservation task, so that the first target client in the client executes the first reservation task. The interrupt signal is an interrupt signal generated by the wake-up register from the start of the wake-up duration writing until the wake-up duration is reached.

11. A vehicle-mounted controller, characterized in that, The vehicle controller is used to implement the method according to any one of claims 1 to 9.

12. A vehicle, characterized in that, The vehicle includes the on-board controller as described in claim 11.

Images