Glossary term

Common-Cause Failure

Engineering definition of common-cause failure covering dependent failures, redundancy limits, IPL independence and beta-model screening.

Definition

concept

Common-cause failure is a dependent failure in which multiple channels, safeguards or redundant elements fail because of a shared cause or shared dependency.

Common-cause failure limits the risk reduction that can be claimed from redundancy or multiple protection layers. It can arise from shared sensors, power, utilities, software, environment, maintenance error, calibration practice, design defect, operator action, physical location, supplier defect or procedure. It must be considered before multiplying PFD values or claiming independent protection-layer credit.

Common-cause failure is a dependent failure in which multiple channels, safeguards or redundant elements fail because of a shared cause. It is one of the main reasons redundancy and protection layers do not deliver the risk reduction implied by a simple independent calculation.

The shared cause may be physical, logical, human, environmental or organizational. Examples include a common power supply, shared instrument impulse line, common software defect, same calibration error, same maintenance procedure, same vendor batch, same cooling utility, same flood zone or one operator action that disables several safeguards.

Why It Matters

If two channels are truly independent and each has failure probability:

q

a simple parallel-failure screen may use:

PFD_{ind}=q^2

This can be dangerously optimistic when the channels share a dominant dependency. Common-cause failure creates a floor below which redundancy cannot reduce risk unless the shared cause is removed, detected or controlled.

Beta-Model Screen

A common first screen separates a common-cause fraction:

\beta

from the single-channel failure probability:

q

For two redundant channels, a simplified beta-model estimate is:

PFD_{ccf}\approx \beta q + (1-\beta)q^2

The first term represents failures that defeat both channels through the shared cause. The second term represents independent coincident failures. This is a screening model, not proof that the architecture is safe.

Boundary With Independent Layers

Independent protection layers may be multiplied only when their failure mechanisms are sufficiently separate for the scenario. If two credited layers depend on the same sensor, logic solver, utility, software, final element, technician action or bypass permit, the independence claim is weak.

The practical test is:

PFD_{total}\neq PFD_1PFD_2

when a shared cause can defeat both layers. The risk review should identify the shared dependency and decide whether it is controlled, diversified, monitored or unacceptable.

Worked Example

A redundant trip path uses two channels with:

q=0.01

If independence is assumed, the combined failure probability is:

PFD_{ind}=q^2=(0.01)^2=0.0001

Now assume a common-cause fraction:

\beta=0.05

The beta-model screen gives:

PFD_{ccf}\approx 0.05(0.01)+(1-0.05)(0.01)^2

so:

PFD_{ccf}=0.0005+0.000095=0.000595

The independent calculation claims:

\displaystyle RRF_{ind}=\frac{1}{0.0001}=10000

but the common-cause screen gives:

\displaystyle RRF_{ccf}=\frac{1}{0.000595}=1680.7

For an initiating event frequency:

f_i=0.20\ \text{year}^{-1}

the residual frequency changes from:

f_{res,ind}=0.20(0.0001)=2.0\times10^{-5}\ \text{year}^{-1}

to:

f_{res,ccf}=0.20(0.000595)=1.19\times10^{-4}\ \text{year}^{-1}

The difference is not a rounding issue. It changes the credited risk reduction by nearly a factor of six.

Sources of Shared Failure

Common-cause failure can come from identical design, identical firmware, identical setpoints, shared power, shared network, shared cooling, shared calibration gas, shared test procedure, same enclosure, same cable tray, same environmental exposure, same operator interface or one maintenance activity performed on all channels.

Diversity can help, but only if it addresses the real shared cause. Two different transmitters still share a dependency if both impulse lines plug from the same process contamination. Two different services still share a dependency if both rely on one database or one identity provider.

Validation Evidence

Useful evidence includes architecture diagrams, dependency maps, cable and utility separation, software diversity, environmental qualification, proof-test records, bypass records, maintenance procedures, field failure history, incident reviews and change-control records.

The review should ask whether one plausible event can defeat more than one credited channel. If yes, either the model should include common-cause contribution or the design should be changed.

Evidence should also match the operating mode being credited. A separation argument proven for normal production may not apply during startup, cleaning, temporary bypass, degraded operation, disaster recovery or maintenance when equipment is aligned differently and human actions are concentrated.

Common Mistakes

Do not assume duplicated equipment is independent. Do not use identical proof-test success as proof that hidden shared defects are absent. Do not multiply PFD values before checking shared dependencies. Do not confuse common-cause reliability beta models with unrelated domain-specific beta factors used for other engineering corrections.

Common-cause failure is best treated as a design question before it becomes a calculation question. The strongest mitigation is often architectural: separation, diversity, diagnostics, independent final elements, independent utilities and procedures that prevent one human or maintenance error from disabling every layer at once.

REF

See also