Concept guide · ISO 26262-4/-5/-6 · 10 chapters

Fault Injection & Safety-Mechanism Verification

Learn how to turn a Diagnostic Coverage (DC) claim into demonstrated evidence by injecting faults and proving safety mechanisms detect and react within the Fault-Tolerant Time Interval (FTTI) across hardware, software, and system levels.

Chapters: 10; Chapters
Injection Techniques: 6; Injection Techniques
V-Model Levels: 4; V-Model Levels
Fault Worked Example: 500; Fault Worked Example

Included inExpert

Start learning See the chapters

Inside the course

01Why Fault Injection
02Fault Models
03Where in the Lifecycle
04Hardware Fault Injection
05Software Fault Injection

Why this course · ISO 26262, Part 4

Why it pays for itself

Turn DC claims into evidence

Every Diagnostic Coverage value in the FMEDA is a claim until a fault injection test demonstrates it. Learn to trace each claimed percentage to an experiment an assessor can inspect.

Verify reaction inside the FTTI

Measure detection latency and fault reaction time against the Fault-Tolerant Time Interval - the worked example catches an interrupt-boundary violation that pushed nine cases past a 25 ms budget.

Plan statistically defensible campaigns

Derive fault lists from FMEDA rows, choose exhaustive or sampled strategies, classify every outcome, and report a Wilson or Clopper-Pearson lower bound instead of a bare point estimate.

After the course

What you’ll be able to do

Justify DC claims with evidence

Trace each FMEDA Diagnostic Coverage value to a fault injection test that demonstrates the mechanism rather than asserting it.

Verify reaction within FTTI

Measure detection latency and fault reaction time, confirming the safe state is reached inside the Fault-Tolerant Time Interval.

Build a representative fault list

Derive injection cases from all FMEDA fault classes and review them so coverage is not systematically optimistic.

Choose the right technique

Match pin forcing, glitching, JTAG, EMFI, laser, RTL simulation, or HIL to the fault model, access, and budget at hand.

Compute coverage with confidence

Classify outcomes consistently, calculate achieved DC, and report a Wilson or Clopper-Pearson lower bound for sampled campaigns.

Package auditable evidence

Produce test plan, test report, and non-conformance log as work products an assessor can trace to the safety case.

The curriculum · 10 chapters

Chapter by chapter

01
Why Fault Injection
Fault injection converts an analytical Diagnostic Coverage (DC) claim in the FMEDA into demonstrated evidence for the safety case, proving mechanisms fire inside the Fault-Tolerant Time Interval (FTTI).
- Claim versus evidence: why an assigned DC needs experimental backing
- FTTI and Fault Handling Time Interval (FHTI) reaction-time verification
- Scope limits: fault injection complements FMEA and FTA, it does not replace them
02
Fault Models
A fault model bridges physical failure mechanisms to the stimuli a test engineer can apply, spanning stuck-at, bridging, open, bit-flip/SEU, and the information-exchange fault classes of ISO 26262-6 Annex D.
- Logic-level faults: stuck-at, bridging, open, and transition/timing
- Single-Event Upsets (SEU): SBU, MBU, and SET transients
- Communication faults: corruption, loss, delay, insertion, babbling idiot
03
Where in the Lifecycle
Fault injection appears on multiple right-side V-model nodes because the relevant faults, observation points, and claims differ at software unit, integration, hardware, and system levels.
- Software unit and integration: variable corruption and flow monitors
- Hardware integration: watchdog, voltage, and clock monitor stimulation
- System and vehicle level: bus, supply, and actuator-feedback faults
04
Hardware Fault Injection
Physical techniques inject faults into real silicon and boards, ranging from safe non-invasive JTAG register writes to spatially precise but destructive laser and heavy-ion methods.
- Pin-level forcing and protocol-aware bus interception
- Power and clock glitching for transient and timing faults
- EMFI, laser (LFI), and JTAG/boundary-scan injection compared
05
Software Fault Injection
Source-level and binary-level injection verifies software safety monitors cheaply and repeatably, exercising range checks, flow monitors, and exception handlers without specialised hardware.
- Code mutation and mutation score as a coverage metric
- Debugger-driven variable and register corruption via JTAG/SWD
- API stubbing and exception/trap forcing for AUTOSAR interfaces
06
Simulation & Model-Based FI
Simulation-based campaigns validate coverage before hardware exists, from RTL/gate-level fault simulation feeding ISO 26262-11 analysis to Model, Software, and Hardware-in-the-Loop saboteur techniques.
- RTL/gate-level fault simulation for stuck-at and transition coverage
- Virtual ECU (vECU) and Software-in-the-Loop injection in CI/CD
- Saboteur and mutant blocks across Model, Software, and Hardware-in-the-Loop
07
Campaign Planning
The fault list is derived from the FMEDA and architecture, then run as an exhaustive or statistically sampled campaign against a golden run with predefined observation points and pass/fail criteria.
- Deriving and peer-reviewing the fault list from FMEDA rows
- Exhaustive versus stratified, random, and risk-guided sampling
- Golden run comparison and FTTI-aware observation points
08
Measuring Coverage
Every injected fault is classified into exactly one outcome, achieved DC is computed from detected over detected plus undetected, and sampled campaigns report a Wilson or Clopper-Pearson confidence bound.
- Outcome classes: detected, silent, late, masked, false alarm, inconclusive
- DC = N_detected / (N_detected + N_undetected), masked excluded
- Lower confidence bound must meet the required DC, not just the estimate
09
Tools & Standards
Four tool categories cover the V-model, results package into formal work products, tools need ISO 26262-8 qualification, and ISO 26262-11 gives semiconductor-specific fault injection guidance.
- RTL simulators, debugger tools, HIL platforms, protocol injectors
- Tool Confidence Level (TCL) qualification under ISO 26262-8 Clause 11
- ISO 26262-11 semiconductor evidence and Safety Element out of Context (SEooC)
10
Worked Example & Pitfalls
A complete ASIL D Electric Power Steering (EPS) torque watchdog example runs 500 stuck-at-high injections to 98.2% DC, exposing a timing non-conformance, plus five pitfalls that invalidate campaigns.
- FMEDA entry to test plan to classified results and safety case entry
- Interrupt-boundary FTTI violation found, root-caused, and re-tested
- Pitfalls: unrepresentative models, blind spots, dropped inconclusive tests

