Common-mode failure: when every backup shares one weakness

01Two inertial systems, one flight

On June 4, 1996, Ariane 5 Flight 501 lifted off on its first flight. About 37 seconds after liftoff, its guidance information was lost and the launcher broke up. The vehicle carried two inertial reference systems, so a single failure should not have ended valid attitude information. Both systems failed, and they failed for the same reason.

The inquiry board traced the sequence to a conversion of a value related to horizontal motion, from a 64-bit floating-point number into a 16-bit signed integer. The value exceeded the range that could be represented. The software had been inherited from Ariane 4, and the backup unit ran the same software, so it met the same out-of-range value. Hardware duplication had doubled the boxes, but not the assumption behind them.

02What redundancy is supposed to buy

Redundancy protects against independent failures: a component wears out, a connector loosens, a memory cell flips. If each channel fails for its own unrelated reason, a second channel can take over. The protection depends entirely on the word independent.

A common-mode failure is a single cause that defeats several channels at once. The channels can be separate boxes, separate wires or separate teams and still share a design assumption, a power source, a maintenance routine, a time reference or an operating environment. On paper the redundancy looks like two layers of protection. In operation it can be one layer copied twice.

Engineers therefore distinguish physical redundancy from functional independence. Physical redundancy is a count of components. Functional independence asks whether a failure in one channel can propagate to the others through shared inputs, software or conditions.

03The shared assumption in the software

The inquiry board also found that an alignment function, useful only before liftoff, remained active after liftoff. The function served no purpose in flight, but it continued to run. One of the board's corrective measures was to switch off or inhibit that function after liftoff, which shows that a reused behavior had outlived its reason for existing.

The board also stressed that the inertial reference system's tests and simulations did not adequately represent the real flight trajectory. Tests that exercised familiar conditions could pass while the new conditions remained untested. A common-mode defect can hide in the gap between the test environment and the operating environment.

The case does not show that all software reuse is unsafe, or that diverse implementations always help. The board's recommendations focus on analyzing the reused system's assumptions and testing coverage of the actual flight domain.

04A shared environment: the O-ring joints

Redundancy can also fail through a shared environment. The Space Shuttle's solid rocket motor joints were sealed by primary and secondary O-rings, with the secondary ring serving as a backup. A common environmental influence that acts on both rings deserves close attention.

The Rogers Commission reported a launch-day ambient temperature of 36 degrees Fahrenheit, 15 degrees colder than the next-coldest earlier launch. It estimated the temperature at the coldest point on one joint at about 28 degrees, with an uncertainty of plus or minus 5 degrees. Its erosion table records a flight on which both primary and secondary O-rings were affected.

The interpretation is cautious. A shared temperature condition can degrade more than one seal at once, so the second seal does not reliably provide independent protection under the same conditions. The report discusses the sealing physics at length. This article uses the case only to illustrate a shared environment.

05Shared infrastructure: the grid's awareness

On August 14, 2003, the Northeast power system suffered a large cascading outage. The final report of the US-Canada task force describes a sequence that included tree contacts with transmission lines, generator trips, and failures of monitoring and alarm functions. Operators relied on those monitoring functions to understand what the physical network was doing.

The report's sequence places the failure of an alarm and logging system at about 14:14 Eastern Daylight Time. Operators did not receive the usual warnings that equipment conditions were changing. The grid had multiple transmission paths, so in principle it had physical redundancy. What it lacked was a reliable way for operators to know which paths were degrading.

Physical redundancy and information redundancy are different things. A grid can have many lines and still depend on a single channel for situational awareness. When that channel fails, the control room's picture may look healthy while the network is degrading.

06Testing for the shared cause

The practical question is where each redundant channel gets its inputs. List the shared items: software version, reference clock, power supply, sensor type, maintenance schedule, operating crew, environmental range and the data format between components.

Then test with representative conditions. The Ariane board emphasized that the tests were not sufficiently representative of the real trajectory. A test built from familiar inputs will confirm what is already known. Tests should include the boundaries: out-of-range values, the extremes of the environmental range and the sequence of operations at the moment of transition.

Make the shared dependency visible in the safety argument. If two channels share a power supply, the argument should say so and assign either a bound on that dependency or a separate test for it.

A simple exercise helps. Write each redundant channel along one axis of a table and each shared resource along the other, then mark every cell where a channel depends on a resource. Rows with many marks show where redundancy is weakest, and they show where testing should start.

07Limits of the idea

Common-mode thinking can turn into a habit of pessimism that blocks useful redundancy. Not every shared dependency is a fatal flaw. Many are acceptable once they are known, bounded and tested.

Diversity is one response: implementing the same function in different ways. It is not free, because different implementations can introduce new errors and new costs. The aim is to explain which failures a redundant design covers and which it does not, rather than to adopt diversity as a fashion.

The open question in many systems is which shared causes have not yet been imagined. A review can list the known dependencies and still miss the one that connects everything. That gap is one reason investigations ask about conditions, not only about components.