Several operating systems on one chip, with proof that one cannot disturb another — what a hypervisor actually does, and why it is the enabling technology for consolidation.
Advanced6 minHypervisor · Virtualisation · Safety
Consolidation creates an immediate problem. Once the instrument cluster and the
infotainment system share a processor, what stops a badly behaved app from
freezing the speedometer?
The answer is a , and understanding what it does — and what it
does not — is essential to reasoning about any consolidated cockpit.
Mixed criticality on one chip — Four operating systems with four different safety obligations. The hypervisor's job is to make the QM guests provably incapable of disturbing the rated ones.
Four resources, and each needs handling differently.
CPU cores. Cores can be assigned exclusively to a guest, or time-shared with
guaranteed budgets. A safety guest usually gets dedicated cores, so no scheduling
decision anywhere else can delay it.
Memory. Each guest gets its own physical memory region, enforced by hardware
memory management. A guest cannot address memory it was not given — not by
convention, but because the hardware refuses.
Devices. Some are assigned exclusively — the safety guest owns the cluster
display controller outright. Some are shared through virtual devices, which is
where most of the complexity lives.
Interrupts. Routed to the owning guest, with priorities that prevent a
low-criticality guest's interrupt storm from delaying a high-criticality one.
Type 1 runs directly on the hardware, with guests above it. This is what
vehicles use — thin, auditable, and certifiable.
Type 2 runs as an application inside a host operating system. Fine for
development, unsuitable for a vehicle, because the whole host is now in the trust
path.
Partitioning CPU and memory is well understood. The graphics processor is where
consolidated cockpits actually get difficult.
Both the cluster and infotainment want to render. There is one GPU. The cluster's
rendering is safety-relevant and must not be starved; infotainment's is not but
is visually demanding.
Approaches in use:
Time-sliced GPU with guaranteed budgets per guest
Hardware-partitioned GPU, where the silicon supports splitting it
Separate display pipelines so composition is independent even if rendering
is shared
A dedicated 2D engine for the cluster's critical layer, bypassing the GPU
entirely
Performance overhead, usually modest for CPU, potentially significant for I/O
and graphics.
Certification effort. The hypervisor itself must be qualified to the highest
safety level of any guest it isolates.
Debugging difficulty. A problem may be in a guest, in the hypervisor, or in
the interaction. Correlating traces across guests requires deliberate tooling.
Licensing. Commercial automotive hypervisors are not cheap.
