Real-Time: What It Actually Means

Intermediate9 min read

Assumes: 0.1 Anatomy of an SoC

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 been in a meeting where someone said “let’s just run the cluster on Android, it’s fast enough now,” this page is your ammunition for why that sentence makes safety engineers break out in hives.

Deterministic ≠ Fast

This is the single most important concept in real-time systems. Tattoo it on your forearm if needed:

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 decided to tidy up, that’s a hard real-time failure — even though the average is excellent. The brakes don’t care about your p99 latency. They care about the p100.

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 live TV broadcast — the 8 PM news starts at 8 PM. Not 8:00:01. A single late frame and millions of viewers see a black screen. Someone’s getting a call from management. Soft real-time is a pizza delivery — 30 minutes is the promise, 45 is annoying, but nobody dies and you still eat. Best-effort is regular mail — it’ll get there when it gets there; tracking says “in transit” for a week and everyone accepts this as normal.

Mnemonic: Hard = deadline is death. Soft = deadline is a bruise. Best-effort = deadline is a vague suggestion your system politely ignores.

Think About It

Your brake-by-wire system responds in under 50 ms, 95% of the time. Your manager calls it “real-time.” Your safety engineer just spit out their coffee. Who’s right, and why?

Reveal Answer

The safety engineer wins this one (they usually do). Hard real-time is defined by bounded worst-case latency (WCET), not percentile averages. The 5% of responses that exceed the deadline are deadline misses; in brake-by-wire, even one 50 ms spike measurably increases stopping distance and fails safety goals. Hard RT requires provable worst case under all preemption, cache, and bus contention — typically 5–15 ms with formal WCET analysis, not “95% good enough.” This system is at best soft real-time or non-compliant for an ASIL-rated braking function. Tell your manager; bring snacks.

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

Beginner thinks 10,000 successful test runs prove hard real-time compliance. If only engineering were that easy — we’d all just run tests until the graph looked nice.

Reality: that’s 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. Your 10,001st run might be the one that misses.

Common Gotcha

If you port a safety-critical function from QNX to AAOS “because latency looks fine in profiling,” you’ve just inherited Linux’s entire unbounded worst-case collection. It’s like moving from a house with fire alarms to one without, because “we’ve never had a fire.”

A single GC pause, kernel preemption, or I/O stall can blow a 10 ms deadline that averages 0.5 ms. Safety reviewers will reject the port unless you can prove WCET — not average-case — compliance.

Why Brakes Need Hard RT but Spotify Doesn’t

Now let’s see what happens when these categories hit the real world — starting with the scariest example.

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. Spotify doesn’t even know what WCET stands for, and it doesn’t need to.

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?

Applied

A. System A — the 50 ms spikes occur too rarely to affect braking safetyB. System B — bounded worst-case latency is what hard RT requiresC. Neither — both are equivalent for ABS since spikes are statistically rareD. System A — lower average latency always wins for braking performance

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

Recall

A. Spotify audio streaming — seconds of buffer absorb any scheduling delay invisiblyB. Airbag deployment timing — fire decision within a bounded 5 ms safety windowC. Rear camera preview — maintaining consistent 30 fps for the backup camera viewD. Instrument cluster telltale update — driven by a QNX real-time display service

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

Applied

A. QNX is open-source and free; Android licensing costs make a dual-VM setup financially necessaryB. QNX runs exclusively on the modem subsystem and cannot host display or cluster workloadsC. Android cannot access the Adreno GPU directly when running alongside QNX on the same SoCD. Safety functions need deterministic QNX scheduling; AAOS handles infotainment with its app ecosystem

4. In automotive real-time terminology, what does 'real-time' actually mean?

Recall

A. The system completes tasks within guaranteed deadlines — predictability over raw speedB. The system responds as fast as possible on average — minimum latency is the primary goalC. The system uses a real-time clock (RTC) to schedule all tasks and maintain timing accuracyD. The system runs at the highest available CPU frequency to minimize all processing delays

5. Your team profiles a telltale warning service on AAOS and sees 0.5 ms average latency with occasional 15 ms GC pauses. A safety reviewer flags the design. What is the correct engineering response?

Applied

A. Ship it — 0.5 ms average exceeds the 200 ms budget, so the safety margin is more than sufficientB. Add more Kryo cores — increased parallelism will reduce the frequency of GC pause eventsC. Switch from CAN to Ethernet — lower bus latency eliminates the GC impact on the display pathD. Reject the port — AAOS inherits unbounded worst-case from GC; telltales need WCET on QNX

6. An OEM proposes running the speedometer telltale renderer on AAOS 'for faster iteration,' with vehicle speed delivered via SOME/IP from a QNX gateway. The QNX side has proven WCET. Is this sufficient for ASIL-adjacent display requirements?

Synthesis

Connects to: Module 9 — Safety, Security & Diagnostics · Module 3 — Signals to Services

A. Yes — SOME/IP guarantees deterministic delivery, making the rendering VM's latency irrelevantB. No — AAOS adds unbounded GC and compositor latency; ASIL evidence needs the full path's WCETC. No — speed data must travel over CAN only; SOME/IP is not accepted for ASIL-rated signal pathsD. Yes — QNX provides proven WCET for speed data, so the AAOS display path is automatically safe

Further Reading

• QNX Neutrino RTOS — Real-Time Operating System — Official QNX RTOS product page covering microkernel architecture, priority scheduling, and automotive safety use cases.
• QNX OS for Safety Documentation — Safety-certified QNX variant documentation relevant to hard real-time and ASIL-rated deployments on cockpit platforms.
• AUTOSAR Classic Platform — OS Specification — AUTOSAR Classic OS evolved from OSEK/VDX and defines the priority-based scheduling semantics still used on deterministic MCU ECUs.
• ISO 26262 — Road vehicles — Functional safety — Functional safety standard defining ASIL levels and WCET analysis requirements referenced for hard real-time functions.
• PREEMPT_RT — Real-Time Linux Patch Set — Linux Foundation documentation on making Linux suitable for soft real-time via preemptible kernel patches.
• Hard Real-Time Computing Systems (Buttazzo, Springer) — Classic textbook on schedulability analysis, WCET bounding, and hard vs soft real-time classification.
• FreeRTOS — Real-Time Kernel for Embedded Systems — Widely used open-source RTOS on automotive MCUs; illustrates priority-preemptive scheduling concepts shared with OSEK/AUTOSAR OS implementations.