Common-Cause Failure and What Design Diversity Actually Buys

Redundancy calculations are usually written as if two channels fail independently, and the resulting numbers are optimistic by one to three orders of magnitude. The reason is common-cause failure: the channels are not independent, because they share an environment, a supply, a specification, a compiler, a connector, or a design team. The correction for this is not more redundancy but a separate analysis of what is shared, and the correction factor has a name and a rough magnitude that every safety case has to confront.

The shared term in a two-channel failure rate

For two channels each with failure rate lambda, independent simultaneous failure has a rate proportional to lambda squared, which is why the naive calculation looks so good: two devices at 10^-6 per hour each give 10^-12 per hour squared, comfortably beyond any requirement. Real systems never achieve that. The standard model splits the failure rate into an independent part and a common-cause part, with the common-cause fraction denoted beta, so each channel contributes a fraction one minus beta of its rate independently and the pair contributes a beta share jointly. For a beta of 0.1, the common-cause term is more than an order of magnitude larger than the independent term, and it is usually the number that decides whether the target is met.

Beta factors in practice are not small. IEC 61508-6 gives guidance for estimating beta from a checklist of shared factors, and the resulting values for redundant channels of the same design in the same environment commonly land between 1 and 10 percent, with values above that for channels sharing a single power supply or a single enclosure without separation. The checklist scoring is crude by design: the point is to force the analysis to name the couplings rather than to produce a precise number. A beta of 1 percent is often quoted as an optimistic figure for well-separated channels with diverse designs, and a beta of 10 percent is realistic for identical channels in one enclosure.

The arithmetic has an uncomfortable consequence. Adding a third identical channel reduces the independent term further but leaves the common-cause term untouched, because that term is governed by the shared cause rather than by how many members the shared cause happens to take down. In the simple shared-cause model the group’s common-cause contribution does not fall as channels are added, and the arrangement’s advantage over a pair shrinks accordingly. Redundancy beyond two channels of the same design buys almost nothing against common cause, which is why the standards treat diversity as the lever and channel count as a secondary one.

Where common cause actually comes from

The couplings fall into a few categories, and naming them is what makes the analysis useful.

Physical coupling includes supply, grounding, temperature, vibration, humidity, and electromagnetic fields. Two channels on the same board share a regulator, a ground plane, and a thermal environment; a regulator failure takes both, and a hot spot affects both. Separation helps: separate supplies, separate boards, separate cable routes, and separate enclosures with independent environmental control. Complete separation is rarely achievable, and the residual coupling is what the beta factor’s physical terms are estimating.

Design coupling includes the specification, the architecture, the component selection, and the software. Two channels built to the same specification will have the same specification error. Two channels running software compiled by the same compiler with the same optimisation settings will have the same miscompilation. Two channels using the same real-time operating system will have the same scheduler defect. This is the coupling that diversity addresses, and it is the one that redundancy alone cannot touch.

Operational coupling includes maintenance, calibration, and testing. A technician who calibrates both channels with the same out-of-tolerance instrument introduces the same error into both. A proof test that exercises both channels through the same test connector can leave both in the same bypassed state. A shared human procedure is a common-cause path, and it is the one most often left out of the analysis because it is not in the schematic.

What diversity changes, and what it costs

Design diversity means building the channels differently enough that a defect in one design is unlikely to be present in the other. The classical forms are diverse hardware, diverse software, and diverse specification.

Diverse hardware uses different processors, different vendors, or different implementation technologies for the two channels. It removes shared component errata and shared silicon defects, at the cost of two toolchains, two sets of device drivers, two qualification packages, and a permanent maintenance burden. Diverse software, sometimes called N-version programming, has two teams write independent implementations from the same specification and runs them in parallel with a voter. Diverse specification goes further and produces two separate specifications from the same requirements, on the theory that the specification is itself a major source of systematic error.

The empirical picture is more sober than the theory. N-version programming was studied in the 1980s and 1990s with the consistent finding that independently written versions fail coincidentally far more often than independence would predict, because the programmers share the same training, the same interpretation of ambiguous requirements, and the same difficult inputs. The famous result is that coincident failures cluster on the same inputs, which is precisely the case a voter cannot resolve. Diversity reduces the common-cause term; it does not eliminate it, and the reduction is smaller than the intuition suggests.

