Common-cause failure — Beta-factor vs Multiple Greek Letter

Why redundancy can lie to you

Suppose you have three identical sensors voting 2-of-3 on a critical reading. Each sensor fails on demand with probability p = 10⁻³. If the three are independent, the system fails (≥ 2 of 3 fail) with probability roughly 3p² ≈ 3×10⁻⁶ — a thousand-fold improvement on a single sensor. That's the whole point of redundancy.

Now suppose 5% of sensor failures actually share a root cause — say a sub-batch from a particular wafer that drifts identically with temperature. Failure of that sub-batch takes out all three sensors at once, with no more probability than a single sensor. The system failure rate becomes approximately:

P(system fail) ≈ P(common-cause failure) + P(at least 2 independent fails)
              ≈ β·p + 3·(1−β)²·p²
              ≈ 0.05 × 10⁻³ + 3 × 0.95² × 10⁻⁶
              ≈ 5×10⁻⁵ + 2.7×10⁻⁶
              ≈ 5.3×10⁻⁵

The β·p term — common-cause — dominates. The redundancy that ostensibly bought a 1000× improvement bought a 19× improvement instead. Five percent of failures sharing a cause cost you most of your supposed reliability gain.

That's the whole story of CCF in two paragraphs. The rest of the modelling work is choosing the right value of β (or the right MGL vector), defending it to a regulator, and integrating it into the fault tree without breaking other assumptions. The two models — β-factor and MGL — are different choices on the spectrum of "how much detail do I need?", and the right answer depends on how many redundant components you have, how good your CCF data is, and how much the regulator cares about distinguishing dual-component CCF from triple-component CCF.

Step 1How CCF appears in a fault tree

Without CCF, a 2-of-3 redundant system shows up in the fault tree as an explicit AND of two ORs (or via a voting gate). All cut sets are pairs of independent component failures. Quantitatively:

P(SYS) ≈ Σ over 2-fail cuts: P(Ci) × P(Cj)
       = 3 p² (for identical components)

With CCF, you add a single new basic event — call it CCF123 — that represents "the common cause that fails all three components at once". This basic event sits as a child of a new OR gate at every place a 2-of-3 vote previously was, and the model now reads:

P(SYS) = P(CCF123) + P(at least 2 of {C1,C2,C3} fail independently)
       = β·p + 3(1−β)²p²

The cut-set structure changes too — the new minimal cut sets are {CCF123} (order 1) plus the original three pairwise cuts (order 2). MOCUS treats the CCF event as just another basic event, which is why the algorithm doesn't need any modification to handle it; the work happens in how you assign the CCF event's probability, which is what the β-factor and MGL models exist to specify.

Two requirements before the CCF basic event makes sense:

• You have to declare a CCF group. A group is a set of components believed to share a potential common cause — typically components of the same type, from the same vendor, on the same maintenance schedule, in the same physical location, running the same firmware. The CCF group is what gets a β-factor (or an MGL vector); individual components don't.
• The components in the group have to be otherwise independent. If two components already share an explicit dependency in the tree (e.g. a common power supply already modelled as a basic event), they shouldn't also be in a CCF group for the same dependency. Double-counting CCF on top of an explicit dependency over-estimates the failure probability and is a common review finding.

Step 2The Beta-factor model — one number, conservative bound

The β-factor model is the simplest possible CCF model. It has a single parameter:

β = (rate of failures that are common-cause)
    ────────────────────────────────────────
            (total failure rate)

Equivalently, given a component fails, β is the probability the failure is part of a common-cause event rather than an isolated independent failure. There is no further structure: β doesn't distinguish "CCF takes out 2 components" from "CCF takes out all m components in the group". Implicitly, β-factor assumes every CCF event affects the entire group.

For a CCF group of m identical components with per-component failure probability p, the basic events become:

P(component i fails independently) = (1 − β) · p
P(CCF event taking out all m components) = β · p

Typical values, drawn from the standards-supplied tables:

The β-factor model's strengths and weaknesses both follow from its simplicity:

