Whether the fault actually gets detected and reacted to before the hazard — with the worst case taken honestly: a full test interval per confirmation, not half of one. And the number you really want, which is the largest diagnostic test interval the budget can afford.
Runs entirely in your browser. Nothing is uploaded, stored, or sent anywhere.
Hardware metrics get the attention in ISO 26262 work, and the timing budget often gets a sentence. But a diagnostic that detects a fault reliably and reports it after the hazard has already happened contributes nothing to safety, however good its coverage number looks in the FMEDA. The fault tolerant time interval is the constraint that decides whether a mechanism is real or decorative.
The definition is simple enough. The FTTI is the time from a fault occurring to a hazardous event occurring, if nothing intervenes. Everything the system does about the fault — noticing it and reacting to it — has to fit inside that window, with margin:
FHTI = N × DTI + t_exec + FRTI ≤ FTTI × (1 − margin)Two things in that expression get underestimated, and both make the budget look healthier than it is.
The first is that a periodic test's worst-case latency is a full interval, not half of one. A fault does not politely arrive just before the check; assume it arrives immediately after one completes, so it waits the whole interval before the next test can see it. Averages have no place in a worst-case timing argument.
The second is the confirmation filter. Almost every real diagnostic requires the fault to be seen some number of times in a row before it reacts, because reacting to a single noisy sample causes nuisance trips and unhappy customers. That count multiplies the interval. A 10 ms test with three confirmations has a 30 ms worst-case detection latency, and the confirmation count is usually a constant somewhere in the code that was raised during noise debugging without anyone revisiting the safety timing. It is the most common reason a budget that closed on paper does not close in the built system.
In practice you rarely get to choose the FTTI — it falls out of the hazard analysis and the physics of the item. The reaction time is usually fixed too, because it is a contactor opening or a motor de-energising. What you actually control is the test interval, so the useful question is not "does this fit" but "what interval can I afford", which is what the fourth tile above reports. That figure is what should go into the software requirement, rather than a round number chosen because it looked reasonable.
The default here reserves 20 %. That is a working convention, not a requirement from the standard, and it exists because every term in the budget is optimistic when first estimated: scheduler jitter, an interrupt that delays the check, a slower part at temperature, the worst-case path through the reaction code rather than the typical one. If you can measure the terms on real hardware at temperature you can defend a smaller margin. If they are estimates, a budget that closes with 2 % to spare has not really closed.
Everything above concerns single-point faults, where the timing constraint is milliseconds. The latent-fault side of the argument uses a different interval entirely — typically a driving cycle, a power-on self-test, or a workshop service interval — because a latent fault is only dangerous in combination with a second one, and the exposure that matters is the time both can sit undetected. That is why a power-on BIST can carry a latent-fault claim it could never carry for single-point faults. The safety mechanism selector marks which mechanisms address which of the two.
Once the timing closes, the metrics are the other half: the FIT and PMHF calculator turns coverage into SPFM, LFM and PMHF for one element, and the FMEDA rollup takes it to a system figure. If the timing does not close and no faster diagnostic exists, decomposition is sometimes the way out — a second, faster, independent element carrying part of the goal.
Each of these runs entirely in your browser. Nothing is uploaded, stored or sent anywhere, and none of them needs an email address.
See all 49 engineering tools →
We add tools here fairly often and write up the things worth writing up — a stackup that behaved oddly, a standard that turned out to be obsolete, a calculator that was quietly wrong. Join and you get told when something new lands.
One email a month at the very most, and usually less. No drip sequence, no sales cadence, no sharing your address with anyone. Unsubscribe whenever you like.