Mru Field: fault tolerance for equipment you cannot repair in time.
Mru Field runs on the two or three processors already in your enclosure. Each cycle it decides which results to trust. As processors fail, it moves from voting to comparing to self-checking, and keeps delivering checked results until none are left.
01 · What it does
Four things, and nothing else.
Fixed triple redundancy stops at the second processor failure. Mru Field continues with what is left, and tells your operators which mode it is in.
01
Steps down instead of stopping
Vote on three, compare on two, self-check on one. It halts only when no processor is left.
02
Delivers only checked results
A result leaves only if two processors agree, or the last one gets the same answer twice. Proved with Kani for every input.
03
Diagnoses before it retires
A processor outvoted 3 times in 200 cycles gets a known-answer test. It is retired only if it fails.
04
Logs every decision
Mode changes, retirements, detected and delivered results, and memory bit flips, for your telemetry.
02 · Requirements and limits
What it needs, and what it does not do.
Your instrument and control code stays as it is. Mru Field sits between that code and your processors.
| Processors | Two or three running the same task. One still works, in self-check mode. |
| Platforms today | Linux on ARM64, 32-bit ARM and x86_64. Decision core also builds bare-metal for ARM Cortex-M. |
| Footprint | About 1.5 MB of memory per process on ARM64, measured in CI. Binary about 0.5 MB. |
| Throughput cost | None with two or three processors alive. Half rate on the last one, because it computes twice. |
| Known limit | On the last processor, a stuck fault is caught only by a periodic known-answer test. A few wrong results can get out before it. The period is configurable. |
| Not for | Certified safety functions. Protection systems keep their own certification. |
Instrument and control code
Sampling, logging, telemetry. Unchanged.
Mru Field
Shrinking quorum, health record, known-answer tests, memory checks, decision log.
Two or three processors
The hardware already in the enclosure. No new boards.
Where it applies
All fifteen settings
Deep-sea observatories
Batteries, a cable, and one service visit a year.
Ocean buoys and moorings
Years at sea between services, on solar power.
Profiling floats and gliders
Deployed once, rarely recovered.
Offshore wind
Every repair needs a vessel and a weather window.
Polar stations
No access for months of the year.
Satellite-linked devices
Small power budgets, links measured in bytes.
03 · How we work with you
Simulate. Pilot. Then the fleet.
Each step is small enough to stop after. We are looking for a few first pilot partners for 2027.
1 · Simulate
Your hardware, modelled
We model your processors, failure rates and deployment length, and show what each redundancy design returns over the whole life. You get the model and the data.
2 · Pilot
One site, months unattended
Mru Field on your own equipment, with the decision log in your telemetry. A pilot in the Azores is planned to reach TRL 6.
3 · Fleet
Licence and support
Annual licence per site or fleet, with support and qualification evidence for your sector.
Questions
Is it open source?
The decision core and the simulator are open source under Apache 2.0, and the design is published. Mru Field adds integration, support and qualification for your site.
What evidence is there today?
Simulation over 10,000 missions, a fault-injection demo on real processes, and four Kani proofs. No unattended field deployment yet. The 2027 pilot is that step.
How is it priced?
An annual licence per site or per fleet, with support. We discuss terms once we know the hardware and the deployment.
Do we need to change our code?
Your task runs on each processor as it does now. Mru Field needs a defined result per cycle to compare, and a known-answer test for that task.