The recovered units make this a post-mortem, not a reconstruction
Most retellings of Ariane 5 Flight 501 stop at the arithmetic: a 64-bit floating-point value was converted to a 16-bit signed integer, the value did not fit, and the launcher was lost. That summary is accurate as far as it goes, and it is also the least useful version of the story for anyone who designs embedded systems.
The Inquiry Board’s report is unusually specific about what happened, because the evidence was unusually good. Both Inertial Reference Systems (SRIs) were recovered from the debris field. The Board read out their memory, reproduced the internal events by simulation, and examined the software code, which it found consistent with the failure scenario. The report states the chain is established beyond reasonable doubt. This is a documented post-mortem with hardware in hand, not an inference from telemetry alone.
What the Board describes is a chain of three separable decisions. The overflow is the first link. The exception-handling policy is the second. The reuse of Ariane 4 alignment behavior is the third. Each link was individually defensible inside its own context. Only the chain was fatal, and the chain is what a bench test can actually exercise.
The chain, in the Board’s order
The sequence the Board establishes runs from the destruction backward. The launcher began to disintegrate at about H0 + 39 seconds under aerodynamic loads from an angle of attack greater than 20 degrees, which separated the boosters and triggered self-destruction. The nozzle deflections that produced that angle were commanded by the On-Board Computer (OBC) using data from the active SRI. Part of that data was not flight data at all but a diagnostic bit pattern from the SRI computer, which the OBC interpreted as attitude information.
The active SRI had stopped sending correct data because it had declared a failure due to a software exception. The OBC could not switch to the backup because the backup had already ceased functioning during the previous data cycle, a 72-millisecond period, for the same reason.
The exception itself came from a data conversion. The Board’s wording is precise: the internal SRI software exception was caused during execution of a data conversion from 64-bit floating point to 16-bit signed integer value, and the floating-point number being converted had a value greater than what a 16-bit signed integer could represent. That produced an Operand Error. The conversion instructions, written in Ada, were not protected against causing an Operand Error, although other conversions of comparable variables in the same place in the code were protected.
The variable in question was an internal alignment result called BH, Horizontal Bias, related to the horizontal velocity sensed by the platform and calculated as an indicator of alignment precision over time. BH was much higher than expected because the early trajectory of Ariane 5 differs from that of Ariane 4 and produces considerably higher horizontal velocity values. The Board does not publish the numeric value of BH in the retrieved report text, and this article does not supply one.
Why a pre-liftoff function was running at H0 + 36 seconds
The conversion that failed sat in software that only performs alignment of the strap-down inertial platform. That module computes meaningful results only before lift-off. After lift-off it serves no purpose.
It was still running because of a timing requirement inherited from the previous vehicle. The alignment function is operative for 50 seconds after the SRI enters Flight Mode, which occurs at H0 minus 3 seconds on Ariane 5. When lift-off occurs, the function therefore continues for approximately 40 seconds of flight. The Board states plainly that this time sequence is based on an Ariane 4 requirement and is not required for Ariane 5.
This is the reuse link, and it is the one most often skipped in summaries. The code was not wrong for Ariane 4. The 50-second window was not wrong for Ariane 4. The assumption embedded in both — that the alignment function’s inputs stay within a bounded range during the window it remains active — was an Ariane 4 assumption. Carrying the module forward carried the assumption forward without a corresponding check against the new vehicle’s early trajectory.
The exception handler is the link that lost the vehicle
The Board is explicit that the overflow alone did not fail the mission. The specification of the exception-handling mechanism contributed to the failure. On any kind of exception, the system specification required three things: indicate the failure on the databus, store the failure context in EEPROM, and shut down the SRI processor. The EEPROM was recovered and read out. The Board identifies the decision to cease processor operation as what finally proved fatal.
The rationale behind that policy is documented and, in its own terms, coherent. The Board describes a culture within the Ariane programme of addressing random hardware failures. From that viewpoint, an exception-handling mechanism is designed for a random hardware failure, which a backup unit can reasonably cover. A systematic software fault is a different failure class, and the policy did not distinguish between them.
Restart was not a recovery path. The Board notes that attitude is too difficult to recalculate after a processor shutdown, so the unit becomes useless. The Board also observes that the computers within the SRIs could have continued to provide their best estimates of the required attitude information, and that there is reason for concern when a software exception is allowed, or even required, to halt a processor handling mission-critical equipment.
Two identical units are a common-cause path, not a backup
The Ariane 5 flight control system carried two SRIs with identical hardware and software, one active and one in hot standby. If the OBC detected that the active unit had failed, it would switch immediately, provided the other unit was functioning properly. On Flight 501 the other unit was not functioning properly, because it had hit the same exception one 72-millisecond cycle earlier.
The Board’s language on this point is worth keeping intact: the loss of a proper software function is hazardous because the same software runs in both SRI units, and in this case it resulted in the switch-off of two still healthy critical units of equipment. The units were healthy in the hardware sense. They were not independent in the failure-mode sense.
This is the redundancy lesson in its least glamorous form. Counting units overstates reliability when the units share a systematic fault path. A hot standby protects against random hardware failure. It offers nothing against a deterministic software exception triggered by the same input on both units within the same cycle.
The 80% workload target and the four-of-seven decision
The Board records why not all conversions were protected. A maximum workload target of 80% had been set for the SRI computer. To bound the exposure of unprotected code, an analysis was performed on every operation that could raise an exception, including Operand Error. The conversion of floating-point values to integers was analyzed, and operations involving seven variables were found at risk. Protection was added to four of them, visible in the Ada code. Three were left unprotected.
The reasoning for the three, as reported to the Board, was that they were either physically limited or had a large margin of safety. For BH, that reasoning turned out to be faulty. The Board found no reference in the source code directly justifying the decision, and observed that the assumption, while agreed, was essentially obscured from external review by the volume of documentation around any industrial application.
Two further findings matter for anyone who audits reuse. The decision to protect some variables and not others was taken jointly by project partners at several contractual levels. And there is no evidence that trajectory data were used to analyze the behavior of the unprotected variables; it was jointly agreed not to include Ariane 5 trajectory data in the SRI requirements and specification.
The interpretation I would draw, and it is an interpretation rather than a Board finding: a resource budget became a safety argument. The 80% workload target is a constraint to negotiate. It is not evidence that a hazard is bounded. When a protection is removed to meet a budget, the justification for removal needs to be as traceable as the protection itself, and it needs to be re-derived whenever the operating envelope changes.
What the testing did not cover
The ESA presentation of the Board’s report states the conclusion directly: the loss of guidance and attitude information was due to specification and design errors in the SRI software, and the extensive reviews and tests carried out during the Ariane 5 development programme did not include adequate analysis and testing of the SRI or of the complete flight control system, which could have detected the potential failure.
The same release stresses that the alignment function, which served a purpose only before lift-off but remained operative afterward, was not taken into account in the simulations, and that the equipment and system tests were not sufficiently representative. The Board’s corrective list follows from that gap: switch off or inhibit the alignment function after lift-off, modify fault processing so the processor does not shut down, and test to check coverage of the SRI flight domain. At system level it calls for representativeness improvements, systematic use of real equipment where possible, and simulation of real trajectories on SRI electronics.
Note what the corrective list targets. It does not begin with “use a wider integer.” It begins with removing the post-lift-off function, changing the exception policy, and proving the flight domain is covered. The arithmetic fix is necessary and insufficient.
Bench-verifiable design rules
These are recommendations, not findings of the Board. Each one maps to a link in the documented chain and can be checked on a bench without flight hardware.
1. Fault-inject the exception handler, not just the arithmetic. For every conversion from floating point to a narrower integer type, drive the input to the representable boundary and past it, then observe what the handler does. The pass criterion is graceful degradation with a defined output, not a logged fault followed by a processor halt. On Flight 501 the handler was specified to shut down the processor, and that specification, not the overflow, is what removed guidance.
2. Treat every protection exemption as a claim requiring evidence. If a conversion is left unprotected because the variable is “physically limited” or has “large margin,” record the bound, the source of the bound, and the operating envelope it assumes. Re-derive it when the envelope changes. The Board found no evidence that trajectory data were used to analyze the unprotected variables, and BH’s margin was the one that failed.
3. Audit reuse at the level of the assumption, not the module. For each inherited module, enumerate every constant, time window, and range check that came from the donor vehicle, and re-derive each against the host vehicle’s actual trajectory and timing. The 50-second alignment window was an Ariane 4 requirement. On Ariane 5 it kept a pre-liftoff function running for roughly 40 seconds of flight.
4. Count independent failure modes, not units. Identical hardware and software in a hot standby pair is a common-cause path for any systematic fault. If the redundancy credit appears in a reliability calculation, the calculation needs a diversity argument or an explicit derating for common-cause failure. Two SRIs failed within one 72-millisecond cycle for the same reason.
5. Make the resource budget a visible constraint, not a silent safety argument. When a workload or timing target drives a decision to remove a check, that decision belongs in the hazard analysis with a named owner and a review path, not only in the code review record. The Board’s account of the four-of-seven decision is a case study in how a defensible local tradeoff becomes invisible to external review.
6. Test the flight domain, not the nominal trajectory. The Board’s corrective measures call for testing that checks coverage of the SRI flight domain and for simulating real trajectories on SRI electronics. A bench harness that replays the host vehicle’s early trajectory through the reused module, including the segment after the function should have been irrelevant, would have exercised the exact input that overflowed.
FAQ
Was the failure caused by a single 16-bit overflow?
The overflow was the trigger. The Board states that although the source of the Operand Error was identified, this in itself did not cause the mission to fail. The specification of the exception-handling mechanism, which shut down the processor, contributed to the failure, and the Board identifies that shutdown as what finally proved fatal.
Why did both inertial reference units fail?
They ran identical hardware and software. The backup ceased functioning during the previous 72-millisecond data cycle for the same reason as the active unit, so the OBC had nothing to switch to.
Why was alignment software running after lift-off?
The function remained operative for 50 seconds after the SRI entered Flight Mode, which occurs at H0 minus 3 seconds. That timing was an Ariane 4 requirement and was not required for Ariane 5, so the function continued for approximately 40 seconds of flight.
Did the Board assign fault to an individual or contractor?
No. The report describes the decision to protect some variables and not others as taken jointly by project partners at several contractual levels, and it frames the failure in terms of specification, design, testing, and organizational factors.
What evidence supports the chain?
Both SRIs were recovered. The failure context was determined from memory readouts, the internal events were reproduced by simulation, and the software code was examined and found consistent with the failure scenario. The Board states the chain is established beyond reasonable doubt.
What would settle the remaining uncertainty?
The Board references a restricted-circulation Technical Report with greater technical detail. That document would carry the precise BH value and the memory readout specifics. The public report supports the qualitative chain without publishing the numeric magnitude, and this article does not estimate it.
Primary sources: the Inquiry Board report as archived at the University of Minnesota, and ESA’s presentation of the Board’s report. Both are cited inline above.
