Mixed-Criticality Systems
When tasks of different importance share one platform, the architecture must ensure low-criticality work can never compromise high-criticality timing.
One Platform, Many Criticalities
A mixed-criticality system runs tasks of differing importance and safety significance on shared hardware. A single controller might run a hard safety-critical loop alongside soft logging, diagnostics, and user-interface tasks. Consolidating them saves hardware and complexity, but it creates a hazard: less critical work must never be able to steal the timing or resources the critical work depends on.
The Isolation Requirement
The central design goal is isolation, both in time and in space. Temporal isolation ensures a low-criticality task overrunning or misbehaving cannot delay a high-criticality task past its deadline. Spatial isolation ensures a fault in one task, a memory corruption or crash, cannot damage another. Without both, certifying the critical functions would require analyzing every non-critical task to the same rigor, defeating the purpose of consolidation.
Mechanisms
- Partitioning: fixed time slices and memory regions per criticality level, enforced by the platform
- Priority and budget enforcement: a task cannot exceed its allotted processor time
- Core dedication: pin critical tasks to their own cores away from noisy neighbors
- Hypervisors: run separate domains with hardware-enforced separation
Time and Space Partitioning
A common approach, used in safety-critical avionics, is a partitioned architecture where each partition receives a guaranteed window of processor time and a protected region of memory, enforced by the operating system or a hypervisor. Within its window a partition runs freely; outside it, it cannot execute, so it cannot interfere with others. This makes the timing of a critical partition independent of the behavior of the rest.
Why It Matters
Mixed-criticality design lets a facility run its protection, control, and monitoring on shared, well-isolated infrastructure while keeping the highest-integrity functions provably independent. The critical safety and control loops keep their guarantees regardless of how the diagnostic, logging, and interface software behaves, and each layer can be verified to the rigor its criticality demands rather than the highest common denominator.