On June 4, 1996, the first flight of the European Space Agency’s new Ariane 5 launcher ended in destruction roughly 37 seconds after the start of the main engine ignition sequence. The vehicle veered off course, broke up under aerodynamic load, and was destroyed, taking with it four Cluster science satellites. ESA convened an independent Inquiry Board, whose findings were presented in July 1996. The official ESA summary states that “the failure of Ariane 501 was caused by the complete loss of guidance and attitude information 37 seconds after start of the main engine ignition sequence,” and traced this to “specification and design errors in the software of the inertial reference system.”
The technical mechanism became one of the most cited software-engineering cautionary tales. The inertial reference system (the SRI, from the French Systeme de Reference Inertielle) ran an alignment routine that was only meaningful before liftoff but was left running for a short window after launch, a carryover from the older Ariane 4. Inside that routine, a 64-bit floating-point value related to horizontal velocity was converted to a 16-bit signed integer. Ariane 5 built up horizontal velocity far faster than Ariane 4, so the value exceeded what 16 bits could hold. The conversion overflowed, the operand error was not trapped, and the SRI software shut itself down.
What made the outcome catastrophic was the design’s response to that shutdown. Both the primary and the backup inertial reference units ran identical software, so the backup failed first in exactly the same way moments before the primary, leaving no redundancy. The failed SRI then sent diagnostic data to the on-board computer, which interpreted that diagnostic bit pattern as if it were genuine flight data. Acting on nonsense, the computer commanded extreme nozzle deflections, the boosters and main engine swiveled to their limits, and the vehicle broke apart.
The Inquiry Board emphasized that the overflowing conversion was not even needed on Ariane 5, and that the reused code had never been re-analyzed against the new launcher’s trajectory. The reviews and tests during development “did not include adequate analysis and testing of the inertial reference system or of the complete flight control system, which could have detected the potential failure.” In other words, the bug was a software defect, but the disaster was a systems-engineering and verification failure: critical reused code carried unstated assumptions, the overflow was unprotected, redundant channels were not truly independent, and the integrated system was never tested under the real flight profile.
Ariane 5 Flight 501 remains a standard reference in software safety teaching precisely because every link in the chain was preventable. It illustrates how an arithmetic edge case (see integer-overflow) becomes lethal only when combined with absent exception handling, identical redundancy, and a downstream component that trusts a corrupted input. The lessons reinforced the broader discipline of treating software in safety-critical systems as a whole-system hazard rather than a collection of correct modules, and they directly informed the changes carried into the later, successful Ariane 5 flights.