Heterogeneous Multi-Core Scheduling with Logical Domains
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Legacy operating systems for vehicles, such as those based on the OSEK standard, do not scale well to multi-core processors and fail to consider hardware accelerators like GPUs, leading to uncontrolled jitter accumulation in real-time systems, particularly in safety-critical applications like ADAS.
Innovation Solution
A heterogeneous multi-core system with logical domains, shared memory, and synchronizers that manage tasks with guaranteed latency and periodicity, ensuring each stage of the execution pipeline has a guaranteed latency and synchronizes inputs with different periodicities to prevent jitter.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If legacy OSEK operating systems are used for real-time scheduling, then periodic rings can execute at different rates with priority-based scheduling, but the system does not scale well to multi-core processors and does not consider hardware accelerators like GPUs
Solution Approach 1:
The system divides the multi-core processor into multiple logical domains, each capable of executing independent periodic rings. This segmentation allows the legacy OSEK scheduling mechanism to be distributed across multiple cores while maintaining its core functionality, thereby achieving scalability without requiring a complete redesign of the scheduling system.
Solution Approach 2:
The patent makes the scheduling system universal by enabling it to handle both traditional CPU tasks and hardware accelerator tasks (such as GPU computations) within the same periodic ring framework. This allows the system to accommodate heterogeneous architectures without requiring separate scheduling mechanisms for different processing units.
2Reliability
If event-driven scheduling systems like ROS are used, then multi-core processors and shared hardware accelerators are effectively supported, but there is no mechanism to determine system latency and jitter accumulates without control
Solution Approach 1:
The patent introduces feedback mechanisms that monitor and control the execution timing of periodic rings. By measuring actual execution times and comparing them against guaranteed latency constraints, the system can adjust scheduling decisions to prevent jitter accumulation and ensure real-time performance guarantees, thereby resolving the latency control issue in event-driven systems.
Solution Approach 2:
The system performs preliminary actions by pre-calculating and enforcing guaranteed latency constraints for each periodic ring before execution begins. This allows the system to proactively control timing and prevent jitter accumulation rather than reacting to it after it occurs, ensuring real-time reliability from the start of execution.
3Productivity
If priority-based scheduling is used in legacy systems, then periodic rings with higher execution rates complete before lower execution rate rings, but jitter accumulates at each step of the execution pipeline without control
Solution Approach 1:
The patent changes the scheduling parameters by introducing guaranteed latency constraints that modify how priority-based scheduling operates. Instead of solely relying on execution rate for priority determination, the system adjusts timing parameters to ensure that each periodic ring meets its latency guarantees, thereby reducing jitter while maintaining execution efficiency.
Data Source
AI summary
A heterogeneous multi-core system that executes a real-time system for an automobile includes a plurality of system-on chips in electronic communication with one another. Each system-on-chip includes a plurality of central processing units (CPUs) arranged into a plurality of logical domains. The heterogeneous multi-core system also includes a plurality of scheduled tasks that are executed based on an execution pipeline and each execute a specific set of tasks for one of the logical domains. The plurality of scheduled tasks includes at least one offset scheduled task that is executed at an offset time and a reference scheduled task located at an execution stage upstream in the execution pipeline relative to the offset scheduled task. The reference scheduled task communicates data to the offset scheduled task and the offset time represents a period of time measured relative to the reference scheduled task.