Real-Time: What It Actually Means

TL;DR

Real-time does not mean fast. It means predictable: a task completes within a guaranteed deadline, every time. A system that averages 0.1 ms but occasionally spikes to 50 ms is worse for safety than one that always takes 1 ms. Hard real-time misses are catastrophic (brakes, airbag timing). Soft real-time misses are degradations (video frame drops). Best-effort has no guarantees (Spotify buffering). QNX is an RTOS built for determinism; Linux/Android is general-purpose and best-effort by default, which is exactly why your platform splits safety and infotainment across them.

If you’ve ever wondered why the team refuses to run the instrument cluster on Android “because it’s faster now,” this page explains the engineering reason.

Deterministic ≠ Fast

This is the single most important concept in real-time systems. Repeat it until it sticks:

A guaranteed 1 ms response beats an average 0.1 ms response with occasional 50 ms spikes.

Consider brake-by-wire. The ECU must apply hydraulic pressure within a fixed window after the pedal sensor reports input. If the system usually responds in 0.5 ms but once per hour takes 40 ms because a garbage collector paused or a kernel thread preempted your task, that’s a hard real-time failure, even though the average is excellent. So what breaks? Stopping distance.

Metric	System A	System B
Average latency	0.1 ms	1.0 ms
Worst-case latency	50 ms	1.2 ms
Suitable for ABS?	No	Yes

One way to remember: real-time asks “What’s the worst case?” not “What’s the average?”

Mental Model

Hard real-time is a train schedule — the 8:03 arrives at 8:03 or someone gets fired. A single missed arrival is a system failure. Soft real-time is a pizza delivery — 30 minutes is the goal, 45 is annoying but nobody dies. Best-effort is regular mail — it’ll get there when it gets there; no one tracks the deadline.

Three Categories of Real-Time

Hard Real-Time

Definition: Missing a deadline is a system failure, potentially loss of life or violation of safety goals.

Characteristics:

• Worst-case execution time (WCET) is analyzed and bounded
• Preemption is controlled and predictable
• Failure modes are designed and tested

Automotive examples:

• Anti-lock braking (ABS) modulation
• Airbag deployment timing
• Steering torque overlay (hands-on detection response)
• Watchdog-triggered safe state transitions
• CAN frame transmission with strict bus timing

Soft Real-Time

Definition: Missing a deadline degrades quality but does not cause catastrophic failure.

Characteristics:

• Occasional misses are tolerable
• System recovers gracefully (drop frame, skip sample, retry)
• User notices quality loss, not danger

Automotive examples:

• Instrument cluster animation (frame drop → stutter)
• Camera preview frame rate (laggy rear view)
• Text-to-speech playback (audio glitch)
• Navigation map tile loading

Best-Effort

Definition: No deadline guarantees. Throughput and average performance matter; occasional long delays are acceptable.

Automotive examples:

• Spotify streaming and buffering
• App store downloads
• Cloud voice assistant round-trips
• OTA package download in background
• Browser rendering a web page

Comparison Table

	Hard RT	Soft RT	Best-Effort
Deadline miss	Catastrophic failure	Quality degradation	Normal operation
Worst-case analysis	Required, certified	Desired, not always formal	Not required
Example OS	QNX, AUTOSAR Classic, FreeRTOS	QNX (non-safety partitions), RT Linux patches	Linux, Android (AAOS)
Automotive function	ABS, airbag, steering assist	Cluster UI, camera preview	Media apps, browser
Scheduling	Priority-based, preemptive, bounded	Priority-aware, recovery OK	CFS/fair scheduling
Your reaction to latency spike	Stop ship, root-cause, safety review	Bug ticket, UX review	User might not notice

Common Gotcha

“We tested it 10,000 times and it never missed” is not a WCET proof. Hard real-time requires analysis of all code paths, interrupt latencies, bus contention, and cache effects, not just empirical testing. Testing shows bugs; analysis bounds worst case. Both are needed for ASIL-rated functions.

Why Brakes Need Hard RT but Spotify Doesn’t

When you press the brake pedal in a modern vehicle, the signal traverses a chain:

sequenceDiagram
    participant Pedal as Brake Pedal Sensor
    participant ECU as Brake ECU / Domain Controller
    participant Actuator as Hydraulic Actuator

    Note over Pedal,Actuator: Hard RT — entire chain must complete within bounded time (e.g. < 10 ms)

    Pedal->>ECU: Pedal position (CAN/Ethernet)
    ECU->>ECU: Validate, compute pressure target
    ECU->>Actuator: Apply braking force
    Actuator-->>ECU: Ack / feedback

If any step exceeds its deadline, stopping distance increases measurably and repeatably, in a way regulators test. ISO 26262 functional safety classifies these functions by Automotive Safety Integrity Level (ASIL). Higher ASIL demands harder real-time guarantees and more rigorous evidence.

Spotify, meanwhile, buffers 5–30 seconds of audio. A 200 ms stall is invisible because the buffer absorbs it. No safety goal is violated. No ASIL applies.

