Intelligent driving deterministic execution system

Abstract

This invention provides a deterministic execution system for intelligent driving, relating to the field of deterministic execution technology. The system establishes a resource mapping relationship between the master ECU's deterministic execution platform and the AUTOSAR adaptive platform; it associates task chain configuration data corresponding to the target service mode according to service mode switching instructions and issues resource initialization instructions to each slave ECU; after all slave ECUs are initialized and ready, it generates a vehicle-level global T0 time, and based on the global T0 time and task chain configuration data, generates a timing orchestration scheme and a distributed resource allocation scheme, which are then distributed to each slave ECU; the deterministic execution platform of each slave ECU initializes all required resources according to the resource mapping relationship and reports the initialization ready status back to the master ECU; it executes associated tasks according to the vehicle-level global T0 time, the timing orchestration scheme, and the distributed resource allocation scheme, and generates vehicle control execution results. The beneficial effect is that it effectively solves the deterministic execution problem existing in the prior art in intelligent driving scenarios.

Description

Technical Field

[0001] This invention relates to the field of deterministic execution technology in intelligent driving operating systems, and more particularly to a deterministic execution system for intelligent driving. Background Technology

[0002] As the automotive industry rapidly transforms towards intelligence and connectivity, the requirements for real-time performance, determinism, and reliability of intelligent driving systems are becoming increasingly stringent. In intelligent driving scenarios, core functions such as Automatic Emergency Braking (AEB) and Adaptive Cruise Control (ACC) need to complete sensor data acquisition, fusion, decision-making, and control command issuance within milliseconds, and must be executed collaboratively across multiple Electronic Control Units (ECUs). This places extremely high demands on the accuracy of task scheduling and the determinism of communication transmission.

[0003] The underlying technologies of current intelligent driving systems are mainly based on the AUTOSAR adaptive platform (AP), Linux real-time scheduling algorithms, traditional communication components and middleware, etc. However, existing technologies have many shortcomings in deterministic execution and are difficult to meet the stringent requirements of intelligent driving scenarios, as follows: 1. Process and Function Group Management Limitations of the AUTOSAR Adaptive Platform (AP) As the mainstream underlying architecture of intelligent driving systems, the AUTOSAR adaptive platform adopts a process-level scheduling model, using function groups as the basic management unit to organize system functions into multiple process clusters, achieving coordination through inter-process communication and service calls. However, its scheduling mechanism has significant shortcomings: on the one hand, the control granularity is too coarse. The AP standard does not define a task-level scheduling strategy, relying only on algorithms such as the operating system's default Completely Fair Scheduler (CFS), which cannot achieve precise control over the task execution process. In scenarios where multiple tasks are vying for resources, this can easily lead to low CPU utilization and unbalanced load. On the other hand, it lacks an effective time constraint mechanism. AP processes cannot be configured with startup jitter limits and execution time limits. Tasks may experience significant time jitter due to non-deterministic factors such as system calls and memory allocation, making it difficult to meet the strict requirements of time-sensitive tasks for startup time and maximum jitter.

[0004] 2. Inherent defects of Linux real-time scheduling algorithms The real-time scheduling algorithms provided by the Linux kernel, such as FIFO (First In First Out), RR (Round-Robin), and RMS (Rate Monotonic Scheduling), offer a certain degree of determinism in a single-core environment. However, they face numerous challenges in the multi-core architecture commonly used in intelligent driving systems: First, the priority preemption mechanism has limitations. High-priority tasks can preempt low-priority tasks without restriction, easily leading to starvation of low-priority tasks. Frequent preemption also reduces cache hit rate and increases context switching overhead. Second, resource conflicts cause high jitter. In a multi-core environment, contention for shared cache and memory bus by tasks significantly increases memory access latency, resulting in fluctuations in task execution time, especially in high-concurrency scenarios. Third, there is a lack of cross-ECU collaboration capabilities. Linux scheduling is limited to a single-machine scope and cannot coordinate task chains across controllers such as SOCs and MCUs. However, many applications in intelligent driving require multi-ECU collaboration, resulting in a lack of global orchestration capabilities.

[0005] 3. The shortcomings of static scheduling in the classic AUTOSAR platform (CP) The classic AUTOSAR platform uses a static scheduling table mechanism, with fixed task execution times. While this can ensure the timing stability of tasks within a single ECU, the rigid scheduling table design cannot adapt to dynamic events in intelligent driving scenarios (such as sudden obstacles or sensor failures). At the same time, the scheduling table is strongly bound to the ECU hardware, and adding or modifying tasks requires redesigning and deploying the scheduling table, resulting in poor scalability and difficulty in supporting rapid iterative upgrades of intelligent driving functions.

[0006] 4. Insufficient COM components in AUTOSAR AP / CP While the communication management components provided by the AUTOSAR platform (ara::com for AP and COM for CP) can meet basic communication needs, they lack deterministic guarantee mechanisms: First, there is no priority guarantee. When communication traffic is high, critical data and ordinary data compete for resources out of order, which can easily lead to delays in the transmission of critical commands and affect system response. Second, service discovery and binding are uncertain. The dynamic service discovery process of the AP platform depends on the network status, and the delay is unpredictable. It cannot guarantee the timeliness of event transmission and is difficult to meet the collaborative needs of cross-ECU task chains.

[0007] 5. Timing limitations of mainstream middleware such as ROS2 ROS2, a commonly used communication middleware in the field of intelligent driving, is based on DDS (Data Distribution Service) for communication. Although it supports Quality of Service (QoS) configuration, it lacks traffic shaping and priority control mechanisms in the default mode, resulting in large fluctuations in message transmission latency under high load scenarios. At the same time, it lacks an event-level timeout monitoring mechanism, making it impossible to detect event loss or delay in a timely manner, and making it difficult to guarantee the reliability and determinism of communication.

[0008] 6. Lack of synergy in TSN technology Time-Sensitive Networking (TSN) technology provides a deterministic foundation for Ethernet communication through mechanisms such as time synchronization and traffic scheduling. However, in existing applications, TSN technology is not deeply integrated with the upper-layer task scheduling mechanism. It can only guarantee the deterministic transmission of a single communication link and cannot achieve end-to-end coordination between task scheduling and communication transmission, making it difficult to support the full-link deterministic execution of cross-ECU task chains.

