QNX and safety operating systems · Bhargava Mandapati

Every cockpit consolidation project eventually hits the same wall: some content on the screen is legally required to be there, and Android cannot promise it will be. and its peers exist for exactly that gap.

The requirement that forces the issue#

What a microkernel actually changes#

QNX is a microkernel, and the architectural difference has direct safety consequences.

   MONOLITHIC (Linux, Android)          MICROKERNEL (QNX)
 
   ┌───────────────────────────┐        ┌────────────┐ ┌────────────┐
   │        applications       │        │    apps    │ │  drivers   │
   ├───────────────────────────┤        │ user space │ │ user space │
   │  drivers │ fs │ net │ mm  │        └──────┬─────┘ └──────┬─────┘
   │        KERNEL SPACE       │               │ message      │
   └───────────────────────────┘        ┌──────┴──────────────┴─────┐
                                        │  microkernel: scheduling, │
   a bad driver panics                  │  IPC, memory protection   │
   the whole system                     └───────────────────────────┘
 
                                        a bad driver is a process
                                        that can be restarted

What "certified" actually means#

This phrase gets used loosely, so be precise about what is being bought.

In plain terms

An ISO 26262 certification for an OS is not a claim that the software has no bugs. It is a package of evidence that:

The development process followed the standard — requirements traced to code, code traced to tests.
Coverage targets were met at the levels the requires (MC/DC coverage at ASIL D, not merely line coverage).
Known defects are documented with analysed impact, not quietly fixed.
A safety manual states exactly how the OS must be configured to remain within its certified envelope, and what the integrator is still responsible for.
An independent assessor reviewed the whole package.

You are buying an argument you do not have to construct, and a supplier who will stand behind it. On a programme where building that argument yourself would take years, that is the entire value proposition.

Gotcha

Certification is conditional. The safety manual will say things like "the following filesystem is not certified" or "this scheduling mode is out of scope". Step outside the envelope and the certificate does not cover you.

Teams have discovered late that the configuration they shipped was not the configuration that was certified. Read the safety manual early, and treat its constraints as requirements rather than suggestions.

The safety island pattern#

Here is how QNX and Android actually coexist, and it is the pattern you will meet in almost every consolidated cockpit.

One SoC, partitions with different safety levels — The hypervisor enforces freedom from interference: Android cannot starve, corrupt or delay the safety partition, whatever it does.

The alternatives to QNX#

QNX has the largest share of this slot but it is not the only option.

Option	Character	Where it fits
QNX	Certified microkernel, commercial, mature tooling	Clusters, hypervisors, ADAS — the default choice
Integrity / PikeOS / VxWorks	Certified RTOS, separation-kernel heritage	Avionics-influenced programmes, very high assurance
Safety-certified Linux	Linux plus a certification package	Attractive licence story, ASIL claims are narrower
AUTOSAR Classic on an MCU	No OS in the desktop sense	Highest ASIL, small deterministic functions
Zephyr / FreeRTOS	Small open-source RTOS	Zone controllers, sensors; certification varies

Why an Android engineer should care#

You will not write QNX code. You will still hit its consequences constantly.

Boot ordering. The safety partition boots first and fast. Android boots later and slower. Anything of yours that assumes it is up early is wrong.

Resource limits are hard limits. Your partition has N cores and M megabytes, fixed by configuration. There is no borrowing from the safety partition under load. Performance work has a ceiling you cannot argue with.

You do not own the whole display. The safety overlay sits above your surfaces. A full-screen layout that assumes it can use every pixel of the cluster will be partly covered, by design.

Some properties are read-only to you for a reason. If a value originates in the safety domain, Android sees it and cannot set it. That is not a missing feature request.

Crashes are contained but visible. Android restarting is survivable, and it is also noticeable to the driver. "The partitioning protects us" is not a reason to be relaxed about stability.

What to remember

Mandatory telltales must be shown reliably, and Android carries no evidence that it can promise that.
QNX is a microkernel: drivers run in user space, a fault is contained, and the small kernel is what makes certification affordable.
Certified means a package of process, coverage and traceability evidence, plus a safety manual whose constraints you must actually follow.
The standard pattern is a safety island — certified hypervisor, fixed partitions, safety content on a hardware overlay above Android.
The property enforced is freedom from interference: Android cannot affect the safety partition, whatever it does.
Alternatives exist, and across all of them higher ASIL means smaller, simpler software.
As an Android engineer this shapes your boot order, your resource budget, your display area, and which properties you may write.

Next#

The cluster — where all of this has to be safe as well as correct.