Why Isolation Matters

Intermediate9 min read

Assumes: 1.2 ECU Basics & Vehicle Networks

TL;DR

Modern cockpit SoCs run mixed-criticality workloads on shared silicon: life-critical brake signals alongside nice-to-have Spotify playback. ISO 26262 ASIL levels (A through D) classify how rigorously each function must be engineered. QM (Quality Managed) means no safety requirement; that’s where AAOS lives. Guaranteed separation between safety and non-safety domains is mandatory, not optional. This is the entire motivation for hypervisors, partitioning, and multi-OS architecture, and why your platform runs QNX + AAOS instead of just Android.

You’ve seen the QNX VM and the Android VM on the same chip. Maybe you’ve wondered: why not just one OS? Surely Android can handle brakes, right? (Narrator: it cannot.) This page answers that question, and it’s one of the most important concepts in automotive software — the reason your phone doesn’t control your steering.

Common Gotcha

Beginner thinks Android is Linux, and Linux cgroups provide enough isolation for safety workloads. After all, containers work great in the cloud, right?

Reality: cgroups are a best-effort resource limiter, not a safety-certified partition boundary. A kernel exploit or driver bug in AAOS bypasses cgroups like a VIP skipping the line. Safety isolation requires hypervisor-level separation with hardware memory protection — which is why QNX Hypervisor (QHEE) exists. Containers isolate microservices; hypervisors isolate lives.

Common Gotcha

If you route a safety-critical signal through AAOS first (instead of QNX → VHAL → AAOS), an Android crash can take down telltales or cluster rendering.

Mixed-criticality means the safety path must never depend on the QM domain’s uptime. Always trace: safety ECU → QNX safety VM → (optional bridge) → AAOS.

Mixed-Criticality: Two Worlds, One Chip

Mixed-criticality means running functions with radically different safety consequences on shared hardware.

Function	Consequence of Failure	Criticality
Brake assist / ABS	Injury or death	Life-critical
Instrument cluster speed display	Driver misinformed, potential accident	Safety-related
Spotify playback	Silence	Nice-to-have
Navigation map rendering	Wrong turn, inconvenience	Low safety impact
Rear camera display	Collision while reversing	Safety-related

On a Qualcomm cockpit SoC, all of these share the same silicon: same CPU cores, same memory controller, same interconnect. The brake signal doesn’t get its own physical chip anymore. It gets software-enforced isolation instead.

This is the central tension of modern automotive architecture: consolidate for cost and performance, isolate for safety.

ASIL Levels: A Preview

ASIL (Automotive Safety Integrity Level) comes from ISO 26262, the functional safety standard for road vehicles (Module 9 goes deep). ASIL classifies how rigorously a function must be developed based on three factors:

• Severity: how bad is the outcome? (S0–S3)
• Exposure: how often does the scenario occur? (E0–E4)
• Controllability: can the driver recover? (C0–C3)

These combine into four levels:

ASIL	Intuitive Meaning	Example Functions	Development Rigor
QM	Quality Managed (no safety requirement)	Infotainment UI, media apps, Wi-Fi hotspot	Standard software QA
ASIL A	Lowest safety integrity	Rear wiper, interior ambient lighting	Basic safety process
ASIL B	Moderate	Exterior lighting, cruise control display	Formal safety lifecycle
ASIL C	High	Adaptive cruise, lane departure warning	Rigorous verification & validation
ASIL D	Highest (maximum rigor)	ABS, airbag deployment, steer-by-wire, BMS thermal protection	Exhaustive analysis, redundancy, formal methods

ASIL letters go A → D like grades, but D is the best (most rigorous), not a failing grade. QM is “off the scale,” below A, meaning no safety case required.

Mental Model

ASIL is like a building fire code rating. A shed (ASIL A) has basic rules — smoke detector optional, maybe a fire extinguisher if you’re feeling responsible. A hospital (ASIL D) has fire doors, sprinkler systems, backup generators, inspected evacuation routes, and a compliance officer who hasn’t smiled since 2003. You wouldn’t run a hospital in a garden shed, and you wouldn’t apply hospital building codes to a shed. Same chip, different rules — enforced by partitioning.