[0009] In summary, current scheduling and communication technologies in the field of intelligent driving suffer from four major common defects: First, the scheduling granularity is mismatched. Neither the process-level scheduling of the AP nor the thread-level scheduling of Linux can meet the fine-grained deterministic requirements of intelligent driving scenarios. Second, resource contention is unavoidable. Existing scheduling algorithms fail to achieve coordinated management from both spatial (CPU core allocation) and temporal (execution timing orchestration) dimensions, leading to frequent resource conflicts in multi-core environments. Third, communication determinism is insufficient. Mainstream communication components and middleware cannot simultaneously guarantee message priority, traffic shaping, and cross-ECU collaboration, making it difficult to guarantee the timeliness and reliability of critical data transmission. Fourth, dynamic adaptability is poor. Static scheduling schemes and fixed communication configurations are unable to cope with dynamic load changes and sudden failures in intelligent driving scenarios, resulting in insufficient system robustness.

[0010] Therefore, there is an urgent need for a deterministic execution system that can achieve fine-grained scheduling, cross-ECU collaboration, and deep integration of communication and scheduling, in order to overcome the shortcomings of existing technologies and meet the stringent requirements of intelligent driving systems for real-time performance, determinism, and reliability. Summary of the Invention

[0011] To address the problems existing in the prior art, the present invention provides an intelligent driving deterministic execution system, which is distributed and deployed in multiple ECUs of an intelligent driving vehicle. The system includes an AUTOSAR adaptive platform and a deterministic execution platform running in each of the ECUs. Each of the ECUs is configured to include a master ECU and several slave ECUs. The deterministic execution platform of the main control ECU includes: The configuration management main module is used to establish the resource mapping relationship between the deterministic execution platform and the AUTOSAR adaptive platform based on the predefined vehicle-level global configuration file and the model files of the AUTOSAR adaptive platform uploaded from each ECU locally. The main module is initialized to associate the task chain configuration data corresponding to the target service mode according to the external service mode switching command, issue resource initialization commands to each slave ECU, and collect the initialization readiness status of each slave ECU. The scheduling and orchestration main module is used to generate a vehicle-level global T0 time after all the slave ECUs are initialized and ready, and to generate a timing orchestration scheme and a distributed resource allocation scheme based on the global T0 time and the task chain configuration data, and distribute them to each slave ECU. The deterministic execution platform from each of the ECUs includes: The configuration management module is used to collect and upload the model files locally, and to receive and store the resource mapping relationships; The initialization slave module is used to receive the resource initialization command, initialize all required resources according to the resource mapping relationship, and at the same time feed back the local initialization ready status to the master control ECU. The scheduling and orchestration module is used to receive the vehicle-level global T0 time, the timing orchestration scheme, and the distributed resource allocation scheme. The task execution module includes execution units that correspond one-to-one with the local tasks in the task chain configuration data. Each execution unit executes its associated task according to the timing arrangement scheme and the distributed resource allocation scheme and generates vehicle control execution results.

[0012] Preferably, the task chain configuration data includes time-driven task chains and event-driven task chains; The scheduling and orchestration main module includes: The T0 time generation unit is used to generate the vehicle-level global T0 time based on the vehicle-level time reference after all the slave ECUs are initialized and ready. The timing orchestration unit, connected to the T0 time generation unit, is used to calculate the fixed offset execution time of each task in the time-driven task chain based on the vehicle-level global T0 time and configure the association rules between tasks; and to configure the event triggering conditions and cross-ECU event propagation timing for the event-driven task chain to form the timing orchestration scheme. The resource allocation unit is used to acquire the hardware resource data of each slave ECU, and allocate a dedicated CPU core to each slave ECU task according to the hardware resource data, the priority of the task chain in the task chain configuration data and the computing requirements. Then, according to the communication requirements between tasks in the task chain, it allocates a TSN communication time window to the corresponding communication link to form the distributed resource allocation scheme.

[0013] Preferably, the scheduling and orchestration main module further includes a dynamic adjustment unit, which is connected to the timing orchestration unit and the resource allocation unit respectively. It is used to acquire the operating status data of each slave ECU, and generate an adjustment instruction when it is determined that there is an operating deterministic anomaly based on the operating status data, so that the timing orchestration unit can dynamically update the timing orchestration scheme according to the adjustment instruction, and the resource allocation unit can dynamically update the distributed resource allocation scheme according to the adjustment instruction.

[0014] Preferably, the operational deterministic anomalies include abnormal vehicle load fluctuations, and / or abnormal ECU resource usage, and / or abnormal ECU task timing deviations.

[0015] Preferably, the execution unit encapsulates an event slot, a trigger, and an executor; The event slot is configured with matching rules corresponding to the timing arrangement scheme. When a task trigger signal is received, and the matching rules are verified to be consistent with the task trigger signal, a task start command is generated. The executor is used to carry the business logic code of the task, and after receiving the task start instruction, it executes the task under the timing constraints in the timing orchestration scheme. The trigger includes a pre-trigger and a post-trigger, which are used to send events to the execution unit of the associated ECU before the actuator performs a task and after the execution of the task, respectively, to drive the execution of upstream and downstream tasks in the task chain.

[0016] Preferably, the intermediate task data generated by the upstream execution unit is encapsulated in the event thrown by the trigger, and the intermediate task data is bound to the corresponding event priority. The event priority is mapped to the IP DSCP field and transmitted to the downstream execution unit via TSN. The transmission gap of intermediate data in the task is constrained by the TSN communication time window in the distributed resource allocation scheme, and the data transmission completion time is earlier than the task start time of the downstream execution unit.

[0017] Preferably, the execution unit further encapsulates a resource management subunit, used to limit the resource usage data during the task execution process according to the distributed resource allocation scheme. The resource usage data includes priority, scheduling strategy, core affinity, and execution timeout.

