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
- 01Why Fault Injection
- 02Fault Models
- 03Where in the Lifecycle
- 04Hardware Fault Injection
- 05Software Fault Injection
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.
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.
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
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.
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%
Unlock the full plan, classification, and safety case entry
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
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 77-guide library. No credit card required.