Timed task scheduling method, device and system, vehicle and chip

Abstract

The embodiment of the invention provides a timed task scheduling method, device and system, a vehicle and a chip, and the method comprises the steps: determining at least one scheduling object and a reference time interval corresponding to each scheduling object according to a preset execution period; obtaining a to-be-scheduled task corresponding to each sensor; determining a trigger multiple corresponding to each to-be-scheduled task according to a preset execution period of the to-be-scheduled task and a reference time interval corresponding to the scheduling object; controlling the timer to periodically generate a trigger signal according to the reference time interval; updating the triggering accumulated value of all the to-be-scheduled tasks corresponding to the scheduling object; determining a judgment result for each to-be-scheduled task; and when the judgment result is yes, executing the corresponding to-be-scheduled task, and resetting the trigger accumulated value corresponding to the executed to-be-scheduled task. Through the scheme of the invention, the total number of timers in the mine automatic driving equipment is greatly reduced, and the resource consumption is reduced.

Description

Technical Field

[0001] This invention relates to the field of autonomous driving technology, and more specifically, to a timed task scheduling method, apparatus, system, vehicle, and chip. Background Technology

[0002] In traditional embedded systems for automated mining operations, a common approach is to create and bind a separate hardware timer for each task with a different execution cycle. This one-task-one-timer model results in dozens or even hundreds of independent timers running concurrently in the system. Multiple timers frequently trigger hardware interrupts concurrently, easily causing interrupt conflicts and response delays. This can prevent high-priority safety tasks from being executed in a timely manner due to interrupt blocking, and the continuous operation of a large number of timers significantly consumes computing resources and memory, reducing system efficiency. Summary of the Invention

[0003] The purpose of this invention is to provide a timed task scheduling method, device, system, vehicle, and chip that can solve the problem that the continuous operation of a large number of timers will significantly consume computing resources and memory, reducing system efficiency.

[0004] In view of this, an embodiment of the first aspect of the present invention provides a timed task scheduling method.

[0005] A second aspect of the present invention provides a timed task scheduling device.

[0006] A third aspect of the present invention provides a timed task scheduling system.

[0007] An embodiment of the fourth aspect of the present invention provides a vehicle.

[0008] An embodiment of the fifth aspect of the present invention provides a chip.

[0009] To achieve the above objectives, an embodiment of the first aspect of the present invention provides a timed task scheduling method for a timed task scheduling system. The timed task scheduling system includes at least one sensor, each sensor having a different preset execution period. The timed task scheduling method includes: determining at least one scheduling object and a reference time interval corresponding to each scheduling object based on the preset execution period, with each scheduling object associated with a timer; acquiring the tasks to be scheduled corresponding to each sensor, with one scheduling object corresponding to at least two tasks to be scheduled; determining a trigger multiple corresponding to each task to be scheduled based on the preset execution period of the tasks to be scheduled and the reference time interval corresponding to the scheduling object; controlling the timer to periodically generate a trigger signal based on the reference time interval; updating the cumulative trigger value of all tasks to be scheduled corresponding to the scheduling object in response to the trigger signal; for each task to be scheduled, determining whether the updated cumulative trigger value is greater than or equal to the trigger multiple corresponding to the task to be scheduled, and determining the determination result; when the determination result is yes, executing the corresponding task to be scheduled and resetting the cumulative trigger value corresponding to the executed task to be scheduled.

[0010] The timed task scheduling method provided by this invention first identifies a few scheduling objects based on multiple task requirements with different preset execution cycles. Each object is strictly bound to a single physical timer and a base time interval is set. Then, all tasks are bound to the corresponding scheduling objects according to the trigger multiple of the cycle and the base interval.

[0011] Trigger signals are periodically generated by a physical timer to synchronously accumulate the trigger values ​​of all tasks. Finally, by comparing the accumulated value of each task with its trigger multiple, tasks that have reached their preset cycle are accurately identified and executed, and then the accumulated state of the tasks to be scheduled is reset.

[0012] For example, the scheduling object includes a timer framework. The timer framework in this invention can support each process of the mine autonomous driving equipment (such as the environmental perception process and the equipment monitoring process) to create 1 to 3 timer framework objects based on the framework. Each timer framework object corresponds to only one physical timer, and the timing interval of the physical timer can be flexibly configured according to the task requirements of the mine autonomous driving.

[0013] Each timer framework is equipped with an independent timeout event handling thread. The timeout event handling thread is only responsible for listening to the timeout signal of the timer and querying the task queue registered under the corresponding timer framework.

[0014] Understandably, by adopting a one-frame-one-timer design, the number of timers in mining autonomous driving equipment is significantly reduced. This fundamentally enables reliable and accurate scheduling of a large number of tasks with different cycles using minimal physical timer resources, solving the technical problems of resource waste and scheduling conflicts caused by the traditional one-task-one-timer mode, and ensuring that mining autonomous driving equipment can still respond quickly to environmental changes under complex working conditions.

[0015] In some technical solutions, optionally, at least one scheduling object and a reference time interval corresponding to each scheduling object are determined according to a preset execution cycle, including: obtaining the preset execution cycles of multiple tasks to be scheduled associated with the scheduling object; calculating the greatest common divisor of the multiple preset execution cycles to determine the initial reference time parameter; adjusting the initial reference time parameter according to the system load constraint parameter to obtain the target reference time parameter; and determining the reference time interval corresponding to the scheduling object according to the target reference time parameter.

[0016] In this scheme, the preset execution cycles of all tasks grouped under the same scheduling object are first obtained. By calculating the greatest common divisor of these cycles, the initial base time parameters are obtained. Then, real-time load constraint parameters of the system (such as CPU utilization and interrupt load) are introduced to dynamically adjust and optimize the initial base time parameters, and finally, the target base time interval is generated and set as the running tick of the scheduling object.

[0017] In some technical solutions, optionally, when the judgment result is yes, the corresponding scheduled task is executed, including: when the judgment result is that the updated cumulative trigger value is greater than or equal to the trigger multiple corresponding to the scheduled task, obtaining the task identifier and preset priority parameter of the scheduled task; generating a task execution descriptor based on the task identifier and preset priority parameter; submitting the task execution descriptor to the priority task queue of the global thread pool; and having the global thread pool schedule and execute the scheduled task from the priority task queue according to the preset priority parameter.

[0018] This solution proposes an asynchronous task submission and scheduling mechanism based on priority identifiers. After the task triggering conditions are met, this mechanism does not execute the task directly. Instead, it first obtains the task's unique identifier and preset priority parameters, encapsulating them into a standardized task descriptor. Subsequently, the descriptor is asynchronously submitted to an independent global thread pool, and placed into the corresponding priority queue according to the priority parameters. Finally, the global thread pool schedules worker threads from the queue to actually execute the task based on the priority strategy.

[0019] In some technical solutions, optionally, in response to a trigger signal, the cumulative trigger value of all tasks to be scheduled corresponding to the scheduling object is updated, including: obtaining the trigger signal through the listening thread associated with the scheduling object; in response to the trigger signal, checking the running status flag of the scheduling object; when the running status flag indicates an active state, accessing the task list corresponding to the scheduling object; traversing the task list and performing update calculations on the cumulative trigger value recorded for each task to be scheduled.

[0020] In this scheme, after each trigger signal is generated by the physical timer associated with the scheduling object, an independent listening thread captures the trigger signal.

[0021] After confirming that the scheduling object is active, the thread safely accesses the list of tasks it manages and iterates through the list to perform an increment operation on the cumulative trigger value recorded for each scheduled task.

[0022] In some technical solutions, optionally, after obtaining the scheduled task corresponding to each sensor, the timed task scheduling method further includes: receiving a registration request for the scheduled task, the registration request including a task identifier, a preset execution period, and a task processing function pointer; matching a target scheduling object for the scheduled task according to the preset execution period; and storing the task identifier and task processing function pointer in the task list managed by the target scheduling object according to the trigger multiplier and the trigger accumulation value initialized to zero.

[0023] In this scheme, during system runtime, a registration request containing key task attributes (identifier, period, function pointer) is received. Based on the divisibility relationship between the task's preset period and the baseline interval of existing scheduling objects, the most suitable target scheduling object is intelligently matched. Then, the triggering multiple of the task under the scheduling object is calculated, and its status information (including the triggering cumulative value initialized to zero) is encapsulated into a task control block and stored in the task list managed by the target scheduling object.

[0024] In some technical solutions, the timed task scheduling method may optionally include: receiving a condition change instruction, which includes a scheduling object identifier and an update baseline interval parameter; locating the target scheduling object based on the scheduling object identifier; updating the baseline time interval of the target scheduling object based on the update baseline interval parameter; recalculating the trigger multiple of each scheduled task under the target scheduling object based on the updated baseline time interval; and synchronizing the recalculated trigger multiple to the task list corresponding to the target scheduling object.