[0018] Preferably, the deterministic execution platform of the main control ECU further includes a full-link monitoring main module; The deterministic execution platform of each ECU also includes a full-link monitoring slave module, which is used to collect the operating data of each local module and upload it to the full-link monitoring master module; The full-link monitoring master module aggregates the operating data of all slave ECUs to monitor abnormal states of task execution, event transmission, communication process, and cross-ECU collaboration. When an abnormality is detected, it issues a stop operation command to the corresponding module and triggers an alarm through the PHM interface and records standardized operation log information.

[0019] Preferably, the service mode switching command is sent from the vehicle-level host computer to the initialization main module of the main control ECU, and the vehicle only runs one service mode at a time. The initialization main module includes a mode switching unit, which is used to generate a switching signal and send it to each of the ECUs when the service mode switching command is received; The task execution module of each ECU stops the execution of the task in the current service mode and releases the relevant resources according to the switching signal, and the initialization main module then completes the resource initialization of the target service mode.

[0020] Preferably, all functional modules of the deterministic execution platform are implemented based on the basic components of the AUTOSAR adaptive platform, and reuse the process management, COM communication, and logging interfaces of the AUTOSAR adaptive platform.

[0021] The above technical solution has the following advantages or beneficial effects: 1) By clearly defining fine-grained task divisions through task chain configuration data and combining the one-to-one correspondence between execution units and tasks, the process-level scheduling granularity of traditional AP platforms is refined to the task level, achieving precise control over the task execution process. Simultaneously, the timing orchestration scheme generated by the main scheduling module configures a fixed offset execution time based on the global T0 time, inter-task association rules, and timing constraints for each task. This effectively solves the problems of coarse scheduling granularity and lack of time constraint mechanisms in existing AP platforms, significantly reducing task startup jitter and significantly improving the predictability of execution time, meeting the stringent requirements of task-level determinism in intelligent driving scenarios.

[0022] 2) The scheduling and orchestration main module plans the execution time of all tasks from a time perspective, enabling tasks to be executed serially or in parallel according to a preset time sequence, reducing resource contention between tasks. Simultaneously, based on the vehicle-level global configuration file and hardware resource data of each slave ECU, it allocates suitable hardware resources to tasks, avoiding disorderly contention in a multi-core environment. This strategy of ordered time arrangement combined with reasonable resource allocation effectively solves problems such as low-priority task starvation, reduced cache hit rate, and execution time jitter caused by priority preemption in Linux real-time scheduling algorithms, significantly improving CPU utilization and greatly enhancing task execution stability.

[0023] 3) The master ECU's scheduling and orchestration module generates a vehicle-level global T0 time and distributes it to all slave ECUs, establishing a unified vehicle-level time base and resolving the issue of clock asynchrony among ECUs in a distributed system. Based on the global T0 time-based timing orchestration scheme, unified orchestration of task chains across different controllers such as SOC and MCU is achieved, clarifying the triggering sequence and correlation of cross-ECU tasks. This overcomes the shortcomings of traditional Linux scheduling, which is limited to a single machine and cannot coordinate cross-ECU task chains, ensuring the timing consistency of multi-ECU collaborative work and meeting the needs of multi-sensor fusion, decision-making, and cross-ECU collaboration in intelligent driving.

[0024] 4) By tightly integrating task scheduling with communication transmission, the timing of communication is planned according to the communication needs between tasks in the task chain and the timing orchestration scheme, ensuring that communication transmission is linked to task execution timing and avoiding conflicts between communication and computing resources. Simultaneously, based on preset task priority configurations, it ensures that communication data for critical tasks is transmitted first, solving the problems of lacking communication priority guarantees and uncontrollable transmission time limits in existing AP / CPCOM components, ROS2, and other middleware. This achieves bounded latency and high reliability in communication transmission, providing stable communication support for cross-ECU task chain collaboration.

[0025] 5) By initializing the main module's service mode switching function, the task chain configuration data corresponding to the target service mode can be associated with external commands. Each slave ECU completes resource initialization and task start / stop according to the new configuration, realizing dynamic switching of the task chain. This configuration-driven dynamic adjustment mechanism solves the problem of the rigidity and poor scalability of the AUTOSAR CP platform's static scheduling table. It enables the system to flexibly adjust task configuration and resource allocation according to dynamic load changes, functional iterations, or sudden failures in intelligent driving scenarios, improving the system's adaptability and robustness to complex operating conditions.

[0026] 6) A globally unified resource mapping relationship is established through the configuration management module, the scheduling and orchestration module realizes global planning of timing and resources, and the task execution module completes the deterministic execution of local tasks. These modules work together to form a full-link deterministic control system from task triggering, resource allocation, timing control to communication transmission. This system deeply integrates task scheduling and communication transmission, solving the problems of scheduling and communication being disconnected in existing technologies, and the inability to extend determinism from a single link to the entire link. It achieves end-to-end deterministic assurance from task triggering to the generation of vehicle control execution results, providing a solid foundation for the high real-time performance and high reliability of intelligent driving systems. Attached Figure Description

[0027] Figure 1This is a schematic diagram of the structure of a deterministic execution system for intelligent driving, as shown in a preferred embodiment of the present invention. Detailed Implementation

[0028] The present invention will now be described in detail with reference to the accompanying drawings and specific embodiments. The present invention is not limited to this embodiment; other embodiments that conform to the spirit of the present invention may also fall within the scope of the present invention.

[0029] In a preferred embodiment of the present invention, based on the above-mentioned problems existing in the prior art, a deterministic execution system for intelligent driving is provided, such as... Figure 1 As shown, multiple ECUs are distributed and deployed in an intelligent driving vehicle. Each ECU is configured to include a master ECU and several slave ECUs. The master ECU and each slave ECU establish a communication connection through a time-sensitive network (TSN) and achieve nanosecond-level time synchronization based on the IEEE 802.1AS-Rev protocol to ensure the timing consistency of cross-ECU collaboration.

[0030] The system comprises an AUTOSAR adaptive platform and a deterministic execution platform running in each ECU. The deterministic execution platform is distributed in the master and slave ECUs according to a master-slave architecture, with each functional module interconnected bidirectionally to form a distributed collaborative system of global control and local execution. The AUTOSAR adaptive platform, as the underlying infrastructure, provides basic capabilities such as process management, COM communication, and logging. The deterministic execution platform is implemented based on its basic components, requiring no modification to the underlying AP architecture and achieving seamless compatibility with the AUTOSAR ecosystem.

