ISO 26262: Functional Safety

TL;DR

ISO 26262 is the automotive functional safety standard. It answers: “If this software fails, can someone get hurt?” You start with hazard analysis (what can go wrong?), derive ASIL A–D from Severity × Exposure × Controllability, then cascade Safety Goals → Functional Safety Requirements → Technical Safety Requirements. ASIL decomposition lets you split ASIL D into two ASIL B(D) elements with independence evidence. On your cockpit platform: QNX host = ASIL D foundation, AAOS guest = QM. The hypervisor’s core job is Freedom from Interference (FFI): proving the Spotify VM cannot corrupt the speedometer.

You’ve been living inside ISO 26262’s consequences since Module 1: QNX beside AAOS, hypervisor partitions, gateway isolation. This page names the standard, shows the paperwork chain, and explains why your architecture looks the way it does.

Hazard Analysis: Start With the Crash, Not the Code

Functional safety begins with Item Definition: what is the system supposed to do? For a cockpit domain controller, the item might be “provide driver speed information and vehicle status telltales.”

Then Hazard Analysis and Risk Assessment (HARA) asks: what happens if it fails, and how bad is that?

HARA Step	Question	Example (Instrument Cluster)
Malfunction	What can go wrong?	Speed display shows 0 mph at 70 mph
Hazardous Event	What’s the dangerous outcome?	Driver misjudges closing speed, rear-end collision
Severity (S)	How bad is the injury?	S3 — life-threatening possible
Exposure (E)	How often does the scenario occur?	E4 — highway driving, frequent
Controllability (C)	Can the driver recover?	C2 — driver may not notice in time
ASIL	Combined rating	ASIL D

HARA produces Safety Goals: high-level statements like “The displayed vehicle speed shall not deviate from actual speed by more than X under defined conditions.” Each safety goal carries an ASIL tag. Always start from the hazard, never from the bug report.

ASIL Derivation: S × E × C

ASIL is not a vibe check. It’s a lookup from three independent ratings defined in ISO 26262 Part 3. Severity (S) runs S0–S3, measuring how bad the injury would be — S0 means no injury, S3 means life-threatening or fatal. Exposure (E) runs E0–E4, measuring how often the scenario occurs — E0 is incredible, E4 is high probability. Controllability (C) runs C0–C3, measuring whether the driver can recover — C0 is controllable in general, C3 is difficult or uncontrollable.

The standard provides a lookup table. You don’t multiply numbers yourself. High S + high E + low C → ASIL D. Moderate combinations → ASIL C, B, A. If the combination falls below the table threshold → QM (Quality Managed, no safety case required).

ASIL	Mnemonic	Typical Cockpit Examples
QM	Quality Managed (no safety requirement)	Spotify, Wi-Fi hotspot, app store UI
ASIL A	Almost casual	Ambient lighting feedback
ASIL B	Be careful	Exterior lighting coordination
ASIL C	Critical attention	ADAS warning overlays
ASIL D	Deadly if wrong	Speed display, brake telltales, steering torque overlay

Remember S-E-C as Severity, Exposure, Controllability: how bad, how often, can the driver recover? ASIL letters go A→D like grades, but D is the honor roll (most rigorous, not a fail).

Mental Model

ISO 26262 is a building permit office for software. HARA is the inspector asking “What happens if this wall falls?” ASIL is the construction code tier — a garden shed (QM) vs. a hospital (ASIL D). You can’t slap hospital code on a shed, and you can’t run a hospital in a shed. The hypervisor is the fire-rated wall between tenants.

The Requirements Cascade

Once safety goals exist, they decompose through three layers, each more implementation-specific:

flowchart TD
    SG["Safety Goals<br/>(HARA output)<br/>'Speed display shall be accurate'"]
    FSR["Functional Safety Requirements<br/>'Speed signal validated within 100ms'"]
    TSR["Technical Safety Requirements<br/>'Gateway CRC-checks CAN frame 0x123<br/>Cluster renders from QNX compositor only'"]
    IMP["Implementation<br/>QNX gateway service · watchdog · redundant path"]

    SG --> FSR --> TSR --> IMP

Layer	Owned By	Example
Safety Goal	OEM safety team	“Prevent unintended acceleration display”
Functional Safety Requirement (FSR)	System architect	“Speed source shall have plausibility check against wheel ticks”
Technical Safety Requirement (TSR)	Software integrator	“VHAL speed property rejected if delta > 15 km/h from redundant source”
Implementation	You	Gateway code, unit tests, integration tests, FMEA evidence

Every layer inherits the ASIL of its parent. An ASIL D safety goal produces ASIL D FSRs and TSRs. You cannot “downgrade” rigor without formal decomposition (next section).

The cascade runs Goals → Functional → Technical → Implementation, like zooming from Google Maps (city) to Street View (your commit).

ASIL Decomposition: Splitting the Burden

Building everything at ASIL D is expensive: redundant hardware, formal methods, exhaustive testing. ASIL decomposition lets you split one ASIL D requirement into two (or more) lower-ASIL elements if you prove independence.

Classic pattern: ASIL D = ASIL B(D) + ASIL B(D)

The (D) suffix means “decomposed from D.” Each element is developed at ASIL B with freedom from interference between them, but integration evidence still carries D-level rigor. A typical decomposition splits speed validation across three ASIL B(D) elements: Speed source A provides the primary CAN signal with plausibility check; Speed source B offers an independent wheel-tick calculation; and a Comparator cross-checks both sources and enters a safe state on disagreement.

