2-out-of-3 voting fault tree: cut sets and exact probability

A 2-out-of-3 voting fault tree for three independent channels, each with failure probability 0.02, has three order-two minimal cut sets and an exact top-event probability of 0.001184, or 0.1184%. The top event occurs when any two or all three channels fail. Simply adding the three pair probabilities gives 0.0012; that rare-event approximation is an upper bound because the all-three-fail outcome appears in every pair and must be de-duplicated.

Scope: a static failure vote, not controller behavior

A voting gate is a compact Boolean statement. VOTING(2/3; A, B, C) means the gate output is true when at least two of its three input events are true. In this example, the inputs are failures, so the top event is loss of the 2-out-of-3 voting function. It is not the desired two-good-out-of-three success vote.

That polarity matters. A success-oriented reliability block diagram might say the system works while at least two channels work. The logically equivalent failure statement is that the system fails when at least two channels fail. NIST’s r-out-of-n model makes the boundary explicit: if at least two of three components must survive, the system fails at the second component failure.

The model here is static and coherent: adding a channel failure cannot restore the system. It does not represent vote timing, disagreement alarms, repair, diagnostic coverage, latent failures, bypasses, sequence dependence, or a software implementation of a voter.

Inputs and assumptions

The fictional protection measurement has three active channels. Any two healthy channels are sufficient for the voting function. For one defined demand or mission interval, each channel has the same probability of being in the failed state:

Input	Meaning	Value
p_A, p_B, p_C	probability that the named channel fails during the defined interval	0.02 each
k	number of channel failures required for the top event	2
n	total channels represented by the voting gate	3
dependence model	relationship among channel failures	mutually independent

The input 0.02 is illustrative. It is a dimensionless probability for one consistently defined interval, not a failure rate such as failures per hour. Multiplying a rate by time without checking the underlying life model, proof-test interval, repair state, and approximation would change the problem.

Independence is the load-bearing assumption. The worked arithmetic assumes no shared power loss, environmental cause, common design defect, common calibration error, shared communications fault, or voter failure. Those omitted events can dominate a real architecture even when the three channel symbols look redundant.

Reproducible Schematex source

faulttree "Loss of 2-out-of-3 voting"
  analysis: cutsets, probability
  prob: exact
  top VOTE_FAIL "At least two channels fail" = VOTING(2/3; A, B, C)
  basic A "Channel A fails" p: 0.02
  basic B "Channel B fails" p: 0.02
  basic C "Channel C fails" p: 0.02

This source was validated and rendered with Schematex 1.0.9 on August 14, 2026. The current fault-tree syntax reference documents voting-gate bounds, MOCUS minimal-cut-set analysis, and rare, mcub, and exact probability methods. That owned documentation establishes renderer behavior; IEC 61025, the NRC and NASA handbooks, and NIST establish the analysis scope and probability concepts used here.

Derive the three minimal cut sets

A cut set is a combination of basic events sufficient to cause the top event. A minimal cut set contains no event that can be removed while the combination remains sufficient. NASA’s handbook describes minimal cut sets as the smallest basic-event combinations that produce the top event.

For a 2-out-of-3 failure vote, every two-channel combination is sufficient:

C1 = {A, B}
C2 = {A, C}
C3 = {B, C}

Each set has order two. There is no order-one cut set, so no individual channel is a single point of failure in this limited model. {A, B, C} is a cut set but not a minimal cut set: remove any one event and the remaining pair still causes the top event.

This is also a structural invariant for the renderer. A correct expansion of VOTING(2/3; A, B, C) must produce C(3,2) = 3 minimal pairs. One pair is missing if only two cut sets appear; the threshold or input count is wrong if a singleton appears.

Calculate the exact top-event probability

There are two mutually exclusive ways to reach the threshold: exactly two channels fail, or all three fail. With identical independent channel failure probability p = 0.02, the binomial calculation is:

P(exactly 2 fail) = C(3,2) × p^2 × (1 - p)
                  = 3 × 0.02^2 × 0.98
                  = 3 × 0.0004 × 0.98
                  = 0.001176

