A deterministic scheduling system and method for intelligent driving domain

Abstract

This invention discloses a deterministic scheduling system and method for the intelligent driving domain. The system includes: multiple schedulers deployed on each on-chip system; at least one scheduler parses a static scheduling configuration file to obtain a hypercycle scheduler table and sends it to the other schedulers. Each scheduler, based on this scheduler table, controls the start, stop, switching, and hyperframe synchronization of the task scheduler within its respective on-chip system. The task scheduler, deployed within each on-chip system, communicates with its assigned scheduler and schedules tasks within its on-chip system in a static, non-preemptive manner according to the hypercycle scheduler table. The scheduling management client provides a hypercycle scheduler table switching API to the application layer via a dynamic library interface and communicates with the schedulers and microcontrollers within each on-chip system to complete the secure switching process of the hypercycle scheduler table. This invention significantly improves the security and reliability of the system.

Description

Technical Field

[0001] This invention belongs to the field of intelligent driving technology, and more specifically, relates to a deterministic scheduling system and method for the intelligent driving domain. Background Technology

[0002] With the rapid development of intelligent driving technology, the automotive electronic and electrical architecture is evolving from distributed to centralized. Domain controllers and central computing platforms based on heterogeneous multi-core architectures have become the industry mainstream. To fully utilize chip computing power, developers have densely deployed perception, decision-making, planning, and control algorithms on domain controllers. To improve task parallelism, algorithm modules typically create a large number of asynchronous tasks and manage them through the operating system kernel scheduler.

[0003] However, existing operating systems (such as Linux and QNX) primarily use thread- or process-level scheduling mechanisms, are unaware of the logical dependencies between tasks, and typically employ a preemptive time-slice round-robin strategy. When a system faces a large number of real-time tasks with complex dependencies, the following technical problems arise: (1) Execution time is difficult to predict: The kernel scheduler only focuses on thread priority and time slice, and cannot understand the data and control dependencies between tasks. In the case of intense resource competition (such as locks, shared memory, I / O), the actual execution time of tasks fluctuates randomly, making it difficult to determine the completion time of the critical task chain, which affects the stability of the system.

[0004] (2) Insufficient real-time performance: Intelligent driving task chains (such as camera / radar perception → fusion → decision-making → planning → control) have strict requirements on end-to-end latency. Traditional scheduling algorithms are limited in response speed when faced with a large number of sudden tasks and complex dependencies, which may lead to delays in the output of control commands, causing the vehicle to miss the opportunity to avoid danger, and failing to meet the real-time performance requirements of functional safety.

[0005] (3) Lack of global optimization: Traditional scheduling algorithms usually focus on the local optimum of a single processor core or local ready queue, ignoring the overall resource utilization and task chain coordination of the system. For example, over-allocating CPU resources to quickly complete camera image recognition tasks may delay radar data processing tasks, thereby affecting the timeliness of path planning, wasting computing resources and affecting driving safety and efficiency.

[0006] Therefore, there is an urgent need for a scheduling system and method that can provide deterministic execution, global task orchestration, and hybrid triggering mechanisms (time-triggered, data-triggered, and event-triggered) for intelligent driving domain controllers to overcome the shortcomings of the existing technologies. Summary of the Invention

[0007] The purpose of this invention is to propose a deterministic scheduling system and method for the intelligent driving domain, which solves the problems of unpredictable task execution time, insufficient real-time performance, and lack of global optimization caused by complex task dependencies, resource contention, and traditional preemptive scheduling in existing intelligent driving domain controllers; and achieves determinism in task execution, controllability of end-to-end latency of critical task chains, and global optimization of system resources in the intelligent driving domain, thereby improving the real-time performance, safety, and reliability of the intelligent driving system.

[0008] To achieve the above objectives, in a first aspect, the present invention proposes a deterministic scheduling system for the intelligent driving domain, deployed in a domain controller comprising multiple system-on-chips and microcontrollers, the system comprising: Multiple scheduling managers are deployed on each of the aforementioned on-chip systems; At least one scheduler is configured to parse a static scheduler configuration file to obtain a supercycle scheduler table and send the supercycle scheduler table to other schedulers; Each of the aforementioned schedulers is used to control the start, stop, switching, and superframe synchronization of the task scheduler within its respective on-chip system based on the supercycle scheduling table; The task scheduler is deployed in each of the on-chip systems and communicates with the scheduling manager in its respective on-chip system. It is used to schedule tasks in its respective on-chip system in a static, non-preemptive manner according to the supercycle scheduling table. The scheduling management client provides an API for switching time-over-time schedule tables to the application layer in the form of a dynamic library interface, and communicates with the scheduling manager and microcontroller unit in each of the on-chip systems to handle the safe switching process of time-over-time schedule tables.

