Safety-Related Timing: FTTI, FDTI & FHTI
Treat time as a first-class safety property and learn how the ISO 26262 fault-handling intervals decide whether a fault is detected and controlled before a hazardous event, with a worked 100 ms brake-by-wire budget.
- Chapters
- 10
- Chapters
- Timing Intervals
- 4
- Timing Intervals
- Worked Example FTTI
- 100 ms
- Worked Example FTTI
- ISO Vocabulary Base
- Part 1
- ISO Vocabulary Base
Why it pays for itself
Untangle FTTI, FDTI, FRTI, FHTI
Learn the verbatim ISO 26262-1:2018 definitions of the fault-handling intervals, which one is fixed by hazard analysis, which are set by your design, and the strict inequality that binds them together.
Build a defensible timing budget
Work a real 100 ms brake-by-wire budget end to end: FTTI reduced to a working budget, detection and reaction allocated in milliseconds, and explicit margin held for jitter and worst-case stacking.
Verify timing with evidence
Go beyond claiming the budget holds: use fault injection to measure real detection latency, WCET analysis for the reaction path, and assemble a timing evidence package the safety case can rely on.
What you’ll be able to do
Distinguish the Intervals
Separate FTTI, FDTI, FRTI, and FHTI correctly and state which is fixed by hazard analysis and which is set by the safety mechanism.
Build a Timing Budget
Allocate detection and reaction budgets against an FTTI, hold an explicit margin, and check FDTI + FRTI < FTTI with confidence.
Specify DTI Requirements
Write diagnostic test interval requirements that bound detection latency and support latent fault coverage targets.
Design Safe-State Reactions
Lay out the reaction path, choose between full safe state and emergency operation, and keep degraded modes inside the deadline.
Allocate Across HW and SW
Place fast detection in hardware and reaction in software while accounting for interrupt latency, jitter, and worst-case execution time.
Verify and Evidence Timing
Use fault injection and WCET analysis to prove worst-case timing and assemble the evidence package for the safety case.
Chapter by chapter
- 01
Time Is a Safety Property
Detection that arrives after the hazard is worthless, so ISO 26262 treats the deadline by which a fault must be handled as a safety property in its own right.
- Fault Tolerant Time Interval (FTTI) as the hard deadline
- Why timing budgets are routinely under-specified
- The fault-to-safe-state chain FHTI = FDTI + FRTI
- 02
FTTI, FHTI, FDTI
Precise ISO 26262-1:2018 vocabulary for each interval, with a labeled fault-to-safe-state timeline and the confusions that lead to under-specified requirements.
- Verbatim definitions for FTTI, FDTI, FRTI, and FHTI
- FDTI + FRTI < FTTI as a strict inequality (3.55 Note 4)
- Why a 20 to 30 percent margin is essential
- 03
Diagnostic Test Interval
How the rate at which a periodic diagnostic runs sets a floor on detection latency, and how the Diagnostic Test Interval (DTI) ties into latent fault coverage.
- DTI defined and related to worst-case FDTI
- The DTI-to-FTTI relationship for single-point faults
- Specifying DTI inside testable safety requirements
- 04
The Timing Budget
Building a defensible timing budget around FHTI = FDTI + FRTI < FTTI, worked through a brake-by-wire pressure-control function with explicit millisecond allocations.
- 100 ms FTTI reduced to an 80 ms working budget
- FDTI 11 ms plus FRTI 31 ms gives 42 ms FHTI
- Trading detection speed against reaction speed
- 05
Safe-State Transition
Anatomy of the Fault Reaction Time Interval (FRTI), the definition of a safe state, and how emergency operation and degraded modes extend the available reaction options.
- Reaction path from signal to actuator settling
- Emergency Operation Tolerant Time Interval (EOTTI)
- Designing degraded modes that stay within FTTI
- 06
Multi-Point Detection
How latent multi-point faults carry different timing constraints from single-point faults, and how the Latent Fault Metric drives diagnostic test rates.
- Single-point versus latent multi-point faults
- Latent Fault Metric (LFM) and the detection interval
- Linking test rates back to FMEDA results
- 07
Worked Timing Diagram
An annotated timeline placing fault occurrence, diagnostic tick, detection, reaction, and safe state in sequence, with event-by-event commentary that keeps everything inside FTTI.
- Diagnostic tick and detection latency made visible
- Reaction path mapped against the deadline
- Reading the spare margin straight off the diagram
- 08
Allocating Timing to HW/SW
Splitting detection budget to hardware monitors and reaction budget to software, accounting for interrupt latency, scheduling jitter, and worst-case execution time at the interface.
- Hardware monitors for fast, short FDTI
- Scheduling and WCET pressure on software reactions
- Recording timing at the hardware-software interface
- 09
Verifying Timing
Producing evidence that worst-case detection and reaction times hold, using fault injection, worst-case execution time analysis, and system-level timing tools for the safety case.
- Fault injection to measure real detection latency
- Static and measurement-based WCET analysis
- Assembling a defensible timing evidence package
- 10
Pitfalls
The recurring mistakes in safety-related timing, from confusing the intervals to leaving zero margin, paired with a review checklist a practitioner can apply directly.
- Ten dangerous timing anti-patterns
- Setting FHTI equal to FTTI with no margin
- A timing-budget review checklist
Not just text: the visual toolkit
Fault-to-Safe-State Timeline
Labeled axis showing fault occurrence, detection at FDTI, safe state at FHTI, and the hazard deadline at FTTI, with the reserved margin called out.
Safe-State Transition Sequence
State view of the reaction path from fault signal through software handler to actuator settling in the defined safe state.
Reaction State Machine
Transitions between nominal operation, fault detected, emergency operation, and full safe state across the FRTI window.
Degraded Mode and Emergency Operation
How limp-home and emergency operation extend reaction options when a full safe state cannot be reached inside FTTI.
HW/SW Timing Allocation
Architecture split assigning short detection budget to hardware monitors and reaction budget to scheduled software tasks across the interface.
Fault Injection Verification
Injection points and measured detection-to-reaction latency used to confirm worst-case timing against the budget.
Brake-by-Wire Pressure Control Timing Budget
A pressure-control function with an FTTI of 100 ms is worked end to end, allocating detection and reaction so the handling time lands comfortably under the deadline with margin to spare.
- FTTI of 100 ms from hazard analysis, reduced to an 80 ms working budget using a 0.8 factor
- Diagnostic runs on a 10 ms period, so FDTI is 10 ms plus 1 ms execution, giving 11 ms
- FRTI of 31 ms covers interrupt latency, task switch, command, and actuator settling
- FHTI = FDTI + FRTI = 11 ms + 31 ms = 42 ms total handling time
- 42 ms sits below the 80 ms working budget and well under the 100 ms FTTI
- Roughly 38 ms of spare margin absorbs jitter and worst-case stacking
Unlock the full margin analysis and verification evidence
Who this guide is for
- System engineers deriving timing requirements from safety goals and safe states
- Software and hardware leads splitting a fault-handling budget across the HSI
- Diagnostics engineers specifying diagnostic test intervals for latent fault coverage
- Anyone whose safety concept says "within FTTI" without a number behind it
Frequently Asked Questions
Common questions about Safety-Related Timing: FTTI, FDTI & FHTI
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.