Diagrams & Visuals

Not just text: the visual toolkit

Fault Model Explorer

Interactive map of stuck-at, bridging, open, SEU, and communication fault classes with automotive failure examples.

Fault Injection Across the V-Model

Where injection sits at software unit, software integration, hardware integration, and system levels with the relevant clauses.

Hardware, Software, and Simulation Comparison

Side-by-side view of injection environments by realism, cost, repeatability, and the evidence each produces.

Campaign Timeline and FTTI

Fault-at-T=0 timeline tracing detection latency and reaction time against the Fault-Tolerant Time Interval budget.

Fault Classification Decision Tree

Branching logic that sorts each injected fault into detected, silent, late, masked, false-alarm, or inconclusive.

Diagnostic Coverage Gauge

Achieved DC visualised against the claimed target with the statistical confidence lower bound for sampled runs.

Worked Example

ASIL D EPS Torque Watchdog: Stuck-at-High Injection

A dual-channel SENT torque sensor on an Infineon AURIX TC397 is injected with a stuck-at-high fault (0xFFFF) at ten program phases to verify the cross-channel plausibility monitor and 10 ms watchdog window against a 25 ms FTTI.

FMEDA-EPS-HW-017 claims 97% DC for the plausibility monitor at ASIL D
JTAG (Lauterbach TRACE32) overwrites the decoded channel A torque register, 500 injections total
Observation spans the PLAUS_FAULT flag, relay coil, motor current, and DTC E0017
Results: 487 detected, 9 FTTI-exceeded, 4 masked, achieved DC = 98.2%
NCR-EPS-FI-003: interrupt preemption pushed 9 cases to 28 ms, fixed by raising task priority
Re-test passed within 18 ms; assessor accepted FI-TR-EPS-017-v2 with 95% lower bound of 96.7%

Campaign Result Summary

Achieved Diagnostic Coverage: 98.2% (487 of 496 non-masked detected)

Unlock the full plan, classification, and safety case entry

Built for

Who this guide is for

Hardware safety engineers who assigned DC values in an FMEDA and now must back them
Test engineers planning HIL, JTAG, or simulation-based injection campaigns
Software leads verifying range checks, flow monitors, and watchdog handlers
Anyone facing an assessor question about where a coverage number came from

Frequently Asked Questions

Common questions about Fault Injection & Safety-Mechanism Verification

Fault injection testing deliberately introduces faults into a system to demonstrate that its safety mechanisms detect and react to them as claimed. In ISO 26262 it appears as a test method at multiple levels - software unit and integration testing in Part 6, hardware integration in Part 5, and system and vehicle integration in Part 4 - with Part 11 adding semiconductor-specific guidance. Its central role is converting an analytical Diagnostic Coverage claim from the FMEDA into demonstrated evidence for the safety case, including proof that detection and reaction complete within the Fault-Tolerant Time Interval. It complements FMEA and FTA; it does not replace them.

Each injected fault is classified into exactly one outcome: detected, silent (undetected), late, masked, false alarm, or inconclusive. Achieved DC is then computed as detected divided by detected plus undetected, with masked faults excluded from the denominator. For sampled campaigns the point estimate is not enough - you report a Wilson or Clopper-Pearson confidence bound, and it is the lower bound that must meet the required DC. Dropping inconclusive results or excluding awkward outcomes is one of the classic ways a campaign silently invalidates itself.

A fault model bridges physical failure mechanisms to stimuli a test engineer can apply. The standard families are logic-level faults (stuck-at, bridging, open, transition and timing faults), single-event upsets (single-bit, multi-bit, and transients), and the communication fault classes of ISO 26262-6 Annex D: corruption, loss, delay, insertion, and babbling idiot. Choosing representative fault models matters as much as the injection itself - an unrepresentative model produces systematically optimistic coverage.

Hardware techniques range from non-invasive JTAG register writes and pin-level forcing through power and clock glitching up to spatially precise but destructive EMFI and laser injection. Software techniques include code mutation, debugger-driven variable corruption, API stubbing, and exception forcing. Simulation covers RTL and gate-level fault simulation, virtual ECUs in CI/CD, and saboteur blocks across MiL, SiL, and HiL. The right choice depends on the fault model, the access you have, and the evidence the safety case needs.

Ten chapters spanning 6 injection techniques and 4 V-model levels, from fault models through campaign planning to coverage statistics and tool qualification. The worked example runs 500 stuck-at-high injections against an ASIL D EPS torque watchdog, reaching 98.2% achieved DC and exposing a timing non-conformance along the way. A free account starts you off, and the Pro and Expert plans unlock more of the library.

Start the course today

A free account unlocks one full concept guide, 3 work product templates, 1 guided process, the Markov simulator, and 5 practice exams per month. The Pro and Expert plans unlock more of the 78-guide library. No credit card required.

Start learning View Pricing Plans