TN-21 · 2026-09-12 · XiL Domain Series · Part 7

Three Views of Functional Safety: ASIL, the Safety MCU, and NCAP

One word, “safety,” is governed by at least three different things in the auto industry: ISO 26262 grades risk and sets the rules for development and testing; an unremarkable little chip inside the domain controller provides the physical backstop; and NCAP translates “safety” into star ratings and scenarios that consumers can understand. All three share the same goal — the car must not hurt people — but they speak in entirely different dialects. This article walks through each view, then assembles them into one picture.

1. ASIL: The Higher the Risk, the Stricter the Rules (the Standards View)

ASIL (Automotive Safety Integrity Level) is how ISO 26262 grades functional-safety risk, answering one question: if this function fails, can it kill someone? How badly? — the higher the risk, the stricter the development and testing rules.

How the level is set: the three HARA factors

It’s not guesswork — it’s scored by Hazard Analysis and Risk Assessment (HARA), combining three dimensions via lookup tables:

1. S (Severity): how bad are the injuries if it fails? S0, no injuries, up to S3, fatal;
2. E (Exposure): how common is this operating scenario? E0, almost never happens, up to E4, high-frequency daily;
3. C (Controllability): can the driver recover when it fails? C0, controllable, up to C3, hard to control.

An example: AEB falsely triggering at highway speed (full braking when nothing is wrong) — high S (a rear-end pileup can kill), high E (highway driving is a daily occurrence), medium-high C (the driver can’t take over in a split second) → it typically lands at C or even D. That’s why ADAS features carry such heavy test-evidence requirements. Note what exposure does: the same failure mode earns a different level on the highway than in a parking lot.

What the level means: not an honor, but the strictness of the rules

• Process: ASIL D demands stricter reviews and independent verification (the people who test must not be the people who develop);
• Coverage: structural coverage for unit tests is tiered — ASIL D requires MC/DC (Modified Condition/Decision Coverage: every condition must independently affect the decision outcome, one notch stricter than branch coverage), with the requirement relaxing step by step down to branch coverage and statement coverage;
• Tool qualification (TCL): high ASIL requires arguing that “your tools won’t silently introduce or miss errors” — the test platform itself gets a TCL assessment, and the requirement–case–verdict chain must be preserved;
• Traceability: requirement → case → result must be traceable in both directions, and you must be able to produce it in an audit.

Don’t confuse the two neighbors

• ASIL (ISO 26262, functional safety): governs “what happens when the system breaks (faults/failures)”;
• SOTIF (ISO 21448, Safety of the Intended Functionality): governs “the system hasn’t broken but isn’t capable enough” (perception misses, algorithm boundaries) — in the ADAS era you need both.

2. The Safety MCU: The Safety Island That Backstops the Domain Controller (the Architecture View)

ASIL sets “how strict the rules are,” but landing them in hardware runs into an unavoidable problem: the main SoC of an ADAS domain controller can’t achieve ASIL D, while braking and steering commands require ASIL D. The industry’s standard solution: bolt on a “small but trustworthy” gatekeeper — the safety MCU, a.k.a. the safety island — and hand it the final signing authority.

Five reasons it can’t be omitted

1. An SoC is too complex to argue safe. An Orin- or Snapdragon-Ride-class SoC has tens of billions of transistors: multi-level caches, cache coherence, GPU/NPU shared memory, complex power management — each one a nightmare for arguing away systematic and random hardware failures. In practice, the SoC itself usually only achieves ASIL B, while an AEB brake request or L2 steering control is ASIL C/D. The solution is ASIL decomposition: the SoC (ASIL B) computes, the safety MCU (ASIL D) reviews, and the system as a whole earns ASIL D.

2. “Statistically low jitter” ≠ “demonstrable determinism.” Linux + PREEMPT_RT can squeeze worst-case latency down to tens of microseconds — but that’s a statistical result; nobody can vouch for every execution path through millions of lines of kernel code. The safety MCU runs AUTOSAR CP or a bare-metal static schedule: small codebase, no dynamic memory, no complex drivers, so every path’s worst-case execution time (WCET) is analyzable and can be written into the safety manual. ASIL D wants the latter.

