Developing Dependable Linux Systems
Applying Industry Standards (ASIL B/D)
When Renesas and Continental started shipping Linux-based ADAS controllers in production vehicles, the question stopped being “can Linux handle safety-critical workloads?” and became “exactly how do you make it meet ASIL B?” The answer is not a single patch or a kernel config flag. It’s an architecture decision made at every layer of the stack, backed by documented evidence that your system behaves predictably when hardware fails.
ISO 26262 defines four Automotive Safety Integrity Levels—ASIL A through ASIL D—based on severity, exposure, and controllability. ASIL D is the highest tier: brake-by-wire, steering controllers, airbag deployment logic. ASIL B covers advanced driver assistance features, lane-keeping assist, adaptive cruise. The standard does not care whether your software is written in C or Rust. It cares whether you can prove, with measurement data, that your system detects faults and transitions to a defined safe state before the fault causes harm.
Linux out of the box is not ASIL-certified. It was never designed to be. What PREEMPT_RT buys you is bounded worst-case interrupt latency—typically under 100 µs on modern x86-64 with a properly tuned kernel—and that bounded latency is the foundation every higher-level safety argument rests on. Without it, a QM (Quality Managed, uncertified) driver holding a spinlock can delay your safety monitor thread by an unbounded duration. On a vanilla 6.8 kernel under load, that latency can exceed 10 ms.
