Safety-Related Timing
Learn to treat time as a safety property: the fault handling intervals, diagnostic test intervals, timing budgets, safe-state transitions, allocation to hardware and software, and verification evidence.
- Chapters
- 10
- Chapters
- Worked examples
- 2
- Worked examples
Quick answers
- What is the fault tolerant time interval (FTTI) in ISO 26262?
- The fault tolerant time interval (ISO 26262-1:2018, 3.61) answers one question: once a fault appears in the item, what is the shortest time before a hazardous event could follow if nothing steps in? It is the hard deadline handed down by the hazard analysis, and whatever detection and reaction your system performs must complete inside it. FTTI is a property of the vehicle-level hazard, not of your design: you cannot negotiate it, only budget against it.
- What is the difference between FTTI and FHTI?
- FTTI is the deadline; FHTI is your performance against it. The fault handling time interval (FHTI) is the sum of the fault detection time interval (FDTI, from fault occurrence to detection) and the fault reaction time interval (FRTI, from detection to reaching the safe state). Safety requires FDTI plus FRTI to stay below FTTI, and in practice with deliberate margin: setting FHTI equal to FTTI leaves no tolerance for jitter and worst-case stacking.
Why it pays for itself
Untangle FTTI, FDTI, FRTI, FHTI
Learn what each fault handling interval means, which one the hazard fixes and which ones your design sets, and the inequality that ties them together.
Build a defensible timing budget
Work a brake-by-wire budget end to end: reduce the interval to a working budget, allocate detection and reaction, and hold explicit margin 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
Use the timing intervals correctly
Separate the intervals fixed by the hazard from those set by your design.
Build a timing budget
Allocate detection and reaction time against the fault tolerant time interval with explicit margin.
Specify diagnostic test intervals
Set test rates that fit both the timing budget and latent fault coverage.
Allocate across hardware and software
Split timing at the HSI and account for scheduling and execution time.
Verify timing with evidence
Back budget claims with fault injection, WCET analysis and a timing evidence package.
Chapter by chapter
- 01
Time Is a Safety Property
See why detection takes time, why timing is so often under-budgeted, and where timing appears across ISO 26262.
- Detection takes time
- The timing chain
- Where timing appears
- 02
FTTI, FHTI, FDTI
Put the fault handling intervals on one fault-to-safe-state timeline, clear up common confusions, and see why margin is essential.
- Interval definitions
- Fault timeline
- Why margin matters
- 03
Diagnostic Test Interval
Define the diagnostic test interval, relate it to the FTTI and to latent fault detection, and specify it in requirements.
- DTI defined
- DTI and FTTI
- Specifying DTI
- 04
The Timing Budget
Set up the core timing inequality, work through a brake-by-wire budget, trade detection against reaction time, and document the result.
- Core inequality
- Brake-by-wire example
- Budget trade-offs
- 05
Safe-State Transition
Define safe states, break down the reaction path, handle emergency operation and design degraded modes.
- Safe state definition
- Reaction path
- Emergency operation
- 06
Multi-Point Detection
Separate single-point from multi-point timing, choose test rates for latent faults and connect them to FMEDA results.
- Latent fault metric
- Test rates
- Link to the FMEDA
- 07
Worked Timing Diagram
Read an annotated fault timeline event by event and draw the conclusions a reviewer would draw.
- Scenario setup
- Annotated timeline
- Key takeaways
- 08
Allocating Timing to HW/SW
Split detection between hardware and software, account for scheduling and WCET, and document timing at the HSI.
- Hardware versus software detection
- Scheduling and WCET
- Timing at the HSI
- 09
Verifying Timing
Verify timing claims with fault injection, WCET analysis and system-level tools, then build the timing evidence package.
- Fault injection
- WCET analysis
- Evidence package
- 10
Pitfalls
Review the timing pitfalls that recur in projects and check a timing budget before it goes to review.
- Timing pitfalls
- Budget review
- Common mistakes
Read all 10 chapters with Expert.
Start with a free account: the complete Functional Safety Concept guide and 5 practice exams a month, then upgrade when you need this guide.
Expert plan pricingBrake-by-Wire Timing Budget
Chapter 4 builds a timing budget for a fictional brake-by-wire pressure control, and Chapter 7 reads a full fault timeline event by event.
- The core inequality the budget has to satisfy
- Allocation of detection and reaction time
- Trade-offs between faster detection and faster reaction
- How the budget is documented for review
Unlock in course
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
Start the course today
A free account unlocks one full concept guide, 3 work product templates, 1 guided process, the Markov and RBD simulators, and 5 practice exams per month. The Pro and Expert plans unlock more of the 93-guide library. No credit card required.
Continue with
Where this topic leads next.
- Concept phaseSafety Design Decisions Across Vehicle DomainsNine automotive domains walk the exact same ISO 26262 Part 3-6 chain (item definition, HARA, FSC, TSC, HSI, hardware and software), yet arrive at radically different technical answers. See why a traction inverter, a brake ECU and a cockpit display controller end up nothing alike.
- System levelTechnical Safety ConceptLearn how to translate safety goals and FSC into technical safety requirements (TSRs), system architecture, and HW/SW allocation. Covers safety mechanisms, diagnostic coverage, FMEA integration, and a complete worked example with templates.
- Concept phaseItem Definition & Concept-Phase InitiationGet the first ISO 26262-3 step right: define the item boundary, interfaces, operating modes, and assumptions of use that HARA, safety goals, and the whole safety case inherit from the concept phase.