[0031] The deterministic execution platform of the main control ECU includes: The configuration management main module 10 is used to establish the resource mapping relationship between the deterministic execution platform and the AUTOSAR adaptive platform based on the predefined vehicle-level global configuration file and the model files of the local AUTOSAR adaptive platform uploaded from each ECU. The main module 11 is initialized to associate the task chain configuration data corresponding to the target service mode according to the external service mode switching command, issue resource initialization commands to each slave ECU, and collect the initialization ready status of each slave ECU. The scheduling and orchestration main module 12 is used to generate the vehicle-level global T0 time after all slave ECUs are initialized and ready, and to generate a timing orchestration scheme and a distributed resource allocation scheme based on the global T0 time and task chain configuration data and distribute them to each slave ECU. The deterministic execution platforms of each ECU include: Configuration management module 20 is used to collect and upload local model files, as well as receive and store resource mapping relationships; The initialization module 21 is used to receive resource initialization instructions, initialize all required resources according to the resource mapping relationship, and at the same time feed back the local initialization ready status to the main control ECU. The scheduling and orchestration module 22 is used to receive the vehicle-level global T0 time, timing orchestration scheme and distributed resource allocation scheme; The task execution module 23 includes execution units 231 that correspond one-to-one with the local tasks in the task chain configuration data. Each execution unit 231 executes its own associated tasks and generates vehicle control execution results according to the timing arrangement scheme and the distributed resource allocation scheme.

[0032] Specifically, in this embodiment, the configuration management master module 10 of the deterministic execution platform of the master ECU stores and manages predefined vehicle-level global configuration files, and receives local AUTOSAR adaptive platform model files uploaded by the configuration management slave modules 20 of each slave ECU. The aforementioned vehicle-level global configuration files cover vehicle-level basic configuration, hardware resource configuration of each ECU, cross-ECU task chain configuration (including constraints such as the longest execution time and maximum jitter time for time-driven and event-driven task chains), event configuration (including event type, priority, and timeout time), and service mode configuration. All configuration items can be customized by the user according to the needs of intelligent driving services. The aforementioned model files contain key information such as the process distribution of the local ECU, communication interface parameters, and hardware resource list. Based on the vehicle-level global configuration files and local model files, a cross-ECU resource mapping relationship between the deterministic execution platform and the AUTOSAR adaptive platform is established. This includes the binding relationship between the CPU cores and communication interfaces of each ECU and the cross-ECU task chains, as well as the mapping relationship between DEP events and AP COM communication instances, ensuring the global unified planning of system resources.

[0033] The initialization main module 11 in the deterministic execution platform of the main control ECU is responsible for managing the vehicle-level resource initialization process and service mode switching, specifically including: 1) Receive external service mode switching instructions issued by the vehicle host computer or vehicle control system. At any given time, the vehicle only runs one service mode to avoid resource conflicts caused by multiple modes running in parallel.

[0034] 2) Based on the service mode switching command, associate the cross-ECU task chain configuration data corresponding to the target service mode. This data clarifies the set of task chains to be started in the target mode, the ECU nodes where the task chains are distributed, and the relationships between tasks.

[0035] 3) Send resource initialization instructions to the initialization module 21 of each slave ECU. The instructions contain key information such as resource mapping relationship and task configuration parameters in the target service mode, and collect the initialization ready status or abnormal status fed back by each slave ECU in real time.

[0036] Furthermore, the initialization main module 11 has a built-in mode switching unit 111. When a service mode switching command is received, a switching signal is first generated and sent to each slave ECU. The task execution module 23 of each slave ECU stops the task execution in the current service mode and releases the relevant resources according to the switching signal. After all ECUs have reported that the resources have been released, the initialization main module 11 sends the resource initialization command of the target service mode to each slave ECU to ensure that the mode switching process is uninterrupted and orderly.

[0037] If an initialization anomaly is detected from a slave ECU (such as local hardware resource failure or cross-ECU communication failure), a vehicle-level initialization retry process will be triggered until all slave ECUs report that initialization is ready or trigger a vehicle-level anomaly alarm.

[0038] The main scheduling and orchestration module 12 in the deterministic execution platform of the main control ECU further includes a time generation unit 121 for time T0, a timing orchestration unit 122, a resource allocation unit 123, and a dynamic adjustment unit 124. Each unit works together to achieve global orchestration of timing and resources.

[0039] The T0 time generation unit 121 generates a unique vehicle-level global T0 time after all slave ECUs have reported that they are ready for initialization. This time is used as the time reference for all time-sensitive tasks and is uniformly distributed to the scheduling and orchestration slave module 22 of each slave ECU through the TSN network. This ensures that the timing calculation of all tasks in the vehicle is based on the same reference and eliminates the coordination deviation caused by clock asynchrony.

[0040] Timing orchestration unit 122 connects to T0 time generation unit 121 and configuration management main module 10, obtains global T0 time and cross-ECU task chain configuration data, and generates timing orchestration schemes according to task chain type: For time-driven task chains: Calculate the fixed offset execution time of each slave ECU task based on the global T0 time (e.g., start the sensor data acquisition task at global T0+100ms), and configure the association rules between tasks, including three types: follow (triggers the subsequent task after the previous task is completed), aligned (multiple tasks start synchronously based on the same T0 offset time), and fixed (the task start time is not related to other tasks, but only based on the T0 offset), to ensure that the task chain is executed serially or in parallel according to the preset timing.

[0041] For event-driven task chains: Configure event triggering conditions (supporting combinational logic of "AND", "OR", and "count", such as "event e1 arrives 2 times and event e2 arrives 1 time" to trigger a task) and cross-ECU event propagation timing (define the maximum delay from event generation to downstream task reception, such as 500 microseconds), while ensuring that the task relationship conforms to the directed acyclic graph (DAG) structure to avoid event-triggered deadlock.

