Skip to content

Dual Modular Redundancy

A two-channel computing arrangement that compares corresponding results to detect faults, without by itself identifying which disagreeing channel is correct.

Version
v2 · 2026-10-03 · History
Domain-specific #
13171
Domain group
Applied Sciences & Engineering
Origin domain
Computer Science & Software Engineering
Subdomain
Fault Tolerant Computing → Computer Science & Software Engineering
Aliases
Double modular redundancy

Core Idea

Dual modular redundancy (DMR) runs two functionally corresponding computing modules over aligned inputs and compares their results. A difference detects an inconsistency. It does not, by itself, tell which channel is correct: there is no majority among two disagreeing outputs. A system therefore needs an additional retry, independent diagnostic, safe-stop or recovery mechanism if it is to do more than signal a fault.[ref-717fdfbe8390][ref-2cebdddcc65b]

Scope of Application

In IBM's z900, two instruction/execution units produce per-instruction results and compare them; mismatch triggers attempted retry, while spare-processor recovery is separate. In digital filtering, two FIR implementations can be run in parallel and their corresponding samples compared. A deliberately diverse FIR design can sometimes locate selected soft errors from distinctive error patterns, but that extra result is not a general property of ordinary DMR.[ref-042489f2dd98][ref-3a7b715c195e][^ref-2cebdddcc65b]

DMR is narrower than generic engineering redundancy and self-checking. It requires exactly two actively compared computational channels, not an idle spare or a three-way voter. The proposed staged DAG parents are Self Checking and Redundancy (engineering). The frozen chronometer anecdote is omitted because its historical attribution was not verified from a primary source.[^ref-717fdfbe8390]

Clarity

Three questions must stay separate: Do the channels disagree? Which is wrong? What should happen next? Bare DMR answers only the first. Equal outputs also do not prove correctness when a shared fault makes both channels err alike. Diverse DMR can add fault-location information for specially engineered patterns, not simply because two modules exist.[ref-717fdfbe8390][ref-2cebdddcc65b]

Manages Complexity

The pair/comparator design isolates fault detection from recovery. Its roles are a matched module pair, aligned observations, a comparator, a mismatch signal, and an optional recovery adjunct. Designers can inspect each role and the costs of a second active path without assuming that fault localization or failover follows automatically. IBM's checkpoint-and-retry machinery shows how recovery can be layered onto the basic comparison.[^ref-042489f2dd98]

Abstract Reasoning

For corresponding outputs \(y_1\) and \(y_2\), a comparator can flag \(y_1\ne y_2\). That relation establishes disagreement under its observation model, not whether \(y_1\) or \(y_2\) is the true answer. A third independent result, a fresh computation, or an independently justified error pattern can add information. Identical paths are easy to align but can share failures; diverse paths may expose more faults yet introduce legitimate small output differences and a harder comparison threshold.[ref-717fdfbe8390][ref-2cebdddcc65b]

Knowledge Transfer

The same detection skeleton maps from duplicated server instruction units to paired FIR filters: two corresponding outputs, an aligned comparison and an underdetermined mismatch. What does not transfer automatically is IBM's retry, the FIR design's pattern-based correction, or any universal claim about reliability. A portable two-witness disagreement idea may warrant future prime study; this admitted identity remains a computing fault-tolerance architecture.[ref-042489f2dd98][ref-3a7b715c195e]

[^ref-717fdfbe8390]: NASA Jet Propulsion Laboratory, ST8 Dependable Multiprocessor, two-versus-three computer discussion. [^ref-042489f2dd98]: IBM, IBM eServer zSeries 900 Technical Guide, Appendix A, printed pp. 245–246. [^ref-2cebdddcc65b]: P. Reviriego, C. J. Bleakley and J. A. Maestro, “Diverse Double Modular Redundancy”, IEEE Design & Test 30 (2013), abstract, Introduction and FIR discussion. [^ref-3a7b715c195e]: P. Reviriego, C. J. Bleakley and J. A. Maestro, “Structural DMR”, IEEE Transactions on Circuits and Systems II 58 (2011), abstract and introduction.

Relationships to Other Abstractions

Local relationship map for Dual Modular RedundancyParents appear above the current abstraction, mutual partners to the right, and children below. Node labels state whether each abstraction is prime or domain-specific; colors identify relation types.Dual ModularRedundancyDOMAINDomain-specific abstraction: Redundancy (engineering) — is a kind ofRedundancy(engineering)DOMAINPrime abstraction: Self Checking — is a kind ofSelf CheckingPRIME

Current abstraction Dual Modular Redundancy Domain-specific

Parents (2) — more general patterns this builds on

  • Dual Modular Redundancy is a kind of Redundancy (engineering) Domain-specific

    Two redundant modules are a restricted engineering-redundancy architecture used for fault detection.

  • Dual Modular Redundancy is a kind of Self Checking Prime

    Two physically distinct paths are partially independent for channel-local faults, and a comparator detects disagreement; common-mode failures remain possible.

Hierarchy paths (13) — routes to 8 parentless roots

Neighborhood in Abstraction Space

Dual Modular Redundancy sits in a sparse region of the domain-specific corpus (86th percentile for distinctiveness): few abstractions share its structure, so a faithful description tends to retrieve it precisely.

Family — Unclustered & Miscellaneous (2551 abstractions)

Nearest neighbors

Computed from structural-signature embeddings · 2026-10-08