[0025] In this scheme, by receiving a condition change instruction containing the target scheduling object identifier and a new baseline interval parameter, the time baseline of the specified scheduling object is accurately located and updated. Then, using this new baseline as a scale, the trigger multiples of all scheduled tasks under its management are uniformly recalculated, and the updated multiples are atomically synchronized to the task status list.

[0026] A second aspect of the present invention provides a timed task scheduling device for a timed task scheduling system. The timed task scheduling system includes at least one sensor, each sensor having a different preset execution period. The timed task scheduling device includes: a scheduling determination module, used to determine at least one scheduling object and a reference time interval corresponding to each scheduling object according to the preset execution period, each scheduling object being associated with a timer; a task acquisition module, used to acquire the tasks to be scheduled corresponding to each sensor, one scheduling object corresponding to at least two tasks to be scheduled; a parameter determination module, used to determine a trigger multiple corresponding to each task to be scheduled according to the preset execution period of the tasks to be scheduled and the reference time interval corresponding to the scheduling object; a signal triggering module, used to control the timer to periodically generate a trigger signal according to the reference time interval; a value update module, used to update the cumulative trigger value of all tasks to be scheduled corresponding to the scheduling object in response to the trigger signal; a timing judgment module, used to determine whether the updated cumulative trigger value is greater than or equal to the trigger multiple corresponding to the task to be scheduled for each task to be scheduled, and to determine the judgment result; and a task scheduling module, used to execute the corresponding task to be scheduled when the judgment result is yes, and to reset the cumulative trigger value corresponding to the executed task to be scheduled.

[0027] An embodiment of the third aspect of this application provides a timed task scheduling system, including at least one sensor, each sensor having a different preset execution cycle.

[0028] An embodiment of the fourth aspect of this application provides a vehicle equipped with a timed task scheduling system as described in the third aspect.

[0029] An embodiment of the fifth aspect of this application provides a chip including a processor and a communication interface, the communication interface and the processor being coupled together, the processor being used to run programs or instructions to implement the steps of the timed task scheduling method as described in the first aspect.

[0030] Additional aspects and advantages of the technical solutions of the present invention will become apparent in the following description or may be learned by practice of the invention. Attached Figure Description

[0031] Figure 1 One of the flowcharts of the timed task scheduling method according to this application is shown;

[0032] Figure 2One of the flowcharts of the timed task scheduling method according to this application is shown;

[0033] Figure 3 One of the flowcharts of the timed task scheduling method according to this application is shown;

[0034] Figure 4 One of the flowcharts of the timed task scheduling method according to this application is shown;

[0035] Figure 5 One of the flowcharts of the timed task scheduling method according to this application is shown;

[0036] Figure 6 One of the flowcharts of the timed task scheduling method according to this application is shown;

[0037] Figure 7 A schematic block diagram of the timed task scheduling device according to this application is shown;

[0038] Figure 8 A schematic block diagram of the timed task scheduling system according to this application is shown;

[0039] Figure 9 A schematic block diagram of the structure of the vehicle according to this application is shown;

[0040] Figure 10 A timing diagram of the timed task scheduling method according to this application is shown.

[0041] Among them, 900: timed task scheduling device; 902: scheduling determination module; 904: task acquisition module; 906: parameter determination module; 908: signal triggering module; 910: value update module; 912: timed judgment module; 914: task scheduling module; 200: timed task scheduling system; 2000: sensor; 100: vehicle. Detailed Implementation

[0042] To better understand the above-described objectives, features, and advantages of the embodiments of the present invention, the embodiments of the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be noted that, unless otherwise specified, the embodiments and features described in these embodiments can be combined with each other.

[0043] Many specific details are set forth in the following description in order to provide a full understanding of this application. However, embodiments of the invention may also be implemented in other ways different from those described herein. Therefore, the scope of protection of this application is not limited to the specific embodiments disclosed below.

[0044] In autonomous driving scenarios in mines, timers are one of the core components that ensure the safe and stable operation of equipment, and their application runs through the entire autonomous driving process.

[0045] For example, autonomous trucks in mining operations need to process data from multiple types of sensors at fixed frequencies: LiDAR needs to collect 3D point cloud data of the surrounding environment at a frequency of 30Hz to identify obstacles ahead (such as mine piles and other engineering vehicles); millimeter-wave radar needs to monitor the relative speed and position of distant targets at a frequency of 10Hz to help determine the safety of the driving trajectory; and high-definition cameras need to collect road images at a frequency of 30Hz to identify lane lines and traffic signs (such as speed limits and avoidance warnings).

[0046] Meanwhile, the timer also needs to support periodic monitoring of the heartbeat signals of critical equipment: the autonomous driving control system needs to monitor the heartbeat of the steering system every 100ms, the heartbeat of the braking system every 200ms, and the heartbeat of the power system every 500ms. If the heartbeat is interrupted, emergency braking must be triggered immediately to avoid safety accidents.

[0047] In addition, tasks such as status reporting (e.g., remaining battery power, tire pressure) and path planning updates for autonomous driving equipment in mines also rely on timers for scheduled execution.

[0048] In the traditional design of embedded systems for autonomous driving in mines, the timing requirements at different frequencies are typically addressed by creating a separate timer for each task. For example, a timer might be created for the 30Hz data processing task of the LiDAR, another timer for the 10Hz monitoring task of the millimeter-wave radar, and yet another timer for the heartbeat monitoring task of the braking system.

[0049] A moderately complex autonomous driving system for mining often requires the creation of dozens or even hundreds of independent timers.

[0050] The parallel operation of multiple timers can frequently trigger interrupts, potentially leading to interrupt conflicts. For example, when the lidar data processing timer and the braking system heartbeat timer trigger simultaneously, the heartbeat monitoring task may be delayed. If the delay exceeds 50ms, braking system malfunctions cannot be detected in time, directly threatening mine operation safety. Furthermore, traditional timer solutions lack adaptability to different task granularities. For instance, during nighttime mine operations, if the camera image acquisition frequency needs to be reduced (from 30Hz to 10Hz), a new timer must be created, which is complex and prone to system instability.

[0051] The timed task scheduling method, apparatus, system, vehicle, and chip provided in this application will be described in detail below with reference to specific embodiments and application scenarios.

[0052] This embodiment provides a timed task scheduling method for a timed task scheduling system. The timed task scheduling system includes at least one sensor, and each sensor corresponds to a different preset execution period, such as... Figure 1 As shown, the scheduled task method includes:

[0053] Step S100: Determine at least one scheduling object and a base time interval corresponding to each scheduling object according to a preset execution cycle, and associate each scheduling object with a timer;

[0054] Step S102: Obtain the task to be scheduled for each sensor. One scheduling object corresponds to at least two tasks to be scheduled.

[0055] Step S104: Determine the trigger multiplier for each task to be scheduled based on the preset execution cycle of the task to be scheduled and the base time interval corresponding to the scheduling object;

[0056] Step S106: Control the timer to periodically generate a trigger signal according to the reference time interval;

[0057] Step S108: In response to the trigger signal, update the cumulative trigger value of all tasks to be scheduled corresponding to the scheduling object;

[0058] Step S110: For each task to be scheduled, determine whether the updated cumulative trigger value is greater than or equal to the trigger multiple corresponding to the task to be scheduled, and determine the result.

[0059] Step S112: When the judgment result is yes, execute the corresponding scheduled task and reset the trigger accumulation value corresponding to the scheduled task after execution.

[0060] The timed task scheduling method provided by this invention first identifies a few scheduling objects based on multiple task requirements with different preset execution cycles. Each object is strictly bound to a single physical timer and a base time interval is set. Then, all tasks are bound to the corresponding scheduling objects according to the trigger multiple of the cycle and the base interval.

[0061] Trigger signals are periodically generated by a physical timer to synchronously accumulate the trigger values ​​of all tasks. Finally, by comparing the accumulated value of each task with its trigger multiple, tasks that have reached their preset cycle are accurately identified and executed, and then the accumulated state of the tasks to be scheduled is reset.

[0062] For example, the scheduling object includes a timer framework. The timer framework in this invention can support each process of the mine autonomous driving equipment (such as the environmental perception process and the equipment monitoring process) to create 1 to 3 timer framework objects based on the framework. Each timer framework object corresponds to only one physical timer, and the timing interval of the physical timer can be flexibly configured according to the task requirements of the mine autonomous driving.

[0063] Each timer framework is equipped with an independent timeout event handling thread. The timeout event handling thread is only responsible for listening to the timeout signal of the timer and querying the task queue registered under the corresponding timer framework.

[0064] Understandably, by adopting a one-frame-one-timer design, the number of timers in mining autonomous driving equipment is significantly reduced. This fundamentally enables reliable and accurate scheduling of a large number of tasks with different cycles using minimal physical timer resources, solving the technical problems of resource waste and scheduling conflicts caused by the traditional one-task-one-timer mode, and ensuring that mining autonomous driving equipment can still respond quickly to environmental changes under complex working conditions.

