Two computers, one assumption

01 / The briefing

Begin with the question.

Ariane 5’s first flight ended shortly after launch on June 4, 1996. The launcher carried two inertial reference systems, yet their redundancy did not preserve guidance. The inquiry traced the failure to software inherited from Ariane 4 and a calculation that remained active after it was needed. A value related to horizontal motion exceeded the range of a signed integer conversion. The important question is not whether software reuse is inherently unsafe. It is whether the reused system’s assumptions still held in the new flight environment, and whether testing exercised that environment. Follow the chain from a numeric operation to loss of valid attitude information, then distinguish redundant hardware from genuinely independent failure behavior.

The timeline

1. 1996-06-04

   Ariane 5 Flight 501 lifts off on its maiden flight.

2. 1996-06-04, about 30 seconds after liftoff

   Valid guidance and attitude information is lost.

3. 1996-06-04, shortly afterward

   Extreme nozzle commands contribute to breakup; the destruction system is triggered.

4. 1996-07-19

   The independent inquiry board dates its report.

5. 1996-07-23

   ESA publicly presents the findings and corrective actions.

A researched reconstruction for learning. These reasoning steps simplify a complex record; no score can capture the full history.

02 / The evidence

What does the record show?

Read each exhibit before settling on an explanation. The numbered source links below every exhibit lead to the record behind it.

03 / Your reasoning

Follow the strongest explanation.

Choose an interpretation, then compare it with the evidence. You can revise your choice. The goal is understanding, not a perfect score.

04 / The findings

The chain behind the outcome.

The inquiry identified specification and design errors in the inertial reference software, together with inadequate analysis and testing of the complete system. The conversion exception shut down the affected unit, and the backup had already encountered the same problem. Data associated with failure were then used in a way that contributed to extreme control commands. The important abstraction is a common-mode failure: two components can be separate boxes while sharing the same vulnerability. The recommended response included disabling unnecessary post-liftoff alignment processing, reconsidering exception handling and testing real trajectory conditions. This is not proof that every system needs different software implementations. Diversity has its own costs and errors. It is evidence that a safety argument must explain which failures redundancy actually covers—and which shared assumptions can take every redundant channel down together.

Take the method with you

• Redundant hardware is not automatically independent protection.
• Reused code carries reused assumptions.
• Test the new operating envelope, including out-of-range behavior.

You can read findings at any time. Exploring every reasoning step marks this case as complete in your notebook.