Hypervisors & Mixed-Criticality Systems
10 chapters Modern vehicles collapse many ECUs onto one SoC, so a QM infotainment stack and an ASIL D cluster now share the same silicon. You learn how a certified hypervisor delivers freedom from interference through spatial and temporal isolation, so software of different criticalities can coexist without one corrupting the other.
How You Learn
Video and text stay in sync. As you scroll through the chapter, the video jumps to the matching explanation automatically.
Learning Objectives
Choose the right hypervisor architecture
Weigh type-1 versus type-2 and certified versus open-source designs against your mixed-criticality and ASIL targets.
Enforce spatial isolation on real silicon
Use stage-2 MMU page tables and the SMMU to guarantee that a QM partition cannot touch ASIL memory or peripherals.
Guarantee temporal isolation under load
Design time-budget scheduling and bandwidth controls so a runaway partition never starves safety-critical work.
Interpret the hypervisor safety manual
Validate the SEooC assumptions of use and fold the isolation claims into your technical safety concept.
Chapters
Why Virtualize the Car?
The business and engineering forces driving ECU consolidation, and why collapsing many controllers onto one SoC creates a mixed-criticality problem that only a hypervisor can solve.
Virtualization Fundamentals
The core building blocks of virtualization, contrasting type-1 bare-metal hypervisors with type-2 hosted designs and defining what a partition really guarantees.
What the Silicon Provides
How hardware-assisted virtualization does the heavy lifting, using EL2 hypervisor mode, stage-2 address translation and the SMMU to enforce isolation the software alone could not.
What ISO 26262 Actually Requires
The freedom-from-interference obligations of ISO 26262-6 Annex D and how a hypervisor is typically qualified as a Safety Element out of Context.
Spatial Isolation
How partitions are prevented from reading or writing each other's memory, from stage-2 page tables to protecting shared peripherals and DMA masters.
Temporal Isolation
How the hypervisor guarantees that a misbehaving partition cannot steal CPU time or bus bandwidth from a safety-critical one through time-budget scheduling.
Safe Communication Between Partitions
How partitions exchange data without breaking isolation, using controlled shared-memory channels, VirtIO and integrity-protected inter-partition messaging.
The Safety Concept of a Virtualized ECU
How the hypervisor's isolation claims are woven into the technical safety concept, allocating requirements and monitors across QM and ASIL partitions.
The Hypervisor Landscape & Deployment
A survey of production automotive hypervisors and the real vehicle architectures they power, from digital cockpits to zonal controllers.
Verifying Isolation, Pitfalls & Decisions
How to prove the isolation claims through fault injection and interference stress testing, and the trade-offs and traps to weigh when choosing a partitioning strategy.
Diagrams & Visuals
Type-1 vs Type-2 Hypervisor Stack
Contrasts the bare-metal and hosted architectures and shows where the safety-relevant partition boundary sits in each.
Stage-2 MMU & SMMU Isolation Map
Traces how two-stage address translation and the SMMU keep each partition, including its DMA masters, inside its own memory.
Temporal Partitioning Budget Timeline
Shows CPU execution budgets and time partitions guaranteeing safety-critical work even while a QM partition overruns.
Shared-SoC Interference Channel Map
Catalogues the memory, cache, bandwidth and communication channels through which one partition could couple into another.
Partition Scheduling State Machine
Models how the hypervisor cycles partitions through run, budget-exhausted and restart states under its scheduler.
Virtualized ECU Safety Concept
Maps safety requirements, monitors and safe-state reactions across the QM and ASIL partitions on one SoC.
Consolidating an ASIL D Cluster and a QM Infotainment Stack on One SoC
A digital cockpit program collapses a standalone ASIL D instrument cluster and a QM Android infotainment stack onto a single automotive SoC running a certified type-1 hypervisor. The worked example walks through the freedom-from-interference argument that lets the QM partition fail without ever corrupting the cluster's telltales.
- Partition layout: ASIL D cluster and QM infotainment placed in separate stage-2 address spaces
- SMMU configured so the infotainment GPU and DMA masters cannot reach cluster memory
- CPU time budgets and DRAM bandwidth caps guarantee cluster rendering under infotainment load
- Safety-critical telltales routed through an integrity-protected inter-partition channel
- Health monitor restarts a crashed QM partition without disturbing the ASIL D partition
- Fault-injection campaign proves no interference channel breaks the isolation claim
Freedom-from-Interference Argument: Cockpit-SoC-2024
Master Mixed-Criticality Integration on a Single SoC
Work through hardware-assisted virtualization, spatial and temporal isolation, and a complete freedom-from-interference case study for a consolidated cockpit ECU.
Start Learning Now