Space 4 November 2026 4 MIN READ

Ariane 5 Flight 501: Thirty-Seven Seconds

How reused software and one unprotected number destroyed a new rocket in 1996, and what the official inquiry recommended.

THE SHORT ANSWER

Ariane 5's first flight in 1996 broke up 37 seconds after ignition. Both inertial reference systems shut down when software reused from Ariane 4 tried to fit a too-large 64-bit number into 16 bits. The inquiry blamed unprotected code, missing tests and a decision to stop the processor.

On this page

Thirty-seven seconds

On 4 June 1996 the first Ariane 5 rocket lifted off from Kourou, French Guiana. According to the official inquiry report, the flight was normal until about 37 seconds after the main engine ignited. Then the vehicle suddenly veered off course, broke up and exploded.

The Inquiry Board, set up by the European Space Agency and the French space agency CNES and chaired by Jacques-Louis Lions, delivered its report on 19 July 1996. It is unusually readable, and it names the culprit precisely.

What failed

The rocket has two inertial reference systems, which tell it how it is oriented and moving. Both stopped working almost together at about 36.7 seconds after the main engine ignited. The active unit failed about 0.05 seconds after the backup, for the same reason. With both gone, the loss of the mission was inevitable.

After failing, the active unit sent diagnostic data that the flight computer treated as real flight data. It commanded large nozzle deflections to correct an attitude error that had not happened. About two seconds later, aerodynamic loads from an angle of attack of more than 20 degrees began to tear the launcher apart, and the separation of the boosters triggered the self-destruct system.

A number that did not fit

The software exception came from converting a 64-bit floating-point number into a 16-bit signed integer when the value was too large to fit. The result was an Operand Error in the Ada code. The variable was the horizontal bias, an indicator linked to the horizontal velocity the platform senses. Its value was far higher than expected.

The story is usually told as a simple overflow, but the Board’s account has more layers.

  • A routine with no job. The failing code was a pre-launch alignment routine, which has no useful output after lift-off. It kept running for about 40 seconds of flight because of a requirement from Ariane 4 that was not needed on Ariane 5.
  • Reuse without re-checking. The inertial reference system design, and especially its software, was practically the same as on Ariane 4. The requirement stayed for what the Board calls commonality reasons, apparently because it seemed unwise to change software that worked. The Ariane 4 feature that motivated it had been used only once, in 1989.
  • A new trajectory. Ariane 5 builds up horizontal velocity five times faster than Ariane 4. That pushed the variable beyond the range the software could hold.
  • Protection by choice. A vulnerability analysis found seven variables at risk of an Operand Error. Four were protected and three, including this one, were not. The Board was told that not all conversions were protected because a maximum workload target of 80% had been set for the computer.
  • A fatal reaction. The decision to stop the processor when an exception occurred, as the specification said, is what finally proved fatal. Because both units ran the same software, one design error switched off two healthy machines.

The Board also noted a testing gap. No test checked how the inertial reference system would behave under the Ariane 5 flight sequence and trajectory, and the Board said that such a test would have exposed the failure mechanism.

The report contains 14 recommendations. Three are easy to remember.

  • Switch off the alignment function after lift-off. More generally, no software function should run during flight unless it is needed.
  • Never let a sensor stop sending its best-effort data.
  • Put trajectory data in the specifications and in the tests.

Behind these sits a stance that was the opposite of the programme’s prevailing view: software should be assumed faulty until best-practice methods demonstrate that it is correct.

What it cost

The report gives no monetary figure. The Independent reported at the time that the rocket and its payload of four Cluster satellites were worth around £500 million and were not insured, and the New York Times Magazine said ESA took ten years and $7 billion to produce Ariane 5. Both are press estimates. ESA approved a Cluster-II replacement mission in April 1997 for a total of 214 million ECU, and the second Ariane 5 test flight on 30 October 1997 was, in ESA’s words, also a partial failure. The third, in October 1998, was a success.

Why it matters

The failure was not exotic. It is the kind of thing that happens when code that works in one context is trusted in another, and when a safety check is dropped to save processor time.

Our take: the old code was correct, for a different rocket. What failed was not the program but the assumption that it still applied. That assumption is the hardest bug to test for.

Do you agree?

Take it to Chevlume: write your view, add your sources and let others answer. The closed alpha is by invitation.

Discuss this on Chevlume

Keep reading

Sources

  1. ARIANE 5 Flight 501 Failure: Report by the Inquiry Board · ESA/CNES Inquiry Board (copy hosted by University of Bielefeld, Faculty of Technology) · Accessed
  2. Ariane-5: Learning from Flight 501 and Preparing for 502 · European Space Agency (ESA Bulletin 89) · Accessed
  3. Bang! went $7bn research, pounds 500m in kit, 10 years' work, dozens of scientists' careers and, probably, Europe's future in space · The Independent (Tom Wilkie) · Accessed
  4. Little Bug, Big Bang · The New York Times Magazine · Accessed
  5. Summary - Cluster - Science Portal · European Space Agency · Accessed
  6. Ariane 5: the story behind the 100 launches... · European Space Agency · Accessed
Discuss on X