[0009] Optionally, the scheduling manager includes: The scheduling execution control module is used to control the start, stop, scheduling configuration distribution, switching, and exit of the task scheduler within the on-chip system based on the super-cycle scheduling table. The task dispatcher is communicatively connected to the scheduling execution control module and is used to manage task descriptions and the super-periodic scheduling table, and to distribute the scheduling information corresponding to the super-periodic scheduling table to the task scheduler. The task description verification module is communicatively connected to the task dispatcher and is used to verify the consistency between the task description dynamically registered by the user and the task definition in the super-cycle scheduling table. The superframe synchronization module is used to synchronize the super-cycle execution of each scheduling manager according to the super-cycle definition in the super-cycle scheduling table; The configuration management module is used to parse the internal configuration of the scheduling system and the static scheduling configuration file. The first tracking and statistics module is used to collect task execution information from the microcontroller unit.

[0010] Optionally, the task scheduler includes: A scheduling synchronizer, which is communicatively connected to the task distributor, is used to receive the scheduling information and create or control scheduler instances; A time scheduler is used to schedule time-triggered tasks to execute at specified times or time intervals. The data scheduler is used to schedule data-triggered tasks and trigger execution based on the execution status of dependent tasks. The event scheduler is used to schedule event-triggered tasks to be executed based on system or user events. The time scheduler and / or the data scheduler are communicatively connected to the superframe synchronization module of the scheduling manager within the system-on-a-chip, and are used to receive super-cycle synchronization signals.

[0011] Optionally, the super-cycle scheduling table includes multiple scheduling tables corresponding to different driving scenarios.

[0012] Optionally, the task scheduler further includes: The task status synchronization module is used to synchronize the execution status of tasks across processes within the domain. The anomaly detection module is used to detect whether the scheduled task has activation anomalies, deadline anomalies, or program flow anomalies. The worker thread execution unit is used to receive the instruction sequence generated by the task scheduler and execute specific tasks. The second tracking and statistics module is deployed on the on-chip system side and is used to collect task execution information within the current application process.

[0013] Secondly, the present invention proposes a deterministic scheduling method for the intelligent driving domain, applied to the deterministic scheduling system for the intelligent driving domain as described in the first aspect, comprising the following steps: At least one scheduler parses the static schedule configuration file to obtain the supercycle schedule table; The at least one scheduling manager sends the super-cycle scheduling table to other scheduling managers; Each scheduling manager controls the start, stop, and superframe synchronization of the task scheduler within its respective on-chip system according to the supercycle scheduling table; The task scheduler schedules tasks within its on-chip system in a static, non-preemptive manner according to the supercycle scheduling table. For time-triggered tasks, the time scheduler makes them execute at a specified time point or time interval; For data-triggered tasks, execution is triggered by the data scheduler based on the execution status of dependent tasks; For event-triggered tasks, execution is triggered by the event scheduler based on system or user events.

[0014] Optionally, a task description verification step may also be included: The scheduler verifies the consistency between the task description dynamically registered by the user and the task definition in the super-periodic schedule table. If they are inconsistent, it issues a warning or prevents the scheduler from executing.

[0015] Optionally, it also includes an anomaly detection step: The task scheduler detects whether the scheduled task has activation anomalies, deadline anomalies, or program flow anomalies, and performs preset fault tolerance or security degradation operations when anomalies are detected.

[0016] Optionally, it also includes tracking and statistical steps: Task execution information is collected on the microcontroller side and / or the system-on-chip side, respectively, for offline or real-time analysis of the deterministic execution of the task.

[0017] Optionally, after completing a supercycle scheduling, the task scheduler automatically repeats the same supercycle scheduling table, or switches to another supercycle scheduling table according to the instructions of the scheduling manager.

[0018] The beneficial effects of this invention are as follows: This application utilizes schedulers deployed across multiple on-chip systems and microcontrollers, enabling at least one scheduler to parse static scheduling configuration files to obtain a hypercycle scheduling table and synchronize it with other schedulers, thus achieving distributed collaboration of a unified time base and scheduling strategy across on-chip systems. By having each scheduler control the start, stop, switching, and hyperframe synchronization of the task scheduler within its respective on-chip system based on the hypercycle scheduling table, it ensures that the task execution rhythm under multi-core heterogeneous computing resources strictly conforms to the preset time window, avoiding time conflicts and resource contention between tasks. Furthermore, by having the task scheduler schedule tasks within its respective on-chip system in a static, non-preemptive manner according to the hypercycle scheduling table, it eliminates the overhead and uncertainty of runtime scheduling decisions, ensuring a high degree of predictability and determinism in task execution time, and meeting the real-time and safety requirements of intelligent driving systems. The invention addresses stringent requirements for performance; by providing a hypercycle scheduling table switching API to the application layer through a dynamic library interface via a scheduling management client, and collaborating with various scheduling managers and microcontrollers to handle the safe switching process of the hypercycle scheduling table, it achieves seamless updates and fault isolation of the runtime scheduling table, enhancing the system's dynamic reconfiguration capabilities and fault tolerance robustness. In summary, without changing the hardware architecture, this invention achieves deterministic scheduling, cross-domain synchronization, and online safe switching of multi-chip cascaded tasks in intelligent driving domain controllers solely through software-layer distributed scheduling collaboration and hypercycle static scheduling mechanisms. It is particularly suitable for L2+ level and above intelligent driving systems with high requirements for real-time performance, safety, and determinism, effectively solving problems such as inconsistent task scheduling between heterogeneous computing units, hyperframe boundary drift, and data inconsistency during dynamic updates of the scheduling table, ensuring the stable and reliable operation of the intelligent driving task chain.

