Consolidating the cluster with infotainment saves real money. The price is that the isolation which used to be obvious — they were separate boxes — now has to be argued for in a document.
This page is about what that document contains and what it demands of your work.
What the cluster owes the driver#
Two distinct obligations, often conflated:
Regulatory. Specific telltales must be a specific colour and symbol, and must appear when their condition occurs. These come from vehicle regulations, not from ratings, and they are checked at homologation.
Functional safety. The rated content must be correct — a speedometer that displays 50 when the vehicle is doing 70 is a safety failure, not a cosmetic one. This is territory, with an ASIL rating attached.
The three failure modes a safety case must address#
For any displayed value, the analysis asks what happens if it is:
Absent. The speedometer shows nothing. Usually detectable by the driver, and usually the least dangerous of the three.
Wrong. The speedometer shows 50 when the vehicle is doing 70. This is the dangerous one, because the driver has no way to know and will act on it.
Stale. The speedometer shows a value from four seconds ago. Dangerous for the same reason as wrong, and harder to detect from inside the system.
Freedom from interference, concretely#
When rated and unrated software share hardware, must be demonstrated in three dimensions.
Memory. The infotainment guest cannot read or write the safety guest's memory. Evidence: hypervisor configuration, hardware memory protection settings, and tests attempting violations.
Timing. The infotainment guest cannot delay the safety guest. Evidence: core allocation, scheduling configuration, and measurement under adversarial load.
Exchange of information. A corrupted or malicious message from the infotainment guest cannot cause incorrect behaviour in the safety guest. Evidence: the receiver validates everything, bounds the channel, and has a defined fallback.
The evidence a safety case actually wants#
Not code quality opinions — artefacts:
| Evidence | What it looks like |
|---|---|
| Hazard analysis | Every displayed item, its failure modes, and the resulting risk |
| Safety requirements | Derived from the hazards, traceable both ways |
| Architecture rationale | Why this partitioning satisfies those requirements |
| Isolation evidence | Configuration plus tests attempting to violate it |
| Timing evidence | Measured worst-case under adversarial load, not typical load |
| Tool qualification | Confidence in the compiler, hypervisor and generators used |
| Verification results | Tests traceable back to requirements |
Requirements that keep landing on the wrong system#
These arrive on infotainment teams regularly, and all of them belong elsewhere:
- "The head unit shall display the brake warning lamp."
- "The infotainment system shall alert the driver when adaptive cruise disengages."
- "Android shall guarantee the speed display updates within 100 ms."
- "The head unit shall place the emergency call."
- Any availability figure Android cannot meet.
Testing the safety argument#
Three tests worth running early and repeatedly:
# From the infotainment guest, on a development build
adb shell stop
# Cluster must be completely unaffected: gauges, telltales, no flicker
adb shell startRun a GPU benchmark, saturate memory bandwidth, and flood the inter-guest
channel — simultaneously. Measure cluster frame timing throughout.Send malformed messages: wrong version, oversized, truncated, wrong field types,
absurd values. The safety guest must reject every one and keep working.Next#
The infotainment side of the same cockpit.