Ariane 5: The Code Worked in Every Demo and Destroyed the Rocket

Mostafa Dhouib·August 15, 2026·7 min read

Ariane 5: The Code Worked in Every Demo and Destroyed the Rocket

The short answer. The module had a flawless record on Ariane 4 and had never been executed against the Ariane 5 flight envelope. Ariane 5 produced horizontal velocity values roughly five times larger, the conversion to a 16 bit signed integer exceeded 32,767, and both inertial reference units failed within microseconds of each other.

Every argument about reusing proven code runs into this flight eventually, and it is usually told as a story about integer overflow. That is the mechanism, not the lesson. The lesson is about what a track record is evidence of.

What actually happened

From the Inquiry Board report chaired by Jacques-Louis Lions, published 19 July 1996.

The Inertial Reference System software was reused unchanged from Ariane 4. Inside it sat an alignment function that continued running for about forty seconds after liftoff. On Ariane 4 that had a purpose, related to the ability to restart the alignment quickly if a countdown was held late. On Ariane 5 it served no purpose whatsoever, and nobody had removed it.

Within that function, a 64 bit floating point value representing horizontal bias, related to horizontal velocity, was converted to a 16 bit signed integer.

Ariane 5's flight profile produced horizontal velocity values roughly five times larger than Ariane 4's. The value exceeded 32,767, which is the largest number a 16 bit signed integer can hold, and the conversion raised an Operand Error. It was unhandled.

Only four of the seven at-risk variable conversions had been protected against overflow. This one was among the three left unprotected, and the reasoning was a performance budget: the unit was being held to a maximum workload target of about 80 percent, and protection code costs cycles.

What happened next is the part that turns a bug into a total loss. The exception was interpreted as a hardware failure, so the active unit shut itself down and handed over to the backup. The backup had already failed microseconds earlier, for exactly the same reason, because it was the same software processing the same data. With no valid attitude data, the on-board computer commanded full nozzle deflection. The launcher swung, aerodynamic loads tore it apart, and the self-destruct fired. Roughly 370 million dollars of payload.

The exact verification gap

The Board's language is worth reading closely, because it is not about the overflow.

They found that the reviews did not include adequate analysis and testing of the inertial reference system for Ariane 5, and that the code was used with no specific verification for Ariane 5. Their stated cause was specification and design errors in the software of the inertial reference system.

Not a coding error. Not a missed edge case. The module's correctness argument had been constructed against Ariane 4 trajectory bounds, and it was carried across to a vehicle with different bounds without anybody re-running it against the new ones.

Why the demonstration record was worth nothing

This is where the story stops being about aerospace.

The module had never failed. That is true and it was widely known and it was the reason nobody worried about it. But it had never failed because the input that breaks it had never been supplied. A record accumulated inside one operating envelope tells you about that envelope. It makes no claim at all about behaviour outside it.

Say it as a general rule and it becomes uncomfortable: a module's test history is a statement about the environment it ran in, not about the module. Reuse moves the code and leaves the evidence behind. What arrives in the new system is the code plus a feeling.

The uncomfortable part is that this applies to everything anyone has ever called battle-tested. A library that has served ten million requests has been verified against the distribution of those ten million requests. A model that has run for a year in one plant has been verified against that plant's inputs. A driver proven on one board revision is unproven on the next. In every case the confidence is real, transferable to nothing, and almost never re-examined at the moment of transfer, because the transfer is precisely when it feels safest.

Would a negative control have caught it

Yes, and it is close to trivial.

Drive the inertial reference module with the actual Ariane 5 trajectory, meaning its real, larger horizontal velocity profile, on the ground. The conversion overflows in the lab. It is one test, it needs no flight hardware, and the input it requires is a document that already existed, because somebody had to compute that trajectory in order to build the rocket.

That is a negative control aimed at the new operating envelope rather than at the code. The distinction matters, because a code review of the module would have found nothing wrong with it. It was correct. It was correct for Ariane 4.

What re-verification actually means

If you inherit a module, the work is smaller than it sounds and it is almost never done.

Write down the envelope it was verified against. Input ranges, rates, timing assumptions, what the surrounding system guarantees it, and what it assumes about the hardware underneath. This document usually does not exist, which is itself the finding.

Compare it to the new system's envelope, item by item. The gaps are your test list. Ariane's gap was one row: horizontal velocity, roughly five times larger.

Drive the boundaries on the ground. Not the nominal case, which is what a demonstration already covers. The edges of the new envelope, which is what nothing covers.

Look hardest for assumptions about things that were removed rather than changed. A numeric range that grew is visible if you look. An assumption that some other part of the system was providing a guarantee, which the new system no longer provides, is invisible in the code because it was never written there. That is how the Therac-25 killed people: it reused software whose safety assumption was that hardware interlocks would prevent unsafe states, and the new machine had removed the interlocks.

Delete the code that has no purpose here. The alignment function had no function after liftoff on Ariane 5. It was running, consuming budget, and holding the fault, for a requirement that belonged to a different vehicle.

If you want a structured way to work out how much of the field your bench actually reproduces, that is what the bench to field coverage tool does, and the multiplication in it is unkind. The general argument this case belongs to is in a test that has never failed is a decoration.

FAQ

What caused the Ariane 5 Flight 501 failure? A 64 bit floating point horizontal bias value was converted to a 16 bit signed integer in inertial reference software reused unchanged from Ariane 4. Ariane 5's horizontal velocity was roughly five times larger, the value exceeded 32,767, and the resulting unhandled Operand Error took down both the active and backup units.

Why did the reused Ariane 4 code fail on Ariane 5? Because its correctness argument assumed Ariane 4 trajectory bounds. The Inquiry Board found the code was used with no specific verification for Ariane 5, so the larger flight envelope reached a conversion that had never been exercised against it.

Could testing have caught the Ariane 5 bug? Yes, with one ground test. Driving the module with the actual Ariane 5 trajectory forces the overflow in the lab, using a trajectory profile that already existed on paper.

Why did the backup system fail too? It was running the same software on the same data, so it hit the identical overflow microseconds earlier. Redundancy protects against random hardware faults, not against a deterministic fault in software that both channels share.

What does Ariane 5 teach about reusing code? That a module's test history is evidence about the environment it ran in rather than about the module. Reused code has to be re-verified against the new operating envelope, and the most dangerous assumptions are the ones about guarantees the old system provided and the new one does not.