Mnemonic: Spotify crashing should never affect the speedometer. If it does, someone skipped the isolation chapter. (Don’t be that someone.)

Think About It

Your Spotify streaming app crashes hard — null pointer. What should happen to the instrument cluster?

Reveal Answer

Nothing — the cluster must keep displaying speed, telltales, and warnings normally. Spotify runs in the QM AAOS VM; the instrument cluster runs in a separate QNX safety VM (ASIL B) behind hypervisor isolation. An AAOS crash triggers failure containment: the infotainment VM may restart, but the cluster VM never shares memory or execution with it — that is Freedom from Interference working as designed.

Why Guaranteed Separation Is Mandatory

Here’s the scenario that keeps safety engineers awake:

A third-party Android app has a memory corruption bug. It writes past its buffer into shared memory. That memory happens to hold brake controller state. The brakes fail.

Without isolation, this isn’t a hypothetical. It’s a regression waiting to happen. Android’s security model (app sandboxing, permissions) was designed for phones, not safety-critical actuators.

Guaranteed separation means:

1. Memory isolation: AAOS apps cannot read or write QNX safety domain memory (hardware-enforced via MMU/Stage-2 translation in the hypervisor)
2. Temporal isolation: safety tasks get guaranteed CPU time; Android cannot starve the brake signal handler (hypervisor scheduling)
3. Failure containment: if Android crashes, QNX and safety VMs keep running
4. Independent watchdog: safety domain monitors its own health without trusting the infotainment domain

ISO 26262 requires evidence that safety functions are free from interference by non-safety functions, a concept called Freedom from Interference (FFI).

QM: Where AAOS Lives

QM (Quality Managed) is not an ASIL level. It’s the classification for functions with no safety requirement under ISO 26262.

If a function fails and the worst credible outcome is “user is annoyed,” it’s QM. That includes:

• Media playback (Spotify, radio)
• Navigation UI (the map, not the underlying speed signal)
• App store and third-party apps
• Wi-Fi hotspot and Bluetooth pairing
• Voice assistant (non-safety commands)

AAOS runs in the QM domain. This is a feature, not a limitation. It means AAOS can use standard Android development practices, accept third-party apps, and iterate quickly without a full ISO 26262 safety case for every APK.

The trick is drawing the boundary correctly:

Component	Typical ASIL	Runs On
Speed signal acquisition from CAN	ASIL B	QNX gateway
Speed display on instrument cluster	ASIL B	QNX (cluster VM)
Speed overlay on navigation map	QM	AAOS
Spotify playback	QM	AAOS
Brake pressure control	ASIL D	Dedicated ECU or QNX safety VM
Rear camera video pipeline	ASIL B	QNX (camera VM)
Rear camera UI overlay graphics	QM	AAOS (receives processed frames)

If a user could say “that’s annoying but I’m not dying” when it fails, it’s QM. If they’d say “that’s dangerous”, it’s ASIL something.

The Multi-OS Architecture: Why QNX + AAOS

The isolation requirements above directly explain your platform architecture:

flowchart TB
    subgraph HW["Qualcomm SoC (Shared Silicon)"]
        subgraph HYP["QNX Hypervisor (QHEE)"]
            subgraph SAFETY["Safety / Real-Time Domain"]
                QNX_RT["QNX RTOS<br/>ASIL B–D functions"]
                CLUSTER["Instrument Cluster VM"]
                GATEWAY["CAN/Ethernet Gateway"]
                CAMERA["Camera Pipeline VM"]
            end
            subgraph QM_DOMAIN["QM Domain"]
                AAOS_VM["AAOS (Android)<br/>QM functions"]
                APPS["Third-Party Apps<br/>Spotify · Nav · Voice"]
            end
        end
    end

    CAN["Vehicle CAN Bus<br/>(ASIL-D brake ECU)"] --> GATEWAY
    GATEWAY -->|"Isolated IPC / VirtIO"| AAOS_VM
    QNX_RT --> CLUSTER
    CAMERA -->|"Processed frames"| AAOS_VM
    AAOS_VM --> APPS