[0065] At the same time, reducing the number of timers also reduces the risk of interrupt conflicts.

[0066] Specifically, each scheduling object is represented internally as an independent timer management module, and each timer management module is uniquely bound to a timer upon creation.

[0067] Timers include, but are not limited to, timing units directly driven by hardware or the operating system kernel.

[0068] The scheduling object maintains a task list to record all tasks registered under the scheduling object and their related parameters.

[0069] Each scheduled task contains at least a pointer to the actual execution function, a preset execution period determined by the task source (such as a specific sensor), and an integer trigger multiplier calculated based on the preset execution period and the baseline time interval of the scheduled object.

[0070] The baseline time interval is the basic time unit of the scheduled object. Its value is usually derived from the preset execution cycle of all tasks included in the scheduled object by an algorithm (such as finding the greatest common divisor) to ensure that the cycle of each task is an integer multiple of the baseline time interval.

[0071] The timer framework is a complete software architecture layer consisting of multiple scheduling objects mentioned above.

[0072] The timer framework provides a unified application programming interface (API) for different functional modules in the system (such as the environment perception process and the vehicle control process) to create and manage scheduling objects.

[0073] The timer framework analyzes the periodic characteristics of all timed tasks in the system and groups tasks with periods that are multiples of each other into the same scheduling object, thereby replacing dozens of independent timers that might be required in traditional solutions with only a few physical timers.

[0074] The physical timer within each scheduling object generates periodic trigger signals strictly according to the baseline time interval.

[0075] Once the trigger signal is captured by a dedicated listening thread within the scheduling object, the thread will non-blockingly traverse the task list, increment the cumulative trigger value of each scheduled task, and compare it with the trigger multiplier of the scheduled task.

[0076] When the accumulated value reaches the trigger multiple, the task to be scheduled will be encapsulated into a task unit and submitted to an independent global thread pool to wait for asynchronous execution, while its accumulated value is reset.

[0077] The scheduled task system will connect to at least one type of sensor when it is running.

[0078] For example, a sensor is a logical entity or physical device that generates periodic triggering requirements. Its instantiated objects in the system include, but are not limited to, environmental perception sensors (LiDAR, millimeter-wave radar, vision cameras), vehicle bus monitoring modules (for acquiring heartbeat messages from control units on the bus), or system status monitoring units (for checking memory usage or network latency).

[0079] Each type of sensor is assigned a pre-defined execution cycle based on its data update frequency, the security level of the monitored event, or the bandwidth requirements of the control loop it serves.

[0080] The preset execution period is a fixed value in milliseconds, which defines the shortest time interval between two allowed executions of the corresponding task.

[0081] The scheduled task method executes the following logical steps in sequence:

[0082] Based on all known preset execution cycles, determine one or more scheduling objects and a baseline time interval specific to each scheduling object.

[0083] The key constraint is that each scheduling object is associated with one and only one timer at the operating system level, which is directly managed by the hardware or the operating system kernel.

[0084] By converging multiple tasks (even those with different cycles) under the same scheduling object and sharing their uniquely associated timers, the number of physical timers in the system is reduced by an order of magnitude, fundamentally avoiding the risks of timer interrupt overload and conflicts.

[0085] Obtain the scheduled tasks corresponding to each sensor.

[0086] A task to be scheduled is an executable data structure that contains at least one function pointer (pointing to the actual business logic code of the task) and its preset execution period attribute. The system assigns each task to a suitable scheduling object based on its preset execution period. A scheduling object must correspond to and manage at least two tasks to be scheduled, thus demonstrating its aggregate management value.

[0087] Based on the preset execution cycle of the task to be scheduled and the baseline time interval of its corresponding scheduling object, a trigger multiple is determined for each task to be scheduled. The trigger multiple is an integer greater than or equal to 1, and it precisely describes how many baseline time interval pulses the task to be scheduled needs to accumulate to reach its expected execution cycle.

[0088] Control the timer associated with the scheduled object to generate hardware interrupts or kernel events, i.e., trigger signals, periodically according to the reference time interval of the scheduled object.

[0089] Whenever a scheduling object receives a trigger signal from its timer, it responds by iterating through all the scheduled tasks under its management and updating (usually by incrementing) the trigger accumulation value (a zero-based counter) within each task. The trigger accumulation value records the number of baseline time intervals that the scheduled task has experienced since its last execution.

[0090] For each task to be scheduled, determine whether its updated cumulative trigger value is greater than or equal to the trigger multiple of the task itself, and determine a judgment result.

[0091] When the judgment result for a scheduled task is yes, i.e. the condition is met, the business logic defined for the scheduled task is executed. After execution, the system immediately resets the trigger accumulation value corresponding to the scheduled task to zero, so that it begins to accumulate counts for the next execution cycle.

[0092] It is understandable that by designing one timer per object, the total number of timers in mine autonomous driving equipment can be significantly reduced from dozens to just a few, thereby significantly reducing resource consumption and the risk of interruption conflicts.

[0093] Furthermore, considering the multi-granularity characteristics of tasks in autonomous driving scenarios in mines (from milliseconds to seconds), this invention supports the creation of multiple timer framework objects with different timing interval granularities within the same process.

[0094] For example, in addition to creating timer framework objects with a granularity of 50ms (to adapt to millisecond-level tasks such as 200ms braking heartbeat and 100ms steering heartbeat), the equipment monitoring process can also create timer framework objects with a granularity of 1s to adapt to low-frequency tasks, such as the remaining battery status reporting of autonomous trucks in mines (reported every 3s, 3s is 3 times 1s) and tire pressure monitoring (checked every 5s, 5s is 5 times 1s).

[0095] By combining multi-granularity timer framework objects, the system can cover the full range of timing requirements in mine autonomous driving, from 10ms (such as high-frequency sensor data processing) to 10s (such as equipment fault log upload). This eliminates the need to design separate timer schemes for different granularity tasks, greatly improving the system's flexibility and maintainability.

[0096] For example, when the mining operation scene switches from daytime to nighttime, and the camera image acquisition frequency needs to be adjusted from 5Hz (200ms cycle) to 2Hz (500ms cycle), it is only necessary to modify the integer multiple coefficient in the 50ms granular timer framework object of the task (from 4 times to 10 times), without recreating the timer. The operation is simple and does not affect the operation of other tasks.

[0097] In some embodiments, the baseline time interval for scheduling objects may be dynamically adjusted based on the current central processing unit (CPU) load or task queue depth.

[0098] When the CPU load rate is below the first threshold or the task queue depth is less than the preset value, the base time interval is increased to reduce the frequency of timer interrupts; when the CPU load rate is above the second threshold, the base time interval is decreased to improve the granularity of task scheduling.

[0099] By dynamically adjusting the baseline time interval, the scheduling system can save computing power when the system load is light and ensure real-time performance when the load is high, thus achieving an adaptive balance between energy efficiency and performance.

[0100] In some embodiments, the scheduled task method may optionally further include, by monitoring the cumulative trigger values ​​of all scheduled tasks, predicting that at least one scheduled task will be triggered within a few baseline time intervals in the future, thereby allocating execution threads from the global thread pool or preloading the required data for these scheduled tasks in advance.

[0101] By using predictive resource allocation, the execution of tasks awaiting scheduling is prevented from being delayed due to waiting for resources after the triggering conditions are met, thus ensuring the determinism of high real-time task execution.

[0102] In some embodiments, optionally, such as Figure 2As shown, at least one scheduling object and a base time interval corresponding to each scheduling object are determined according to a preset execution cycle, including:

[0103] Step S1042: Obtain the preset execution cycle of multiple tasks to be scheduled associated with the scheduling object;

[0104] Step S1044: Calculate the greatest common divisor of multiple preset execution cycles to determine the initial reference time parameters;

[0105] Step S1046: Adjust the initial reference time parameters according to the system load constraint parameters to obtain the target reference time parameters;

[0106] Step S1048: Determine the reference time interval corresponding to the scheduling object based on the target reference time parameter.

[0107] In this embodiment, the preset execution cycles of all tasks grouped under the same scheduling object are first obtained. By calculating the greatest common divisor of these cycles, the initial base time parameter is obtained. Then, real-time load constraint parameters of the system (such as CPU utilization and interrupt load) are introduced to dynamically adjust and optimize the initial base time parameter, and finally, the target base time interval is generated and set as the running tick of the scheduling object.

[0108] Understandably, by combining theoretical calculations to establish a divisibility basis with dynamic optimization to adapt to the system state, while ensuring that all timed task cycles can be accurately divided and triggered, the system intelligently avoids the problem of invalid interruption overhead caused by setting the base interval too small, or the problem of setting it too large, which may affect the real-time response of the task. Thus, an adaptive balance is achieved between scheduling accuracy and overall system resource utilization.

