HFT for Safety Availability, HFTs for Process Availability — What You Need to Know

A 1oo2 and a 2oo3 have the same HFT. The safety case looks identical, so engineers pick 1oo2 — and they are right on safety. They are wrong on process availability, and that mistake has consequences.

The Architecture Decision Engineers Get Half Right

When you select a safety architecture, you are answering two distinct questions:

1. If a dangerous failure occurs, does the safety function still work?
2. If a safe failure occurs, does the process keep running?

HFT answers question one. That is the measure most engineers reach for, and IEC 61508 defines it clearly. What is less widely understood is that question two has its own measure — one that Risknowlogy introduced as HFTs (Hardware Fault Tolerance for Safe failures).

What HFT Measures — and What It Does Not

HFT is the number of dangerous failures a subsystem can absorb before the safety function is lost.

For any MooN system: HFT = N − M

A 2oo3 system: HFT = 3 − 2 = 1. The safety function survives one dangerous failure. A second dangerous failure loses it.

HFT is a measure of safety availability. It says nothing about what happens when a safe failure occurs — a failure that causes the safety function to go to the safe state when it should not.

What HFTs Measures

HFTs is the number of safe failures a subsystem can absorb before it trips the process.

For any MooN system: HFTs = M − 1

A 2oo3 system: HFTs = 2 − 1 = 1. One safe failure is absorbed. A second safe failure causes a spurious trip — process shutdown, lost production, and potentially a process hazard if unplanned shutdown is itself dangerous. Including the startup aftwards.

A 1oo2 system: HFTs = 1 − 1 = 0. The first safe failure trips the process. There is no tolerance.

HFTs is a Risknowlogy extension of the IEC framework. It applies the same MooN voting logic to safe failures rather than dangerous failures.

The Six Standard Architectures Side by Side

Three pairs emerge, grouped by HFT. Within each pair, HFTs is the only differentiator.

HFT = 0: 1oo1 and 2oo2 offer identical safety availability. But 2oo2 tolerates one safe failure before a spurious trip. 1oo1 tolerates none. The cost of that tolerance is one extra channel.

HFT = 1: 1oo2 and 2oo3 are equivalent on safety availability. 2oo3 has HFTs = 1; 1oo2 has HFTs = 0. One safe failure trips 1oo2 every time. 2oo3 absorbs it.

HFT = 2: 1oo3 and 2oo4 both achieve high safety availability — two dangerous failures can occur and the safety function remains active. But 1oo3 has HFTs = 0. A single safe failure shuts the process down. 2oo4 absorbs one before tripping.

The Real Cost of Getting This Wrong

The 1oo2 versus 2oo3 choice comes up often. Both have HFT = 1. Engineers choose based on HFT alone, because the safety case looks identical.

In a process where safe failures are infrequent, that choice may be fine. In a process where sensors drift or trip regularly, 1oo2 will shut the plant down every time one sensor fails safe. That is lost production. In some processes — where unplanned shutdown creates its own hazards — it is also a safety problem.

What to Do Before Finalising Your Architecture

Calculate both HFT and HFTs for every architecture under consideration. Then verify two constraints separately:

• Does the architecture meet the SIL requirement? That is an HFT and PFD check.
• Does the architecture meet the spurious trip target? That is an HFTs and STL check.

If you only check HFT, have you actually selected the right architecture — or just half of it?

These are independent constraints. Satisfying one does not satisfy the other.