P(exactly 3 fail) = C(3,3) × p^3
                  = 1 × 0.02^3
                  = 0.000008

P(at least 2 fail) = 0.001176 + 0.000008
                   = 0.001184
                   = 0.1184%

The complementary success probability is:

P(fewer than 2 fail) = 1 - 0.001184
                     = 0.998816
                     = 99.8816%

The units check is simple but essential: every term is a probability, so each result is dimensionless and lies between zero and one.

Why the rare-event sum is slightly high

Minimal cut sets overlap. If all three channels fail, then {A,B}, {A,C}, and {B,C} are all true at once. Adding their probabilities as though they were mutually exclusive counts that shared outcome more than once:

P_rare = P(A and B) + P(A and C) + P(B and C)
       = 3 × 0.02^2
       = 0.001200

Exact inclusion-exclusion removes the overlap:

P_exact = 3p^2 - 2p^3
        = 3 × 0.02^2 - 2 × 0.02^3
        = 0.001184

The absolute difference is 0.000016, or 0.0016 percentage points. Relative to the exact result, the rare-event sum is about 1.35% high. That is small in this example, but the gap grows as basic-event probabilities or cut-set overlap grow. A report must state which method produced its number; “top-event probability” is incomplete when the quantification method is hidden.

Schematex uses exact inclusion-exclusion because the source requests prob: exact; the rendered label rounds the independently checked 0.001184 result to 0.00118. Exact inclusion-exclusion is practical for this small tree. Large fault trees can make exact cut-set enumeration expensive, and specialized analysis may use binary decision diagrams, truncation controls, or other validated methods.

Checks before trusting the result

Use these invariants to catch polarity, threshold, and arithmetic errors:

1. k = 2 is within 1 ≤ k ≤ n = 3, and the declared n matches the three inputs.
2. Exactly three order-two minimal cut sets appear: {A,B}, {A,C}, and {B,C}.
3. No individual channel is a single point of failure in the stated model.
4. The all-three-fail combination is not listed as minimal because each pair already suffices.
5. The exact probability 0.001184 is below the rare-event upper bound 0.001200.
6. Setting any one channel probability to zero leaves one order-two failure pathway through the other two channels.
7. Setting two channel probabilities to zero makes the top-event probability zero.
8. Setting one channel probability to one reduces the remaining problem to an OR of the other two channel failures.

The NRC and NASA handbooks both emphasize that a fault tree is defined around a particular top event and analysis boundary. Passing these numerical checks cannot repair an incorrectly defined top event or an incomplete boundary.

Failure modes this clean vote omits

Common-cause failure. A shared cabinet temperature, power supply, specification defect, maintenance action, or environmental exposure can defeat more than one channel. Treating those failures as independent overstates the benefit of redundancy.

The voter itself. A real architecture may have shared voting logic, output circuitry, or communications. If voter failure can cause the top event, it belongs in the tree—often as an order-one cut set unless it is also redundant.

Detection and repair. A channel may fail silently and remain unavailable until a proof test. The relevant probability can depend on diagnostic coverage, test interval, repair time, and operating mode rather than one fixed p.

Different channel probabilities. If p_A, p_B, and p_C differ, do not use the identical-trial binomial shortcut. The exact union of the three pair events still works, but every product must retain its channel-specific probability.

Dynamic behavior. A static voting gate does not establish simultaneous sampling, deadline compliance, transition behavior, fail-safe output state, nuisance-trip performance, or correct PLC/SIS execution. Those claims require the actual hardware and software design, timing assumptions, and verification evidence.

Reproduce and challenge the model

Paste the source into the Schematex playground and run three perturbations. Change VOTING(2/3; …) to VOTING(3/3; …); the three pairs should collapse to the single order-three cut set {A,B,C}, and the probability should become 0.02^3 = 0.000008. Change it to VOTING(1/3; …); three order-one cut sets should appear. Finally, add a shared voter failure under an OR gate above the voting branch. That shared event should appear as a single point of failure and will usually dominate the fictional channel probabilities.