[0109] Specifically, it retrieves the preset execution cycles of multiple tasks to be scheduled associated with a scheduling object. This refers to the scheduling system reading the cycle values ​​declared by all tasks to be scheduled that have been assigned to a specific scheduling object for management from its internal registry or configuration file.

[0110] The preset execution cycle is a fixed value predefined by the task's own attributes or external requirements (such as sensor data sampling frequency and system monitoring frequency). It represents the fixed time interval at which the task is expected to be executed. For example, a lidar data processing task may correspond to a 33-millisecond cycle, while a braking system heartbeat check task may correspond to a 200-millisecond cycle.

[0111] Multiple tasks to be scheduled associated with a scheduling object mean that these tasks are logically categorized into the same management group and share the same physical timer resource.

[0112] Secondly, the greatest common divisor (GCD) is calculated for multiple preset execution cycles to determine the initial base time parameters. The GCD calculation aims to find the largest integer factor common to a set of cycle values. The purpose of the GCD calculation is to find the largest base time unit from a set of discrete cycle values ​​that can divide (or approximately divide) all cycles.

[0113] The calculated base time unit is the initial reference time parameter, which is a theoretically optimal candidate value designed to ensure that the preset execution cycle of each task can be represented as an integer multiple of the initial reference time parameter, thus laying the mathematical foundation for the subsequent integer multiple triggering mechanism.

[0114] Next, the initial reference time parameters are adjusted according to the system load constraint parameters to obtain the target reference time parameters.

[0115] System load constraint parameters are dynamic indicators that reflect the real-time operating status of the system.

[0116] For example, system load constraints include, but are not limited to, the current utilization of the central processing unit, the frequency of interrupt requests, the average wait length of the task queue, or the available memory resources.

[0117] The initial reference time parameters are compared and analyzed with the real-time system load constraint parameters. For example, when the system load is light, the system load constraint parameters may be maintained or fine-tuned; while when the system detects high load or frequent interrupt conflict risk, the system load constraint parameters may be appropriately increased to reduce the timer interrupt frequency, thereby reducing CPU overhead.

[0118] The final value obtained after the dynamic adjustment process is the target reference time parameter, which is the actual application value after achieving a balance between the theoretical optimal value and the real-time operating efficiency of the system.

[0119] Finally, the baseline time interval corresponding to the scheduling object is determined based on the target baseline time parameter.

[0120] Set the target reference time parameter value as the final reference time interval for the scheduling object. The reference time interval will serve as the sole trigger period for the timer bound to this scheduling object, and also as the reference for calculating the trigger multiple for all scheduled tasks under its jurisdiction.

[0121] In some embodiments, the system load constraint parameters may optionally include the average interrupt frequency of the central processing unit and the average length of the task ready queue within the current time window.

[0122] The initial baseline time parameter is adjusted using a weighted average of the average interrupt frequency and average queue length. For example, the higher the interrupt frequency or the longer the queue, the larger the target baseline time parameter should be compared to the initial value. By integrating interrupt load and queue status for comprehensive adjustment, the baseline time interval setting can simultaneously alleviate interrupt pressure and scheduling latency, improving the overall response determinism of the system under complex operating conditions.

[0123] In some embodiments, determining the target reference time parameter may optionally include obtaining task type identifiers associated with system functional safety from the set of tasks to be scheduled.

[0124] If there are tasks to be scheduled that are identified as safety-critical, then during the adjustment process, an upper limit value is set for the initial base time parameter to ensure that the target base time parameter does not exceed the upper limit value.

[0125] By setting a baseline interval upper limit for safety-critical tasks, the minimum execution frequency of such high real-time tasks is ensured, thereby stabilizing the system's security foundation.

[0126] In some embodiments, optionally, before calculating the greatest common divisor of multiple preset execution cycles, a preprocessing step is included: removing the cycles with the largest and smallest values ​​from the preset execution cycle sequence before calculating the remaining cycles. This strategy helps to eliminate the excessive influence of extreme cycle values ​​on the calculation results, making the determined initial reference time parameters more representative of the cycle characteristics of the main task, and improving the universality and robustness of the scheduling plan.

[0127] In some embodiments, optionally, after determining the base time interval corresponding to the scheduling object based on the target base time parameter, the method further includes: recalculating the trigger multiple of each scheduled task based on the base time interval; if the trigger multiple of a scheduled task is greater than a preset maximum multiple threshold, generating a warning log and suggesting that the scheduled task be migrated to another scheduling object with a smaller base time interval.

[0128] By adding verification and alarm mechanisms, we can prevent the risk of triggering multiples from being too large due to the excessively long cycle of individual tasks, which could lead to overflow of the cumulative trigger value or inaccurate status tracking.

[0129] In some embodiments, optionally, such as Figure 3 As shown, when the judgment result is yes, the corresponding scheduled task is executed, including:

[0130] Step S1122: When the judgment result is that the updated cumulative trigger value is greater than or equal to the trigger multiple corresponding to the task to be scheduled, obtain the task identifier and preset priority parameter of the task to be scheduled;

[0131] Step S1124: Generate a task execution descriptor based on the task identifier and preset priority parameters;

[0132] Step S1126: Submit the task execution descriptor to the priority task queue of the global thread pool;

[0133] Step S1128: The global thread pool schedules and executes the scheduled tasks from the priority task queue according to the preset priority parameters.

[0134] This embodiment proposes an asynchronous task submission and scheduling execution mechanism based on priority identifiers. After the task triggering conditions are met, this mechanism does not directly execute the task. Instead, it first obtains the task's unique identifier and preset priority parameters, and encapsulates them into a standardized task descriptor. Subsequently, the descriptor is asynchronously submitted to an independent global thread pool, and placed into the corresponding priority queue according to the priority parameters. Finally, the global thread pool schedules worker threads from the queue to actually execute the task according to the priority strategy.

[0135] It is understandable that by introducing a scheduling strategy based on task priority, critical safety tasks (such as issuing braking commands and emergency obstacle avoidance) can be given high priority and will be given priority to obtain CPU time slices when resources are scarce.

[0136] For example, even under extreme conditions where the system load reaches 90%, the response latency of high-priority tasks is still controlled within 3ms, which is far below the 10ms threshold required by the safety regulations for automated driving in mines.

[0137] Meanwhile, the priority scheduling strategy effectively isolates the coupling between tasks. A single task failure (such as a communication module jamming) will not block the operation of the entire timer framework, significantly enhancing the long-term stable operation capability of mine autonomous driving equipment in harsh and complex environments.

[0138] When the system determines that the cumulative trigger value of a task to be scheduled meets the trigger multiple corresponding to the task, the task execution process is triggered.

[0139] First, obtain the task identifier and preset priority parameters of the task to be scheduled.

[0140] Retrieve and read the metadata associated with the task to be scheduled from the task list managed by the scheduling object.

[0141] A task identifier is a unique symbol or code that identifies a specific task to be scheduled. It is used to precisely refer to a task instance in the system, such as a lidar point cloud processing task or a braking system heartbeat check task.

[0142] The preset priority parameter is a pre-configured numerical value or level label that represents the relative importance and urgency of the task to be scheduled in the overall system.

[0143] For example, tasks directly related to vehicle safety (such as brake heartbeat monitoring) are assigned the highest priority parameters, while ordinary tasks related to data reporting are assigned lower priority parameters.

[0144] Next, a task execution descriptor is generated based on the task identifier and preset priority parameters.

[0145] The acquired task identifier, preset priority parameters, and other necessary execution context information (such as the entry address of the task function, required parameters, etc.) are packaged to create a structured data block, namely the task execution descriptor.

[0146] The task execution descriptor is a standardized carrier for transferring tasks from the scheduling system to the execution system. The task execution descriptor completely describes all the necessary information for a single execution instance of a task to be scheduled.

[0147] Then, the task execution descriptor is submitted to the priority task queue of the global thread pool.

[0148] After generating the task execution descriptor, the scheduling object or its associated event handling thread immediately sends it to a global thread pool that is independent of the scheduling thread.

[0149] A global thread pool is a set of reusable worker thread resources that are pre-created and managed by the system.

[0150] The task execution descriptor is placed in the priority task queue managed by the global thread pool, which is a buffer that is sorted according to the preset priority parameters in the task execution descriptor.

[0151] High-priority task descriptors are placed at the front of the queue to ensure they are processed first. This design prevents time-consuming task execution from blocking the scheduling thread's timely response to the next timed signal, thus ensuring the determinism of scheduling timing.

[0152] The global thread pool schedules and executes tasks from the priority task queue based on preset priority parameters. The scheduler in the global thread pool continuously monitors the priority task queue and retrieves task execution descriptors from the queue in descending order of priority according to the preset priority parameters in the task execution descriptors.

[0153] The scheduler then allocates an idle worker thread from the thread pool and hands over the retrieved task execution descriptor to the worker thread. Based on the information in the task execution descriptor, the worker thread calls the corresponding task function to complete the actual execution of the scheduled task, such as executing a sensor data processing algorithm or sending control commands.