[0019] The system of the present invention has other features and advantages that will be apparent from or will be set forth in detail in the accompanying drawings and following detailed description, which together serve to explain the particular principles of the invention. Attached Figure Description

[0020] The above and other objects, features and advantages of the present invention will become more apparent from the accompanying drawings, in which like reference numerals generally denote like parts.

[0021] Figure 1 A schematic diagram of a deterministic scheduling system for the intelligent driving domain according to Embodiment 1 of the present invention is shown.

[0022] Figure 2 A schematic diagram of a deterministic scheduling system for the intelligent driving domain according to Embodiment 2 of the present invention is shown. Detailed Implementation

[0023] The invention will now be described in more detail with reference to the accompanying drawings. While preferred embodiments of the invention are shown in the drawings, it should be understood that the invention can be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that the invention will be thorough and complete, and will fully convey the scope of the invention to those skilled in the art.

[0024] Example 1

[0025] like Figure 1 As shown, this embodiment provides a deterministic scheduling system for the intelligent driving domain, deployed in a domain controller comprising multiple system-on-chips and microcontrollers. The system includes: Multiple scheduling managers are deployed on each on-chip system; At least one scheduler is configured to parse a static scheduler configuration file to obtain a supercycle scheduler table and send the supercycle scheduler table to other schedulers. Each scheduler manager is used to control the start, stop, switching, and superframe synchronization of the task scheduler within its respective on-chip system based on the supercycle scheduling table; The task scheduler is deployed in each on-chip system and communicates with the scheduler manager in its respective on-chip system. It is used to schedule tasks in its respective on-chip system in a static, non-preemptive manner according to the overcycle scheduling table. The scheduling management client provides the overcycle scheduler switching API to the application layer in the form of a dynamic library interface, and communicates with the scheduling manager and microcontroller unit in each on-chip system to handle the safe switching process of the overcycle scheduler.

[0026] Specifically, in this deterministic scheduling system, multiple schedulers are deployed on various System-on-Chip (SoCs). At least one scheduler (which can be the master scheduler or any instance with parsing capabilities) is configured to parse static scheduling configuration files, obtain a hypercycle scheduler table, and send this hypercycle scheduler table to other schedulers in the system. Each scheduler (including the receiver) centrally controls the startup, shutdown, switching, and hyperframe synchronization of task schedulers within its respective SoC based on this globally unified hypercycle scheduler table. Task schedulers are deployed within each SoC and communicate with schedulers within the same SoC; they schedule various tasks running on their respective SoCs in a static, non-preemptive manner according to the hypercycle scheduler table issued by the scheduler. Furthermore, the scheduling management client, as a functional component exposed by the deterministic scheduling framework, is encapsulated in the form of a dynamic link library (such as .so or .dll) interface and provides a hypercycle scheduler table switching API (Application Programming Interface) for direct invocation by the application layer (such as autonomous driving business modules and scene decision modules). When the driving scenario changes (e.g., switching from automatic parking to highway navigation), the application layer can initiate a scheduler switch request via this API. Upon receiving the request, the client does not immediately execute the switch. Instead, it first communicates with the scheduler managers within each System-on-Chip (SoC) to notify them to prepare to load the new hypercycle scheduler. Simultaneously, it communicates with the Microcontroller Unit (MCU) to coordinate the synchronization points and superframe alignment of tasks on the MCU side. During the switch, the client waits for all schedulers to confirm that the tasks of the current cycle have been safely completed and that the starting superframe boundary of the new scheduler is aligned before sending a unified switch confirmation command. This ensures no time overlap or task omission between the old and new schedulers. This multi-terminal collaborative and secure switch process avoids data inconsistencies or timing conflicts caused by forcibly replacing the scheduler midway through critical task execution, thus guaranteeing the reliability and determinism of the intelligent driving system's dynamic task orchestration adjustments during runtime.