Each box is a separate virtual machine with:

• Dedicated memory regions: hardware-enforced, no shared pages
• Dedicated vCPU cores: pinned to physical cores with scheduling guarantees
• Separate boot and update paths: QNX IFS and Android partitions flash independently
• Separate crash domains: AAOS reboot doesn’t take down the cluster

Freedom from Interference (FFI) in Practice

ISO 26262 requires demonstrating Freedom from Interference: proving that a lower-ASIL or QM component cannot corrupt a higher-ASIL component. Evidence includes memory protection unit (MPU/MMU) configuration audits, worst-case execution time (WCET) analysis for safety tasks, hypervisor scheduling analysis, and fault injection testing. This is why you can’t simply “move cluster to Android.” The safety case for the speed display depends on QNX’s certified isolation properties.

What This Means for Hypervisors and Partitioning

The hypervisor is a safety mechanism, not a convenience. Specifically:

Mechanism	What It Does	Why It Matters
Stage-2 MMU	Hypervisor controls guest OS memory access	AAOS physically cannot touch QNX memory
vCPU pinning	Safety VMs get dedicated physical cores	Android jitter doesn’t delay brake signal processing
VirtIO channels	Controlled data sharing between VMs	Speed signal crosses the boundary through an audited IPC path, not shared memory
Independent watchdog	Each VM has its own health monitor	QNX detects AAOS hang without relying on AAOS
Separate update domains	QNX and AAOS flash independently	A bad Android OTA can’t brick the safety stack

Module 5 covers the Qualcomm hypervisor (QHEE) implementation. Module 6 covers how QNX and AAOS coexist in practice. Module 9 covers the ISO 26262 standard that mandates all of this.

Connect the Dots

This is why your platform runs QNX + AAOS instead of just one OS.

• Module 0 gave you the SoC hardware: one chip, many blocks.
• Module 1.2 gave you the vehicle networks: signals from ASIL-D ECUs arriving at your gateway.
• This page explains why those signals must be handled by QNX, not Android, and why AAOS handles everything else.
• Module 5 shows how the hypervisor implements this separation on SA8155P/SA8295P.
• Module 6 shows what runs where: QNX cluster, QNX gateway, AAOS infotainment.
• Module 9 formalizes the ISO 26262 standard that requires it all.

The short version

1. Mixed-criticality: life-critical and nice-to-have functions share the same silicon; isolation replaces physical separation.
2. ASIL A–D classifies safety rigor; QM means no safety requirement (where AAOS lives).
3. Freedom from Interference is mandatory. A Spotify bug must not affect brakes.
4. Hypervisor + multi-OS (QNX + AAOS) is the architectural response, not a vendor preference.

Where You'll See This

You’ll see isolation decisions in everyday work:

• “Can we run cluster on Android?” No. Cluster is ASIL B; Android is QM. The hypervisor boundary exists for this reason.
• VHAL as a controlled bridge: AAOS reads vehicle speed through VHAL (an audited IPC path), never directly from CAN hardware.
• Separate flash partitions: QNX IFS and Android images update independently; a bad AAOS OTA must not corrupt QNX.
• VM crash debugging: AAOS reboots while cluster keeps running? That’s isolation working, not failing.
• Core pinning in device tree: safety VMs pinned to specific Kryo cores; don’t move them without safety team review.

When integrating a new AAOS feature that touches vehicle signals, always ask: “What’s the ASIL of the signal source, and am I crossing a partition boundary?”

Check Your Understanding

1. Using the building fire code analogy, which pairing is correct?

Recall

A. ASIL A equals hospital-grade fire safety; ASIL D equals garden shed rulesB. Every ASIL level requires identical safety processes, evidence, and test depthC. ASIL B means zero safety requirements; QM demands the highest engineering rigorD. QM means no fire code needed; ASIL D means maximum fire protection requirements

