The fault-tolerant time interval, or FTTI, is the maximum time a dangerous fault can exist in a process before a hazardous event occurs. It sets the outer time budget that a safety instrumented system must fit inside: everything from detecting the fault, to deciding to act, to physically moving the final element has to finish before the FTTI elapses. It is closely related to process safety time but is framed from the fault side rather than the deviation side, which is why engineers treat it as a separate budgeting exercise. Getting the FTTI right decides how fast your logic scans and how quickly your shutdown valves have to slam closed.
Fault-tolerant time interval (FTTI) in one line: The fault-tolerant time interval (FTTI) is the total time from the moment a dangerous fault occurs until a hazardous event happens if nothing intervenes. A safety instrumented system must detect the fault and drive the process to a safe state well within this window, so the FTTI is used to budget diagnostic intervals, fault reaction time and final-element stroke time.
The fault-tolerant time interval starts the clock at the instant a dangerous fault appears in the process or in a component whose failure allows the process to run toward danger. It ends at the point where a hazardous event becomes unavoidable, meaning the process has crossed into a state where damage, release or injury will follow. Everything a protective system needs to do has to be complete before that endpoint. Because it is bounded by the physics of the process rather than by the equipment, the FTTI is a property of the hazard, not of the safety system you happen to install.
It is easy to confuse the FTTI with process safety time, and the two are related, but they are framed differently. Process safety time is usually described from the onset of a process deviation to the point where the hazard is reached. The FTTI is described from the onset of a fault to that same hazardous point, so it is the natural budget to use when you are reasoning about component failures and diagnostics rather than about a single measured process variable drifting out of range. In practice many teams treat the shorter of the two as the hard limit and design against it.
The important design consequence is that the FTTI is a fixed amount of time you cannot negotiate. You do not get to make it longer by buying faster equipment; it is set by how quickly the process can hurt someone once a fault is present. Everything that follows is about carving that fixed budget into pieces and making sure the sum of those pieces stays comfortably under the total, with margin left over so that a slightly slow valve or a delayed scan does not tip you over the edge.
The FTTI is spent in three main chunks. First is detection: how long it takes for the fault to be noticed, which for undetected faults depends on the diagnostic test interval and for process faults depends on the sensor scan rate. Second is fault reaction time: the time the logic solver takes to decide the safe action and command the outputs once the fault is known. Third is final-element response: the stroke time of the shutdown valve or the de-energise time of the trip relay, including any actuator travel and solenoid delay. Added together, these must land well inside the FTTI.
A widely used rule of thumb is that the diagnostic-plus-reaction time should be significantly shorter than the process safety time or FTTI, often by a comfortable factor rather than just squeaking under it. The reason is that the FTTI is an absolute deadline, and real equipment has scatter: a valve that normally strokes in a few seconds might be sluggish on a cold morning, and a diagnostic that usually fires on the next scan might slip a cycle. Building in margin means the safety function still succeeds on its bad days, not just its average ones.
This budgeting is what turns an abstract time into concrete equipment specifications. If the FTTI is short, you may need a faster logic scan, a higher diagnostic test frequency, or a valve with a quick-exhaust actuator and a larger solenoid to shave stroke time. If the FTTI is long, you have room to relax those requirements and save cost. The FTTI is therefore the number that quietly drives sizing decisions on actuators, the choice of scan rate on the logic solver, and how aggressively self-tests are scheduled.
The FTTI belongs to the safety instrumented system and its trip decision must be made locally, in the logic solver, because no cloud path can be trusted to meet a hard millisecond-scale or second-scale deadline. A cloud SCADA platform sits alongside that safety layer rather than inside its timing budget. That distinction matters: monitoring should never be counted on to detect the fault or make the trip, because the round trip to a data centre and back is nowhere near fast enough for most FTTI budgets and is not designed to be.
Where a monitoring platform earns its place is in proving that the timing assumptions behind the FTTI still hold. Time-stamped event logs streamed to a cloud historian let you measure the real interval between a trip initiation and the valve reaching its closed limit switch, so you can confirm the actual stroke time against the number you budgeted. If valves are drifting slower over months of service, that trend is visible long before it eats into the FTTI margin, and maintenance can act on it. In an oil and gas setting where a shutdown valve might sit untouched for a year between demands, that visibility is genuinely useful.
A cloud layer also helps verify that diagnostics are firing at the interval the FTTI budget assumed. If a self-test is scheduled to run on a cadence and the event stream shows it has gone quiet, that is a sign the detection slice of the budget is no longer being honoured. Merobix and similar cloud SCADA tools give operations and functional-safety engineers a shared, historical view of these timings without touching the safety logic itself, so the analysis stays honest and the safety system stays independent.
They are closely related but framed from different start points. Process safety time is usually measured from the onset of a process deviation to the hazard, while the FTTI is measured from the onset of a fault to the same hazard. Many engineers design against whichever is shorter and treat it as the hard deadline the safety function must beat.
The FTTI sets the total time available, and the final-element stroke time is one slice of that budget. If the FTTI is short, the shutdown valve must close quickly, which can require a larger actuator, a quick-exhaust valve or a bigger solenoid. A longer FTTI relaxes those requirements and can save cost, so the interval effectively drives actuator selection.
The FTTI is an absolute deadline set by the process, and real equipment varies from day to day. Leaving generous margin between the diagnostic-plus-reaction time and the FTTI means the safety function still succeeds when a valve strokes slowly or a diagnostic slips a scan, rather than only under ideal conditions.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.