• Easy to defend and easy to specify. One number, one regulatory conversation. The standards even ship with checklists (IEC 61508-6 Annex D scoring system, NUREG-CR-5485 stress factors) that map design choices to a recommended β.
• Always conservative for "all-fail" requirements. If the system fails only when all m components fail simultaneously (e.g. 1-of-m voting), assigning the entire CCF mass to "all m fail" gives the right answer or a slight overestimate. Good for SIL claims that need worst-case bounding.
• Can be non-conservative for partial-failure voting systems. For 2-of-m voting, partial CCFs (CCF affects 2 components, leaves the others good) also defeat the system. β-factor doesn't model these explicitly — it lumps all CCF into the all-fail event. We'll see in Step 3 how this can under-count system failure rate, contrary to the common intuition that β is "always conservative".
• Indistinguishable from a single-channel system at high β. If β = 0.5 on a 2-redundant system, the CCF rate (β·p = 0.5p) approaches the single-channel rate. Beyond β ≈ 0.3 the model is telling you the redundancy isn't really there; check whether the components really should be in the same CCF group.

The β-factor model is what you should reach for first. For most automotive, process and small-aerospace systems, its single-number simplicity is exactly the right level of detail.

Step 3Multiple Greek Letter — vector of conditional probabilities

MGL refines β by asking: given a CCF event has happened, how far does it propagate? Instead of one number, MGL gives a vector of conditional propagation probabilities, one per group size:

β = P(CCF involves ≥ 2 components | a failure occurred)
γ = P(CCF involves ≥ 3 components | CCF involves ≥ 2)
δ = P(CCF involves ≥ 4 components | CCF involves ≥ 3)
... and so on for larger groups.

For a group of size m, the model has m − 1 parameters (β, γ, δ, …). β-factor is the special case where γ = δ = … = 1 — every CCF propagates all the way. MGL allows γ < 1 to model the realistic case where a common cause sometimes only affects a subset of the group.

For a 3-component group, the per-component probability mass redistributes as:

P(component fails alone)            = (1 − β) · p
P(specific pair fails as CCF)        = β · (1 − γ) · p / 2
P(all three fail as CCF)             = β · γ · p

The factor of 2 in the pair line is because there are 3 distinct pairs sharing the β·(1−γ)·p mass, and each component sits in 2 of them.

Where MGL diverges from β-factor

The two models give the same total CCF mass per component (β·p), but distribute it differently across the possible CCF event sizes. The system failure rate they predict therefore depends on which CCF sizes actually defeat the system:

That second row is the counter-intuitive one. β-factor is widely characterised as "conservative" because it assigns all CCF mass to the worst-case all-fail event. For voting systems where partial CCFs also defeat the vote — which is most real redundancy designs — β-factor actually under-counts system failure rate, by a factor that grows with (1−γ). Step 4 quantifies the gap on a 2-of-3 example.

When to reach for MGL

• CCF group size m ≥ 4. The β/γ/δ vector has more degrees of freedom to capture the propagation curve; treating a 4-component group as β-factor only collapses too much information.
• Voting systems with partial-failure thresholds. 2-of-4, 2-of-3, k-of-m where 1 < k < m. β-factor under-counts; MGL gets it right.
• You have CCF data sufficient to estimate γ defensibly. Industry CCF databases (NUREG-CR-6268 for nuclear, IEEE 500 for instrumentation) publish γ-equivalent values. If your industry doesn't have a comparable database, defending a γ < 1 is hard and you might as well stay with β-factor.
• Regulator explicitly asks for it. NRC PRAs use MGL or its sibling alpha-factor model by default; some EASA submissions request the more granular model for catastrophic-class hazards.

Step 4Worked 2-of-3 — putting numbers on the disagreement

To make the divergence concrete, take a 2-of-3 voting system of identical pressure transducers in a process control loop. Each transducer fails per demand with probability p = 10⁻³. Total CCF fraction β = 0.05 — i.e. one in twenty failures shares a common cause. The voting fails if any 2 (or all 3) transducers fail simultaneously.

Compute the system failure probability under four assumptions: pure independence (no CCF modelled), β-factor (equivalently MGL with γ = 1), and MGL with two values of γ — 0.7 (CCF strongly propagates) and 0.3 (CCF often only takes out a pair):

Three observations:

• CCF dominates the answer. The "≥ 2 independent" column is roughly 3×10⁻⁶ in every row — the redundancy is doing its job for that mode. The CCF columns add 50 × that. CCF is the gating constraint, full stop.
• β-factor under-estimates the answer for 2-of-3 voting. By 14% at γ = 0.7, by 34% at γ = 0.3. The mass that β-factor assigns entirely to triple CCF (5×10⁻⁵) is split by MGL between triple-CCF and pair-CCF, and pair-CCFs also defeat 2-of-3 voting — but at a higher event count (3 distinct pairs vs 1 triple). The pair-CCF entry can therefore dominate when γ is small.
• The total CCF mass per component (β·p) is constant. All four CCF rows allocate β·p = 5×10⁻⁵ of failure-rate budget to common-cause events; they just distribute it differently across CCF event sizes. This is the conservation law that makes the three models inter-translatable.