[0042] Resource allocation unit 123 is used to acquire hardware resource data (number of CPU cores, communication interface bandwidth, storage capacity, etc.) of each slave ECU, and generate distributed resource allocation schemes in the resource allocation phase and communication configuration phase respectively. Resource allocation phase: Based on the priority and computing requirements of the task chain in the task chain configuration data, a dedicated CPU core is allocated to each task in the ECU (i.e., core affinity rules are configured). Tasks of the same type or those with resource contention risks are bound to different CPU cores to avoid cache contention and memory bus conflicts in a multi-core environment, thereby improving the stability of task execution.

[0043] Communication configuration phase: Based on the communication requirements between tasks in the task chain, allocate TSN communication time windows for the corresponding cross-ECU communication links. The start and end times of the communication time windows are linked to the task execution time (e.g., the communication time window is included in the gap between the completion of the preceding task and the start of the following task) to avoid communication and computing resource conflicts and ensure the determinism of communication transmission.

[0044] The dynamic adjustment unit 124 is connected to the timing arrangement unit 122 and the resource allocation unit 123 respectively. It is used to acquire the operating status data of each slave ECU and generate adjustment instructions when there is a deterministic abnormality in operation based on the operating status data. This enables the timing arrangement unit to dynamically update the timing arrangement scheme according to the adjustment instructions, and the resource allocation unit to dynamically update the distributed resource allocation scheme according to the adjustment instructions.

[0045] The aforementioned operational status data includes raw data such as CPU utilization, memory usage, cache hit rate, actual task execution time, execution duration, and event transmission latency for each ECU. Preferably, based on preset thresholds and rules, deterministic operational anomalies are identified from the operational status data. These deterministic operational anomalies include: Abnormal vehicle load fluctuations: The average CPU utilization of multiple ECUs simultaneously exceeds 85% or falls below 20%, and the TSN network bandwidth utilization exceeds 90% or remains below 10% for an extended period. This indicates that the vehicle resource load is too high or too low, affecting system execution efficiency. The above preset thresholds are for illustrative purposes only and can be customized. Abnormal ECU resource usage: If the dedicated CPU core utilization of a single ECU is ≥95% for 3 consecutive cycles (e.g., 1 second), or the hardware interface (e.g., PCIe, storage I / O) utilization exceeds 95%, or the number of resource request failures is ≥1, it indicates that local resources are overloaded or the allocation is ineffective. The above preset thresholds are only examples and can be customized. Abnormal ECU task timing deviation: The deviation (jitter) between the actual execution time and the theoretical time of the task is greater than or equal to the preset threshold (e.g., 10 microseconds), or the cross-ECU event transmission delay exceeds the threshold, or the task cycle deviation exceeds 20%, indicating that the timing orchestration scheme has not been effectively implemented.

[0046] When the above anomalies are detected, adjustment instructions are generated and sent to timing orchestration unit 122 and resource allocation unit 123. Timing orchestration unit 122 adjusts parameters such as task T0 offset time and event trigger threshold according to the instructions. Resource allocation unit 123 reallocates CPU cores or adjusts TSN communication time window. The updated scheme is distributed to each slave ECU in real time through TSN network to ensure that the system can maintain determinism under dynamic load or abnormal scenarios.

[0047] The deterministic execution platform of the master ECU also includes a full-link monitoring master module 13, which receives local operating data uploaded by the full-link monitoring slave modules 24 of each slave ECU, including the initialization status of each module, task execution status (startup / completion / error / timeout), event transmission status (sent / received / timeout), resource usage data, etc.

[0048] This module aggregates all operational data to achieve end-to-end monitoring of vehicle-level cross-ECU time synchronization deviations, task execution anomalies, communication transmission delays, and abnormal resource usage. When an anomaly is detected, a stop command is immediately issued to the corresponding module to prevent the fault from spreading. Simultaneously, a vehicle-level alarm is triggered through the PHM interface, and a standardized operational log is recorded, including the anomaly entity ID (task ID / event ID / ECU ID), timestamp (accurate to nanoseconds), and anomaly type. The log is synchronously stored in the local storage unit of the main control ECU for subsequent fault tracing and system optimization.

[0049] The configuration management module 20 from the deterministic execution platform of the ECU connects to the configuration management module 10 of the main control ECU. It collects the model files of the local AUTOSAR adaptive platform and uploads them to the main control ECU. At the same time, it receives the cross-ECU resource mapping relationship synchronized by the main control ECU and stores it in the local storage unit. This provides the configuration basis for local resource initialization and task execution, ensuring that the local configuration is consistent with the global configuration.

[0050] Initialization module 21 in the deterministic execution platform of the ECU connects to both the local configuration management module 20 and the initialization master module 11 of the master ECU. After receiving resource initialization instructions from the master ECU, it initializes the local ECU's CPU core, communication interface, task execution environment, and other resources according to the cross-ECU resource mapping relationship. Simultaneously, it initializes the communication links and protocol stack required for cross-ECU interaction. After initialization, it reports the local initialization ready status to the master initialization module 11 of the master ECU. If a local hardware resource abnormality or a cross-ECU interaction link failure is detected, it immediately reports the abnormality information and type, and waits for a retry instruction from the master ECU.

[0051] The scheduling and orchestration module 22 in the deterministic execution platform of the ECU connects to the local initialization module 21 and the main scheduling and orchestration module 12 of the main control ECU. It receives the vehicle-level global T0 time, timing orchestration scheme and distributed resource allocation scheme issued by the main control ECU, and preferably parses them into locally executable local scheduling instructions and local resource allocation rules. The local scheduling instructions specify the local start time of time-driven tasks, the triggering rules of event-driven tasks and the maximum execution duration of tasks, etc. The local resource allocation rules specify the dedicated CPU core number, scheduling strategy (FIFO / RR / OTHER) and TSN communication parameters of each local task, etc., to ensure that the global scheme is adapted to the local hardware environment.

[0052] The task execution module 23 in the deterministic execution platform of the ECU is connected to the local scheduling and orchestration module 22. It is the core carrier of local task execution, including execution units 231 that correspond one-to-one with local tasks in the cross-ECU task chain. Each execution unit 231 works together to achieve deterministic execution of the task.

