Centralized Scheduling for Autonomous Driving
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing autonomous driving systems face challenges with decentralized architectures, leading to inconsistencies, resource contention, and single-point failures due to multi-process models and inefficient data communication, which result in unpredictable behavior and difficulty in debugging and deploying autonomous driving modules.
Innovation Solution
A centralized scheduling system is introduced, utilizing a single-threaded task scheduler with a global store for data management and communication, eliminating the need for kernel-level modifications and enabling atomic operations, thus ensuring consistent results and easy debugging, while also decoupling core logic from IO communication.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If a decentralized multi-process model is used for autonomous driving modules, then module independence and continuous operation are achieved, but resource contention, race conditions, and system inconsistency occur
Solution Approach 1:
The patent merges multiple independent module processes into a single unified process that executes sequentially. This eliminates the multi-process architecture that causes resource contention and race conditions, while maintaining module independence through functional decomposition within the single process. The single process model ensures that only one module executes at a time, preventing concurrent access issues to shared resources.
Solution Approach 2:
The patent segments the autonomous driving system into discrete functional modules (sensors, perception, prediction, decision, control) that are executed sequentially within a single process. Each module is implemented as a distinct function or subroutine that can be independently developed and tested, maintaining adaptability while avoiding the pitfalls of multi-process execution.
2Duration of action of stationary object
If modules run as long-running independent processes, then continuous operation is enabled, but failover becomes difficult and single points of failure emerge
Solution Approach 1:
The patent implements dynamic module execution where modules are activated based on current system state and requirements rather than running continuously. The single process can dynamically load, execute, and unload modules as needed, enabling graceful degradation and failover. If one module fails, the system can recover by reloading or bypassing that specific module while maintaining overall continuous operation.
3Adaptability or versatility
If a publisher-subscriber message passing model is used for inter-module communication, then module decoupling is achieved, but IO overhead and communication delay increase
Solution Approach 1:
The patent extracts the communication overhead from the core execution path by implementing direct function-to-function calls within the single process. Modules communicate through shared memory structures and function parameters rather than network message passing, eliminating the IO overhead associated with publisher-subscriber models while maintaining logical module decoupling through clear interface definitions.
4Adaptability or versatility
If data is copied between modules for communication, then module independence is maintained, but data transmission delay increases
Solution Approach 1:
The patent uses selective copying where data is copied only when necessary between modules, rather than continuously copying all data. Shared memory structures allow modules to access the same data buffers without duplication, reducing memory overhead and copy operations. Critical time-sensitive data is passed by reference or pointer rather than being copied, minimizing transmission delay while maintaining module independence.
Data Source
AI summary
An event queue is maintained to store IO events generated from a number of sensors and timer events generated for a number of autonomous driving modules. For each of the events pending in the event queue, in response to determining that the event is an IO event, the data associated with the IO event is stored in a data structure associated with the sensor in a global store. In response to determining that the event is a timer event, a worker thread associated with the timer event is launched. The worker thread executes one of the autonomous driving modules triggered or initiated the timer event. Input data is retrieved from the global store and provided to the worker thread to allow the worker thread to process the input data.