3. The monitor must be independent of the monitored (common-cause failure). If the monitoring thread runs on the SoC, one power glitch, memory-controller fault, or deadlock kills monitor and business together — which equals no monitoring at all. The safety MCU has its own power domain, its own clock, its own watchdog, and it unidirectionally holds the SoC’s reset line — it can restart the SoC; the SoC has no right to touch it.

4. SoCs crash and reboot; the car can’t be left unattended. Linux takes seconds to tens of seconds to boot, and a kernel panic mid-drive is a real scenario. The safety MCU is up within milliseconds of power-on and stands watch through every gap — SoC boot, crashes, OTA reflash reboots: maintaining basic safety functions, executing the minimal risk maneuver (MRM), turning on warning lights. Regulation has a matching scenario: the rear-view camera image must be available within 2 seconds of reverse engagement (FMVSS 111).

5. The actuator’s “last mile” needs deterministic IO. The CAN frames sent to the brake ESP and steering EPS must have hard-deterministic timing. An MCU carries native CAN FD controllers, so the transmit instant is demonstrable; an SoC sending CAN goes through Ethernet/PCIe bridges with uncontrollable latency jitter. Hence an unwritten industry rule: safety-relevant outputs must be signed off by the MCU — what the SoC computes is only a “proposal”; it becomes a “command” only after the MCU approves it.

The safety island’s duty roster

• Heartbeat monitoring: receives periodic heartbeats from the SoC and key applications; a timeout is a death verdict (typically on the order of 100 ms);
• Sanity checks: physical-feasibility checks on the SoC’s steering-angle and deceleration outputs (range, rate of change); anything insane is vetoed;
• Minimal risk maneuver (MRM): after a death verdict it takes over — hold the lane, brake gently, pull over, warn;
• Vehicle state and power management: vehicle wake/sleep, network management (AUTOSAR CP’s home turf);
• Safety logging: black-box recording for accident reconstruction.

Three failure scenarios

SoC kernel panic          -> MCU heartbeat timeout -> degrade immediately, enter MRM
AP outputs 90° of wheel   -> MCU sanity check vetoes; only sane commands pass
brake command 200 ms late -> MCU command-timeout backstop; the safe policy executes

The architecture diagram below is the sum of all the reasons above:

┌────────────────────────────┐
│ Big SoC (ASIL B)           │
│ perception & planning;     │
│ output is only "advice"    │
└─────────────┬──────────────┘
              │ advice + heartbeat
              ▼
┌────────────────────────────┐
│ Safety MCU (ASIL D) —      │
│ the safety island:         │
│ heartbeat monitoring,      │
│ sanity checks, one-way     │
│ reset of the SoC, takes    │
│ over on timeout            │
└─────────────┬──────────────┘
              │ issues commands (CAN FD)
              ▼
        ESP / EPS (brakes / steering)

What it means for test engineers

This “life-or-death channel” is the signature use-case area of HIL fault injection: kill the SoC process or cut its power outright, inject illegal commands, stretch command latency — and verify the MCU vetoes and enters the MRM within the allotted time. Every acceptance criterion is timing (how fast it detects, how fast it degrades). The rig equipment that does this is the fault injection unit (FIU).

3. NCAP: Translating “Safety” into Scenarios (the Market View)

The standards view and the architecture view both speak inside engineering; consumers can’t hear them and wouldn’t understand them. What translates safety into market language is NCAP.

What NCAP is: first distinguish it from regulation

NCAP = New Car Assessment Program:

NCAP is nominally voluntary, but the star rating goes straight into advertising and sales — it has de facto coercive power over OEMs, which is why the industry calls it “market regulation.”

The various NCAPs

