Mru Aerospace

We're building Mru: A Fault-Tolerant Operating System for Thousand-Year Autonomous Operation

Everything Mru's planned kernel does must work for a thousand years. So it does almost nothing.

The bottom layer of Mru is planned to be tiny: a few hundred instructions, small enough to prove correct. Its only job is to keep the machine alive. Everything clever runs above it.

The oldest distributed system on Earth is life. No maintainer, no patches, no downtime, for 3.5 billion years. Nobody has launched anything like it. Yet.

A sensor 1,700 m under the Atlantic gets one visit a year, when a ship can reach it. If a fault starts to corrupt its results in month two, the bad data can run for ten months before anyone looks. We recently released Mru Field 0.1.0 for equipment like this. It runs the task as three copies, lets out only results it has checked, and keeps going as copies fail. It's the same decision code that ran on ESA's OPS-SAT satellite.

Kill one copy and the others keep running. We showed that part in orbit on October 18. Corrupt the stored instructions and the copies restore them. That part is still the design. A living cell does both.

Everything we build is open source. The code that ran in orbit, the simulator, the paper. If software is going to outlive the people who wrote it, anyone should be able to read it.

The comparison with biology has a hard limit. Life makes billions of copies, lets most of them die, and lets selection fix the bugs. A probe is one machine. No copies, no selection. So we borrow how a cell is built, not how evolution works.

Mru Field runs your task three times on the same processor. Three running: the majority wins. One fails: the other two compare. Two fail: the last one does the work twice and checks itself. It stops only when nothing is left.

No software has ever run for 100 years. Nothing digital is that old yet. The first program that does will run on a machine nobody can reach.

One cell holds millions of ribosomes, all running the same tiny program. Lose a few and nothing notices. A probe's chip could work the same way: many copies of one small program, so losing part of the chip costs a little, not everything.

From the Mru paper: 'Robustness lives not in any part but in the replication of a simple interpreter over a mutable program.' That sentence describes a living cell. It also describes the spacecraft we want to build.

NASA JPL's F´ is open-source flight software. It flew the Ingenuity helicopter on Mars. Mru Flight now comes as F´ components. They're built, they ran in full in ESA's test environment, and on October 26 we proposed them to ESA for our third run in orbit.

In the late 1940s, John von Neumann showed on paper that a machine could build a copy of itself from a written description. Almost eighty years later, that idea is where we start on a probe that has to rebuild itself around its own broken parts.

Your phone gets a software update every few weeks. A probe sent to another star will get none, for centuries. Everything it will ever need has to leave Earth with it, including a way to adapt.

Every cell in your body runs the same tiny machine, the ribosome. It reads instructions and builds what they say. Nobody has maintained it for 3.5 billion years. That is the design we want for a probe: a tiny reader that never changes, and instructions that can.

A service ship at an offshore wind farm costs about $40,000 a day, before fuel. Most trips are for batteries, sensors and moving parts. Software can't fix those. But a processor that starts giving wrong answers shouldn't need a ship. Mru Field keeps it delivering checked results until the next visit.

Our software successfully ran on an ESA satellite for the second time on October 22. Its three copies failed one by one as planned. When the last one went bad, it stopped rather than give a wrong answer. Then we shut the program off without warning. It restarted where it left off, with 0 wrong results.