№ 006 · Results
Mru Flight ran in orbit
On 18 October 2026, Mru Flight v0.3.1 ran on ESA's OPS-SAT PRETTY satellite. Three software replicas on one flight processor, faults from a schedule, and a prediction written two days before the run, met on every tick.
What ran
On 18 October 2026 at 09:45 UTC, Mru Flight v0.3.1 ran on ESA's OPS-SAT PRETTY satellite, as experiment exp4051 of the ESA OPS-SAT Space Lab. The experiment was registered on 7 October and the package was sent on 15 October: eleven days from registration to orbit.
The package is the fault-injection demo from release v0.3.1, built as a static 32-bit ARM binary. One entry point runs the shrinking quorum, then fixed triple redundancy (TMR), with the same seed and the same fault schedule (one tick is one voting round): a sensor self-test at tick 20, a bit flip in replica 2 at tick 60, replica 1 stuck at tick 120, replica 0 killed at tick 240. Each run has 110 seconds, a 5% share of the processor, 128 MB per process, and a 64 MB block of memory scanned for upsets every 250 ticks.
Three hosts, the same events
The same binary ran three times: in ESA's software environment on 15 October (a Linux virtual machine, not the flight processor), on TU Graz's FlatSat on the flight processor on 16 October, and in orbit on 18 October. Every scheduled fault landed on the same tick on every host. No run gave a wrong result.
| Run | Shrinking quorum: correct, wrong, ticks | Fixed TMR: correct, then detected disagreements to tick | Total | Exit |
|---|---|---|---|---|
| Software environment, 15 Oct | 14,886 · 0 · 29,532 | 239, to 19,250 | 222 s | 0, 0 |
| FlatSat, 16 Oct | 2,745 · 0 · 5,250 | 239, to 4,778 | 224 s | 0, 0 |
| In orbit, 18 Oct | 2,745 · 0 · 5,250 | 239, to 4,500 | 227 s | 0, 0 |
Tick counts follow the speed of the host: the virtual machine ran about six times as many ticks as the SEPP in the same 110 seconds. The FlatSat and the orbit run gave the same counts for the shrinking quorum. Total is both runs plus start-up and the result files, from the run-info times.
In orbit
The shrinking quorum retired the stuck replica at tick 122, two ticks after the fault. It ran alone on the last replica from tick 240, checked by known-answer tests (80 in the run). The memory scan at tick 250 found the injected flip and repaired it. After 5,250 ticks and 113.5 seconds it had delivered 2,745 correct results and 0 wrong, at about 46 ticks per second.
Fixed TMR, on the same faults, delivered 239 correct results. From tick 240 it had one good replica and one stuck one, and it detected a disagreement on every tick to 4,500 without delivering a result. On the last replica, where fixed TMR stops, the shrinking quorum keeps delivering checked results.
The voter used 65,992 KiB resident, almost all of it the 64 MB sensor block, and 5.2% of wall time including start-up. Each replica used 452 KiB.
What we said it would do
The prediction had five parts. The same events on the same ticks as on the FlatSat: met, every fault on its tick. About 2,700 correct results for the shrinking quorum: 2,745. 239 for fixed TMR: 239. Zero wrong results: zero. About 225 seconds in total: 227. We also wrote that any real upset would show as an extra sensor_upset line in the log. There was none.
What it shows, and what it does not
It shows that the policy runs on a flight processor, in user space, at a 5% share of the processor, and keeps delivering correct results on the last replica where fixed TMR stops. It shows that one binary gives the same events on a virtual machine, on the FlatSat and in orbit. For an operator, that answers one question: the policy behaves the same on the flight processor as on the ground.
It does not show more than that. The three replicas were software processes on one Linux processor, not three processors. The faults came from a schedule, not from the environment. The memory sensor saw no real upset in 227 seconds. The run used the demo voter and replicas, not the F´ components. Qualification evidence needs the F´ version in orbit, real upsets and a long run. This run is the step before that.
One defect: both runs overran the 110-second cap by about 3 seconds. The limit is checked once per tick, and the last tick was a 64 MB scan. A fix is planned for the next version.
Next
A second run of five minutes or less is proposed to ESA, with a hung replica, a stuck bit on the last replica, a safe halt and a resume across a restart. It is not scheduled. Until then, the numbers above are the whole record: one run, 227 seconds, zero wrong results.