[0027] In this embodiment, the scheduling manager includes: The scheduling execution control module is used to control the start, stop, scheduling configuration distribution, switching, and exit of the task scheduler within the on-chip system based on the supercycle scheduling table. The task dispatcher communicates with the scheduling execution control module to manage task descriptions and over-cycle scheduling tables, and distributes the scheduling information corresponding to the over-cycle scheduling tables to the task scheduler. The task description verification module communicates with the task dispatcher and is used to verify the consistency between the task description dynamically registered by the user and the task definition in the super-cycle scheduling table. The superframe synchronization module is used to synchronize the supercycle execution of each scheduler according to the supercycle definition in the supercycle scheduling table; The configuration management module is used to parse the internal configuration and static scheduling configuration files of the scheduling system. The first tracking and statistics module is used to collect task execution information from the microcontroller unit.

[0028] Specifically, the scheduler integrates multiple collaborative functional modules. The scheduling execution control module is the brain of the entire scheduler. Based on the pre-loaded hypercycle scheduling table, it manages the entire lifecycle of the task scheduler within its system-on-chip, including controlling the start, stop, dynamic distribution of scheduling configurations, execution scheduling table switching, and exit of the task scheduler. The task dispatcher, which communicates with the scheduling execution control module, is responsible for the unified management of global task description information and the hypercycle scheduling table itself. It accurately distributes the specific scheduling information corresponding to the hypercycle scheduling table (such as the activation time, execution duration, and dependencies of each task) to the underlying task scheduler, ensuring that scheduling instructions are transmitted correctly layer by layer. The task description verification module also communicates with the task dispatcher. Its function is to perform consistency checks on the dynamically registered task descriptions during the development phase or system initialization, verifying whether these descriptions match the predefined task definitions in the hypercycle scheduling table, thereby detecting runtime anomalies that may be caused by configuration errors in advance. The superframe synchronization module performs hyperperiod-level synchronization among multiple schedulers based on the hyperperiod parameters set in the hyperperiod scheduling table, ensuring that all on-chip systems can advance their scheduling windows using the same global time base. The configuration management module parses the internal configuration parameters of the deterministic scheduling framework itself, as well as externally input static scheduling configuration files, providing necessary configuration data for other modules. The first tracking and statistics module specifically collects task execution information from the microcontroller unit (MCU), such as the actual start time, end time, and whether the deadline was met. This data can be used for offline analysis of the system's deterministic execution status, as well as for real-time monitoring and health management.

[0029] In this embodiment, the task scheduler includes: The scheduling synchronizer communicates with the task dispatcher and is used to receive scheduling information and create or control scheduler instances. A time scheduler is used to schedule time-triggered tasks to execute at specified times or time intervals. The data scheduler is used to schedule data-triggered tasks and trigger execution based on the execution status of dependent tasks. The event scheduler is used to schedule event-triggered tasks to be executed based on system or user events. The time scheduler and / or data scheduler are connected to the superframe synchronization module of the scheduling manager within the system-on-chip to receive super-cycle synchronization signals.

[0030] Specifically, the task scheduler, as the core execution component of the deterministic scheduling framework, takes over the execution of specific tasks downwards and responds to instructions from the scheduler manager upwards. The scheduler synchronizer maintains a communication connection with the task dispatcher in the scheduler manager, receiving scheduling information from the task dispatcher (including the time attributes, execution order, and resource constraints of each task in the hypercycle scheduler table), and creates or controls the corresponding type of scheduler instance within its own process based on this information, thereby effectively decoupling the scheduling logic from the application tasks. The time scheduler is specifically responsible for scheduling time-triggered tasks. It precisely activates tasks according to predefined time points or time intervals in the hypercycle scheduler table, meeting the extremely stringent time deterministic requirements of scenarios such as periodic sensor acquisition and control law calculation in intelligent driving. The data scheduler is responsible for scheduling data-triggered tasks. It does not rely on fixed times but triggers execution based on the execution status of dependent tasks and the readiness of output data—for example, when a perception task completes and generates data, the data scheduler immediately initiates a fusion or decision task, thus forming an efficient data-driven pipeline. The event scheduler handles event-triggered tasks, dynamically initiating corresponding processing flows based on internal system state changes or external user events (such as mode switching or emergency braking signals) to ensure rapid response to unexpected situations. Furthermore, the time scheduler and / or data scheduler directly communicate with the superframe synchronization module in the on-chip system's scheduling manager to receive supercycle synchronization signals. This connection ensures strict alignment of time-triggered and data-triggered tasks at global supercycle boundaries, avoiding scheduling misalignments caused by cross-chip clock drift, thereby enhancing the synchronization and determinism of task execution in multi-SoC environments. Through this division of labor and collaboration, the task scheduler simultaneously supports time, data, and event-triggered modes, fully covering the control requirements of periodic, dependent, and sudden tasks in the intelligent driving domain.

[0031] In this embodiment, the super-cycle scheduling table includes multiple scheduling tables that correspond to different driving scenarios.

