Systems that still run a thousand years after we're gone
Mru is software for systems that cannot be easily maintained or repaired: ocean observatories, offshore and remote sites, spacecraft. When processors fail, it keeps delivering checked results with the ones left, instead of stopping.
The problem
Most fault tolerance assumes someone can step in eventually.
Spacecraft mostly fly two strings of radiation-hardened processors, with error-correcting memory, watchdogs and autonomous fault protection. When a part fails, the system makes itself safe and people decide what comes next. On equipment nobody can reach in time, that wait can be the rest of the deployment.
Stepping down from three replicas to two to one is not new: the Space Shuttle's computers did it. Mru adds three things. It degrades on its own, with no ground team. Its decision core is small and verified. Its trade data is public. Prior art
What it costs to reach the hardware. Batteries, sensors and mechanical work cause most of these visits, not processor failure, and Mru does not remove them. Mru keeps the processors that are left doing checked work between visits. It needs two or more processors, and each extra processor costs power.
Voyager in flight, with a ground team the whole time. Its limit is power, about 4 W less each year. Mru does not address power today.
NASA JPL, 2025 · Photo NASA/JPL, PD
EMSO-Azores, on batteries at 1,700 m. A maintenance cruise reaches it once a year.
EMSO-Azores cruises · Photo Ifremer, CC BY 4.0
New Argo floats needed each year to hold the array. Each costs about $20,000, about double once deployed. Batteries set a float's life at 3 to 5 years.
Argo Program FAQ · Photo Ifremer, CC BY 4.0
About the charter day rate for a service operation vessel at an offshore wind farm, excluding fuel.
£30k · BVG Associates · Photo US DOE, PD
Mechanism
Vote on three. Compare on two. Self-check on one.
On three replicas, Mru votes as fixed TMR does. On two, a mismatch triggers a known-answer test that can find and retire the bad replica, where fixed TMR stays in disagreement. On one, the last processor computes twice and delivers a result only when both runs match. Remove a processor to compare.
The full rule, in the docsFixed TMR
Vote
Two of three must agree. One bad result is outvoted.
Mru · shrinking quorum
Vote
Same outcome as TMR for the same replies.
| Processors left | Fixed TMR | Mru |
|---|---|---|
| 3 | Vote. One bad result is outvoted. | Vote. One bad result is outvoted. |
| 2 | Compare. A mismatch loses the result. | Compare. A known-answer test finds the bad one. |
| 1 | Stopped, for good. | Still working, at half speed. It computes twice and checks itself. |
Evidence
1.34× the useful work of fixed TMR, on the same hardware.
Dusk, our open-source Monte Carlo: 10,000 missions on processors that fail and are never repaired. Every policy sees the same fault history. This assumes no ground support after launch. With ground support that never ends, the gain is 1.00×. Ground support
Against autonomous baselines the result is mixed. Cold standby does more work when an unpowered spare ages at less than 0.20 of the powered rate. A fallback with no self-check does more work, with far more wrong results.
In orbit on ESA's OPS-SAT PRETTY, 18 October 2026: 2,745 correct results and 0 wrong over 5,250 ticks, where fixed triple redundancy stopped at 239. Mru Flight ran in orbit
| Against fixed TMR | 1.34× (95% CI 1.33× to 1.35×) |
| Against cold standby, three strings, spares aging 0.1 to 1.0 | 0.92× to 1.60× |
| Against TMR with an unchecked fallback | 80% of the work, 1.00% of the wrong results |
| Missions with at least one wrong result | Mru 20.1%, fixed TMR 0.0%, cold standby 43.2% to 61.3% |
| Fixed TMR wins only if one wrong result costs more than | 136 years of work (95% CI 131 to 142) |
| Against fixed TMR, across the sensitivity sweep | 1.11× to 1.68× |
Limits: parameters are illustrative, not calibrated to flight data. Power and thermal limits are not modeled. The aging rate of an unpowered spare is not known, so it is swept. Full results and method
Where it applies
Hard-to-reach systems on Earth.
Mru fits when three things are true: the equipment has two or more processors, it must run unattended for months or longer, and a repair visit is slow, costly or impossible.
See more use cases
Products
One core, on Earth and in space.
The same core runs in both products.
Earth
Mru Field
For hard-to-reach systems on Earth: ocean observatories, buoys, offshore and remote sites. Annual license per site or fleet, with support.
Mru FieldSpace
Mru Flight
Onboard software for spacecraft, built on NASA JPL's F´. v0.3.1 has run once in orbit, on ESA's OPS-SAT PRETTY. Per mission, with support. Qualification is planned; no qualification evidence exists yet.
Mru FlightOpen core: the decision core and the simulator are public under Apache 2.0, and the whitepaper under CC BY 4.0. We sell integration, support and simulation of your own hardware.