37 Seconds: The Most Expensive Software Failure in Space History
Europe's new heavy rocket flew for 37 seconds before a number too large for a 16 bit variable, in code the rocket did not need, running for a reason that no longer existed, destroyed it. The backup failed identically, because it was identical.
Flight 501
On June 4, 1996, the European Space Agency launched the maiden flight of Ariane 5, the heavy lift rocket a decade and several billion dollars in the making, carrying the four Cluster science satellites, themselves the product of years of work and roughly 370 million dollars. Thirty seven seconds after liftoff, the rocket veered abruptly off its trajectory, began to break apart under aerodynamic loads, and was destroyed by its automated self destruct system. No one was hurt. The inquiry board, chaired by the eminent mathematician Jacques-Louis Lions, produced a report within weeks that remains one of the most read failure analyses in engineering, because the chain it documented is a nearly perfect specimen of how software fails: not through exotic complexity, but through reasonable decisions whose assumptions silently expired.
The chain, per the Lions report
Ariane 5's inertial reference system, the unit that tells the rocket its own orientation and motion, reused software from Ariane 4, a rocket with a long, successful record. Prudent: flight proven code is precious. Within that software ran an alignment function that, on Ariane 4, usefully continued executing for a brief period after liftoff, a provision for a particular Ariane 4 operational scenario. On Ariane 5, that post liftoff execution served no purpose at all, but the function was left running, because it had always run and removing it was a change nobody needed to make.
The function calculated, among other things, a value related to the rocket's horizontal velocity, and at one point converted it from a 64 bit floating point number to a 16 bit signed integer. On Ariane 4, the physically possible values fit comfortably. Ariane 5 was a different, more powerful rocket with a different, faster trajectory, and 37 seconds in, its horizontal velocity value exceeded what a 16 bit integer can hold. The conversion overflowed and raised an exception. The exception was not handled for this variable, because analysis years earlier, on Ariane 4, had concluded the value could not physically grow that large, which had been true, for that rocket. The inertial reference unit, per its design philosophy that a software exception indicated a hardware fault best handled by shutdown, declared itself failed and stopped, transmitting diagnostic data. The rocket's guidance switched to the backup inertial reference unit, the redundancy provided for exactly this moment, and found that the backup had already failed, milliseconds earlier, in exactly the same way, because it ran identical software processing identical inputs. Redundancy without diversity is an echo, not a safety net. The flight computer, receiving the primary unit's diagnostic data on the channel where flight data belonged, interpreted the diagnostics as real attitude readings, commanded a drastic nozzle deflection to correct a deviation that did not exist, and the vehicle's fate was sealed inside a second.
The Lions report's most quoted finding is about testing: the alignment software had never been tested against Ariane 5's actual trajectory data. The system was reviewed, the code was flight proven, and the one test that mattered, does this code survive the numbers this rocket will actually produce, was never run, in part because the requirement to run it fell between the seams of reuse: everyone inherited confidence, and no one inherited the obligation to re earn it.
What it teaches
Ariane 5 opens this series' Tiny Bug Hall of Fame because it is the archetype from which half the hall descends. Reused code carries assumptions, not just functions, and porting software to a new environment means re validating every assumption against the new physics, the new trajectory, the new scale; flight proven means proven for the flights it flew. Dead and purposeless code is live risk, the same finding the SEC would write about Knight Capital sixteen years later: the alignment function had no job on Ariane 5 and killed it anyway. Exception handling policy is safety architecture: shut down on any anomaly is a reasonable philosophy for random hardware faults and a catastrophic one for deterministic software faults, which will recur identically on every identical unit. And redundancy requires diversity: two copies of the same software are one point of failure with two chassis. Every one of these lessons was purchasable, before the flight, for the price of one simulation run with real trajectory data. That is the Hall of Fame's founding exhibit: the gap between the cost of the test and the cost of its absence, measured here at roughly half a billion dollars in 37 seconds.
Sources
7 sources
Every figure in this article traces to one of the following: the same record the episode cites.
ARIANE 5 Flight 501 Failure Report by the Inquiry Board
Ariane 501 Inquiry Board, for the Director General of ESA and the Chairman of CNES1996
Flight 501 failure- first information
European Space Agency (press release N° 20-1996)1996
PR 33-1996: Ariane 501 - Presentation of Inquiry Board report
European Space Agency, Science and Technology1996
Ariane-5: Learning from Flight 501 and Preparing for 502
ESA Bulletin, nr. 891997
The Resurrection of the Cluster Scientific Mission
ESA Bulletin, nr. 911997
Design by Contract: The Lessons of Ariane
Jean-Marc Jézéquel and Bertrand Meyer, in Computer (IEEE)1997
James Gleick, The New York Times Magazine (archived by the Internet Archive)1996