[0053] In a preferred embodiment of the present invention, the execution unit 231 encapsulates an event slot 2311, a trigger 2312, and an executor 2313; Event slot 2311 is configured with matching rules corresponding to the timing orchestration scheme, including time-driven T0 offset ± allowable jitter range and event-driven event combination logic and timing order. After receiving a task trigger signal, if the task trigger signal matches the matching rules, a task start command is generated. The task trigger signal is either a time signal from the local scheduling and orchestration slave module 22 or a cross-ECU event from another ECU. The verification includes time verification and logic verification. Time verification checks whether the arrival time is within the allowable jitter range, and logic verification checks whether the event combination logic matches the receiving order. A task start command is generated only when both verifications pass; otherwise, a timing anomaly is determined and reported to the local scheduling and orchestration slave module 22.

[0054] Actuator 2313 carries the business logic code for the task. Upon receiving the task start instruction, it executes the task under the timing constraints of the timing orchestration scheme. The business logic code includes sensor data acquisition, data fusion, decision reasoning, and control command generation. The timing constraints in the timing orchestration scheme include the maximum execution time and the upper limit of the execution completion time. Actuator 2313 monitors the execution time in real time. If it approaches 90% of the maximum execution time, it sends a duration warning. If it exceeds the maximum execution time, it automatically stops non-core computational logic to ensure that the result is output before the upper limit of the execution completion time, avoiding impact on the timing of downstream tasks.

[0055] Trigger 2312 includes a pre-trigger and a post-trigger, which are used to send cross-ECU events with T0 timing tags to the execution unit 231 of the associated ECU before and after the actuator 2313 executes a task, respectively, according to the event emission timing, priority, and transmission timeout time defined by the timing arrangement scheme, thereby driving the execution of upstream and downstream tasks in the task chain. Specifically, the event emitted by the pre-trigger is used to notify the associated ECU to prepare to receive data or start a preprocessing task, while the event emitted by the post-trigger is used to drive the execution of downstream tasks, ensuring orderly coordination between upstream and downstream tasks in the task chain.

[0056] In a preferred embodiment of the present invention, the intermediate task data (such as sensor preprocessing results, fused data, decision instructions, etc.) generated by the upstream execution unit 231 is encapsulated in an event thrown by the trigger 2312, and the intermediate task data is bound to the corresponding event priority. The event priority is configured in levels 0-63 and mapped to the IP DSCP field. High-priority data (such as emergency braking control instructions) is assigned a higher DSCP priority to ensure priority transmission. Further, the intermediate task data is transmitted to the downstream execution unit 231 via TSN. The transmission gap of the intermediate task data is constrained by the TSN communication time window in the distributed resource allocation scheme. When planning the communication time window, the resource allocation unit 123 ensures that the data transmission completion time is earlier than the task start time of the downstream execution unit 231, reserving data processing time for the downstream task and avoiding task timing disorder caused by data delay.

[0057] In a preferred embodiment of the present invention, the execution unit 231 further encapsulates a resource management subunit 2314, which is used to limit the resource usage data during task execution according to the distributed resource allocation scheme. The resource usage data includes priority, scheduling policy (FIFO / RR / OTHER), core affinity (binding to a dedicated CPU core), and execution timeout. At the same time, it collects resource usage data (CPU utilization, memory utilization, etc.) in real time and uploads it from module 22 to the main control ECU through scheduling and orchestration to provide data support for dynamic adjustment.

[0058] In a preferred embodiment of the present invention, the deterministic execution platform of each slave ECU further includes a full-link monitoring slave module 24, which is connected to the local configuration management slave module 20, initialization slave module 21, scheduling and orchestration slave module 22 and task execution module 23 respectively. It is used to collect the operating data of each local module, including initialization status, task execution timing data (actual start / completion time, execution duration), resource usage data, event transmission status, communication delay, etc., and upload them to the full-link monitoring master module 13 at a period of 10~100ms to provide local data support for vehicle-level full-link monitoring.

[0059] Example 1 In this embodiment, the task chain for intelligent driving automatic emergency braking (AEB) is applied. The AEB task chain needs to complete sensor data acquisition, fusion, decision-making, and control command issuance within milliseconds. It involves two slave ECUs (ECU1: SOC side, responsible for data preprocessing and AI inference; ECU2: MCU side, responsible for arbitration and vehicle control) and one master ECU. The task chain includes time-driven task chains (sensor data acquisition and fusion) and event-driven task chains (arbitration and vehicle control).

[0060] The actual operation flow of the system is as follows: 1. System initialization phase: The main configuration management module 10 of the main control ECU loads the vehicle-level global configuration file. The configuration management modules 20 of ECU1 and ECU2 respectively upload the local AP model files. The configuration management module 10 establishes cross-ECU resource mapping relationships, such as binding the data acquisition task to core0 of ECU1 and binding the fusion task to core1, and binding the arbitration task to core0 of ECU2 and binding the vehicle control task to core1.

[0061] The main module 11 of the main control ECU receives the autoDriving service mode switching command, associates the AEB task chain configuration data, and sends resource initialization commands to ECU1 and ECU2.

[0062] The initialization of ECU1 and ECU2 is completed by module 21, which initializes local resources (starts sensor interface, communication protocol stack, and task execution environment) and reports the ready status to the main control ECU.

[0063] 2. Global solution generation and distribution phase: The T0 time generation unit 121 of the main control ECU generates the global T0 time and distributes it to ECU1 and ECU2.

[0064] The timing orchestration unit 122 generates a timing orchestration scheme: the sensor data acquisition task (time-driven) of ECU1 starts at global T0+0.5ms, and the fusion task (time-driven) starts following the acquisition task; the arbitration task (event-driven) of ECU2 is triggered by the post-trigger event of the fusion task of ECU1, and the vehicle control task (event-driven) is triggered by the post-trigger event of the arbitration task.

[0065] Resource allocation unit 123 generates a distributed resource allocation scheme: allocates core0 to the acquisition task of ECU1 and core1 to the fusion task, allocates core0 to the arbitration task of ECU2 and core1 to the vehicle control task; allocates a TSN communication time window (global T0+1.0ms~T0+1.2ms) to the fusion data communication link of ECU1→ECU2.

