Common-Cause FMEA¶

Method — instantiates Common-Mode Failure Analysis

Extends failure mode and effects analysis by asking which single causes could defeat multiple redundant elements or controls at once.

Version: v1 · 2026-08-24 · History
Mechanism #: 1539
Type: Method
Form family: Analysis, Modeling & Optimization
Solution family: Redundancy & Fault Tolerance
Problem family: Fragility, Failure & Continuity Risk
Problem subfamily: Dependency Concentration & Common-Mode Loss
Origin domain: Engineering & Design
Instantiates: Common-Mode Failure Analysis

A standard Failure Mode and Effects Analysis walks each component, lists how it can fail, and traces the effect — one part at a time. Common-Cause FMEA adds a column that the ordinary table cannot express: for each failure cause, how many otherwise-independent elements does it take down together? It is a bottom-up, enumerative method — it starts from the parts and their failure modes and rolls up to shared causes — and its distinctive question is not "can this part fail?" but "does this cause defeat the redundancy that is supposed to survive this part failing?" The whole point is to catch the case where three backups all share one manufacturer, one calibration procedure, or one software build, so a single root cause quietly clears the entire redundant set.

Example¶

An aircraft is designed with three fully separate hydraulic systems — call them green, blue, and yellow — routed through different parts of the airframe so that no single leak can take flight control away. A standard FMEA on each system passes: any one can be lost and the other two fly the plane. The Common-Cause FMEA is the pass that looks for the cause that spans all three.

The team builds the table cause-first. They ask, for each candidate root cause, which of the three systems it reaches. A hydraulic pump seal failure: one system. A particular fluid contamination introduced at a shared servicing step: potentially all three, because they are filled from the same cart. An uncontained engine rotor burst throwing debris across a section of the airframe where two of the three lines run close together: two systems at once. Each of those multi-hit rows is a common-cause finding invisible to the per-system analysis. The output is a ranked map of shared causes — the servicing procedure and the debris zone rising to the top — that tells the designers exactly where "three independent systems" is a claim and where it is a fact.

How it works¶

The method reshapes the familiar FMEA worksheet around coupling:

Scope the function, then list its redundant elements. Fix the function that must survive and enumerate every element expected to preserve it, so the analysis measures redundancy rather than parts in isolation.
Enumerate failure modes bottom-up, then pivot to causes. For each element, list how it fails; then reorganize by cause and count how many elements each cause touches.
Flag the multi-hit causes. Any cause that reaches more than one redundant element is a common-cause candidate; rank these by how much of the redundancy they erase and how severe the resulting loss is.
Interrogate shared origins explicitly. For each redundant set, ask whether the elements descend from the same design, vendor, software, calibration, or procedure — the couplings that never appear as a physical wire.

The product is a cause-indexed map, not a verdict; it hands ranked common-cause candidates to mitigation, testing, and the register.

Tuning parameters¶

Enumeration granularity — coarse functional blocks versus fine sub-components. Finer granularity finds more shared causes but multiplies the worksheet and invites fatigue.
Cause taxonomy breadth — how many cause categories you admit (physical, environmental, human, software, design, procedural). Wider taxonomies catch subtler common modes at the cost of a much larger table.
Multi-hit threshold — how many redundant elements a cause must touch before it is escalated. A low threshold surfaces more but dilutes attention.
Scoring scheme — whether rows carry severity, occurrence, and detectability ratings, and how those combine. Scoring focuses effort but can manufacture false precision.
Design-lineage depth — how far back you chase shared origins (same team, same tool, same supplier's supplier). Deeper is more revealing and more effortful.

When it helps, and when it misleads¶

Its strength is systematic coverage: because it walks every element and every cause, it is hard for a shared cause to hide from a diligent Common-Cause FMEA, and it forces the uncomfortable admission that "independently developed" often means "correlated." Reliability engineering names this with the beta-factor model, which treats some fraction of each component's failure rate as common to its redundant siblings precisely because perfect independence is a fiction.^[n1]

Its failure mode is the enumerator's curse: the table can grow so large that it becomes ritual, completed for the audit trail while the one decisive shared cause sits misclassified in a low-scored row. The classic misuse is running it as a component-by-component FMEA and never pivoting to causes — producing a fat document that certifies each part while missing the thing that fails them together. The guarding discipline is to hold a scope tight enough to finish, and to judge the analysis by the multi-hit rows it surfaced, not by the row count.

How it implements the components¶

protected_function_set — the analysis is anchored to a function that must survive, which is what makes it a redundancy test rather than a parts inventory.
common_failure_mode_map — its central output: a cause-indexed map linking each shared cause to the redundant elements it defeats.
common_design_lineage_check — its shared-origin pass explicitly asks whether redundant elements descend from the same design, vendor, software, or procedure.

It maps causes but does not model their reach — it does not compute a blast_radius_model or encode the top-down independence_assumption structure of its nearest analytical twin, Fault Tree with Common-Cause Branching, which works down from the failure while this works up from the parts; nor does it run the live independence_validation_probe of Backup Independence Test.

Instantiates: Common-Mode Failure Analysis — this method produces the ranked shared-cause map the archetype acts on.
Sibling mechanisms: Backup Independence Test · Correlated Risk Register · Credential and Infrastructure Dependency Audit · Diverse Vendor Review · Fault Tree with Common-Cause Branching · Supply-Chain Dependency Review · Tabletop Cascade Exercise

Editorial Notes¶

Form Classification¶

Form family: Analysis, Modeling & Optimization

Rationale: Extends failure mode and effects analysis by asking which single causes could defeat multiple redundant elements or controls at once, making its operative form a computation, comparison, model, or analytic representation used to infer, estimate, or choose.

Independent corroboration: The frozen evidence defines Common-Cause FMEA as 'Extends failure mode and effects analysis by asking which single causes could defeat multiple redundant elements or controls at once', so its operative form is Analysis, Modeling & Optimization.

Review outcome: Independent reviewer agreement; high confidence.

Origin Attribution¶

Primary origin: Engineering & Design

Origin pattern: Single lineage

Present-day reach: Specialized

Rationale: Reliability engineering extended component-level FMEA with explicit common-cause rows and beta-factor reasoning for failures spanning redundant elements.