You can't pull over a satellite

Ariane 5 carried two inertial reference systems on its first flight. Both failed. Thirty seconds after lift-off, the rocket had lost the guidance and attitude information it needed.

Having a spare had not saved the flight.

That is what pulls me towards embedded systems in aerospace. A value in memory can become a motor command, a control-surface movement, or a thruster firing. The distance between a software mistake and something moving in the real world can be very short.

And the machine has to keep making decisions while things go wrong.

A drone can lose a sensor. A launch vehicle can encounter a condition its software was never properly tested against. A spacecraft can suffer a radiation-induced upset. Putting a second computer beside the first sounds reassuring. The interesting question is whether it will fail for the same reason.

A tiny chip with a very physical job

The hardware is often less exotic than the vehicle around it. The Pixhawk 6X flight controller, for example, uses an STM32H753 microcontroller. Its design includes three IMUs and isolated sensor domains with separate buses and power control. That is a recognisable microcontroller family doing a job where sensor availability matters to flight.

That does not mean an STM32 board, a satellite onboard computer, and an airliner’s flight-control system are interchangeable. Their environments, assurance requirements, and acceptable risks differ enormously. It does mean the engineering questions connect: which information can I trust, how much time do I have, and what happens if this component stops cooperating?

Take timing. Imagine a control task with an illustrative two-millisecond deadline. Getting the calculation right after five milliseconds does not meet that requirement. During those extra milliseconds, the vehicle has continued moving. A fast average execution time tells you little about the one delayed cycle that matters.

Suddenly an innocent-looking blocking call deserves a much closer look. So does an interrupt that can monopolise the CPU, or a shared resource whose owner takes longer than expected. These are the details I find compelling: a scheduling decision on a small chip has consequences for a flying machine.

Two computers can share one bad assumption

Ariane 501 is a hard example to forget. On 4 June 1996, the first Ariane 5 flight failed. ESA’s account of the inquiry describes the failure of both inertial reference systems and the resulting loss of guidance and attitude information. It also identifies inadequate analysis and testing of the reference system and complete flight-control system.

There were two reference systems. The failure still got through.

The lesson I take from that is to ask exactly what the spare protects against. A second unit can cover the loss of one piece of hardware. It cannot, by its mere presence, protect against a design assumption shared by both units. Testing each box is also different from testing the boxes together under the conditions of the actual flight.

You can see the distinction on a much smaller scale. Put three sensors on one vulnerable power rail and you still have a way to lose all three together. Feed three processors the same incorrect input and agreement may be entirely unhelpful.

Redundancy starts with a fault you intend to survive. The extra hardware comes after that decision.

An illustrative majority vote, not a particular vehicle’s architecture. Two agreeing channels can outvote one faulty channel under the assumed fault model. Shared causes and the voter itself still need analysis.

NASA gives that starting point a useful name: the failure hypothesis. Its guidance for safety-critical avionics asks designers to specify assumptions about the kinds, number, and persistence of failures the architecture can tolerate. That makes “fault tolerant” a claim you can examine, rather than a reassuring label.

A computer needs to know when to stop talking

One detail in Orion’s avionics architecture is particularly good: a flight computer module that detects an internal disagreement stops sending outputs. NASA describes it as failing silent. The module can then reset, learn the current state from the other modules, and rejoin.

That recovery sequence matters. A restarted computer cannot safely assume that the spacecraft is still doing whatever it was doing before the reset.

Orion also has a dissimilar backup processing platform with independently developed flight software. That adds another layer beyond duplicating the primary computers. It is a much more interesting design story than simply counting processors.

At microcontroller scale, a watchdog raises a related question. It can detect that expected progress has stopped and trigger a reset. But after the reset, what happens to the outputs? Which state is restored? Does the same input immediately trigger the same failure again?

A timer being serviced proves that some code is running. The health checks behind it need to establish whether the work that matters is progressing.

Space can change the data underneath you

Radiation adds a failure mechanism that is wonderfully inconvenient for software: stored state can change without the intended write. NASA’s small-spacecraft avionics review distinguishes single-event upsets from cumulative radiation damage and other single-event effects. An upset can alter a memory cell’s logic state; other effects can be destructive.

Error-correcting memory, radiation-tolerant parts, redundancy, and recovery mechanisms address different parts of that problem. None makes every failure disappear. The choice depends on the mission and its risk tolerance; a short student satellite mission and a crewed spacecraft have very different budgets and consequences.

I like how concrete this makes the hardware-software boundary. The program’s assumptions depend on the electronics continuing to represent its state correctly. The system needs a response for the occasions when that assumption breaks.

“Safe” depends on what is still working

It is tempting to imagine one universal emergency action. A satellite, a rocket during ascent, a hovering drone, and an aircraft on approach make that idea fall apart quickly. Their remaining options and available time are different.

Even “return home” is conditional. You need a usable estimate of where home is and where the vehicle is now. PX4’s failsafe documentation makes those dependencies explicit: position-loss responses depend on the vehicle, flight mode, and estimates that remain available. A recovery action has prerequisites too.

That is where resilience becomes a system problem. Losing one function should lead to a defined next behaviour, with enough working hardware and software left to carry it out. Sometimes the mission can continue. Sometimes the sensible goal becomes preserving the vehicle or the people aboard it.

Proving that takes tests with awkward timing: a sensor fails during a manoeuvre, a processor restarts while another channel is unavailable, or a fault arrives during recovery. A clean demonstration of normal flight will not answer those questions.

My work on payload-manager software for Da Vinci Satellite sits within this broader world of embedded aerospace systems. What keeps me interested is following a small decision all the way out: from a peripheral register, through software and subsystem interfaces, to what the spacecraft actually does.

The launch and the flight get the photographs. I also want to know what the computers do when they disagree, and which decisions let the vehicle keep going.

---

Cover: AI-generated editorial illustration of a fictional satellite. Voting diagram: a simplified explanatory drawing, not a flight-system design.