[0154] After execution, the worker thread is released and returned to the thread pool, waiting for the next allocation. By combining a global thread pool with a priority queue, the system achieves efficient reuse of computing resources and prioritizes critical tasks.

[0155] In some embodiments, the preset priority parameter may be dynamically adjusted according to the current operating mode of the system or the degree of resource scarcity.

[0156] For example, when the system detects that the CPU load rate continuously exceeds the safety threshold or that critical memory resources are insufficient, it can automatically increase the priority parameters of safety-related tasks such as vehicle chassis control and emergency braking, while appropriately reducing the priority parameters of non-critical tasks such as data recording and status reporting.

[0157] By dynamically adjusting priority parameters, the task scheduling strategy can adapt to system load, prioritizing the real-time performance of core security functions when resources are limited, thereby improving system robustness.

[0158] In some embodiments, the process of generating a task execution descriptor may include estimating the possible execution time of the task to be scheduled and using the estimated time as a field of the descriptor.

[0159] When the scheduler of the global thread pool selects a task from the priority task queue, it makes a comprehensive decision based on the preset priority parameters and the estimated time of the task.

[0160] By introducing execution time estimation for joint scheduling, the efficiency of the thread pool can be further optimized while satisfying the priority order, avoiding excessive blocking of thread resources by long tasks and improving the overall throughput of task completion.

[0161] In some embodiments, optionally, such as Figure 4 As shown, in response to a trigger signal, the cumulative trigger values ​​of all tasks to be scheduled corresponding to the scheduling object are updated, including:

[0162] Step S1082: Obtain the trigger signal through the listening thread associated with the scheduling object;

[0163] Step S1084: In response to the trigger signal, check the running status identifier of the scheduled object;

[0164] Step S1086: When the running status indicator shows an active state, access the task list corresponding to the scheduling object;

[0165] Step S1088: Traverse the task list and perform an update calculation on the cumulative trigger value of each task to be scheduled.

[0166] In this embodiment, after each trigger signal is generated by the physical timer associated with the scheduling object, an independent listening thread captures the trigger signal.

[0167] After confirming that the scheduling object is active, the thread safely accesses the list of tasks it manages and iterates through the list to perform an increment operation on the cumulative trigger value recorded for each scheduled task.

[0168] Understandably, by checking the running status identifier, the scheduling process is provided with management capabilities such as pausing and resuming, which enhances the controllability of the system.

[0169] Furthermore, by limiting the cumulative value update to a single listening thread and completing it serially, the status of multiple tasks is synchronized and consistently advanced, avoiding the state chaos that may be caused by concurrent updates from multiple threads, and laying a reliable data foundation for subsequent accurate determination of trigger conditions.

[0170] Specifically, the trigger signal is obtained through the listening thread associated with the scheduling object.

[0171] The listener thread is an independent execution thread that is generated and started when the scheduling object is created. The listener thread is designed to continuously monitor the output of the physical timer bound to its scheduling object.

[0172] Acquiring a trigger signal means that the listening thread passively receives events through the event waiting mechanism provided by the operating system (such as blocking on a semaphore, event object, or message queue), or actively reads them by polling the status of hardware registers, thereby capturing hardware interrupts or software events generated by physical timers. This event is the trigger signal, which marks the expiration of a new reference time interval.

[0173] In response to a trigger signal, the running status flag of the scheduled object is checked. After confirming the trigger signal is valid, the listening thread immediately enters the corresponding signal handling logic. The running status flag is a variable managed internally by the scheduled object, used to indicate whether the scheduled object is currently in a working state that allows processing timed events and updating task status.

[0174] For example, the running status identifier includes, but is not limited to: active, paused, stopped, or faulty.

[0175] When the running status indicator shows an active state, access the task list corresponding to the scheduling object. The active state indicates that the scheduling object has been enabled and is functioning normally, and subsequent status update operations can be performed.

[0176] The task list is a data structure (such as an array, linked list, or hash table) maintained in memory by the scheduling object. The task list stores the control block information of all tasks to be scheduled registered under this scheduling object.

[0177] Each task control block should contain at least the following fields: task identifier, trigger multiplier, current cumulative trigger value, and task function pointer.

[0178] Finally, the task list is traversed, and the trigger accumulation value of each pending task record is updated. The listening thread visits each pending task control block in the task list one by one in a certain order (such as sequential or iterator method). The core operation of this response is to update the trigger accumulation value of each pending task record. For each pending task in the list, the listening thread reads its currently stored trigger accumulation value (an integer), calculates the new accumulation value according to the predetermined update rule (usually an increment operation), and writes this new value back to the corresponding field of the task control block.

[0179] The entire update process occurs within the listening thread context, ensuring the timeliness and consistency of state modifications.

[0180] In some embodiments, optionally, the task list corresponding to the scheduling object is accessed using a copy-on-read technique. Before traversing the list, the listening thread obtains a read-only copy of the current task list structure. All update calculations are performed based on this copy. After the traversal and update are completed, an atomic pointer switch replaces the newly generated state list with the current list.

[0181] By using copy-on-read technology to access the task list, the mutex lock contention between the listening thread and the management thread is completely eliminated, achieving non-blocking concurrency in the state update process and the list management process, thus improving system performance in highly dynamic task scenarios.

[0182] In some embodiments, optionally, when performing update calculations on the triggered cumulative value, an addition operation with a saturation cap is used. That is, the cumulative value is incremented to a predefined maximum value and then stops increasing until it is reset after the task is executed. The system configures this saturation cap value for each scheduling object during initialization. By introducing a saturation cap for the triggered cumulative value, the abnormal situation of the cumulative value growing indefinitely and eventually overflowing due to the task not being scheduled for a long time can be effectively prevented, providing a safety net for the system's state.

[0183] In some embodiments, optionally, such as Figure 5 As shown, after obtaining the scheduled task corresponding to each sensor, the timed task scheduling method also includes:

[0184] Step S1030: Receive the registration request of the task to be scheduled. The registration request includes the task identifier, the preset execution cycle, and the task processing function pointer.

[0185] Step S1032: Match the target scheduling object for the task to be scheduled according to the preset execution cycle;

[0186] Step S1034: Based on the trigger multiplier and the trigger accumulation value initialized to zero, store the task identifier and task processing function pointer into the task list managed by the target scheduling object.

[0187] In this embodiment, during system runtime, a registration request containing key task attributes (identifier, period, function pointer) is received. Based on the divisibility relationship between the task's preset period and the baseline interval of existing scheduling objects, the most suitable target scheduling object is intelligently matched. Then, the triggering multiple of the task under the scheduling object is calculated, and its status information (including the triggering cumulative value initialized to zero) is encapsulated into a task control block and stored in the task list managed by the target scheduling object.

[0188] Understandably, new scheduled tasks are dynamically added during system runtime without requiring a restart or rebuild of the entire scheduling framework. This completely decouples task registration from the management of underlying physical timer resources. By periodically aggregating tasks under a few shared scheduling objects, the core architectural advantage of driving a large number of logical tasks with very few physical timers is continuously reinforced, greatly improving the system's scalability and maintainability.

[0189] First, the system receives registration requests for tasks to be scheduled.

[0190] The system obtains task registration instructions initiated by other modules within the system or external configuration sources through predefined application programming interfaces, message queues, or event buses.

[0191] The registration request is a structured data message that contains at least three core fields: task identifier, preset execution cycle, and task processing function pointer.

[0192] A task identifier is a string or numeric code that uniquely represents the task to be scheduled across the entire system, and is used to accurately identify the task in logs, monitoring, and subsequent management operations.

[0193] The preset execution cycle is a positive integer value in milliseconds or microseconds. It is predefined by the task issuer based on sensor data update requirements, control loop frequency, or monitoring security level, and specifies the theoretical shortest interval between two consecutive executions of this task.

[0194] A task processing function pointer is a reference to the entry address of an executable code segment in memory. The code segment encapsulates the specific business logic that the scheduled task needs to complete, such as calling a specific sensor driver to read data, executing a specific control algorithm, or performing a status check.

[0195] Next, according to the preset execution cycle, a target scheduling object is matched for the task to be scheduled.

[0196] Each scheduling object records its baseline time interval. The preset execution cycle in the registration request is compared and calculated with the baseline time intervals of each scheduling object in the registry.

[0197] The goal of matching is to find a scheduling object whose baseline time interval is divisible (or approximately divisible, within the allowable error range) by the preset execution period, i.e., the preset execution period is an integer multiple of the baseline time interval.

[0198] If multiple eligible scheduling objects exist, the system can select one as the target scheduling object according to a preset strategy.

[0199] If no existing scheduling object meets the requirements, the system can trigger a process to create a new scheduling object based on a preset execution cycle.

[0200] Then, based on the trigger multiplier and the initial zero-based cumulative trigger value, the system stores the task identifier and task processing function pointer in the task list managed by the target scheduling object. After matching the target scheduling object, the system calculates the trigger multiplier, which is an integer obtained by dividing the preset execution period by the base time interval of the target scheduling object.