• US NCAP (1979, NHTSA): the originator;
• Euro NCAP (1997): the most influential, the global bellwether, tightening its protocols every 2–3 years;
• C-NCAP (2006, CATARC): the Chinese edition; its early, lenient star-giving earned it the nickname “five-star wholesaler”;
• C-IASI (insurance-backed): not an NCAP but plays a similar role — its 25% small-overlap crash has unmasked several “five-star cars,” and it enjoys stronger consumer credibility;
• Others: Latin NCAP, ANCAP (Australia), JNCAP (Japan), Global NCAP;
• The US also has the IIHS (funded by the insurance industry), positioned between regulation and NCAP — the small-overlap crash is its signature.

What Euro NCAP tests: the four pillars (through 2025)

Euro NCAP long organized its rating around four pillars:

1. Adult occupant protection: crash tests — full-width and offset frontal (MPDB), side, pole, whiplash;
2. Child occupant protection: child-seat interfaces, dynamic crashes;
3. Vulnerable road users (VRU): pedestrian head/leg impact plus AEB pedestrian/cyclist;
4. Safety Assist: AEB car-to-car (CCR), LKA, speed assistance, driver monitoring.

Each pillar is scored, and the weighted sum folds into 1–5 stars (a terrible single pillar can sink the overall rating). Starting with the 2026 protocol, the rating is regrouped into four stages along the safety chain — Safe Driving, Crash Avoidance, Crash Protection, and Post-Crash Safety — with the pillar test items redistributed into these stages; downstream content such as CCR and AEB is unchanged.

The AEB scenario matrix: the public base layer of the case library

ADAS-related testing uses standardized scenarios:

• CCRs (Car-to-Car Rear stationary): the lead vehicle is stationary;
• CCRm (moving): the lead vehicle moves at constant speed;
• CCRb (braking): the lead vehicle is braking.

Each scenario comes with a speed matrix: in the current Euro NCAP protocol, for example, CCRs approach speeds step from 10 to 80 km/h in 10 km/h increments (the exact grid shifts with protocol versions); and standardized props (the GVT soft-target car, dummies, driving robots) guarantee results are comparable worldwide.

This matrix deserves a second look — it’s a real-world specimen of three ideas:

• Risk-weighted sampling done for you by an authority — it doesn’t enumerate every combination; it picks the most lethal intervals from accident statistics;
• Sampling inside the Operational Design Domain (ODD), in the flesh — the speed matrix is one-dimensional sampling within the ODD boundary;
• Ready-made acceptance criteria — avoid the collision, or reduce impact speed below a threshold; the criteria are fully public and drop straight into your test cases as verdict conditions.

The limitation: teaching to the test, and an arms race

NCAP scenarios are public with explicit criteria → OEMs inevitably optimize against them (“teaching to the test”) → the long tail of real accidents lives outside NCAP scenarios → NCAP can only keep adding scenarios and raising difficulty. It’s a perpetual arms race, and the reason the protocol gets revised every few years.

The OEM’s correct posture is two-layered:

1. Max out the NCAP scenario library — the admission ticket, the “public base layer,” with known answers;
2. Build your own scenario library for the long tail — dangerous scenarios poured back from real-world data or dug out by directed search; that’s the real body of safety competitiveness.

4. One Picture for Three Views

Back to the opening question: who gets to say “safety”?

ASIL sets how strict the rules are — the higher the risk, the stricter the development and testing rules; the safety MCU backstops execution — when the rules say ASIL D, this little chip is the hardware guarantee that “someone catches it when things go wrong”; NCAP sets the market’s acceptance — it translates everything above into concrete scenarios and star ratings, so consumers can vote with their wallets.

The three aren’t isolated topics: NCAP scenarios are written into system requirements at the requirements phase, HARA assigns them a level, the ASIL D chain lands in hardware on the safety MCU’s sign-off, and the test evidence chain serves both ends — traceability you can produce in an audit, and stars you can earn at launch. One sets the standard, one guarantees execution, one performs acceptance — that is the complete grammar of “functional safety” in the auto industry.

Appendix: Glossary (in order of appearance)