ISO 26262 Mandates Fault Injection at ASIL D
Mostafa Dhouib··5 min readBranch coverage is highly recommended at ASIL B, C and D; MC/DC and fault injection become highly recommended at ASIL D. The hardware side permits only about 1 percent residual single point faults at ASIL D, assessed through fault injection campaigns. Negative control discipline, written as a requirement.
ISO 26262 Mandates Fault Injection at ASIL D
The short answer. At the top automotive assurance level, deliberately injecting faults to prove detection is not advice, it is a highly recommended method for software unit and integration testing. Branch coverage rises to highly recommended at ASIL B, C and D, and MC/DC joins fault injection at ASIL D.
Most of this pillar argues that you should break your own checks on purpose. This post is the observation that an entire industry already requires it, in writing, at the level where being wrong kills people.
What the standard requires, by ASIL
Part 6, section 9 covers software unit testing, with structural coverage scaling by ASIL.
Statement coverage: highly recommended at lower ASILs.
Branch coverage: highly recommended at ASIL B, C and D.
MC/DC: highly recommended at ASIL D.
Fault injection testing: a recommended method that becomes highly recommended at ASIL D for software unit and integration testing.
Confidence note, stated rather than buried: the structure of these obligations is well established, and the exact table wording here comes from reputable summaries rather than the primary text, which is paywalled. Treat the shape as solid and any specific phrasing as needing confirmation against the standard itself before you cite it in a certification argument.
The hardware metrics, for scale
The software table is easy to read as advisory. The hardware side shows how seriously the top level is meant.
Single Point Fault Metric at or above 99 percent at ASIL D. Only roughly 1 percent residual single point faults are permitted, and the assessment method named is fault injection campaigns.
Latent Fault Metric at or above 90 percent at ASIL D.
Those are quantitative targets. You cannot reach them by inspection, and you cannot argue your way to them in a document, which is exactly why the standard names injection as the assessment method rather than analysis.
Why a standards body requires breaking things
Because the alternative has a measured failure record, and the reference case is recent.
The alternative is analysis. Reason that a fault would be detected, write the reasoning down, and let the document stand as the verification. MCAS is what that produces at its worst: a hazard classification was recorded, it implied a redundancy requirement, the shipped architecture did not meet it, the safety analysis understated the system's authority by more than four times, and nobody fed the system a bad sensor value to see.
Fault injection converts an assumption about detection into an observation of detection. Those are different acts. A standards body that has watched enough programmes converged on requiring the second one.
Which makes ISO 26262 the clearest external evidence for this pillar's whole thesis. The negative control is not a stylistic preference held by people who like testing. At the top assurance level of a major safety-critical industry, it is the requirement.
What a campaign actually involves
Enumerate faults by class. Corrupted sensor values, including the stuck-at case that produces perfectly valid readings. Forced error returns on every call that can fail. Bit flips. Dropped, duplicated and reordered packets. Delayed interrupts.
Run them in simulation. This is the difference between a control and an event. Renode simulates MCUs, peripherals and sensors and has been integrated with AFL++ for Zephyr and Contiki-NG; QEMU covers emulation-based fuzzing. A campaign that needs a bench and a person runs quarterly at best, and a control that runs quarterly is not protecting the commits in between.
Record detection, not absence of crash. A system that survives an injected fault without noticing it has failed the test. This is the most common way a campaign gets misread as a pass, and it is worth writing into the acceptance criteria explicitly.
If you are not in automotive
The obligation does not apply to you. The reasoning does, and it transfers without modification.
Map your functions to the right level in whichever standard governs you: DO-178C DAL, ISO 26262 ASIL, or IEC 62304 class. Then adopt the obligations that level carries, because somebody has already done the work of deciding what rigor a given consequence deserves.
And treat a hazard that depends on a single sensor as a design defect to fix before certification, not a test to add later. That is the MCAS and Ariane lesson in a regulatory frame: at ASIL C or D, or a hazardous or catastrophic classification, a single point dependence or an unverified reused module is not something more testing resolves.
Budget honestly while you are at it. Roughly 15 to 35 percent more up front effort is the figure from the test-discipline studies, and top-ASIL rigor is commonly estimated at 3 to 5 times, from industry estimates rather than controlled study.
The technique in detail is in fault injection for firmware, the case that motivates it in MCAS, and the general argument in a test that has never failed is a decoration.
FAQ
Does ISO 26262 require fault injection? It is a recommended method that becomes highly recommended at ASIL D for software unit and integration testing, and it is the named assessment method for the hardware Single Point Fault Metric at that level.
What coverage does ASIL D require? Branch coverage is highly recommended at ASIL B, C and D, and MC/DC is highly recommended at ASIL D.
What is the Single Point Fault Metric at ASIL D? At or above 99 percent, permitting roughly 1 percent residual single point faults, assessed through fault injection campaigns. The Latent Fault Metric is at or above 90 percent.
How confident are these clause details? The structure is well established. The exact table wording comes from reputable summaries rather than the paywalled primary text, so confirm any specific phrasing before citing it in a certification argument.
What if we are not in automotive? The reasoning transfers. Map functions to the right level in whichever standard governs you, and treat a hazardous function depending on a single sensor as a design defect rather than a testing gap.
Tell us the system, the stakes, and the date that matters. You get a straight technical reply from the person who would lead the work, within 24 hours.
Bring us the program