[0201] At the same time, the system creates a status record for this task to be scheduled, in which the cumulative trigger value is initialized to zero, indicating that the task to be scheduled has not experienced any baseline time interval trigger of its scheduling object since registration or since the last execution.

[0202] Finally, the task identifier, task processing function pointer, calculated trigger multiplier, and trigger accumulation value initialized to zero are stored as a complete task control block in the task list managed by the target scheduling object.

[0203] The task list is a data structure (such as a linked list, array, or hash table) inside the target scheduling object used to manage all the tasks to be scheduled under it. Through this list, the scheduling object can efficiently traverse and update the trigger accumulation value of all registered tasks each time the baseline time interval is triggered.

[0204] Optionally, when receiving a registration request for a task to be scheduled, the system simultaneously verifies the validity of a preset execution period. The verification includes determining whether the preset execution period is a positive integer, whether it falls within the minimum and maximum period range supported by the system, and whether it conflicts with an already registered task identifier. If any verification fails, the registration request is rejected, and a response containing a specific error code is returned to the requester.

[0205] By adding a pre-verification mechanism for registration requests, illegal or conflicting parameter configurations can be intercepted before tasks are connected to the system, ensuring the consistency and reliability of data within the scheduling system from the source and avoiding runtime anomalies caused by misconfiguration.

[0206] In some embodiments, optionally, after storing the task information in the task list, the system synchronously returns a registration receipt to the initiator of the registration request. The registration receipt includes the internal task handle allocated by the system, the identifier of the finally matched target scheduling object, and the calculated trigger multiplier. The initiator can subsequently query, modify, or cancel the task through the internal task handle.

[0207] By providing synchronized receipts containing key information, the system enhances the transparency and manageability of system interactions by offering clear confirmation and credentials for subsequent operations to task managers.

[0208] In some embodiments, optionally, for scheduled tasks with a preset execution cycle of extremely long (e.g., more than 10 seconds), the system will create an independent, dedicated scheduling object for them during registration, rather than attempting to match them to an existing high-frequency scheduling object.

[0209] The independent scheduling object will directly set its baseline time interval based on the preset execution cycle of this long-cycle task.

[0210] By enabling a separate scheduling object for ultra-long-cycle tasks, we can avoid such tasks from occupying the task list resources of the common scheduling object for a long time due to excessive triggering multiples, and reduce unnecessary frequent cumulative value update calculations, thereby improving the running efficiency of the common scheduling object.

[0211] In some embodiments, optionally, such as Figure 6 As shown, the scheduled task method also includes:

[0212] Step S1140: Receive the operating condition change instruction, which includes the scheduling object identifier and the update baseline interval parameter;

[0213] Step S1142: Locate the target scheduling object based on the scheduling object identifier;

[0214] Step S1144: Update the baseline time interval of the target scheduling object according to the updated baseline interval parameter;

[0215] Step S1146: Recalculate the trigger multiple of each scheduled task under the target scheduling object based on the updated baseline time interval;

[0216] Step S1148: Synchronize the recalculated trigger multiplier to the task list corresponding to the target scheduling object.

[0217] In this embodiment, by receiving a condition change instruction containing the target scheduling object identifier and a new baseline interval parameter, the time baseline of the specified scheduling object is accurately located and updated. Then, using this new baseline as a scale, the trigger multiples of all scheduled tasks under its management are uniformly recalculated, and the updated multiples are atomically synchronized to the task status list.

[0218] Understandably, by reconfiguring parameters once, the periodic characteristics of all scheduled tasks are ensured to continue, while maintaining the integrity and real-time performance of the internal state of the scheduling framework. This significantly improves the system's adaptability to complex environmental changes and its overall maintainability.

[0219] Specifically, the system receives instructions regarding changes in operating conditions. It obtains adjustment commands initiated from outside the system (such as an upper-level monitoring system) or inside the system (such as an adaptive strategy module) through predefined management interfaces, configuration channels, or event message queues.

[0220] The operating condition change instruction is a structured instruction data packet that explicitly contains two core data fields: the scheduling object identifier and the update baseline interval parameter.

[0221] A scheduling object identifier is a symbol or number that uniquely identifies a specific scheduling object within the system, used to accurately locate the instance of the scheduling object that needs to be adjusted.

[0222] The update baseline interval parameter is a positive integer value in milliseconds or microseconds. The update baseline interval parameter represents the new base time unit that the target scheduling object should adopt under the new operating conditions after the change.

[0223] Secondly, the system locates the target scheduling object based on the scheduling object identifier. Using the received scheduling object identifier as a query key, it performs a matching search in the registry to find and obtain a reference or pointer to the specific scheduling object corresponding to the scheduling object identifier.

[0224] Next, the system updates the baseline time interval of the target scheduling object based on the updated baseline interval parameter. The value of the updated baseline interval parameter is then set as the new value of the baseline time interval, an internal state variable of the target scheduling object. This operation directly changes the core time base of the target scheduling object.

[0225] At the same time, the system will reconfigure the hardware registers or kernel timer parameters of the physical timer uniquely associated with the target scheduling object based on this new reference time interval, so that its subsequent trigger signal period is consistent with the new reference time interval.

[0226] Then, the trigger multiplier for each scheduled task under the target scheduling object is recalculated based on the updated baseline time interval. The task list managed by the target scheduling object is accessed, and the preset execution cycle recorded for each scheduled task in the list is retrieved sequentially.

[0227] For each task to be scheduled, the system performs a division operation: dividing the task's preset execution period by the updated baseline time interval. The integer quotient obtained is the triggering multiple of the task under the new time baseline.

[0228] Finally, the recalculated trigger multiples are synchronized to the task list corresponding to the target scheduling object. The trigger multiples recalculated for each task to be scheduled in the previous step are written back to the trigger multiple storage field of the corresponding task control block in the task list, overwriting the existing values.

[0229] Meanwhile, as a robust design, the system usually resets the cumulative trigger value of each task to zero or scales it proportionally according to the relationship between the old and new multiples to ensure that the task status is smoothly connected with the scheduling logic under the new baseline interval.

[0230] Understandably, by receiving instructions containing the target identifier and new interval parameters, the baseline time interval of a specific scheduling object can be accurately located and updated; then, based on this new interval, the trigger multiple of all tasks under its command can be recalculated and synchronously updated to the task status list, which significantly improves the overall adaptability and maintainability of the system.

[0231] The timing diagram of the scheduled task method is as follows: Figure 10 As shown, the operation flow of the timed task scheduling method of the present invention in a real system can be specifically demonstrated through the scheduling sequence of the heartbeat task of the braking system in the equipment monitoring process. The timing diagram depicts the complete closed loop from task registration, periodic triggering, condition judgment, asynchronous execution to result feedback.

[0232] The equipment monitoring process is a functional module in the system responsible for monitoring the status of key vehicle components.

[0233] During the initialization phase, the device monitoring process calls a creation interface to generate a 50-millisecond frame object. This 50-millisecond frame object is a specific scheduling object defined in this method, with its base time interval set to 50 milliseconds. When the scheduling object is created, the system creates and binds a unique physical timer to it, and simultaneously generates an independent timeout handling thread and a task queue.

[0234] The device monitoring process registers the braking heartbeat task to this 50-millisecond framework object.

[0235] The preset execution period for the braking heartbeat task is 200 milliseconds. The system automatically calculates the trigger multiple of the task as 4 according to the formula (trigger multiple = preset execution period / baseline time interval), and stores the task information (including task identifier, trigger multiple, and current cumulative count initialized to 0) in the task queue managed by the scheduling object.

[0236] The physical timer triggers a timeout signal strictly and periodically at a base interval of 50 milliseconds. Each time a timeout signal is generated, the timeout handling thread (i.e., the listening thread of the scheduling object) is awakened. The thread queries the current cumulative count of the braking heartbeat tasks in the task queue. Upon receiving the first three timeout signals, the current cumulative counts were 1, 2, and 3, respectively. After each query, the timeout handling thread performs a "cumulative count + 1" operation and updates the task queue. However, at this point, the cumulative counts of 1, 2, and 3 are all less than the trigger multiplier of 4, so task execution is not triggered.

[0237] When the fourth timeout signal arrives, the timeout processing thread checks and finds that the current cumulative count is 4.

[0238] At this point, the current cumulative count equals the trigger multiplier, satisfying the task triggering condition. The timeout processing thread immediately resets the current cumulative count to 0, generates a task execution descriptor for the braking heartbeat task, and submits it to the global thread pool.

[0239] After receiving a task, the global thread pool schedules an idle worker thread from its resource pool to execute the task.

[0240] Thread 3 calls the task processing function associated with the braking heartbeat task, namely the Brake_Heartbeat_Check() function. Executing the function means communicating with the braking system in real time to obtain the heartbeat status (normal or abnormal) of the braking system.