The same exercise on 1-of-3 voting

Now switch the voting to 1-of-3 (system fails only when all three transducers fail). Same components, same β, same γ values:

The picture inverts. Under 1-of-3 voting only triple-CCFs defeat the system, so β-factor (which assigns all CCF mass to triple) gives the highest answer, and MGL with γ < 1 gives a lower number. β-factor is conservative here — by exactly the factor 1/γ.

Same components, same models, same parameters. The "is β-factor conservative or non-conservative?" question has no answer in the abstract; it has an answer per voting topology, and the sign of the answer flips between adjacent topologies.

What this means for design and review

• If the safety case rests on a 2-of-N voting system, defaulting to β-factor is risky. The model under-counts failure rate, the SIL claim is optimistic, and a reviewer with MGL data can demolish the calculation. For 2-of-3 / 2-of-4 / k-of-m where 1 < k < m, run both and report whichever is more conservative — or ideally MGL with industry-typical γ.
• For 1-of-N voting (fail-safe systems where any survivor protects), β-factor is conservatively safe. If you're claiming an SIL using 1-of-3 redundancy, β-factor's over-estimate is in the safe direction. MGL would give a better number, but β-factor's claim still holds.
• Importance measures interact strongly with CCF events. The CCF basic event sits in an order-1 cut set (it alone fails the system), so its F-V importance is dominant. After introducing CCF, expect the importance ranking to be led by the CCF event itself, with the individual component events demoted. This is the design-conversation outcome of the analysis: whether to invest in component reliability or in defending the common cause (diversity, separation, staggered maintenance).

Step 5Which standards specify which model

Mapping the three CCF models to the standards reveals defaults rather than mandates — most standards permit any of the models with adequate justification, but each has a strongly preferred default that reviewers are calibrated to.

The pattern across the table: β-factor is the default everywhere except NRC nuclear PRA, which uses alpha-factor (and accepts MGL) because it has the data and the consequences to justify the extra rigour. If you're working under any other regulator, β-factor is the expected default — and your job is to know when its conservativeness is in the wrong direction (Step 4) and step up to MGL with explicit justification.

Operational pitfalls — five that show up in audit

• Declaring a CCF group too broadly. If your group includes components that don't actually share a common cause, β·p over-counts dependence. The CCF group should be defensible: same vendor/model OR shared environment OR identical firmware OR identical maintenance cycle, not just "redundant items".
• Declaring a CCF group too narrowly. Conversely, if components share a hidden cause not captured in your group definition, β·p under-counts. Common audit finding: "Did you consider whether items in different physical locations still share a software-update cycle?"
• Using β = 0.10 by default with no defence-in-depth credit. The Annex D scoring is there to be used. A β-factor that doesn't take credit for diversity, separation, staggered maintenance and dissimilar implementations is over-conservative and makes SIL claims harder than they need to be. Document the score sheet.
• Mixing β-factor and MGL across CCF groups in the same fault tree. Internally consistent if done deliberately, but reviewers will ask. If only one or two CCF groups need MGL (because they're large or k-of-m voted), document the criterion that selected them.
• Ignoring CCF between barriers in an ETA. The β-factor / MGL conversation usually happens at the FTA basic-event level. But ETA barriers (track circuit + signaller + ATP, in the SPAD example from Article 4) are also subject to common-cause — a power outage, a fatigue event, a control-room incapacitation. Barrier CCF is the same modelling challenge in a different notation, and it's the one most commonly missed.

Where to go next

• Add CCF to your tree. Open FTA Studio — the CCF Manager (Enterprise) lets you declare groups, assign β-factor or MGL parameters, and propagate the corresponding basic events through the cut-set analysis automatically.
• Re-rank importance after CCF. CCF basic events sit in order-1 cut sets and tend to dominate the F-V importance ranking. Article 2 covers what each importance measure tells you about CCF — particularly RAW, which captures the "what depends on this CCF defence holding" question directly.
• For nuclear / process applications, NUREG-CR-5485 is the canonical reference. It includes worked alpha-factor / MGL / β-factor conversions and the industry CCF database that supplies the parameter values.
• For software CCF, the standards are weaker — DAL-A avionics, ISO 26262 ASIL-D, IEC 61511 SIL 4 all require qualitative arguments because there's no clean way to estimate β for "shared software bug". Diversity, formal proof, staged release, and dissimilar implementations are the leverage points; β-factor is the failure mode to retreat to only when those don't apply.