Ariane 5 Exploded Because of Code That Worked Perfectly on Ariane 4

Thirty-seven seconds after liftoff, Europe’s new rocket turned sharply off course. Moments later it broke apart and destroyed itself above the launch site in Kourou, French Guiana.

The rocket was Ariane 5, on its first flight. On board were the four Cluster science satellites. Nothing had exploded in an engine. No structure had failed on its own.

The cause was a number that did not fit.

The number was too big

Flight 501 lifted off on 4 June 1996. For the first half-minute, everything looked normal. Then both of the rocket’s inertial reference systems, the units that tell the flight computer where the vehicle is pointing and how it is moving, shut down within a fraction of a second of each other.

The independent Inquiry Board, chaired by the French mathematician Jacques-Louis Lions, traced the failure to one operation in the inertial reference software: converting a 64-bit floating-point value into a 16-bit signed integer. The value, an internal alignment result called BH, or horizontal bias, was larger than a 16-bit integer can hold. The conversion raised an “operand error.” The software had no handler for it, so the processor did what its specification required: it shut itself down.

The backup unit had already done the same thing, 72 milliseconds earlier. It was running identical software on identical data, so it hit the identical problem. The redundancy that was supposed to protect the mission simply failed twice.

The code did not need to be running

The most unsettling detail is that the calculation which failed had no purpose once the rocket left the pad.

The alignment function belonged to the period before launch. On Ariane 4, it was designed to keep running for roughly 40 seconds into flight, so that a countdown interrupted at the last moment could resume quickly without a long realignment. Ariane 5 did not need that behaviour. The function was kept anyway, for the sake of commonality with the proven Ariane 4 system.

On Ariane 4, the code was fine. Ariane 5 simply flew a different early trajectory, with considerably higher horizontal velocity. That pushed BH far beyond anything Ariane 4 had produced, and beyond what the 16-bit variable could hold.

The software was not “buggy” in the usual sense. It did exactly what it had been written to do. What had changed was the world around it.

A deliberate decision, made for good reasons

It is tempting to imagine a careless programmer who forgot a range check. The Inquiry Board found something more instructive.

Seven variables in that part of the code had been analysed for possible overflow. Four were protected. Three, including BH, were left unprotected, partly because the engineers were working to a maximum processor workload target of 80 percent and partly because they had concluded that those values were physically limited or had a large margin. That conclusion was true for Ariane 4. Nobody re-checked it for Ariane 5.

The Board also noted that the Ariane 5 trajectory data had not been included in the requirements for the inertial reference system. So the test campaign never fed the system the numbers that would have exposed the problem. The system was also simulated rather than wired into the full closed-loop tests. The report says plainly that the failure could have been detected.

Then the computer read an error message as flight data

Shutting down was only half the damage. When the active unit failed, it sent out a diagnostic bit pattern. The on-board computer interpreted that pattern as genuine flight data.

Believing the rocket was badly off attitude, the computer commanded full deflection of the solid booster nozzles and the main engine. The rocket pitched to an angle of attack of more than 20 degrees. Aerodynamic loads tore the boosters away from the core stage, and that separation triggered self-destruction about 39 seconds after liftoff.

Underneath it all was a design philosophy. As the Board put it, the specification treated a software exception as if it were a random hardware failure, something a backup could absorb. But a software design error is not random. Two copies of the same code fail together.

What the Inquiry Board told engineers to do

The report’s recommendations read like a checklist that still applies to software teams today:

Turn off functions that are not needed during flight. Code that is not running cannot fail.
Test the real system in closed loop, with realistic data, not just simulated components.
Do not let a sensor stop sending data entirely. Best-effort data beats silence.
Review the implicit assumptions in reused software, especially assumed ranges of values.
Put the actual trajectory data into the specifications and the test requirements.

The lesson is about reuse, not one line of code

Ariane 501 is often summarised as “a 64-bit number crashed a rocket.” That is accurate, but it misses the point. The overflow was the symptom. The cause was that a well-tested component carried an assumption from an old system into a new one, and that nobody owned the job of re-checking it.

In 1997, Jean-Marc Jézéquel and Bertrand Meyer called it a reuse error. Their argument was that reusable code needs its assumptions written down where they can be checked, not left in the heads of the people who wrote it.

Every software team inherits code that “has always worked.” The useful question is not whether that code is good. It is: worked under which conditions, and are those conditions still true?

Ariane 4’s software answered that question correctly for Ariane 4. Flight 501 is what happened when no one asked it again.

Explore

Stay connected