[0032] Specifically, the hypercycle scheduling table is not a single, unchanging scheduling plan, but rather comprises multiple scheduling tables corresponding to different driving scenarios, such as automatic parking, urban road cruising, highway navigation, and emergency avoidance. Each scheduling table is statically orchestrated offline using an offline toolchain, based on the task set, real-time requirements, and resource constraints of the corresponding scenario. It covers the hypercycle execution sequence of all time-triggered, data-triggered, and event-triggered tasks in that scenario. When a scenario change occurs during vehicle operation (e.g., transitioning from urban roads to highways), the application layer calls the hypercycle scheduling table switching API through the scheduling management client. The scheduling manager, in coordination with various on-chip systems and microcontroller units, executes a safe switching process, smoothly replacing the currently executing scheduling table with the target scenario's scheduling table while maintaining the continuity of the hyperframe synchronization signal. This multi-scenario scheduling table design allows the deterministic scheduling framework to meet the real-time and predictability requirements of each driving scenario while flexibly adjusting resource allocation and task orchestration according to actual driving conditions. This avoids over-reserving resources for all scenarios using a single scheduling table, thereby improving the overall computing efficiency and system responsiveness of the heterogeneous multi-core platform.

[0033] In this embodiment, the task scheduler further includes: The task status synchronization module is used to synchronize the execution status of tasks across processes within the domain. The anomaly detection module is used to detect whether the scheduled task has activation anomalies, deadline anomalies, or program flow anomalies. The worker thread execution unit is used to receive the instruction sequence generated by the task scheduler and execute specific tasks. The second tracking and statistics module, deployed on the on-chip system side, is used to collect task execution information within the current application process.

[0034] Specifically, in addition to managing three types of trigger schedulers, the task scheduler integrates several auxiliary modules to enhance the system's robustness and observability. The task status synchronization module is responsible for real-time synchronization of the execution status (e.g., inactive, running, completed, timed out) of tasks managed by this task scheduler in a cross-process, cross-core distributed environment. This ensures that data schedulers in different processes can accurately know the completion status of dependent tasks, thereby triggering subsequent tasks according to conditions and avoiding scheduling misjudgments or deadlocks caused by state asynchrony. The anomaly detection module continuously monitors the runtime behavior of each scheduled task. If it detects activation anomalies (e.g., a task not being woken up within the expected time window), deadline anomalies (the actual completion time of the task is later than the deadline specified in the scheduling table), or program flow anomalies (the task execution path does not match the preset control flow), it immediately captures the anomaly and reports it to the scheduling manager or executes a preset fault-tolerance strategy. The worker thread execution unit is the underlying executor that specifically undertakes task computation. It receives the instruction sequence (e.g., function pointers, parameters, execution context) generated by the task scheduler after parsing the scheduling table, and executes these specific tasks concurrently or serially, while ensuring sequential execution under non-preemptive semantics. The second tracing and statistics module is deployed on the on-chip system side to collect task execution information within the current application process, including the actual start time, end time, execution time, whether the deadline is met, number of triggers, and exception count for each task. This statistical data can be fed back to the scheduler manager in real time for dynamic adjustment or diagnosis, or imported offline into analysis tools for quantitative evaluation and performance optimization of the system's deterministic execution. Together with the first tracing and statistics module deployed on the microcontroller side, it constitutes a complete deterministic observation system.

[0035] Example 2

[0036] like Figure 2As shown, the deterministic scheduling system for the intelligent driving domain in this embodiment is deployed in a domain controller containing two System-on-Chip (Soc1 and Soc2) and one Microcontroller Unit (MCU). Soc1 houses a Scheduler Manager (DSF::Manager), a Task Scheduler (DSF::Scheduler), and a scheduling client. The Scheduler Manager further includes scheduling execution control, a task dispatcher (containing task descriptions, scheduling tables, and verification results), configuration management, Trace statistics (MCU), a superframe synchronizer, and Hyperperiod synchronization signal output. The Task Scheduler further includes task registration, dispatching scheduling instructions, time-triggered task schedulers, data-triggered task schedulers, event-triggered task schedulers, anomaly detection, and Trace statistics. The scheduling client provides a scheduling table switching API. Soc2 houses a Task Scheduler, a Scheduler Manager, and another Task Scheduler (multiple instances are shown for illustration). The MCU is shown separately and works in conjunction with Soc1 and Soc2.

[0037] In this embodiment, the scheduler in SoC1 acts as the global scheduling management entity. It parses the static scheduling configuration file, generates a scheduling table containing hyperperiod definitions, and sends Hyperperiod synchronization signals to the scheduler in SoC2 and the local task scheduler via a hyperframe synchronizer. The scheduler in SoC2 receives the scheduling information and synchronization signals from SoC1 and controls its two internal task schedulers to execute specific tasks. The time-triggered, data-triggered, and event-triggered schedulers in each task scheduler perform static non-preemptive scheduling for time-sensitive, data-driven, and bursty tasks according to the scheduling table, respectively. Simultaneously, they collect task execution information through the Trace statistics module and report it to the scheduler or MCU. The scheduling client allows the application layer to safely switch hyperperiod scheduling tables during runtime to adapt to different driving scenarios. This embodiment achieves deterministic scheduling across SoC and MCU, eliminating time jitter caused by asynchronous task preemption and ensuring the real-time performance and predictability of intelligent driving tasks.

