[Improvement] Introduce a Mixed-Criticality Orchestrator (MCO) for Dynamic, Context-Aware Resource Management

This proposal introduces the concept of a Mixed-Criticality Orchestrator (MCO), a new layer of intelligence on top of the existing ExecutionEngine. The MCO will enable dynamic, context-aware resource management, transforming the current static scheduler configuration into a truly adaptive real-time system.

The current ExecutionEngineBuilder allows developers/integrator to define a mixed-criticality system by statically assigning thread parameters (priority, affinity) to different workers. While this is a solid foundation, it lacks the ability to adapt to changing runtime conditions, which is crucial for complex systems like autonomous driving (ADAS/AD).

The MCO will act as an intelligent "traffic controller" for system resources (CPU, memory, etc.). It will understand the criticality of each task and the overall system context, making dynamic decisions to guarantee safety while maximizing hardware utilization.

This improvement addresses the following high-level stakeholder needs :

**Guaranteed Safety for Critical Tasks:** The system must ensure that high-criticality functions (e.g., vehicle braking) always meet their execution deadlines, regardless of the load from lower-priority tasks (e.g., logging, UI updates).

**Efficient Hardware Utilization:** To reduce cost and power consumption, the system must make optimal use of the available hardware. CPU cores dedicated to safety should not sit idle if they can be safely used for other tasks.

**Dynamic Adaptability:** The system must be able to adapt its resource allocation strategy based on the operational context. For example, an autonomous vehicle requires a different resource profile for highway cruising versus navigating a complex urban intersection.

**Proposed Solution: The MCO Layer**
We propose adding a new MCO layer that orchestrates the ExecutionEngine at runtime.

**Key Responsibilities of the MCO:**
**Policy-Based Governance:** The MCO will operate based on a set of user-defined policies. These policies will define the system's operational modes , the tasks belonging to each mode, and the resource guarantees for each task.

**Dynamic Priority/Affinity Management:** The MCO will have the authority to dynamically adjust thread priorities and CPU affinities of the workers within an ExecutionEngine. For instance, it could elevate the priority of a perception task when a potential hazard is detected.

**Resource Borrowing:** It will facilitate "resource borrowing," where low-priority tasks can run on high-priority cores when they are idle, with the guarantee of immediate preemption when a critical task needs to run.

**Context-Aware State Transitions:** The MCO will manage transitions between different system states. An external or internal trigger (e.g., a sensor input) can signal a context change, causing the MCO to apply a new set of resource policies.

**Architectural Integration:**
The MCO would not replace the ExecutionEngine but rather manage it.
**MCO Builder:** A new MCOBuilder would be introduced to define operational modes and policies.
**Runtime Control:** The MCO would hold a handle to the ExecutionEngine and use a new set of internal APIs to adjust worker parameters at runtime.
**Application API:** The application would interact with the MCO to trigger state transitions (e.g., mco.switch_mode("UrbanDriving")).

This approach builds upon the existing robust scheduling foundation while adding a powerful layer of dynamic control, moving the orchestrator from a static task executor to a dynamic, intelligent system manager.

**Benefits**
**Enhanced Safety:** Provides formal, verifiable guarantees for critical task execution.

**Increased Efficiency:** Maximizes hardware utilization by reclaiming idle cycles from high-priority cores.

**Greater Flexibility:** Allows the system to adapt to unpredictable, dynamic workloads without being over-provisioned.

**Simplified Application Logic:** Offloads complex resource management logic from the application developer to the MCO, allowing them to focus on business logic.

We believe this is a natural and critical evolution for the orchestrator, positioning it as a leading solution for next-generation, mixed-criticality software-defined systems. We are eager to **discuss this proposal and collaborate on its implementation**.