Voting Architectures in Safety Systems: 1oo1 vs 1oo2 vs 2oo2 vs 2oo3 Compared
More sensors don't automatically mean a safer system. How they vote against each other decides whether you get better safety, better uptime, or accidentally neither.
1oo1, 1oo2, 2oo2, and 2oo3 describe how redundant sensors, logic solvers, and final elements vote before a safety instrumented function acts. This guide compares all four architectures on safety, availability, and cost, with a simplified PFD calculator to show why the choice matters.
What is Voting Logic in a Safety Instrumented System?
A Safety Instrumented Function (SIF) rarely relies on a single sensor. Instead, it uses two, three, or more redundant devices, sensors, logic solvers, or final elements, arranged so that a defined number of them must agree before the function trips the process to a safe state. That agreement rule is called the voting architecture, written in "M-out-of-N" notation, or MooN: how many of the N channels must vote to trip (M) before the safety action actually occurs.
The choice of voting architecture is a deliberate tradeoff, not a free upgrade. Adding redundancy can make a system safer, more available, more expensive, or in the wrong configuration, actually less safe. Understanding what each of the four common architectures, 1oo1, 1oo2, 2oo2, and 2oo3, actually does is essential before specifying a Safety Instrumented System (SIS).
Real Life Example
Think of three friends deciding whether to pull a fire alarm. If any one of them can pull it alone (1oo2-style, with two friends present), you get a fast response but a higher chance of a false alarm if one friend panics unnecessarily. If both must agree before pulling it (2oo2-style), false alarms almost disappear, but so does your protection if one friend is asleep during a real fire. Add a third friend and require any two of the three to agree (2oo3-style), and you get the best of both worlds, at the cost of recruiting and coordinating a third person.
The Four Common Voting Architectures
1oo1 (One-out-of-One)
1oo2 (One-out-of-Two)
2oo2 (Two-out-of-Two)
2oo3 (Two-out-of-Three)
Comparison Table
Simplified PFD Comparison Calculator
Voting Architecture PFD Comparison
Simplified, ignores common cause failure and test interval effectsCommon Voting Architecture Mistakes
✅ Do This
- Match the architecture to the required SIL, not just to available budget
- Use 2oo3 when both high safety and high uptime genuinely matter
- Account for common cause failure (beta factor) in any real PFD calculation
- Plan proof testing procedures for each architecture before installation
❌ Avoid This
- Choosing 2oo2 for a genuinely high-consequence safety function
- Assuming more redundant channels always means a safer system
- Ignoring that testing a 1oo2 system temporarily drops it to 1oo1 coverage
- Mixing up fail-safe and fault-tolerant behavior for the same MooN notation
Voting Architectures in Safety Systems: Video Walkthrough
Frequently Asked Questions About Voting Architectures
- Kenexis, Comparison of Voting Arrangements in SIS
- Inst Tools, Voting Logic in Safety Instrumented System (SIS)
- InstruNexus, Functional Safety Architectures: 1oo1 vs 1oo2 vs 2oo2 vs 2oo3
What We Learn Today
- Voting architecture (MooN notation) defines how many redundant channels must agree before a safety function trips
- 1oo2 favors safety, 2oo2 favors availability, and 2oo3 balances both at a higher hardware cost
- More redundancy does not automatically mean more safety, the voting rule determines the actual outcome
- Required SIL under IEC 61508 directly constrains which architectures are permitted for a given application
- Proof testing procedures and common cause failure must be planned for and accounted for in any real PFD calculation