[0066] 3. Task execution and data transmission phase: The event slot 2311 of the execution unit 231 (acquisition task) of ECU1 detects the global T0+0.5ms trigger signal, generates a start command, and the actuator 2313 starts sensor data acquisition. The resource management subunit 2314 limits the CPU core 0 utilization rate to ≤90% and the execution timeout time to ≤0.3ms. After the acquisition is completed, the trigger throws an acquisition completion event, carrying the acquired data (bound to priority 63, mapped to the EF queue of the IP DSCP).

[0067] The event slot 2311 of the fusion task receives the acquisition completion event and verifies it, generates a start command, the actuator 2313 performs data fusion, and after completion, throws out a fusion completion event, carrying the fused data to the ECU2 through the TSN communication time window.

[0068] The event slot 2311 of the arbitration task of ECU2 receives the fusion completion event and passes the verification. The actuator 2313 performs decision arbitration, generates a braking control command, and the trigger throws out the arbitration completion event. After receiving the event, the vehicle control task starts and the actuator 2313 sends control commands to the vehicle chassis to complete the emergency braking action.

[0069] 4. Dynamic Adjustment and Anomaly Handling Phase: If the CPU utilization of ECU1 continues to exceed 85% (abnormal vehicle load fluctuation), the dynamic adjustment unit 124 of the main control ECU generates an adjustment command, the resource allocation unit 123 adds core2 to ECU1 and allocates it to the fusion task, the timing arrangement unit 122 adjusts the maximum execution time of the fusion task to 0.4ms, and the updated solution is distributed to ECU1 in real time.

[0070] If the communication delay between ECU1 and ECU2 exceeds 500 microseconds (communication anomaly), the end-to-end monitoring main module 13 triggers an alarm, records the log and issues a command. The resource allocation unit 123 adjusts the TSN communication time window to T0+1.0ms~T0+1.3ms to ensure data transmission determinism.

[0071] In summary, the application of this invention: 1. Resolve the scheduling granularity mismatch issue. This invention solves the technical problem of excessively coarse-grained process-level scheduling in existing AP platforms. AP platforms use processes as the basic scheduling unit, and their function group management method cannot meet the task-level determinism requirements of intelligent driving scenarios. DEP, by introducing a task chain and fine-grained task management mechanism, refines the scheduling granularity from the process level to the Runnable function level, achieving precise control over the task execution process.

[0072] Specifically, this invention establishes a task-event driven model to realize a function-oriented programming paradigm, providing more accurate deterministic guarantees for high real-time applications and solving the technical defects of AP platforms in that they cannot perform fine-grained management of task execution time, startup jitter, resource allocation, etc.

[0073] 2. Overcome resource competition and fluctuation issues This invention addresses the resource contention and high jitter issues of Linux real-time scheduling algorithms (FIFO / RR / RMS) in multi-core environments, proposing a deterministic scheduling scheme based on spatiotemporal orchestration. While existing scheduling algorithms can guarantee priority order to some extent, they cannot fundamentally avoid resource contention issues such as CPU cache contention and memory bus conflicts. Deterministic Estimation (DEP) employs a hybrid scheduling strategy combining static orchestration at design time and dynamic adjustment at runtime to avoid resource conflicts at both the spatial (CPU core allocation) and temporal (execution time arrangement) dimensions. Specifically, it solves the execution time jitter caused by cache contention between tasks in multi-core environments, memory latency fluctuations caused by memory access conflicts, and the starvation of low-priority tasks due to long-term resource occupation by high-priority tasks.

[0074] 3. Achieve cross-ECU collaborative scheduling This invention addresses the technical challenge of existing technologies failing to support collaborative scheduling across ECU task chains. Traditional Linux scheduling is limited to a single machine, and the static scheduling table of the CP platform only applies to a single ECU, failing to meet the needs of multi-ECU collaborative operation in intelligent driving systems. DEP achieves unified orchestration of vehicle-level task chains by establishing a global T0 time and a master-slave collaborative mechanism. Specifically, it solves the problems of inconsistent timing management of task chains across SOCs and MCUs, the coordination difficulties caused by clock asynchrony between ECUs in distributed systems, and resource allocation and conflict avoidance when task chains are executed across controllers.

[0075] 4. Enhance communication determinism assurance capabilities This invention addresses the technical deficiency of AP / CP COM components and communication middleware such as ROS2 in lacking strict deterministic guarantees, proposing a deterministic communication scheme based on event priority mapping and TSN technology integration. Specifically, DEP establishes a strict priority scheduling mechanism by binding event priorities to IP DSCP fields, solving the problem that existing middleware cannot guarantee the priority transmission of highly critical messages. It also solves the problem that traditional communication methods cannot guarantee message delivery within a specific time frame. Furthermore, DEP eliminates the time uncertainty in the service discovery process through pre-configuration and static binding mechanisms, resolving the problem of random delays in the service discovery process of the AP platform.

[0076] 5. Enhance the system's dynamic adaptability DEP enhances the dynamic adaptability of a system while maintaining determinism through event-driven task chains and dynamic orchestration algorithms. It addresses the timely response to unexpected events, dynamic resource adjustment during system load changes, and task chain reconstruction and recovery in fault scenarios.

[0077] 6. Establish an end-to-end deterministic guarantee system The ultimate goal of this invention is to construct a complete end-to-end deterministic guarantee system, solving the end-to-end deterministic challenge from task triggering to communication transmission. By deeply integrating task scheduling and communication transmission, a unified deterministic management framework is established, providing a reliable technical foundation for high real-time applications such as autonomous driving.

[0078] Therefore, this invention not only solves the deterministic problem of individual technical links, but more importantly, it establishes a collaborative mechanism between various technical links to ensure the end-to-end determinism of the entire system and meet the stringent requirements of intelligent driving systems for real-time performance and reliability.

[0079] The above description is merely a preferred embodiment of the present invention and does not limit the implementation and protection scope of the present invention. Those skilled in the art should realize that any equivalent substitutions and obvious changes made using the content of this specification and illustrations should be included within the protection scope of the present invention.

Claims

