An Experimental Evaluation of the Assumption of Independence in Multiversion Programming¶
Knight, J. C., & Leveson, N. G. (1986). An Experimental Evaluation of the Assumption of Independence in Multiversion Programming. IEEE, 12(1), 96-109.
Cited by¶
4 citations across 4 artifacts.
Each citation links to the sentence it supports in the citing article.
Mechanisms¶
- Diverse Implementation Voting
- Its failure mode is correlated errors: when the independent teams share a flawed specification, a common algorithm, or the same misunderstanding, they can all vote the same wrong answer, and the vote ratifies it.
This sourceShows that independently developed program versions can fail dependently, so majority voting may select a shared erroneous result rather than mask it.
- Its failure mode is correlated errors: when the independent teams share a flawed specification, a common algorithm, or the same misunderstanding, they can all vote the same wrong answer, and the vote ratifies it.
- Diverse Vendor Review
- This is the empirical lesson of design-diversity research — that independently sold does not guarantee independently failing, because shared assumptions and shared sources correlate the misses.
This sourceFinds that separately developed program versions fail together more often than independence predicts, including because they implement the same specification.
- This is the empirical lesson of design-diversity research — that independently sold does not guarantee independently failing, because shared assumptions and shared sources correlate the misses.
- Multichannel Redundant Delivery
- It misleads through correlated redundancy — nominally separate channels that share a backbone, vendor, or timing, so a single outage takes them all and the "redundancy" was theater — and duplicate copies on the same degraded channel add clutter without adding persistence.
This sourceDemonstrates that nominally independent redundant implementations can fail together far more often than independence assumptions predict.
- It misleads through correlated redundancy — nominally separate channels that share a backbone, vendor, or timing, so a single outage takes them all and the "redundancy" was theater — and duplicate copies on the same degraded channel add clutter without adding persistence.
- Redundant Voting
- The classic caution is that even independently developed program versions do not fail independently — they tend to err on the same hard inputs, so the vote can be unanimous and unanimously mistaken.
This sourceFinds that independently developed program versions exhibit correlated failures on common inputs, allowing an agreeing vote to be wrong.
- The classic caution is that even independently developed program versions do not fail independently — they tend to err on the same hard inputs, so the vote can be unanimous and unanimously mistaken.
Verification¶
Does it exist? Confirmed. This work's DOI resolves to a registered record, which fixes its identity. That is all it fixes.
Does it back the claim? Not recorded. Neither this nor any other of the 4 citations of this work carries a recorded support check.
Was it audited? Yes. A second, independent pass read the citation against the article text and recorded a verdict.
Support is checked per citation rather than per work — the same source can be cited soundly in one article and wrongly in another. Per-citation recording began recently, so a citation with no recorded check is a gap in the record rather than evidence it went unchecked.
See how references were verified.
Registry ID ref:065239265a45 · see in the full table