Redundancy, HFT, and Voting in Safety Systems

16 August 2014 · Dr. Michel Houtermans · 5 min read
Redundancy, HFT, and Voting in Safety Systems

Redundancy, HFT, and voting are often used interchangeably in functional safety, but they are not the same. Understanding the difference is essential to correctly design and assess safety architectures.

Redundancy

We often get the question of whether HFT (hardware fault tolerance) is equal to redundancy. The answer is no. To understand why, we first need to understand three terms: redundancy, HFT, and voting.

In the technical world, everybody seems to know the word redundancy, and yet it can be very confusing. Especially when you try to express it in a number, i.e., how much redundant is a design?

Redundancy can be defined as a system function which is designed in such a way that there are multiple means (parts, components, devices, software, etc.) to carry out the function so that the function will not fail if one or more of these means fails.

Redundancy is not determined by the number of similar parts or devices you see. Whether there is redundancy or not is solely determined by the function that you carry out with these parts or devices.

redundancy 1oo2 2oo2 valves

Is this redundant or not?

Well, that depends on the function that is being carried out with these two valves. If the function is to stop the flow upon demand and both valves are open during normal operation, then only one valve must close and stop the flow. In other words, if one valve is stuck open (a dangerous failure), the function will still work as the other valve can close. This would be redundancy and is a so-called 1oo2 architecture design.

If, on the other hand, the function is to open the flow and both valves are closed during normal operation, then both valves need to open in order to start the flow. If one valve is stuck closed (in this case, also a dangerous failure), the function cannot be carried out, even if the other valve opens. This is not redundancy; the valves are in a so-called 2oo2 architecture design.

In the first case, we are redundant but how much redundant? Some cultures call it redundant, others say it is two redundant, but the correct way to express it is one redundant. One valve is needed to stop the flow, and there is one additional valve in case the other fails.

The key question is: do multiple devices automatically mean redundancy, or does redundancy depend on how the function is designed?

HFT and Voting

In the functional safety business, we use the term HFT to express whether we have redundancy or not. When a design has an HFT of X, it means that it can tolerate X dangerous failures, and it still works. X+1 dangerous failures, and it does not work any more.

HFT can easily be calculated if the architecture is known, i.e., 1oo1, 1oo2, 2oo3, etc. If the architecture is expressed as MooN, then the HFT is calculated as N – M. In other words, a 2oo4 architecture has an HFT of 2. This means it can tolerate two failures, and it still works; thus, it is an architecture with redundancy.

But how much redundant is it? This is where voting becomes important.

Voting is the number of paths that must work out of the total number of paths available. A 2oo2 has two paths available, but also, two paths need to work. If one path fails, it does not work any more, even if the other path is available. Hence a 2oo2 has no redundancy.

So just because you see two valves does not mean you have redundancy. You need to know how much voting is needed.

Redundancy is not about how many components you have. It is about whether the function still works when one of them fails.

Architecture Comparison

The table below shows how architecture, voting, HFT, and redundancy relate to each other.

Architecture Voting HFT Redundancy
1oo1 1 0 0
1oo2 1 1 1
2oo2 2 0 0
2oo3 2 1 1
2oo4 2 2 3
3oo3 3 0 0

Do you notice anything special? HFT looks like it is equal to redundancy, but with 2oo4, it is not. Which automatically means that hardware fault tolerance is not a measure of redundancy. It is not the same.

If HFT is larger than zero, you know you have redundancy, but you do not know how much.

Understanding Redundancy in 2oo4

Let's assume we have four transmitters, A, B, C, and D, in a 2oo4 architecture. This means we have the following options to carry out our desired function: AB, AC, AD, BC, BD, and CD.

In order to know how much redundant we are, we need to know how many options are left if a similar device has failed.

If one transmitter fails, does it still work? If it does, we have redundancy. Let's assume A fails, then we have the following options left: AB, AC, AD, BC, BD, and CD. In other words, after one failure, we have three options left, and thus we are three redundant after one failure. We are one redundant after two failures.

Important: HFT tells you how many failures you can tolerate. It does not tell you how much redundancy you have.

Practical Conclusion

My preference is to use HFT instead of trying to count redundancy. It expresses better what we want to know in the first place: how many failures can the system tolerate and still perform its safety function.

Understanding the difference between redundancy, HFT, and voting helps prevent incorrect assumptions and leads to better safety system design.


Go deeper — IEC 61508 Course

Our IEC 61508 course explains system architectures, HFT, voting logic, and how to correctly design and assess redundancy in safety systems.

Explore the course → Ask us a question

We use cookies
Cookie preferences
Below you may find information about the purposes for which we and our partners use cookies and process data. You can exercise your preferences for processing, and/or see details on our partners' websites.
Analytical cookies Disable all
Functional cookies
Other cookies
We use cookies to personalize content and ads, to provide social media features and to analyze our traffic. Learn more about our cookie policy.
Accept all Decline all Change preferences
Cookies