dusk

Classic triple modular redundancy^1,2,3 has a fixed threshold. Three processors vote, two can still detect a disagreement, and one cannot outvote anything, so the system stops. With no repairs and no ground team in reach, that throws away the last processor's whole remaining life.

The Mru whitepaper⁴ proposes a shrinking quorum instead: vote while three processors are alive, compare while two are, and self-check on one. Falling back from TMR to simplex is not new. The question here is what it is worth when no ground team can command it. dusk simulates 10,000 missions and plays five policies against the same failing hardware.

The shrinking quorum matches fixed TMR while three processors survive. It pulls ahead once TMR starts to stop and keeps working long after. By construction it never does less on any single mission: the two are identical until TMR stops, and a test checks this over 200 seeds. The cost is a few wrong results in the single-processor tail, which TMR never lives long enough to make.

When the ground can help

Real spacecraft do not run TMR alone. When a string fails, a ground team diagnoses it and commands a fallback by hand. Voyager, launched in 1977, still has that team: it now switches off instruments to live within a power supply that falls about 4 watts a year⁵. Interstellar Probe is designed to last at least 50 years⁶. So the fair baseline is TMR plus a ground team that switches it to self-checking simplex, once it loses its majority, for as long as support lasts.

• Answer time barely matters. A fallback 1 day or 6 months after it is needed gives the same result to two decimals. The lost days are small next to decades of single-processor life.
• What matters is whether anyone is still there. If ground support never ends, autonomy adds nothing to throughput, because the ground does the same thing by hand. The whole gain comes from the years after support ends. With 49 years of support (Voyager's so far) against a 98-year median hardware life, it is still 1.25x. The ratio of the two is what counts: shorter-lived hardware moves the curve left. With a 60-year Weibull scale, 50 years of support leaves 1.10x instead of 1.25x.

Two more baselines

TMR + unchecked simplex falls back on its own, as the shrinking quorum does, but its last processor does not check itself. It runs at full rate, so it does more useful work: the shrinking quorum does 80% of it. But every upset on that last processor is a wrong result, and the shrinking quorum makes 1.00% as many. This baseline isolates what self-check is worth.

Cold standby is the nearest model here of dual-string with autonomous switchover. One processor is powered and the others are not. Each spare is switched on in turn when the active one dies, and the active one self-checks. It runs on the same three processors as TMR. An unpowered spare ages more slowly than a powered one, but nobody knows by how much, so the chart sweeps that rate.

• Where the shrinking quorum loses on work. If a cold spare ages at less than about 0.20 of the powered rate, cold standby does more useful work. At 0.1 the shrinking quorum does 0.92x of it.
• Where it wins. Above that rate, the shrinking quorum does more, up to 1.60x at 1.0. At every rate, cold standby has more missions with a wrong result, because it never votes: 61.3% at 0.1 and 43.2% at 1.0, against 20.1%.
• With two processors, the true two-string case, the shrinking quorum does 1.05x the useful work of cold standby at 0.1 and 1.49x at 1.0.

The model

Each mission is a day-by-day fault-injection run⁷. Every policy plays against the same fault history and the same upsets, so any difference between policies is the policy.

Useful work is days of correct output, weighted by throughput and summed over the whole mission: the accomplishment measure performability analysis uses for systems that degrade¹⁰. A wrong result (an undetected error) is a day of output nobody knew was bad. Only a lone processor makes one. Risk is the share of missions with at least one wrong result. Service runs to the first day the policy can never produce output again. Intervals are 95% paired bootstrap intervals over whole missions¹¹. Curves are monotone cubics, which cannot overshoot the data¹².

How much the result depends on the assumptions

The parameters are plausible orders of magnitude, not values fitted to flight data. So each one the model cannot pin down is varied on its own, with the rest at default, over 10,000 missions per value.

All five policies

Means over the same 10,000 missions. Years are mission years. Cold standby is shown at both ends of its spare aging range. Risk is the share of missions with at least one wrong result.

What this does not claim

• The parameters are illustrative, not calibrated. The claim is the shape of the trade, and the sweep shows where it holds.
• The ground team is perfect: it always diagnoses correctly and its command always works. Real anomaly response is slower and less certain, so this flatters the ground.
• A day is the unit of work. Power, thermal limits, and duty cycling are not modeled.
• Two or more upsets in a vote are always caught as a split, which slightly flatters every voting policy equally.
• The cold spare aging rate is a sweep, not a measured value. Cold standby keeps the correlated deaths of the powered history, so it slightly under-correlates.

The same quorum program ran in orbit on ESA's OPS-SAT PRETTY on October 18, 2026 (v0.3.1) and October 22, 2026 (v0.4.0), three software replicas on one payload processor with faults from a schedule. On October 28, 2026, the same decision core ran there as an F´ deployment (v0.7.0), each replica a process of its own, with a real process kill (results). That checks the program on a flight processor, not this model. The 1.34x figure comes from the 10,000 simulated missions here, not from those runs, and with no real upset in their 227 s and 136 s windows (the October 28 run had no upset sensor) the runs calibrate nothing in this model.

Run it yourself

Rust, no dependencies. Results depend only on the seed, and every number on this page comes from the same seeds.

git clone https://github.com/mruspace/dusk
cd dusk
cargo run --release              # the default scenario
cargo run --release -- --ground  # against TMR with a ground team
cargo run --release -- --ground --scale-years 60  # shorter-lived hardware
cargo run --release -- --sweep   # sensitivity, and cold standby by aging rate
cargo run --release -- --cold-aging 0.5  # cold standby at one aging rate

Cite this

@software{binns2026dusk,
  author = {Binns, Will},
  title  = {dusk: A Monte Carlo of Redundancy Policies on Hardware That Only Ever Decays},
  year   = {2026},
  url    = {https://github.com/mruspace/dusk},
  note   = {Results at https://dusk.mru.space}
}

References

1. R. E. Lyons and W. Vanderkulk, “The Use of Triple-Modular Redundancy to Improve Computer Reliability,” IBM Journal of Research and Development, vol. 6, no. 2, pp. 200–209, 1962.
2. J. von Neumann, “Probabilistic Logics and the Synthesis of Reliable Organisms from Unreliable Components,” in Automata Studies, C. E. Shannon and J. McCarthy, Eds. Princeton University Press, 1956, pp. 43–98.
3. D. P. Siewiorek and R. S. Swarz, Reliable Computer Systems: Design and Evaluation, 3rd ed. A K Peters, 1998.
4. W. Binns, “Mru: A Fault-Tolerant Operating System for Thousand-Year Autonomous Operation,” 2026. doi:10.5281/zenodo.23305299
5. NASA Jet Propulsion Laboratory, “NASA Turns Off 2 Voyager Science Instruments to Extend Mission,” March 5, 2025. jpl.nasa.gov
6. P. C. Brandt, E. A. Provornikova, et al., “Interstellar Probe: Humanity's Exploration of the Galaxy Begins,” Acta Astronautica, vol. 199, pp. 364–373, 2022. doi:10.1016/j.actaastro.2022.07.011
7. M.-C. Hsueh, T. K. Tsai, and R. K. Iyer, “Fault Injection Techniques and Tools,” Computer, vol. 30, no. 4, pp. 75–82, 1997.
8. W. Weibull, “A Statistical Distribution Function of Wide Applicability,” Journal of Applied Mechanics, vol. 18, no. 3, pp. 293–297, 1951.
9. A. Avižienis, J.-C. Laprie, B. Randell, and C. Landwehr, “Basic Concepts and Taxonomy of Dependable and Secure Computing,” IEEE Transactions on Dependable and Secure Computing, vol. 1, no. 1, pp. 11–33, 2004.
10. J. F. Meyer, “On Evaluating the Performability of Degradable Computing Systems,” IEEE Transactions on Computers, vol. C-29, no. 8, pp. 720–731, 1980.
11. B. Efron, “Bootstrap Methods: Another Look at the Jackknife,” The Annals of Statistics, vol. 7, no. 1, pp. 1–26, 1979. doi:10.1214/aos/1176344552
12. F. N. Fritsch and R. E. Carlson, “Monotone Piecewise Cubic Interpolation,” SIAM Journal on Numerical Analysis, vol. 17, no. 2, pp. 238–246, 1980. doi:10.1137/0717021