2. Spotify playback stops working after an AAOS update. The instrument cluster and brake functions continue normally. This demonstrates:

Recall

A. Correct isolation — QM domain failure is contained; safety domains unaffectedB. A hypervisor fault that warrants immediate safety-team escalation and reviewC. A CAN bus signal routing fault affecting only the media-related ECU clusterD. An ASIL-D compliance violation that legally requires a vehicle safety recall

3. Why can't AAOS (Android) directly read brake pressure from the CAN bus?

Applied

A. CAN bus baud rate is too slow for Android's userspace scheduling modelB. Android's kernel lacks hardware drivers for automotive CAN transceiversC. Brakes are ASIL-D and AAOS is QM — direct access violates FFI rulesD. The CAN transceiver is physically wired only to the QNX processor cores

4. Per the ASIL boundary table on this page, where should vehicle speed acquisition from CAN run, and where should a speed overlay on the navigation map run?

Applied

A. Speed acquisition on QNX gateway (ASIL B); nav map overlay in AAOS (QM)B. Speed acquisition in AAOS via VHAL; cluster display also rendered by AAOSC. Both run on AAOS — vehicle speed is just a numeric value shown in two placesD. Both run on QNX — Android fundamentally cannot display numeric data values

5. Android jitter causes occasional 200 ms UI freezes in the infotainment VM. Safety engineers are unconcerned. Which hypervisor mechanism ensures brake signal processing in the QNX safety VM is unaffected?

Applied

A. Android cgroups throttle CPU usage for misbehaving background app processesB. vCPU pinning gives safety VMs dedicated cores with guaranteed schedulingC. Shared memory regions between VMs provide lower-latency IPC data transferD. Both OSes share one vCPU with fair round-robin time-slicing by the kernel

6. An integrator proposes reading ABS wheel-speed CAN frames directly in AAOS to reduce latency for a nav app. Safety review rejects it. Best architectural alternative satisfying Freedom from Interference?

Synthesis

Connects to: Module 6 — VHAL

A. Downgrade the ABS ECU from ASIL-D to QM so Android can read it freelyB. QNX gateway reads CAN with E2E, exposes sanitized speed via VHAL IPCC. Grant AAOS a raw socketcan driver on the shared CAN hardware interfaceD. Route CAN frames through the AMSS modem to cloud, then back via LTE

Module Review: Why Cars Became Computers

Question 1 of 10

After an AAOS OTA, Spotify and navigation crash but cluster and telltales continue normally. A colleague files a P1 safety ticket. Your response?

🔗 Connects to: Module 6 — QNX + AAOS Coexistence

A. Reflash QNX IFS because the hypervisor must have corrupted QNX heap memoryB. Close as working-as-designed: QM failure contained; safety domains unaffectedC. Roll back the OTA image and permanently disable future AAOS OTA updatesD. Escalate immediately — every post-OTA crash is a safety event by definition

Further Reading

• ISO 26262 — Road vehicles — Functional safety — Core functional safety standard defining ASIL levels, Freedom from Interference, and mixed-criticality requirements referenced throughout this page.
• ARINC 653 — Avionics Application Software Standard Interface — Foundational partitioned RTOS standard that influenced automotive hypervisor and temporal/memory isolation concepts.
• QNX Hypervisor (QHEE) — Official QNX hypervisor product documentation covering Stage-2 MMU, vCPU pinning, and VM isolation on shared SoC silicon.
• QNX OS for Safety — Product Overview — Safety-certified QNX variant used for ASIL-rated functions in the safety domain of multi-OS cockpit platforms.
• AUTOSAR — Guidelines for Freedom from Interference — AUTOSAR Classic guidance on demonstrating FFI between software elements at different ASIL levels.
• ARM TrustZone and Virtualization Extensions — ARM documentation on hardware memory protection mechanisms that hypervisors use to enforce partition boundaries.
• Mixed-Criticality Systems (Baruah, Burns & Davis — IEEE) — Foundational academic paper on scheduling and partitioning mixed-criticality workloads on shared processors.