Common cause failures — why two channels aren't always safer

Redundancy is the foundation of safety architecture. Two channels instead of one. If Channel A fails, Channel B catches it. The logic seems straightforward: more channels, more safety.

But there's a failure mode that redundancy cannot solve by itself. Common cause failures — abbreviated CCF — are failures that affect multiple channels simultaneously because those channels share something: a power supply, a firmware version, a temperature environment, a design assumption, a manufacturing batch.

When a common cause failure occurs, the redundancy doesn't help. Both channels fail at the same time, for the same reason, in the same way. The safety system behaves as if it has zero channels, not two.

IEC 61508 quantifies common cause susceptibility using the β (beta) factor — the fraction of dangerous failures that affect redundant channels simultaneously. A dual-channel system with β = 10% means that 10% of all dangerous failures will defeat the redundancy entirely. Both channels fail together. And here's the critical detail: β = 10% is the default value in IEC 61508 — it's what you get if you haven't implemented ANY common cause defenses. It's not a worst case. It's the starting point.

Four common cause categories appear repeatedly in practice.

Shared power supply. A voltage spike, a brown-out, or a power supply failure takes out both channels simultaneously because they draw from the same source. Mitigation: independent power domains with separate fusing and filtering.

Same firmware on both processors. A software bug, a timing error, or a watchdog misconfiguration affects both channels identically because they run the same code. Mitigation: diverse software — different teams, different languages, different compilers, or at minimum different implementations of the same specification.

Environmental coupling. Both sensors are mounted in the same thermal zone. An overheating event degrades both simultaneously. Both PCBs share the same enclosure and are exposed to the same vibration profile. Mitigation: physical separation, independent thermal management, environmental diversity.

Design commonality. The same engineer designed both channels. The same assumptions were made. The same blind spots exist in both. Mitigation: diverse design teams, independent design reviews, architectural diversity (one channel hardware-logic-based, the other microcontroller-based).

IEC 61508-6:2010, Annex D provides a structured scoring checklist for evaluating common cause defenses. The checklist covers separation and independence, diversity, complexity, assessment and analysis, competence and training, environmental control, and procedures for testing and maintenance. Each category contributes to the β factor calculation.

If you're designing a dual-channel safety system for Physical AI and you haven't calculated your β factor — your redundancy claim is aspirational, not engineered. Two channels with high common cause susceptibility can be less safe than a single channel with high diagnostic coverage. The math doesn't lie.

This is the question worth asking of the safety architecture the whole industry is now watching. NVIDIA's Halos puts a functional-safety island next to the AI compute — but on the same chip, from the same vendor, designed by the same team. In β terms, that stacks three common-cause categories by construction: shared substrate, design commonality, and a single supplier. It may well be engineered to a low β — NVIDIA has serious functional-safety talent — but a low β is a number to be shown, not assumed. On-chip isolation is a real improvement over software-only safety; it is not, by itself, independence. So the right question for any Physical AI safety layer — NVIDIA's included — isn't "are there two channels?" It's "what's your β?"