[0038] Example 3

[0039] This embodiment provides a deterministic scheduling method for the intelligent driving domain, applied to the deterministic scheduling system for the intelligent driving domain in Embodiment 1, and includes the following steps: At least one scheduler parses the static schedule configuration file to obtain the supercycle schedule table; At least one scheduler sends the over-cycle schedule table to the other schedulers; Each scheduling manager controls the start, stop, and superframe synchronization of the task scheduler within its respective on-chip system according to the supercycle scheduling table; The task scheduler schedules tasks within its on-chip system in a static, non-preemptive manner based on the overcycle scheduling table. For time-triggered tasks, the time scheduler makes them execute at a specified time point or time interval; For data-triggered tasks, execution is triggered by the data scheduler based on the execution status of dependent tasks; For event-triggered tasks, execution is triggered by the event scheduler based on system or user events.

[0040] Specifically, firstly, at least one scheduler (e.g., a scheduler deployed on the main SoC) parses the static scheduling configuration file, extracting information such as time parameters, dependencies, and resource constraints for all cyclic tasks, and generates one or more hypercycle schedule tables through offline orchestration using the toolchain. Subsequently, the scheduler distributes the generated hypercycle schedule tables to schedulers within other SoCs via data distribution, ensuring a unified task orchestration view across the entire system. Upon receiving the hypercycle schedule table, each scheduler controls the start and stop of the task scheduler within its SoC based on the schedule table, while simultaneously performing hyperframe synchronization: that is, using a hyperframe synchronization module to generate a Hyperperiod synchronization signal, ensuring that the task scheduler within its SoC is strictly aligned with other SoCs and MCUs on the global hypercycle boundary. Next, the task schedulers within each SoC schedule specific tasks on their respective SoCs in a static, non-preemptive manner according to the received hypercycle schedule tables. This means that the start time and duration of each task are pre-fixed in the schedule table; once a task begins execution, it runs until it voluntarily relinquishes the CPU, preventing preemption by other tasks and eliminating random fluctuations in execution time. During the scheduling process, time-triggered tasks are handled by the time scheduler: it strictly follows the preset time points or time intervals in the scheduling table to activate tasks, ensuring that critical operations such as periodic sensor acquisition and control calculations are executed on time. Data-triggered tasks are handled by the data scheduler: it does not rely on fixed times, but continuously monitors the execution status of upstream dependent tasks. Only when the dependent task is completed and produces data is the downstream task triggered, forming an efficient data-driven pipeline. Event-triggered tasks are scheduled by the event scheduler: it dynamically responds to changes in the system's internal state or external user input (such as emergency braking signals or mode switching commands), promptly initiating corresponding processing tasks to meet the real-time requirements of intelligent driving for unexpected events. Through the above methods, the system achieves global deterministic scheduling of time, data, and event-triggered tasks on all SoCs.

[0041] In this embodiment, a task description verification step is also included: The scheduler verifies the consistency between the task description dynamically registered by the user and the task definition in the supercycle scheduler table. If there is a discrepancy, a warning is issued or the scheduler is blocked from execution.

[0042] Specifically, this method also includes a task description verification step to detect configuration errors in advance during development or system initialization. Specifically, the scheduler (usually the one responsible for parsing static scheduling configurations) obtains the dynamically registered task descriptions (e.g., task identifier, period, deadline, dependencies, resource requirements, etc.) and compares them one by one with the predefined task definitions in the over-period scheduling table. If both are completely consistent in all required attributes, the verification passes, and subsequent scheduling can proceed normally. If any inconsistencies are found, such as a mismatch between the registered task period and the period in the scheduling table, a contradiction between the task dependencies and the order defined in the scheduling table, or a task execution duration exceeding the time window reserved in the scheduling table, the scheduler will issue a warning (e.g., output logs or report errors). In severe cases, it can directly prevent the scheduling execution of the task, avoiding unpredictable behavior at runtime. Through this verification mechanism, the system can ensure that the user registration information is strictly consistent with the global static orchestration results before the task actually runs, thereby eliminating risks such as activation anomalies, missed deadlines, or resource conflicts caused by human configuration errors, further enhancing the determinism and security of intelligent driving domain scheduling.

[0043] In this embodiment, an anomaly detection step is also included: The task scheduler detects whether the scheduled task has activation anomalies, deadline anomalies, or program flow anomalies, and performs preset fault tolerance or security degradation operations when anomalies are detected.

