What Is Safe Failure Fraction (SFF)? How It Affects Your SIL Capability

Safe failure fraction is the proportion of an element’s failures that are either inherently safe or detected by diagnostics. Put simply, SFF = (safe failures + detected dangerous failures) divided by total failures. It matters because IEC 61508 pairs SFF with hardware fault tolerance to set a ceiling on the SIL an element is permitted to claim. Higher SFF and higher fault tolerance push that ceiling up. But SFF is a limit on what you can claim, not proof that you got there.

That distinction trips up a lot of teams. They calculate a healthy SFF, see the architectural constraint table turn green, and assume the SIL is in the bag. Then the failure-rate math comes back short, or an assessor asks why the safe failures got counted the way they did.

This post covers what SFF actually measures, how it differs from diagnostic coverage, how it combines with hardware fault tolerance to cap your SIL, and the mistakes that quietly inflate the number.

What Safe Failure Fraction Actually Measures

Every failure mode in a safety-related element falls into one of a few buckets. Some failures move the element toward a safe state (a sensor reads zero, an output de-energizes). Some are dangerous: they leave the safety function unable to act when a demand arrives. Among the dangerous ones, diagnostics catch some (detected) and miss others (undetected).

SFF rolls those buckets into a single ratio:

SFF = (λ_S + λ_DD) / (λ_S + λ_DD + λ_DU)

Here λ_S is the rate of safe failures, λ_DD is detected dangerous failures, and λ_DU is undetected dangerous failures. The numerator credits everything that is either safe or caught. The denominator is the full population of failures that the analysis considers. What is left out of the numerator, the undetected dangerous failures, is the part that actually hurts you.

So SFF answers one question: of all the ways this element can fail, what fraction land somewhere you can live with? A high number says most failures are benign or visible. A low number says a meaningful slice of failures are dangerous and silent.

How SFF Differs From Diagnostic Coverage

These two figures get confused constantly, and the confusion shows up in real safety files. Diagnostic coverage counts only dangerous failures. It asks: of the dangerous failures, what fraction do my diagnostics detect? Safe failures never enter the DC calculation at all.

SFF is wider. It credits safe failures and detected dangerous failures together. That single difference has a consequence worth sitting with: an element can post a strong SFF on the strength of its safe failures alone, even when its diagnostic coverage is mediocre.

Picture a device where two-thirds of all failures happen to be inherently safe. Even with weak diagnostics, that device can show an SFF north of 70% simply because the safe failures fill the numerator. DC would tell a much less flattering story, because DC ignores those safe failures entirely and reports only how many of the dangerous failures got caught.

The practical takeaway: DC describes the quality of your diagnostics. SFF describes the overall failure character of the element, including luck. They are not the same lever, and you cannot substitute one for the other when you read the architectural constraint tables.

How SFF and Hardware Fault Tolerance Set Your SIL Ceiling

This is where SFF earns its keep. IEC 61508 offers an architectural route, often called Route 1H, that uses SFF together with hardware fault tolerance (HFT) to cap the maximum SIL an element may claim. HFT is the number of faults an element can tolerate and still perform the safety function. An HFT of 0 means a single dangerous fault defeats it; an HFT of 1 means it survives one fault and needs two to fail.

The logic is intuitive once you see it. More fault tolerance plus a higher safe failure fraction equals a higher achievable SIL. You buy SIL capability with redundancy, with diagnostics, or with a failure profile that tilts toward safe. The standard expresses this as a lookup: find your HFT row, find your SFF band column, read the maximum SIL.

Here is the conceptual relationship for a Type B element, the more complex category that covers most programmable hardware:

Read one cell and the pattern is clear. A single-channel Type B element (HFT = 0) with an SFF below 60% cannot be used in a safety function at all under this route. Push that same element to an SFF of 90% or better and it reaches SIL 2. Add a redundant channel to get HFT = 1 and the ceiling climbs again.

Two cautions about the table. First, Type A elements (simple, well-characterized failure behavior) use a different and more permissive table than the Type B values shown here. Classifying your element wrong means reading the wrong table. Second, this is the conceptual structure for orientation. The governing values live in the current edition of IEC 61508, and that is what your assessment must reference.

SFF Is a Ceiling, Not a Guarantee

This is the point most worth holding onto. Clearing the SFF and HFT table tells you the maximum SIL your architecture is allowed to claim. It does not tell you that you achieved it.

The architectural constraints are one of two gates. The other is the quantitative target: your element still has to meet the required PFH (probability of dangerous failure per hour) or PFD (average probability of failure on demand) for the SIL you want. That number comes from the probabilistic failure model, and it is driven hard by the undetected dangerous failure rate, the same λ_DU that SFF politely leaves out of its numerator.

So you can have an element that sails through the SFF table at SIL 3 and still misses the PFH target for SIL 3. In that case the element does not achieve SIL 3, full stop. The table gave you permission to aim there. The math decides whether you land.

Treating SFF as the finish line is how teams end up surprised late in a program, when the reliability calculation finally runs and the architecture they committed to cannot carry the load.

Where SFF Estimation Goes Wrong

A handful of mistakes account for most of the trouble.

Over-crediting safe failures. Because safe failures sit in the SFF numerator, there is a temptation to classify ambiguous failure modes as safe. Every generous classification inflates SFF and weakens the safety argument. The FMEDA has to justify why each mode is genuinely safe, not merely convenient.

Mishandling no-effect failures. Some failure modes have no effect on the safety function. How you treat them changes the denominator and therefore the ratio. Sweeping no-effect failures into the safe bucket is a common way to nudge SFF upward without doing any real engineering.

Confusing SFF with DC. Plugging a diagnostic coverage figure into a place that wants SFF, or vice versa, produces a number that looks plausible and is wrong. The two are calculated differently and credit different failures.

Treating SFF as the whole SIL story. Covered above, but it bears repeating because it is the costliest error. SFF caps the claim. PFH and PFD still have to be met independently.

That tracking burden is part of why roughly 60% of safety engineering time gets spent on documentation rather than design. SFF, DC, HFT, and the failure-rate math all draw on the same FMEDA, yet they usually live in disconnected spreadsheets. Change a component and every one of them has to be reconciled by hand.

How ASAP Keeps SFF Tied to the Architecture

A reliability model is only useful if it stays honest as the design moves. ASAP tracks SFF, diagnostic coverage, and hardware fault tolerance together and ties them to the architecture they describe. When you change a component’s failure classification or add a redundant channel, the achievable SIL recalculates against the architectural constraints and the quantitative target in the same pass. As a web-based alternative to a desktop reliability calculator, it keeps that model accessible to the whole team rather than locked on one engineer’s machine.

This matters because the failure modes feeding SFF are the same modes feeding your PFH calculation. When both draw from one model, a generous safe-failure classification cannot quietly help your SFF while it hurts your dangerous-failure math somewhere else in a different file. The numbers stay consistent because they come from one source.

The reliability modeling in ASAP is AI-assisted and human-verified: the platform surfaces classifications and calculations, and a safety engineer confirms every judgment that enters the record. Fennec's specified ASAP tools are qualified by TÜV Rheinland as Tool Class 2 (T2) offline support tools under IEC 61508-3:2010, Clause 7.4.4. Reliability UI 0.5.181 is within the reported scope.safety case without a separate round of tool validation on your part.