Independence must be demonstrated: separate software paths, separate CPUs or cores, no shared mutable state without protection. The hypervisor partition boundary is often part of this evidence.

Common Gotcha

ASIL decomposition is not a loophole. You can’t declare your cluster app “QM” and call it done because QNX is ASIL D. Decomposition requires explicit independence analysis, interface FMEA, and evidence that failure of one element cannot corrupt the other. Auditors will ask for the decomposition rationale document, not your opinion.

QNX Host = ASIL D, AAOS Guest = QM

This is the architecture you’ve been debugging. The hypervisor and safety VM run QNX Neutrino + QHEE as an ASIL D foundation — a certified SEooC with deterministic scheduling and FFI enforcement. The infotainment VM runs AAOS (Linux) at QM, handling apps, media, and navigation with no safety case on the OS itself. The modem subsystem (AMSS/MPSS) follows a separate safety and security analysis path — it is not a hypervisor guest and carries its own TARA and update path.

QNX carries third-party assessed ASIL D certification as a Safety Element out of Context (SEooC). The OS vendor provides safety manuals, WCET analysis support, and integration guidelines. Your team still certifies how you use it: which processes run where, what crosses the VM boundary, what happens on failure.

AAOS is QM by design. Google does not certify Android Automotive as ASIL anything. Safety-critical telltales and vehicle data validation happen on the QNX side; AAOS receives already-validated properties through VHAL (Module 6.3).

Freedom from Interference: The Hypervisor’s Job

Freedom from Interference (FFI) is the ISO 26262 concept that safety functions must not be corrupted by non-safety functions: not logically (bad data), not physically (memory overwrite), not temporally (CPU starvation).

The hypervisor provides FFI evidence through:

Mechanism	What It Prevents
Stage-2 memory translation	AAOS guest cannot read/write QNX safety VM RAM
CPU time partitioning	Safety VM gets guaranteed scheduling budget
Device assignment	Display layer 0 (cluster) owned by QNX, not Android SurfaceFlinger
Watchdog independence	QNX health monitor survives AAOS kernel panic
Controlled IPC only	VHAL/gRPC channels (no raw shared memory between QM and safety domains)

When a safety auditor asks “prove Spotify cannot affect the speedometer,” the answer is a chain: hypervisor memory map + VHAL server input validation + cluster rendering on QNX display pipeline + decomposition evidence. Not “we trust Android sandboxing.”

SEooC: Safety Element out of Context

A SEooC is a component developed and certified without knowing the exact vehicle it will ship in: QNX Neutrino, a pre-certified MCU abstraction layer, a generic watchdog driver. The vendor provides assumed safety requirements and integration constraints. Your project must show the SEooC’s assumptions hold in your architecture. Violating the QNX safety manual (e.g., running an uncertified driver in the safety path) can void inherited certification for that integration.

Connect the Dots

Every architecture decision in Modules 2–6 traces back to a safety argument. Module 2’s zonal vs. centralized debate? ASIL decomposition and fault containment boundaries. Module 3’s signal gateway on QNX? ASIL D TSR for validated vehicle data. Module 5’s boot chain with verified images? Safety-of-intended-function and tamper evidence. Module 6’s QNX host + AAOS guest split? FFI requirement from ISO 26262 Part 6. Module 9.2 (ISO 21434) adds the cybersecurity layer that can create new hazards if ignored.

What to remember

1. HARA first: hazards and safety goals before writing requirements.
2. ASIL = f(S, E, C): Severity, Exposure, Controllability via lookup table.
3. Cascade: Goals → FSR → TSR → Code. Each layer inherits ASIL rigor.
4. Decomposition splits ASIL D into independent lower-ASIL elements with evidence.
5. QNX = ASIL D foundation; AAOS = QM. Safety work happens on the QNX side.
6. Hypervisor = FFI enforcer: memory, time, and failure isolation between domains.

Where You'll See This

When someone asks “Can we just run the cluster in Android?”, your answer framework:

1. What’s the safety goal and ASIL? Speed/telltales are typically ASIL B–D.
2. Does AAOS carry ASIL certification? No. It’s QM.
3. What’s the FFI argument? You’d need decomposition showing Android only renders pre-validated data from a QNX safety service, which is exactly the current VHAL architecture.
4. Where’s the evidence? Safety case document, FMEA, fault injection test results. Not your Slack thread.

In bug triage, if a telltale is wrong, you’re in functional safety territory. Capture logs from QNX gateway and cluster service, not just adb logcat. Safety-related defects have severity classification and may trigger formal change control, not a casual hotfix.

Check Your Understanding

1. A HARA analysis finds: Severity S3, Exposure E4, Controllability C3 for a malfunctioning speed display. What is the typical outcome?

A. QM — infotainment functions are always QMB. ASIL D — highest rigor tier from the S-E-C combinationC. ASIL A — display functions are always low ASILD. No ASIL needed if QNX is certified

2. What does ASIL decomposition ASIL D → ASIL B(D) + ASIL B(D) require?

A. Running both elements on the same AAOS process for simplicityB. Demonstrated independence between elements so failure of one cannot corrupt the otherC. Downgrading the safety goal to QMD. Removing the hypervisor to reduce latency

3. Why is the hypervisor central to the ISO 26262 safety case on a QNX + AAOS platform?

A. It makes Android boot fasterB. It provides Freedom from Interference — hardware-enforced separation so QM guest workloads cannot corrupt ASIL safety functionsC. It replaces the need for hazard analysisD. Google requires hypervisor use in AAOS compatibility tests