Why Isolation Matters

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? This page answers that. It’s one of the most important concepts in automotive software.

Common Gotcha

“Android is Linux, and Linux has cgroups. Isn’t that enough isolation?” No. cgroups are a best-effort resource limiter, not a safety-certified partition boundary. A kernel exploit or driver bug in AAOS bypasses cgroups entirely. Safety isolation requires hypervisor-level separation with hardware memory protection, which is why QNX Hypervisor (QHEE) exists.

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, no sprinkler required. A hospital (ASIL D) has fire doors, sprinkler systems, backup generators, and inspected evacuation routes. 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.

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	An 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. Spotify playback stops working after an AAOS update. The instrument cluster and brake functions continue normally. This demonstrates:

A. A hypervisor failure that needs immediate escalationB. Correct isolation — QM domain failure contained, safety domains unaffectedC. A CAN bus fault affecting only media signalsD. An ASIL-D violation requiring a recall

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

A. Android doesn't support CAN driversB. CAN bus speed is too slow for AndroidC. Brake functions are ASIL-D; AAOS is QM — direct access would violate Freedom from Interference requirementsD. The CAN transceiver is physically connected only to QNX

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

A. ASIL A = hospital, ASIL D = garden shedB. QM = no fire code needed, ASIL D = maximum fire protection requirementsC. ASIL B = no safety requirements, QM = highest rigorD. All ASIL levels require identical safety processes