The cost side is substantial and often decisive. Two independent implementations double the development effort, double the verification effort, and create a permanent obligation to keep both correct through every change. A change to one version must be assessed for its effect on the diversity claim, and a change made to both versions in the same way silently re-couples them. Projects that adopt diversity without budgeting for the maintenance phase end up with two versions that have drifted into agreement, which is the worst of both arrangements: the cost paid and the benefit lost.

IEC 61508 handles this by requiring a diverse or diverse-and-redundant architecture at the higher integrity levels for certain elements, and by allowing the beta factor to be reduced when diversity is demonstrated. The credit is a reduction in the estimated beta factor, not a licence to assume independence, which reflects the standard’s conservative view of how much diversity is worth.

Diverse monitoring as a cheaper alternative

A full second channel is expensive. A common middle ground is a diverse monitor: a simple, independently designed device that checks the output of the main channel rather than computing the same result. The monitor does not need to be able to perform the function; it only needs to be able to recognise when the function’s output is wrong.

A monitor of this kind is typically built from different technology: an analog comparator instead of a digital computation, a separate microcontroller with a simple program instead of a complex one, or a programmable logic device implementing a limit check. Because it is simpler, its own failure modes are easier to enumerate, and because it is built differently, it does not share the main channel’s specification or software defects. What it cannot do is continue the function after the main channel fails, so it suits fail-silent architectures and not fail-operational ones.

The independence argument for a monitor is easier to make than for a full second channel, because the monitor’s job is small. The argument has to cover the sensor, though, and this is where many designs fall short: if both the main channel and the monitor read the same sensor, a sensor failure is common cause regardless of how different the two processing paths are. The fix is a second sensing element with a different physical principle, or a plausibility check against a modelled value, which is a form of diversity at the level of the measurement rather than the computation.

Analysing the coupling rather than counting channels

The practical method is a structured review of every shared element between the channels, with each coupling classified and either eliminated or accepted with a beta contribution. The output is not a single number but a list of couplings with arguments, which is what a reviewer can actually assess.

Coupling	Typical mitigation	Residual
Shared supply	Separate regulators, independent feeds	Partial: site power remains shared
Shared clock	Independent oscillators	Full for the oscillator, none for the board
Shared software	Diverse implementation or diverse monitor	Partial: shared requirements
Shared specification	Independent specification review	Small: shared domain assumptions
Shared enclosure	Physical separation, thermal isolation	Partial: shared ambient
Shared maintenance	Separate test procedures, independent calibration	Full if enforced

The residual column is the honest part. Almost every mitigation leaves something shared, and the analysis should say what. A site power feed is shared by every channel in the plant, so a grid disturbance is a common cause no architecture eliminates; what the architecture can do is ensure that the response to a supply loss is a safe state rather than an undefined one, which is the argument made in Safe States and Fail-Silent Behaviour in Control Systems.

The analysis also has to consider the failure of the voting or comparison mechanism itself. A voter that fails to a “always agree” state converts a two-channel system into a one-channel system with no indication, which is a latent fault in the mechanism that implements the redundancy. That is why the voter needs its own self-test, the same reasoning that applies to a comparator in Lockstep Cores and Comparator Logic in Safety Microcontrollers, and why the latent fault metric in Runtime Self-Tests and Diagnostic Coverage Measurement is computed over the mechanisms rather than over the functional hardware.

Why the standards still demand redundancy

If common cause dominates, a natural conclusion is that redundancy is pointless and a single well-built channel would do. The standards do not accept that conclusion, and the reason is that the two mechanisms address different populations. A single channel’s random hardware failures are covered by its diagnostics; redundancy covers the case where the diagnostics are overwhelmed or where a fault is outside their detection capability. The two arguments are complementary, and the requirement for hardware fault tolerance at the higher integrity levels is a requirement that the architecture survive a fault without relying solely on detection.

The disciplined position is that redundancy and diversity are separate claims with separate evidence. The redundancy claim is about fault tolerance: one channel fails, the function continues or the system goes to a safe state. The diversity claim is about common cause: the failure of one channel does not imply the failure of the other. A design that claims both without distinguishing them will usually be strong in one and unexamined in the other, and the unexamined one is the one that fails in a way nobody predicted.