1. A deterministic execution system for intelligent driving, characterized in that, The system is distributed across multiple ECUs in an intelligent driving vehicle, including an AUTOSAR adaptive platform and a deterministic execution platform running in each of the ECUs, and each of the ECUs is configured to include a master ECU and several slave ECUs. The deterministic execution platform of the main control ECU includes: The configuration management main module is used to establish the resource mapping relationship between the deterministic execution platform and the AUTOSAR adaptive platform based on the predefined vehicle-level global configuration file and the model files of the AUTOSAR adaptive platform uploaded from each ECU locally. The main module is initialized to associate the task chain configuration data corresponding to the target service mode according to the external service mode switching command, issue resource initialization commands to each slave ECU, and collect the initialization readiness status of each slave ECU. The scheduling and orchestration main module is used to generate a vehicle-level global T0 time after all the slave ECUs are initialized and ready, and to generate a timing orchestration scheme and a distributed resource allocation scheme based on the global T0 time and the task chain configuration data, and distribute them to each slave ECU. The deterministic execution platform from each of the ECUs includes: The configuration management module is used to collect and upload the model files locally, and to receive and store the resource mapping relationships; The initialization slave module is used to receive the resource initialization command, initialize all required resources according to the resource mapping relationship, and at the same time feed back the local initialization ready status to the master control ECU. The scheduling and orchestration module is used to receive the vehicle-level global T0 time, the timing orchestration scheme, and the distributed resource allocation scheme. The task execution module includes execution units that correspond one-to-one with the local tasks in the task chain configuration data. Each execution unit executes its associated task according to the timing arrangement scheme and the distributed resource allocation scheme and generates vehicle control execution results.

2. The intelligent driving deterministic execution system according to claim 1, characterized in that, The task chain configuration data includes time-driven task chains and event-driven task chains; The scheduling and orchestration main module includes: The T0 time generation unit is used to generate the vehicle-level global T0 time based on the vehicle-level time reference after all the slave ECUs are initialized and ready. The timing orchestration unit, connected to the T0 time generation unit, is used to calculate the fixed offset execution time of each task in the time-driven task chain based on the vehicle-level global T0 time and configure the association rules between tasks; and to configure the event triggering conditions and cross-ECU event propagation timing for the event-driven task chain to form the timing orchestration scheme. The resource allocation unit is used to acquire the hardware resource data of each slave ECU, and allocate a dedicated CPU core to each slave ECU task according to the hardware resource data, the priority of the task chain in the task chain configuration data and the computing requirements. Then, according to the communication requirements between tasks in the task chain, it allocates a TSN communication time window to the corresponding communication link to form the distributed resource allocation scheme.

3. The intelligent driving deterministic execution system according to claim 2, characterized in that, The scheduling and orchestration main module further includes a dynamic adjustment unit, which is connected to the timing orchestration unit and the resource allocation unit respectively. It is used to acquire the operating status data of each slave ECU, and generate an adjustment instruction when it is determined that there is an operating deterministic anomaly based on the operating status data. This enables the timing orchestration unit to dynamically update the timing orchestration scheme according to the adjustment instruction, and the resource allocation unit to dynamically update the distributed resource allocation scheme according to the adjustment instruction.

4. The intelligent driving deterministic execution system according to claim 3, characterized in that, The operational deterministic anomalies include abnormal fluctuations in vehicle load, and / or abnormal ECU resource usage, and / or abnormal ECU task timing deviations.

5. The intelligent driving deterministic execution system according to claim 1, characterized in that, The execution unit encapsulates an event slot, a trigger, and an executor; The event slot is configured with matching rules corresponding to the timing arrangement scheme. When a task trigger signal is received, and the matching rules are verified to be consistent with the task trigger signal, a task start command is generated. The executor is used to carry the business logic code of the task, and after receiving the task start instruction, it executes the task under the timing constraints in the timing orchestration scheme. The trigger includes a pre-trigger and a post-trigger, which are used to send events to the execution unit of the associated ECU before the actuator performs a task and after the execution of the task, respectively, to drive the execution of upstream and downstream tasks in the task chain.

6. The intelligent driving deterministic execution system according to claim 5, characterized in that, The intermediate task data generated by the upstream execution unit is encapsulated in the event thrown by the trigger, and the intermediate task data is bound to the corresponding event priority. The event priority is mapped to the IP DSCP field and transmitted to the downstream execution unit through TSN. The transmission gap of intermediate data in the task is constrained by the TSN communication time window in the distributed resource allocation scheme, and the data transmission completion time is earlier than the task start time of the downstream execution unit.

7. The intelligent driving deterministic execution system according to claim 5, characterized in that, The execution unit also encapsulates a resource management subunit, which is used to limit the resource usage data during the task execution process according to the distributed resource allocation scheme. The resource usage data includes priority, scheduling strategy, core affinity, and execution timeout.

8. The intelligent driving deterministic execution system according to claim 1, characterized in that, The deterministic execution platform of the main control ECU also includes a full-link monitoring main module; The deterministic execution platform of each ECU also includes a full-link monitoring slave module, which is used to collect the operating data of each local module and upload it to the full-link monitoring master module; The full-link monitoring master module aggregates the operating data of all slave ECUs to monitor abnormal states of task execution, event transmission, communication process, and cross-ECU collaboration. When an abnormality is detected, it issues a stop operation command to the corresponding module and triggers an alarm through the PHM interface and records standardized operation log information.

9. The intelligent driving deterministic execution system according to claim 1, characterized in that, The service mode switching command is sent from the vehicle-level host computer to the initialization main module of the main control ECU, and the vehicle only runs one service mode at a time. The initialization main module includes a mode switching unit, which generates a switching signal and sends it to each of the ECUs when the service mode switching command is received; The task execution module of each ECU stops the execution of the task in the current service mode and releases the relevant resources according to the switching signal, and the initialization main module then completes the resource initialization of the target service mode.

10. The intelligent driving deterministic execution system according to claim 1, characterized in that, All functional modules of the deterministic execution platform are implemented based on the basic components of the AUTOSAR adaptive platform, and reuse the process management, COM communication, and logging interfaces of the AUTOSAR adaptive platform.

Images