[0044] Specifically, this method also includes an anomaly detection step to ensure the robustness of the system during task execution. The task scheduler continuously monitors the behavior of each scheduled task during runtime. The detection includes three types of anomalies: First, activation anomalies, where the task is not successfully woken up within the time window specified in the schedule—for example, due to a timeout of a preceding task or resource occupation causing a startup delay exceeding the scheduler's allowable fluctuation range. Second, deadline anomalies, where the actual completion time of the task is later than the preset deadline in the scheduler, potentially causing downstream task dependencies to fail or control output to lag. Third, program flow anomalies, where the task's execution path does not match the expected control flow obtained from static toolchain analysis, such as skipping critical checks, entering an infinite loop, or prematurely exiting. Once the task scheduler detects any of these anomalies, it does not simply abandon the task but immediately executes preset fault-tolerance or security degradation operations. These operations can include: restarting the task (if a transient error is detected), skipping the remainder of the current cycle and reporting to the dispatch manager, calling a backup task to replace the faulty task, notifying the high-reliability management module to switch to a safe operating mode (such as limiting vehicle speed or requesting driver takeover), or executing a minimum risk strategy (MRM) according to a pre-programmed emergency schedule. Through this anomaly detection step, the system can quickly identify and proactively degrade when faced with partial execution failures or time-lapses, preventing the anomaly from spreading to other chips or tasks, thereby maintaining the overall safety status of the intelligent driving domain.

[0045] In this embodiment, a tracking and statistical step is also included: Task execution information is collected on the microcontroller side and / or the system-on-chip side, respectively, for offline or real-time analysis of the deterministic execution of the task.

[0046] Specifically, this method also includes a tracking and statistics step to collect key data during the scheduling execution process to evaluate and verify the deterministic behavior of the system. Specifically, a first tracking and statistics module deployed on the microcontroller unit (MCU) side and a second tracking and statistics module deployed on each system-on-a-chip (SoC) side independently collect task execution information. The MCU side mainly collects task information related to real-time control, vehicle communication, and safety monitoring, such as the actual trigger time, completion time, whether the deadline is met, and exception flags. The SoC side collects task execution information within each application process, including the start timestamp, end timestamp, execution time, dependency state changes, activation count, and any runtime exceptions for time-triggered, data-triggered, and event-triggered tasks. The collected information can be reported in real-time to the scheduling manager or central diagnostic system via a debug interface or dedicated data channel for online monitoring of the current scheduling health status; it can also be persistently stored for in-depth analysis by offline analysis tools, such as statistically analyzing the probability distribution of jitter, identifying latency spikes, verifying the matching degree between the over-cycle scheduling table and actual execution, and discovering potential resource contention or blocking points. Through the above tracking and statistical steps, developers and system maintainers can quantitatively evaluate the performance of the deterministic scheduling framework under real load, locate the root causes of nondeterministic behavior, and optimize static scheduling table parameters or fault tolerance strategies accordingly, thereby continuously improving the predictability and reliability of the intelligent driving system.

[0047] In this embodiment, after completing a supercycle scheduling, the task scheduler automatically repeats the same supercycle scheduling table, or switches to another supercycle scheduling table according to the instructions of the scheduling manager.

[0048] Specifically, the task scheduler has two execution modes for the hypercycle scheduler. The first mode is automatic repetitive execution: after the task scheduler completes the scheduling of all tasks within a full hypercycle (i.e., the least common multiple of all tasks in all cycles) according to the current hypercycle scheduler, it automatically returns to the starting point of the scheduler without external intervention and executes the next hypercycle again according to the same task time sequence, and so on. This cyclical mode is suitable for normal driving scenarios (such as city cruising or highway driving), ensuring that the system runs continuously with a fixed global time base and avoiding additional overhead caused by repeatedly loading the scheduler. The second mode is switching execution: when the vehicle driving scenario changes (e.g., switching from automatic parking to highway navigation), the scheduling manager sends a switching command to the task scheduler based on the scenario decision, instructing it to stop the currently executing hypercycle scheduler and load another pre-distributed and locally stored hypercycle scheduler corresponding to the new scenario. During the switching process, the scheduling manager, in conjunction with the superframe synchronization module, ensures that the switching boundary is aligned with the hypercycle starting point, ensuring the continuity and determinism of task execution. By combining these two modes, the task scheduler can not only re-execute the same scheduling plan stably in a single scenario for a long time, but also flexibly switch to a more suitable scheduling table according to real-time operating conditions, thus ensuring determinism while taking into account the dynamic adaptability of the system.

[0049] The various embodiments of the present invention have been described above. These descriptions are exemplary and not exhaustive, nor are they limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments.

Claims

