How cluster pixels actually get drawn

Once you accept that the cluster's rated content must come from a safety system and its informational content from Android, a practical question follows: how do those two actually end up on one screen?

There are four answers in production use, and the choice shapes a lot else.

Option 1 — Native, everything drawn by the safety system#

The safety guest draws every pixel. Android sends structured content — a navigation instruction, a media title — and the safety guest renders it in its own style.

Android ──(structured message)──> Safety guest ──> Display

Good: cleanest safety argument. One system owns the display, so proving availability is straightforward. Android failing changes nothing about how the cluster looks except that the info card empties.

Costs: the safety guest must implement rendering for everything, including things it does not naturally care about. Visual richness is limited by what a certifiable renderer can reasonably do. Every visual change requires a change to certified software.

Option 2 — Streamed, Android renders and sends pixels#

Android renders its region into a buffer and sends the image to the cluster, which composites it under its own rated layer.

Android ──(pixel buffer)──> Safety guest ──(composites)──> Display

Good: Android's region can look like anything. No renderer to build twice. Visual updates ship with Android rather than with certified software.

Costs: bandwidth, latency, and a hard failure question — what happens when the stream stops?

Option 3 — Shared surface, composed by hardware#

Both guests render into separate buffers. The display controller composites them in hardware, with the rated layer always on top.

Safety guest ──> layer 0 (rated)      ┐
                                      ├──> display controller ──> Display
Android      ──> layer 1 (info)       ┘

Good: the best of both. Android renders freely; the rated layer is composited by hardware that Android cannot influence. If Android stops, its layer is stale or empty but the rated layer is untouched — provably, because the compositing is in silicon.

Costs: requires a display controller with enough independent hardware layers, and careful configuration so Android genuinely cannot affect layer 0. It is a hardware-dependent option.

Option 4 — Dedicated 2D path for the critical layer#

Telltales and warning lamps bypass the GPU entirely, drawn by a simple 2D engine or even fixed-function hardware.

Good: proving GPU availability to a safety standard is genuinely hard. Avoiding the dependency is much easier than proving it.

Costs: limited to simple content. Fine for lamps and numbers; not for a rendered 3D scene.

Choosing#

The GPU is the contended resource#

Whichever option, if the cluster and infotainment share a GPU, that GPU is the hard problem.

Approaches:

• Time-sliced with guaranteed budgets — the safety guest gets a reserved share, enforced by the hypervisor
• Hardware-partitioned, where the silicon supports splitting it
• Separate display pipelines, so composition is independent even if rendering is shared
• Avoid the dependency, per option 4

Latency budgets#

The cluster is in the driver's direct view, and delay is noticeable there in a way it is not on the centre screen.

Next#

Proving all of this to a safety standard.