In short. Redundancy assumes failures are independent. Common-cause failures break that assumption: one event disables several redundant elements together. Typical causes are shared environment, shared support systems, shared design or maintenance errors and shared fuel. Defend with separation, diversity and independent support, and test the result.
Common-cause versus common-mode
A common-cause failure is one cause, such as a flood or a wrong setting, affecting several elements. A common-mode failure is the same failure mode appearing in similar equipment, such as identical units failing from the same design defect or the same firmware bug. Both defeat redundancy by acting on duplicates together.
Sources in power systems
| Source | Example | Defence |
|---|---|---|
| Environment | Flooding, fire, heat, dust in a shared room | Separate rooms, fire barriers, flood protection |
| Support systems | Shared cooling, fuel, DC supply, ventilation | Independent support per path |
| Design and manufacturing | Identical units with the same defect | Diversity of type or supplier; staggered ages |
| Software and firmware | Same bug on all controllers | Staged updates, diverse logic, fallback modes |
| Maintenance and settings | Same wrong setting applied to both units | Independent verification; staggered maintenance |
| Fuel | Contaminated fuel in all tanks | Sampling, polishing, separate supplies |
| Grid and external | Regional outage; storm; supplier failure | Local generation and storage; diverse supply |
| Human | One operator error across both paths | Procedures, checks, access control |
Defences
- Physical separation: distance, fire-rated walls, separate cable routes, separate rooms.
- Functional independence: separate controls, separate supplies, no shared single devices.
- Diversity: different manufacturers, ages or technologies for key elements where practical.
- Staggered maintenance and changes: avoid doing the same thing to both paths at once.
- Monitoring: alarms for early signs of a common problem.
Diversity trade-offs
Diversity reduces common-mode risk but raises spares, training and integration cost. Use it where the consequence justifies it, for example different controller types for the two halves of a critical plant, or generators from different production batches.
Worked illustration
Two generators in one room appear independent. A fire in the room disables both. Moving one to a separate enclosure or fire-rated bay removes that cause. A second review notes both burn fuel from a single tank filled by one supplier; a batch of bad fuel would stop both. The fix is sampling at delivery, polishing, and a second source of fuel. A third, subtle, point is that a firmware update applied to both controllers at once could introduce a bug in both, so the update is staged and tested on one first.
A review checklist
- List each redundant pair and write what they share.
- Ask what single event, internal or external, would hit both.
- Check maintenance practice for same-day, same-person changes.
- Check supply chain for common upstream failure.
Common cause defeats redundancy
Two units are only redundant if one failure does not cause the other. Common-cause failures strike several units together, and they dominate real outage statistics once single failures are covered.
| Cause | Example | Defence |
|---|---|---|
| Environmental | Heat, flooding, dust, fire in a shared room | Separation, rated barriers, cooling redundancy |
| Design | Same wrong setting or design flaw in each unit | Independent review, diversity |
| Software | Same firmware bug on all controllers | Staged updates, version diversity |
| Supply | Same fuel batch, same utility feeder | Multiple suppliers, fuel testing |
| Maintenance | Same error repeated on each unit in one visit | Stagger work, verify before next |
| Operational | One wrong command affecting both | Interlocks, procedures, access control |
Beta factor illustration
If each unit has unavailability 1 percent, independent failure of both gives 0.01 percent. If 5 percent of failures are common cause (beta = 0.05), the combined unavailability is about 0.01 percent + 0.05 percent = 0.06 percent, six times worse. The common-cause term dominates.
Practices
- Stagger maintenance and firmware updates between redundant units.
- Use diverse equipment where affordable.
- Separate physically.
- Test as a system, not unit by unit.
Redundancy needs independent failure paths. See reliability modelling.
Common mistakes
- Assuming redundant means independent.
- Updating firmware and settings on all units at once.
- Overlooking environmental and fuel sources.
What to send us
Send the layout, the support systems and the maintenance plan. Send your application details. See also single-point-of-failure elimination.
Questions engineers ask
Why do redundant systems still fail together?
Because something is shared: a room, a support system, a design defect, a setting, a fuel batch or a procedure.
Is diversity always worth it?
Not always. It costs more in spares and training. Use it where the loss is severe.
What is the cheapest defence?
Procedure: stagger changes and maintenance, and verify settings independently.
How do I analyse common-cause risk?
List what each redundant pair shares, and identify events that would affect both.
This guide gives general principles. A formal reliability study quantifies these risks for your system.