Ariane 5: the assumption in both computers

The 1996 inquiry traced a failed conversion through a backup system, a test gap and the decision to trust reused software.

Explainer · 2026-10-16 · Codex · AI-written · Edited by Codex · 5 min read

Primary-source statement · Ariane 5’s first flight, on June 4, 1996, ended before it could demonstrate its intended mission. In its July 1996 announcement of the inquiry’s findings, the European Space Agency described a launcher that had behaved normally until about 36 seconds after the start of the ignition sequence, then lost the guidance information needed to remain on course. The inquiry put that loss at 37 seconds after the sequence began, or 30 seconds after liftoff. Those are different clocks. The original record is more revealing than a compressed tale of a rocket destroyed by one bad calculation. [1]

Primary-source statement · The inquiry describes two inertial reference systems with identical hardware and software. The active unit hit an exception converting a 64-bit floating-point value to a 16-bit signed integer. A horizontal-bias calculation exceeded the expected range because Ariane 5’s early trajectory produced greater horizontal velocities than Ariane 4’s. Switching units could not restore service: the backup had failed for the same reason during the preceding 72-millisecond cycle. A diagnostic bit pattern from the active unit was interpreted as flight data. The onboard computer commanded extreme nozzle movements, and aerodynamic forces broke the launcher apart. The shared defect had defeated the backup. [2]

Primary-source statement · The arithmetic problem is approachable without knowing how to design a rocket. In his written analysis, software engineer Robert L. Baber expresses the conversion as assigning an integer version of a value to an integer variable. A signed 16-bit destination can represent integers from minus 32,768 through plus 32,767. A larger source format does not enlarge the destination. Baber’s point is that a conversion has a precondition: the resulting value must fit the permitted range. For an invented illustration, assigning the integer 40,000 to that signed 16-bit range cannot satisfy the condition. That is an explanation of a boundary, not a recreation of Ariane’s actual data or a test of its software. [3]

Primary-source statement · Baber also argues that the restriction must be followed backward through the calculations that produce the input, rather than treated as a detail belonging only to the conversion instruction. A component can meet its arithmetic contract with one set of inputs and violate it with another. His mathematical discussion explains what a successful conversion requires; it does not independently establish the flight sequence. For that, his article relies on the inquiry. Keeping those roles separate preserves the useful explanation without presenting a later interpretation as another investigation. [3]

Primary-source statement · The ESA announcement identifies another part of the failure: an alignment function useful before launch continued operating afterward. It says this function had not been accounted for in the simulations, and that equipment and system testing were insufficiently representative. The announced remedies included inhibiting alignment after liftoff, changing fault handling so that a detected fault did not simply stop the processor, and simulating actual trajectories on the reference electronics. These measures address different steps in the chain. Removing the unused function and improving the system’s response to an exception were both part of the stated plan. [1]

Primary-source statement · The inquiry’s testing discussion makes the gap more specific. Equipment tests rigorously covered environmental conditions, but had not exercised the reference system against Ariane 5’s countdown, flight timing and trajectory. The complete-flight simulations substituted software models for the actual reference units. The board acknowledged technically valid reasons for that choice, including precision and simulation difficulties. Its objection was to assuming the missing coverage had been supplied by previous qualification or Ariane 4 service. A model could help test one requirement while leaving a different, consequential behavior untested. [2]

Primary-source statement · In a subsequent ESA Bulletin account, J. de Dalmau and J. Gigou described changes to engineering responsibility as well as to code. Embedded software had previously been treated within hardware equipment items, leaving its detailed design and effects elsewhere in the vehicle insufficiently understood. The response established a software-architect role and called for embedded programs to be separately controlled configuration items. The authors described responsibilities for specifications, reviews, qualification plans and system implications. They also distinguished changes coded and tested at unit level from validation still planned at system level. A repair’s existence and evidence that the whole system handles it were separate milestones in their account. [4]

Primary-source statement · NASA’s later guidance gives that distinction a practical counterpart. Its Software Engineering Handbook requirement SWE-211 calls for reused and off-the-shelf embedded software to be tested to the same level required for a custom-developed component’s intended use. The relevant phrase is “for its intended use.” The guidance includes interfaces, operating conditions and the particular version being integrated. A history of successful use elsewhere does not remove that new acceptance task. This is NASA’s engineering requirement, not a claim that every program everywhere is governed by it, nor proof that any test program guarantees safety. [5]

Primary-source statement · A written set of NASA Engineering and Safety Center slides prepared by Cornelius Dennehy separately lists evaluation of identical-component redundancy and evaluation of inherited hardware and software as design practices. It also calls for hardware-in-the-loop testing and end-to-end checks from sensors to actuators. These recommendations connect two questions that are easy to separate on an organization chart: whether an individual part behaves as expected, and whether the whole control chain responds correctly. The slides caution that their best practices are no substitute for sound engineering judgment. More duplicated equipment and a longer test list are not, by themselves, the acceptance evidence those recommendations ask for. [6]

Analysis · For an engineering review, the useful question is consequently more demanding than whether a part worked before. NASA’s intended-use requirement asks what must be shown in the new application; ESA’s account assigns responsibility for the software’s effects across that application. Taken together, they suggest asking which input assumptions remain valid, which failure responses have been exercised, and who owns the evidence linking component tests to system behavior. This is an analytical lesson from the records, not an accusation about a present product. Reuse can begin a design. Its supporting evidence still has to reach the system being built. [5] [4]

Reporting note. Based on selected original inquiry pages, ESA’s written response and later engineering documents. No flight recording, recovered equipment, source-code audit or ICU reproduction was performed. Later authors share the inquiry’s flight evidence.

Corrections

No corrections recorded.

Report an error