How a Simple Data‑Type Conversion Bug Sank the Ariane 5 Rocket

Background

On 4 June 1996 the European Space Agency launched the Ariane 5 launch vehicle. About 30 seconds after liftoff, at an altitude of roughly 3 700 m, the rocket deviated from its planned trajectory and disintegrated, causing a loss of nearly €500 million.

Software defect in the guidance system

The guidance computer continuously measured the vehicle’s velocity and transmitted the value to the main flight computer. The original Ariane 4 software was reused without modification and contained a conversion routine that cast the measured speed from a 64‑bit floating‑point number ( double) to a 16‑bit signed integer ( INTEGER*2 in Ada).

Because the numeric ranges differ dramatically, the conversion could overflow when the velocity exceeded the limits of a 16‑bit signed integer.

16‑bit signed integer range: –32 768 to +32 767

64‑bit floating‑point range: far exceeds the 16‑bit limits (e.g., values up to 9.22 × 10¹⁸ for signed integers)

During the Ariane 5 ascent the velocity quickly rose above 30 000 m/s (the exact value depends on the flight profile). When the conversion was performed, the 64‑bit value was truncated to the lower 16 bits, producing a wrapped‑around negative number (e.g., 40 000 → ‑25 536). The guidance software did not check for overflow or raise an exception, so the erroneous speed was forwarded to the main computer.

The main computer used the corrupted velocity to compute thrust‑vector and attitude‑control commands. The resulting commands were physically impossible, causing the vehicle to lose attitude control and ultimately explode.

Technical lessons

Code reuse must be validated: Legacy code should be reviewed, unit‑tested, and verified for compatibility with new hardware and software environments.

Explicit range checking: Conversions between floating‑point and integer types must include bounds checks or saturating arithmetic to prevent overflow.

Robust exception handling: Systems should detect and handle conversion errors gracefully, e.g., by falling back to a safe default or aborting the operation.

Comprehensive testing: Include unit tests for edge‑case values, integration tests that simulate full flight profiles, and stress tests that push data ranges beyond nominal limits.

Static analysis and code review: Automated tools and peer reviews help uncover hidden assumptions such as implicit type casts.

Clear documentation: Document the intended data ranges, conversion logic, and failure modes to avoid misuse by future developers.

Redundancy and fault tolerance: Design backup pathways for critical sensor data so that a single conversion error cannot disable the entire guidance chain.