Ask yourself: “What happens if this is 100 ms late?” If the answer involves injury, it’s hard RT.

Why QNX Is an RTOS and Linux/Android Isn’t

This is about design tradeoffs, not about QNX being “better.”

QNX: Microkernel RTOS

• Microkernel architecture: only essential services (scheduling, IPC, memory management) run in kernel space; drivers and services run as user-space processes
• A crashing audio driver doesn’t take down the kernel
• Priority inheritance and preemptive scheduling with bounded interrupt latency
• Designed from the ground up for deterministic response
• Used in medical devices, industrial control, and automotive safety domains

Linux / Android: General-Purpose Monolithic Kernel

• Monolithic: drivers, filesystems, networking all in kernel space
• Optimized for throughput and feature richness, not worst-case latency
• Completely Fair Scheduler (CFS) is fair, but not deadline-guaranteeing
• GC pauses in Java/Kotlin runtime add unbounded latency to userspace
• Excellent for infotainment; not certified for hard RT safety functions without significant isolation (and even then, the RT work runs elsewhere)

flowchart LR
    subgraph QNX["QNX (Microkernel RTOS)"]
        QK["Minimal kernel"]
        QD1["Driver process"]
        QD2["Safety service"]
        QD3["Display service"]
        QK --- QD1
        QK --- QD2
        QK --- QD3
    end

    subgraph Linux["Linux / AAOS (Monolithic)"]
        LK["Large kernel<br/>drivers · FS · net · GPU"]
        LA["Android framework"]
        LApps["Apps · GC · JIT"]
        LK --> LA --> LApps
    end

Can Linux Be Real-Time?

Yes, with patches. PREEMPT_RT reduces non-preemptible kernel sections and makes Linux suitable for soft real-time on embedded systems. Some teams run RT-patched Linux for non-ASIL workloads. But for ASIL-B/D safety functions, the industry standard is dedicated RTOS (QNX, AUTOSAR OS on MCUs), not AAOS with patches. The hypervisor approach lets you use both: QNX for determinism, Android for ecosystem.

Where You'll See This

This is why QNX hosts safety functions and AAOS handles infotainment on the same SoC. Not because engineers love two OSes, but because one OS cannot serve both masters.

In your daily workflow you’ll see:

• QNX VM: instrument cluster, vehicle bus gateway, camera safety overlays, watchdog services, hypervisor management. Latency-sensitive, ASIL-adjacent.
• AAOS VM: center stack, navigation, media, voice assistants, app store. Best-effort, rich ecosystem.
• Cross-VM IPC: vehicle speed, gear state, and telltales cross a boundary from QNX (deterministic source) to Android (display consumer).

When cluster rendering stutters, QNX teams investigate scheduling, GPU contention, and display pipeline timing. When Spotify stutters, nobody files a safety ticket. That organizational split maps directly to the hard/soft/best-effort taxonomy.

If someone proposes “moving the speedometer to Android for faster iteration,” your response should be: “Speedometer telltales have soft-to-hard RT requirements and a safety integrity context. What’s the WCET analysis?”

Connect the Dots

Module 1.3 (Why Isolation Matters) explains why these domains must not share an address space. Module 6.1 (QNX: The Safety Guardian) dives into QNX services you’ll actually debug. Module 9.1 (ISO 26262) formalizes the ASIL levels referenced here.

Quick Reference: Latency Budgets in Your Head

Function	RT Class	Rough Budget	OS Home
Brake pressure command	Hard	5–15 ms	MCU / QNX / AUTOSAR
Airbag fire decision	Hard	1–5 ms	Dedicated MCU
Telltale warning display	Soft–Hard	50–200 ms	QNX cluster
Rear camera frame	Soft	33 ms (30 fps)	QNX or AAOS
Touch input to UI response	Soft	50–100 ms	AAOS
Music playback	Best-effort	Seconds of buffer	AAOS

What to remember

1. Real-time means predictable, not fast.
2. Classify every function as hard, soft, or best-effort before choosing an OS.
3. QNX earns its place through determinism; AAOS earns its place through ecosystem. Neither replaces the other.
4. When in doubt, ask: “What’s the worst-case latency, and what happens if we miss?”

Check Your Understanding

1. System A averages 0.1 ms latency with occasional 50 ms spikes. System B guarantees 1.0 ms every time. Which is better for an ABS control loop?

A. System A — lower average latency winsB. System B — bounded worst case winsC. Neither — both are equivalent for ABSD. System A — spikes are rare enough to ignore

2. Which automotive function is best classified as best-effort (not real-time)?

A. Airbag deployment timingB. Instrument cluster telltale updateC. Spotify audio streaming with bufferD. Rear camera preview at 30 fps

3. Why does a typical cockpit platform run QNX and AAOS on separate VMs instead of one Linux with RT patches?

A. QNX is free and Android is expensiveB. Safety-critical functions need deterministic scheduling and isolation; AAOS provides app ecosystem for non-safety infotainmentC. Android cannot access the GPU on Qualcomm SoCsD. QNX runs only on the modem subsystem