1. A deterministic scheduling system for intelligent driving domains, characterized in that, Deployed in a domain controller comprising multiple system-on-a-chip and microcontroller units, the system includes: Multiple scheduling managers are deployed on each of the aforementioned on-chip systems; At least one scheduler is configured to parse a static scheduler configuration file to obtain a supercycle scheduler table and send the supercycle scheduler table to other schedulers; Each of the aforementioned schedulers is used to control the start, stop, switching, and superframe synchronization of the task scheduler within its respective on-chip system based on the supercycle scheduling table; The task scheduler is deployed in each of the on-chip systems and communicates with the scheduling manager in its respective on-chip system. It is used to schedule tasks in its respective on-chip system in a static, non-preemptive manner according to the supercycle scheduling table. The scheduling management client provides an API for switching time-over-time schedule tables to the application layer in the form of a dynamic library interface, and communicates with the scheduling manager and microcontroller unit in each of the on-chip systems to handle the safe switching process of time-over-time schedule tables.

2. The smart domain oriented deterministic scheduling system according to claim 1, wherein, The scheduling manager includes: The scheduling execution control module is used to control the start, stop, scheduling configuration distribution, switching, and exit of the task scheduler within the on-chip system based on the super-cycle scheduling table. The task dispatcher is communicatively connected to the scheduling execution control module and is used to manage task descriptions and the super-periodic scheduling table, and to distribute the scheduling information corresponding to the super-periodic scheduling table to the task scheduler. The task description verification module is communicatively connected to the task dispatcher and is used to verify the consistency between the task description dynamically registered by the user and the task definition in the super-cycle scheduling table. The superframe synchronization module is used to synchronize the super-cycle execution of each scheduling manager according to the super-cycle definition in the super-cycle scheduling table; The configuration management module is used to parse the internal configuration of the scheduling system and the static scheduling configuration file. The first tracking and statistics module is used to collect task execution information from the microcontroller unit.

3. The smart domain oriented deterministic scheduling system according to claim 2, wherein, The task scheduler includes: A scheduling synchronizer, which is communicatively connected to the task distributor, is used to receive the scheduling information and create or control scheduler instances; A time scheduler is used to schedule time-triggered tasks to execute at specified times or time intervals. The data scheduler is used to schedule data-triggered tasks and trigger execution based on the execution status of dependent tasks. The event scheduler is used to schedule event-triggered tasks to be executed based on system or user events. The time scheduler and / or the data scheduler are communicatively connected to the superframe synchronization module of the scheduling manager within the system-on-a-chip, and are used to receive super-cycle synchronization signals.

4. The deterministic scheduling system for the intelligent driving domain according to claim 1, characterized in that, The super-cycle scheduling table includes multiple scheduling tables corresponding to different driving scenarios.

5. The deterministic scheduling system for the intelligent driving domain according to claim 1, characterized in that, The task scheduler also includes: The task status synchronization module is used to synchronize the execution status of tasks across processes within the domain. The anomaly detection module is used to detect whether the scheduled task has activation anomalies, deadline anomalies, or program flow anomalies. The worker thread execution unit is used to receive the instruction sequence generated by the task scheduler and execute specific tasks. The second tracking and statistics module is deployed on the on-chip system side and is used to collect task execution information within the current application process.

6. A deterministic scheduling method for the intelligent driving domain, applied to the deterministic scheduling system for the intelligent driving domain as described in any one of claims 1 to 5, characterized in that, Includes the following steps: At least one scheduler parses the static schedule configuration file to obtain the supercycle schedule table; The at least one scheduling manager sends the super-cycle scheduling table to other scheduling managers; Each scheduling manager controls the start, stop, and superframe synchronization of the task scheduler within its respective on-chip system according to the supercycle scheduling table; The task scheduler schedules tasks within its on-chip system in a static, non-preemptive manner according to the supercycle scheduling table. For time-triggered tasks, the time scheduler makes them execute at a specified time point or time interval; For data-triggered tasks, execution is triggered by the data scheduler based on the execution status of dependent tasks; For event-triggered tasks, execution is triggered by the event scheduler based on system or user events.

7. The deterministic scheduling method for intelligent driving domain according to claim 6, characterized in that, It also includes task description verification steps: The scheduler verifies the consistency between the task description dynamically registered by the user and the task definition in the super-periodic schedule table. If they are inconsistent, it issues a warning or prevents the scheduler from executing.

8. The deterministic scheduling method for intelligent driving domain according to claim 6, characterized in that, It also includes anomaly detection steps: The task scheduler detects whether the scheduled task has activation anomalies, deadline anomalies, or program flow anomalies, and performs preset fault tolerance or security degradation operations when anomalies are detected.

9. The deterministic scheduling method for intelligent driving domain according to claim 6, characterized in that, It also includes tracking and statistical steps: Task execution information is collected on the microcontroller side and / or the system-on-chip side, respectively, for offline or real-time analysis of the deterministic execution of the task.

10. The deterministic scheduling method for intelligent driving domain according to claim 6, characterized in that, After completing a supercycle scheduling, the task scheduler automatically repeats the same supercycle scheduling table, or switches to another supercycle scheduling table according to the instructions of the scheduling manager.

Images