[0241] The heartbeat status returned by the braking system serves as the task execution result and is fed back to the device monitoring process via a callback mechanism. After the task is completed, thread 3 releases itself and returns to the thread pool, becoming idle and waiting for the next scheduling.

[0242] The timing diagram clearly verifies the core process of the method of the present invention: a scheduling object (50 milliseconds framework object) is driven by its uniquely bound physical timer, based on the integer multiple relationship between the base time interval (50ms) and the trigger multiple (4), and precisely triggers the braking heartbeat task at the preset execution cycle (200ms).

[0243] Furthermore, the time-consuming execution of tasks (interacting with the braking system) is separated into a global thread pool for asynchronous completion, ensuring that the timeout handling thread can continue to respond to the next timed signal without being blocked, thereby guaranteeing the real-time performance and reliability of the entire timed scheduling system.

[0244] In one specific embodiment, the timed task scheduling method may optionally include:

[0245] 1. Timer framework object creation (adapted for autonomous driving scenarios in mines):

[0246] During the initialization phase of the automated driving equipment in the mine, a timer framework object can be created by calling the TimerFramework_Create interface provided by this invention. The interface requires three core parameters:

[0247] (1) The basic timing interval (unit: ms) needs to be determined according to the mainstream cycle of the tasks in the process. For example, the environmental perception process uses 10ms as the basic interval, and the device monitoring process uses 50ms and 1s as the basic interval.

[0248] (2) Thread priority: Considering the safety of automatic driving in mines, the timer framework object processing thread priority of the equipment monitoring process should be set to the highest (e.g., priority 1), followed by the environmental perception process (priority 3), to avoid high-priority tasks being blocked by low-priority tasks.

[0249] (3) Task queue capacity is configured according to the number of tasks registered in the process. For example, if the device monitoring process needs to register 8 tasks such as steering, braking, and power system heartbeat, the task queue capacity is set to 16 (with one times the redundancy reserved). After the interface is called, the system will automatically create the corresponding physical timer, timeout handling thread and task queue, and return the timer framework object handle for subsequent task registration.

[0250] 2. Timer Configuration (Adapting to Changes in Mine Operating Conditions):

[0251] The timer framework object of the mine's automated driving equipment supports dynamic adjustment of the basic timing interval to adapt to different operating conditions. For example, when the mine experiences rain or snow, the noise in the LiDAR point cloud data increases, requiring the data processing frequency to be reduced from 30Hz to 20Hz (the period adjusted from 33.3ms to 50ms). In this case, the basic interval of the timer framework object for the environmental perception process can be adjusted from 10ms to 25ms (50ms is twice 25ms) by calling the TimerFramework_SetInterval interface, without needing to rebuild the timer framework object.

[0252] At the same time, the system will automatically update the integer multiple coefficients of all tasks in the task queue to ensure that the task triggering cycle matches the new base interval.

[0253] In addition, the timer also supports pause and resume functions. For example, when the mining autonomous truck enters maintenance mode and does not need to perform environmental perception tasks, the TimerFramework_Pause interface can be called to pause the corresponding timer framework object, reducing unnecessary CPU consumption. After maintenance is completed, the TimerFramework_Resume interface can be called to resume operation.

[0254] 3. Task Registration and Management (Mining Task Classification Management):

[0255] Tasks in mine automated driving equipment need to be registered to the corresponding timer framework object via the TimerTask_Register interface. Registration requires parameters such as task name, task period, and task execution function. The system automatically calculates an integer multiple coefficient based on the task period and the base interval of the timer framework object, and stores the task information in the task queue. For example, when registering a braking system heartbeat task, if the task period is 200ms and the base interval of the timer framework object is 50ms, the system automatically calculates a coefficient of 4 and adds information such as "Task Name: Braking Heartbeat, Coefficient: 4, Execution Function: Brake_Heartbeat_Check" to the task queue.

[0256] Meanwhile, the system supports dynamic cancellation and modification of tasks. For example, when a new tire pressure monitoring sensor is added to the mine, a tire pressure monitoring task every 5 seconds needs to be added. The TimerTask_Register interface can be called to register it to a timer framework object with a basic interval of 1 second (coefficient of 5). If the tire pressure monitoring cycle needs to be adjusted to 6 seconds later, the TimerTask_Modify interface can be called to modify the task cycle. The system will automatically update the coefficient to 6, without the need for cancellation and re-registration.

[0257] In addition, the system will periodically check the task queue. If a task is not executed by the thread pool after being triggered 3 times in a row (such as a thread pool failure), an alarm signal will be triggered immediately, and the operation and maintenance personnel will be notified through the central control system of the mine's automatic driving system to handle the issue and avoid safety risks caused by task loss.

[0258] 4. Timeout handling thread interacts with the thread pool (to ensure the real-time performance of mining tasks):

[0259] Each timer frame object's timeout handling thread continuously listens for the physical timer's timeout signal. Once a timeout is triggered, the thread first checks its own state (whether it is in a paused state). If normal, it iterates through all tasks in the task queue, determining whether each task's "cumulative timeout count" reaches an integer multiple of the coefficient. For example, if the device monitoring process's 50ms timer frame object times out once, the cumulative timeout count is incremented by 1. The thread then checks whether the cumulative count of the braking heartbeat task (coefficient 4) has reached 4. If not, it continues iterating; if it has, it resets the cumulative count to 0 and calls the ThreadPool_Submit interface to submit the task to the global thread pool.

[0260] The thread pool employs a priority scheduling mechanism. Safety-related tasks in mine automated driving (such as braking heartbeat monitoring and emergency braking triggering) are given the highest priority, while ordinary tasks (such as power reporting) have the next highest priority. For example, when the thread pool receives both a braking heartbeat task (priority 1) and a power reporting task (priority 5) at the same time, it will execute the braking heartbeat task first to ensure the real-time performance of safety tasks.

[0261] Meanwhile, the thread pool supports dynamic expansion. When multiple high-priority tasks are triggered simultaneously by the mine's autonomous driving equipment (such as when LiDAR, millimeter-wave radar, and camera tasks need to be processed at the same time in rainy or snowy weather), the thread pool will automatically increase the number of threads (up to twice the number of CPU cores) to avoid task backlog. After the tasks are processed, the number of threads will be automatically reduced to reduce resource consumption.

[0262] like Figure 7As shown in the figure, this application embodiment also provides a timed task scheduling device 900 for a timed task scheduling system. The timed task scheduling system includes at least one sensor, and each sensor corresponds to a different preset execution period. The timed task scheduling device 900 includes: a scheduling determination module 902, used to determine at least one scheduling object and a reference time interval corresponding to each scheduling object according to the preset execution period, and each scheduling object is associated with a timer; a task acquisition module 904, used to acquire the task to be scheduled corresponding to each sensor, and one scheduling object corresponds to at least two tasks to be scheduled; and a parameter determination module 906, used to determine the parameters according to the preset execution period of the task to be scheduled and the time interval corresponding to the timer. The system uses a base time interval corresponding to the object to determine the trigger multiple for each scheduled task; a signal triggering module 908 controls a timer to periodically generate trigger signals based on the base time interval; a value update module 910 updates the cumulative trigger values ​​of all scheduled tasks corresponding to the scheduling object in response to the trigger signals; a timing judgment module 912 determines whether the updated cumulative trigger value is greater than or equal to the trigger multiple corresponding to the scheduled task for each scheduled task, and determines the judgment result; and a task scheduling module 914 executes the corresponding scheduled task when the judgment result is yes, and resets the cumulative trigger value corresponding to the executed scheduled task.

[0263] like Figure 8 As shown in the figure, this application embodiment also provides a timed task scheduling system 200, including at least one sensor 2000, each sensor 2000 corresponding to a different preset execution cycle.

[0264] like Figure 9 As shown in the figure, this application embodiment also provides a vehicle 100, which is equipped with a timed task scheduling system 200.

[0265] For example, in a specific implementation scenario of the present invention, vehicle 100 is an autonomous driving truck operating in a mining environment, which integrates various on-board electronic control units and corresponding sensors and actuators responsible for environmental perception, decision-making and planning, and vehicle control.

[0266] The scheduled task scheduling system 200 operates as a core middleware in the vehicle's electronic and electrical architecture. At least one sensor in the system is embodied as a real physical device on the vehicle, such as lidar and millimeter-wave radar for detecting surrounding obstacles, cameras for recognizing lane lines and traffic signs, and brake / steering / power system status sensors for monitoring chassis health.

[0267] The preset execution cycle for each sensor is strictly defined by vehicle functional safety requirements and performance requirements. For example, the cycle for lidar point cloud acquisition is 33 milliseconds, and the cycle for braking system heartbeat monitoring is 200 milliseconds. These sensors send data or event trigger signals to the timed task scheduling system via the vehicle bus.

