An ASIL D electric power steering team nails the HARA. They derive a safety goal with a Fault Tolerant Time Interval of 100 ms — a torque fault must not persist longer than that before the system transitions to a safe state. They specify a 50 ms watchdog, a torque-sense plausibility check running every 20 ms, and a transition-to-manual steering at a 20 Nm/s ramp. The concept review passes. Six months later, the assessor pulls out a calculator, asks for the worst-case FDTI and FRTI values, adds them, and gets 142 ms. The FTTI is blown. The safety case is wrong. And because the mechanical safe-state transition time was never formally budgeted, the team has to redesign the actuator command profile or re-open the HARA to justify a longer FTTI. This is the single most expensive timing mistake in ISO 26262 programs, and it happens because engineers treat FTTI as a number rather than a budget.
What FTTI Actually Means in ISO 26262
ISO 26262-1:2018 defines the FTTI (Fault Tolerant Time Interval) as the minimum time-span from the occurrence of a fault in the item to a possible occurrence of a hazardous event, if the safety mechanism is not activated. That last clause matters: FTTI is measured against the hazard, not the fault detection latency. It is a property of the item and its environment — derived from the HARA and documented in the safety goal per ISO 26262-3 Clause 7.4.
The safety mechanism must act inside this window. ISO 26262-4 Clause 6 and Part 5 Clause 7 require that the FHTI (Fault Handling Time Interval) be strictly less than FTTI, expressed as FHTI = FDTI + FRTI < FTTI, where:
- FDTI (Fault Detection Time Interval) is the worst-case time from fault occurrence until the safety mechanism detects it.
- FRTI (Fault Reaction Time Interval) is the worst-case time from detection until the item reaches the safe state.
"Strictly less than" is not a suggestion — assessors want to see a documented safety margin, typically 20–30% of the FTTI, to account for measurement uncertainty, timing jitter, and aging effects on hardware. A common bench-level guideline is FDTI + FRTI ≤ 0.7 × FTTI. If your margin falls below that, expect questions.
Deriving the FTTI: From HARA to Timing Budget
FTTI is not a single number the system team pulls out of thin air. It falls out of the hazard analysis. For each hazardous event, the team must establish how long the hazardous behavior can persist before it leads to harm. Two inputs drive this:
- The vehicle-level dynamics — how fast the unwanted behavior can propagate. An unintended 30% torque surge in EPS behaves differently at 30 km/h in a parking lot than at 130 km/h on the autobahn.
- The controllability factor (C0–C3) from the HARA — an FTTI that assumes the driver can intervene within 250 ms is only defensible if the hazard is classified C1 or C2 with evidence.
Once the concept-level FTTI is set, system design (ISO 26262-4 Clause 6.4.2.1) allocates a timing budget to each contributing element: sensor acquisition, network transport, ECU detection, actuator command, and mechanical response. Miss any of these and the budget lies to you.
The Hidden Contributors to FDTI
FDTI is not just "watchdog period." Engineers routinely under-count contributors. For a typical distributed safety mechanism on CAN FD:
| Contributor | Typical Worst Case | Notes |
|---|---|---|
| Sensor sample period | 5–20 ms | Depends on sensor ASIC |
| Sensor-to-ECU transport (CAN FD) | 2–5 ms | Plus retries on error frames |
| ECU task activation jitter | 1 OS tick (typ. 1–10 ms) | Worst-case under load |
| Plausibility check window | 1–N periods | Needs N consecutive bad samples |
| Debounce/confirmation | 2–3 samples | Required to avoid spurious trips |
| End-to-end protection latency (E2E) | 1 period | AUTOSAR E2E adds a period minimum |
An engineer who writes FDTI = "50 ms watchdog" without summing these is under by 20–40 ms. On a 100 ms FTTI, that is the difference between a compliant design and a scrapped architecture.
FRTI: The Part Nobody Budgets for Mechanical Motion
FRTI is where naive designs die. "Transition to safe state" is often physical — cutting torque output, engaging hydraulic bypass, closing a contactor, deploying a redundant steering actuator. Each of these has a minimum time that is governed by physics, not software. A contactor has a 15–30 ms open time. A DC-link capacitor can take 50–150 ms to discharge below a safe threshold. An electric motor commanded to zero torque still produces cogging and flux-decay transient torque for 5–20 ms.
FRTI must include:
- Software reaction time (notification, mode transition, output update)
- Communication latency to the actuator (if the reacting element is a different ECU)
- Driver-stage and gate-driver delay
- Physical actuator response time
- Any mechanical settling or discharge
A Worked Example: EPS Torque Plausibility, ASIL D, 100 ms FTTI
Consider the EPS case from the opening paragraph. Assume the concept HARA fixes FTTI = 100 ms and the team proposes a dual-redundant torque-sensor plausibility check with transition to manual steering as the safe state.
| Time Interval | Budget | Source |
|---|---|---|
| Sensor sample rate | 4 ms (250 Hz) | ASIL D torque sensor ASIC |
| E2E + CAN FD transport | 5 ms | 500 kbit/s FD, ASIL D profile |
| Plausibility confirmation (3 samples) | 12 ms | 3 × 4 ms sample period |
| OS scheduling jitter (worst-case) | 5 ms | 1 kHz task with preemption |
| FDTI total | 26 ms | Sum |
| Mode-transition software latency | 4 ms | 1 task period after detection |
| Torque ramp-down command | 20 ms | 20 Nm/s at typical 0.4 Nm |
| Gate-driver and motor flux-decay | 15 ms | Measured worst-case across temperature |
| FRTI total | 39 ms | Sum |
| FHTI (FDTI + FRTI) | 65 ms | Budget check |
| Margin (FTTI − FHTI) | 35 ms (35%) | Compliant |
That is a defensible budget. The opening scenario gets to 142 ms because the team forgot E2E latency (5 ms), under-counted sample confirmation (one sample instead of three — 8 ms under), missed OS jitter (5 ms), and assumed instant motor shutdown (15 ms under). The individual omissions look small; the sum breaks the safety goal.
Common Assessor Findings
Three findings show up repeatedly on ISO 26262 Part 8 Clause 6 timing reviews:
- FTTI and diagnostic test interval conflated. The diagnostic test interval (how often the safety mechanism runs) is not FDTI. If your mechanism runs every 10 ms but needs three consistent readings to declare a fault, your FDTI starts at 30 ms, not 10 ms.
- Latent fault detection interval ignored. For ASIL C/D items, multiple-point faults require that the multiple-point fault detection time interval from ISO 26262-5 Clause 7.4.2 be evaluated. For a dual-channel system, this is often minutes or hours, and it must be shown separately from FTTI.
- No traceability from FTTI to a hazard. FTTI must be backed by a documented hazard timing rationale — vehicle speed, actuator authority, driver response model. "Engineering judgment" is not acceptable for ASIL C/D.
AUTOSAR and Multi-Core Complications
On AUTOSAR Classic platforms with a safety partition, FTTI analysis must account for OS-level timing protection (TimingProtection, Classic Platform 4.4) and resource-lock contention between the QM and ASIL partitions. Two subtleties trip teams up:
- Memory protection fault reaction. If the safety mechanism is triggered by a memory protection unit (MPU) violation, the FRTI includes the trap-to-handler latency — often 1–2 µs on a Cortex-R52, but up to hundreds of microseconds if the handler must cross partition boundaries.
- Inter-partition communication. IOC (Inter-OS-Application Communication) adds a tick of latency. On a 1 ms task, that is a full millisecond of FDTI every time the safety mechanism talks across partitions.
For Adaptive AUTOSAR, the equivalent pitfalls are POSIX thread scheduling jitter and ara::com sample delivery latency, both of which vary with CPU load.
How ISO WIZ Handles FTTI Budgeting
FTTI budgets fail because the information is spread across documents — the HARA spreadsheet has the FTTI, the technical safety concept has the allocation, the software detailed design has the task periods, and the actuator datasheet has the response time. Nobody checks the sum.
ISO WIZ pulls these into a single linked model. An FTTI defined in the item definition is traced down to the FDTI and FRTI allocations on each contributing element. The platform sums them automatically and flags any chain where FDTI + FRTI + safety margin ≥ FTTI before the design review, not after. Because ISO WIZ is built around ISO 26262, ISO 21448, ISO 21434, and ASPICE in one schema, the timing contributors from SOTIF triggering conditions and cybersecurity incident response time are included in the same budget check. Cross-standard gaps — like an OTA rollback that exceeds the FTTI of the function it is updating — surface as red-flag findings rather than as assessor questions two months before SOP.
Try ISO WIZ on Your Timing Budgets
If your safety case still has "FTTI = 100 ms" sitting in a requirements spreadsheet with no formal budget decomposition, you have a finding waiting to happen. Spin up a project in ISO WIZ, import your safety goals, and let the platform build the FDTI/FRTI chain for each safety mechanism. You will see the margins — and the holes — inside of an hour. Start at isowiz.com.