[0268] During vehicle operation, the scheduling object determination module of the timed task scheduling system creates corresponding scheduling objects based on the task requirements of different functional modules (such as environmental perception process and vehicle control process).

[0269] For example, create a scheduling object with a base time interval of 10 milliseconds for the environmental perception process, and create a scheduling object with a base time interval of 50 milliseconds for the vehicle control process.

[0270] Each scheduling object is uniquely associated with a timer provided by the vehicle computing platform.

[0271] Divide the preset execution cycle of each sensor task (such as the 30Hz LiDAR task, the 10Hz millimeter-wave radar task, and the 5Hz braking heartbeat task) by the base time interval of its respective scheduling object to obtain its integer trigger multiple (e.g., 3, 10, 4), and complete the registration.

[0272] Based on the configuration, the vehicle's timer control module drives the physical timer to periodically generate trigger signals at reference time intervals (such as 10ms or 50ms). The value update module (implemented by a high-priority listening thread within the scheduling object) responds to these signals and updates the trigger accumulation value of the corresponding task.

[0273] When the cumulative value of a critical safety task (such as brake heartbeat monitoring) reaches its trigger multiple, the timing judgment module determines that the execution conditions are met. The task scheduling module immediately submits the task to the global thread pool. Since the task has the highest priority, the thread pool will prioritize scheduling resources to execute it, thereby driving the vehicle's control system to send heartbeat check commands or perform fault diagnosis via the bus to ensure driving safety.

[0274] When the vehicle's operating conditions change (such as switching from daytime to nighttime operation), the upper-level system can send a condition change instruction to the timed task scheduling system.

[0275] Based on this, the system dynamically adjusts the baseline time interval of relevant scheduling objects and automatically updates the trigger multiple of all associated tasks, achieving seamless and uninterrupted switching of task execution frequency and ensuring efficient and stable operation of vehicles in different operating modes.

[0276] Therefore, vehicles equipped with this timed task scheduling system can reliably, accurately, and in real-time coordinate and manage a large number of sensing, decision-making, and control tasks of different frequencies with minimal physical timer resources. This fundamentally avoids the delay of critical tasks caused by interruption conflicts and significantly improves the safety, reliability, and operating efficiency of vehicles in complex and harsh operating environments.

[0277] This application also provides a chip, which includes a processor and a communication interface. The communication interface and the processor are coupled. The processor is used to run programs or instructions to implement the various processes of the above-described timed task scheduling method embodiments, and can achieve the same technical effect. To avoid repetition, it will not be described again here. In addition, the chip improves the data processing speed corresponding to the timed task scheduling method in this application.

[0278] It should be understood that the chip mentioned in the embodiments of this application may also be referred to as a system-on-a-chip, system chip, chip system, or system-on-a-chip, etc.

[0279] In this invention, the terms "first," "second," and "third" are used for descriptive purposes only and should not be construed as indicating or implying relative importance; the term "multiple" refers to two or more unless otherwise explicitly defined. The terms "install," "connect," "link," and "fix" should be interpreted broadly. For example, "connect" can be a fixed connection, a detachable connection, or an integral connection; "link" can be a direct connection or an indirect connection through an intermediate medium. Those skilled in the art can understand the specific meaning of the above terms in this invention according to the specific circumstances.

[0280] In the description of this invention, it should be understood that the terms "upper," "lower," "left," "right," "front," "rear," etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are only for the convenience of describing this invention and simplifying the description, and do not indicate or imply that the device or unit referred to must have a specific orientation or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on this invention.

[0281] In the description of this specification, the terms "one embodiment," "some embodiments," "specific embodiment," etc., refer to specific features, structures, materials, or characteristics described in connection with an embodiment or example that are included in at least one embodiment or example of the present invention. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0282] The above are merely preferred embodiments of the present invention and are not intended to limit the invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for scheduling timed tasks, characterized in that, A timed task scheduling system is used, the timed task scheduling system including at least one sensor, each sensor corresponding to a different preset execution period, the timed task scheduling method including: Based on the preset execution cycle, at least one scheduling object and a base time interval corresponding to each scheduling object are determined, and each scheduling object is associated with a timer; Obtain the scheduled task corresponding to each of the sensors, and one scheduling object corresponds to at least two scheduled tasks; Based on the preset execution cycle of the task to be scheduled and the base time interval corresponding to the scheduling object, determine the trigger multiple corresponding to each task to be scheduled; The timer is controlled to periodically generate a trigger signal according to the reference time interval; In response to the trigger signal, update the cumulative trigger value of all tasks to be scheduled corresponding to the scheduling object; For each scheduled task, determine whether the updated cumulative trigger value is greater than or equal to the trigger multiple corresponding to the scheduled task, and determine the determination result; When the judgment result is yes, the corresponding scheduled task is executed, and the trigger accumulation value corresponding to the scheduled task after execution is reset.

2. The timed task scheduling method according to claim 1, characterized in that, The step of determining at least one scheduling object and a baseline time interval corresponding to each scheduling object according to the preset execution period includes: Obtain the preset execution cycle of multiple tasks to be scheduled associated with the scheduling object; Calculate the greatest common divisor of multiple preset execution cycles to determine the initial reference time parameter; The initial reference time parameters are adjusted according to the system load constraint parameters to obtain the target reference time parameters; The reference time interval corresponding to the scheduling object is determined based on the target reference time parameter.

3. The timed task scheduling method according to claim 1, characterized in that, When the determination result is yes, the corresponding scheduled task is executed, including: When the determination result is that the updated cumulative trigger value is greater than or equal to the trigger multiple corresponding to the task to be scheduled, the task identifier and preset priority parameter of the task to be scheduled are obtained. A task execution descriptor is generated based on the task identifier and preset priority parameters; Submit the task execution descriptor to the priority task queue of the global thread pool; The global thread pool schedules and executes the scheduled tasks from the priority task queue according to the preset priority parameters.

4. The timed task scheduling method according to claim 1, characterized in that, The step of updating the cumulative trigger value of all tasks to be scheduled corresponding to the scheduling object in response to the trigger signal includes: The trigger signal is obtained through the listening thread associated with the scheduling object; In response to the trigger signal, check the running status identifier of the scheduling object; When the running status indicator indicates an active state, access the task list corresponding to the scheduling object; Iterate through the task list and perform an update calculation on the cumulative trigger value of each task to be scheduled.

5. The timed task scheduling method according to claim 1, characterized in that, After obtaining the scheduled task corresponding to each of the sensors, the timed task scheduling method further includes: Receive the registration request of the task to be scheduled, the registration request including task identifier, preset execution period and task processing function pointer; According to the preset execution cycle, a target scheduling object is matched for the task to be scheduled; Based on the trigger multiplier and the trigger accumulation value initialized to zero, the task identifier and the task processing function pointer are stored in the task list managed by the target scheduling object.

6. The timed task scheduling method according to any one of claims 1 to 5, characterized in that, Also includes: Receive a condition change instruction, the condition change instruction including a scheduling object identifier and an update baseline interval parameter; The target scheduling object is located based on the scheduling object identifier; Update the baseline time interval of the target scheduling object according to the updated baseline interval parameter; The trigger multiple for each scheduled task under the target scheduling object is recalculated based on the updated baseline time interval; The recalculated trigger multiplier is synchronized to the task list corresponding to the target scheduling object.

7. A timed task scheduling device, characterized in that, For a timed task scheduling system, the timed task scheduling system includes at least one sensor, each sensor corresponding to a different preset execution period, the timed task scheduling device includes: The scheduling determination module is used to determine at least one scheduling object and a reference time interval corresponding to each scheduling object according to the preset execution cycle, wherein each scheduling object is associated with a timer. The task acquisition module is used to acquire the scheduled tasks corresponding to each of the sensors, and one scheduling object corresponds to at least two scheduled tasks. The parameter determination module is used to determine the trigger multiple for each scheduled task based on the preset execution cycle of the task to be scheduled and the base time interval corresponding to the scheduling object. A signal triggering module is used to control the timer to periodically generate a trigger signal according to the reference time interval; The value update module is used to update the cumulative trigger value of all tasks to be scheduled corresponding to the scheduling object in response to the trigger signal; The timing judgment module is used to determine whether the updated cumulative trigger value is greater than or equal to the trigger multiple corresponding to the task to be scheduled for each task to be scheduled, and to determine the judgment result. The task scheduling module is used to execute the corresponding scheduled task when the judgment result is yes, and to reset the trigger accumulation value corresponding to the scheduled task after execution.

8. A timed task scheduling system, characterized in that, The timed task scheduling system includes at least one sensor, and each sensor corresponds to a different preset execution cycle.

9. A vehicle, characterized in that, The vehicle is equipped with the timed task scheduling system as described in claim 8.

10. A chip, characterized in that, The chip includes a processor and a communication interface, the communication interface being coupled to the processor, the processor being used to run programs or instructions to implement the steps of the timed task scheduling method as described in any one of claims 1 to 6.

Images