A

PROJECT REPORT
ON :

Ariane 5 Rocket Explosion

For the Degree of Third year of Computer
Engineering
By
Pranay Suryavanshi (2023016400733446)
Prathamesh Jadhav (2022016402277976)
Chirag Sawant (2021016402108343)
Tanish Talekar (2021016402108304)
Armaan Nakhuda (2022016402277961)
Radha Saple (2022016402279503)

Guide by: Prof. Sheena Bhaskar

Assistant Professor

2025-26
 CERTIFICATE

This is to certify that the project entitled “Arian 5 Rocket Explosion” is a Bonafide work of “of
Pranay Suryavanshi(B-28); Prathamesh Jadhav(B- 43 ); Chirag Sawant (B-55); Tanish
Talekar(B-56); Armaan Nakhuda(B-57); Radha Sapale (B-58)” submitted to the University
of Mumbai in partial fulfilment of the requirement for the award of the degree of “Bachelor of
Engineering” in “Computer Engineering”

Prof. Sheena Bhaskar

Guide
[Link]
The Ariane 5 rocket explosion on its maiden flight in 1996 was caused by a software error
rooted in the reuse of Ariane 4’s software without proper adaptation to Ariane 5’s distinct flight
conditions. A 64-bit floating-point number representing horizontal velocity was converted to a
16-bit integer, causing an overflow exception. This failure shut down both primary and backup
inertial reference modules, which then sent incorrect data to the flight computer. The computer,
misreading this data, issued erratic commands that led to the rocket veering off course and self-
destructing 37 seconds after liftoff. Beyond the software bug, this disaster revealed significant
system engineering faults, including incomplete requirements capture, inadequate design for
Ariane 5’s higher velocities, and insufficient testing using realistic flight data. The event
underscores the critical need for rigorous system engineering practices, formal requirement
specifications, thorough validation, and verification processes in mission-critical aerospace
software, emphasizing that safety depends not only on coding but on holistic system-level
engineering and organizational oversight.
The Ariane 5 Flight 501 failure remains one of the most significant and extensively studied
engineering disasters in aerospace history. On its maiden flight in June 1996, the rocket self-
destructed just 37 seconds after liftoff due to a malfunction in its Inertial Reference System
(IRS), resulting in the loss of a substantial scientific payload and financial damage. This
catastrophe has been widely analyzed to understand the underlying causes, revealing a complex
interplay of software reuse issues, system engineering shortcomings, process failures, and
inadequate risk management.
A critical consensus, is that the immediate cause was a software error: an unhandled integer
overflow caused by converting a 64-bit floating-point number representing horizontal velocity
into a 16-bit integer, which exceeded the allowable range inherited from the Ariane 4’s software
system. However, analyses such as those by Gérard Le Lann (1996, 1997) and others reveal
that this was ultimately a symptom of deeper systemic issues rooted in poor system engineering
practices—such as incomplete and ambiguous requirements capture for Ariane 5’s different
flight profile, and faulty system design and dimensioning that failed to account for operational
differences from the prior Ariane 4.
Other studies emphasize the organizational and process-related dimensions. Mark Dowson
(1997) and Bashar Nuseibeh (1997) argue that the failure reflects a breakdown in continuous
risk management and inadequate adaptation of reused software components, which were not
rigorously validated against the new specifications and flight conditions responsible for the
failure. The reuse of legacy software without sufficient testing using Ariane 5–representative
data allowed a critical assumption (disabling an exception handler to save computing
resources) to become deadly when new mission parameters invalidated it.
Formal modeling and validation efforts, like those described by Ober et al. (2006), showcase
the importance of rigorous, model-driven engineering approaches with formal verification to
manage the complexities of real-time aerospace software architectures and ensure compliance
with timing and safety requirements. Meanwhile, research on hardware safety (Kamoulakos et
al., 1997) highlights peripheral risks associated with the launch system, such as explosion
hazards from post-mission pressurized tanks, emphasizing the broad spectrum of safety
concerns in such missions.
In summary the Ariane 5 failure is not merely a tale of a software bug but a profound lesson in
system engineering discipline, thorough requirement specification, robust software
development practices, continuous risk assessment, and integrated validation and verification.
These lessons have propelled advances in aerospace engineering and software reliability
practices, underscoring the need for holistic approaches in mission-critical system design.
[Link] Survey
1. The Ariane 5 Flight 501 failure is widely regarded as a classic example of how
inadequate system engineering can lead to catastrophic outcomes in aerospace projects.
Only 37 seconds after liftoff, the rocket self-destructed due to a malfunction in its
Inertial Reference System, caused by the reuse of Ariane 4 software without proper
adaptation to Ariane 5’s different flight dynamics. A 64-bit floating-point value for
horizontal velocity overflowed when converted to a 16-bit integer, shutting down both
primary and backup systems and sending faulty data to the flight computer. Beyond the
coding flaw, the incident reflected deeper issues in requirements capture, redundancy
design, realistic testing, and exception handling. It underscored that in complex,
mission-critical systems, safety depends as much on rigorous, proof-based system
engineering and validation as on robust software implementation,
2. The Ariane 5 software failure occurred 37 seconds into its maiden flight in 1996, when
the rocket exploded due to an unhandled exception in its Inertial Reference System. A
64-bit floating-point horizontal velocity value overflowed during conversion to a 16-bit
integer because Ariane 5’s higher speeds exceeded limits expected from Ariane 4’s
reused software. The incident, caused by inadequate input validation, lack of robust
exception handling, and insufficient testing with mission-specific data, was
preventable. It highlights the need for rigorous requirements analysis, careful code
reuse, thorough validation, and formal verification in safety-critical aerospace systems.
3. The Ariane 5 Flight 501 failure was caused by fundamental system engineering flaws
rather than just software mistakes. On its maiden launch in 1996, the rocket exploded
39 seconds after liftoff when reused Ariane 4 software, unsuited to Ariane 5’s higher
velocities, triggered an unhandled overflow converting a 64-bit value to a 16-bit integer.
Both inertial systems failed, sending faulty data to the flight computer. The disaster was
rooted in poor requirements capture, flawed system design, inadequate testing with
realistic conditions, and missing exception handling. It underscores the need for
rigorous, proof-based system engineering to ensure safety in mission-critical aerospace
systems.
4. The Ariane 5’s maiden launch in 1996 ended in disaster 37 seconds after liftoff due to
a software fault from reused Ariane 4 code that was not adapted to Ariane 5’s higher
velocities. An unnecessary calibration routine caused a 64-bit to 16-bit conversion
overflow, triggering an exception that halted both inertial navigation units. Erroneous
data sent to the flight computer led to incorrect steering commands and self-destruction.
Contributing factors included inadequate requirements validation, absence of robust
exception handling, lack of realistic testing, and flawed redundancy design. The case
underscores the need for disciplined development, thorough validation, and safe error
handling in safety-critical systems.
5. The paper “Ariane 5: Who Dunnit” analyzes the maiden flight failure of Ariane 5,
caused by an unhandled overflow when converting a 64-bit floating-point value to a
16-bit integer in the inertial reference system’s reused Ariane 4 software. Hardware and
flight profile changes were not fully addressed in verification, allowing the flaw to
surface seconds after liftoff. Drawing on failure reports and specifications, the study
links development missteps, legacy code reuse, inadequate testing, and organizational
shortcomings to the disaster. It emphasizes rigorous requirements analysis, realistic
simulations, cross-disciplinary reviews, and a safety-focused culture as essential
reforms for future aerospace software projects.
6. This paper presents the modeling and validation of Ariane-5’s flight software
architecture to satisfy both functional and stringent real-time requirements. Using UML
with the Omega profile, the system’s periodic control tasks and aperiodic mission
management are formally represented. Fixed-priority preemptive scheduling replaces
traditional methods to better handle asynchronous events and load variations. Mission
management, thrust monitoring, control, and guidance are modeled as active UML
classes, with observer state machines used to formalize requirements. Validation with
the IFx toolset verifies schedulability, mutual exclusion, and timing compliance, even
under overload. The results show model-driven engineering and formal verification
ensure reliability in mission-critical aerospace systems.
7. The Ariane 5 Flight 501 failure occurred 37 seconds after launch due to a software
error in its Inertial Reference System (IRS), caused by reusing Ariane 4 code without
adapting it to Ariane 5’s faster flight dynamics. An unprotected 64-bit to 16-bit
conversion overflow shut down both primary and backup IRS units, which then sent
invalid data to the flight computer, leading to incorrect nozzle commands and self-
destruction. The official inquiry cited inadequate testing with realistic data, failure to
disable obsolete pre-launch functions, and poor exception handling. The case
underscores the need for rigorous requirements analysis, thorough validation, and
cautious software reuse.
[Link] and reason
3.1 Immediate Technical Failure
1. Software Exception and Data Handling:
The immediate, technical trigger was an unhandled exception within the IRS: a 64-bit
floating-point value (horizontal velocity) exceeded the valid range for conversion into a
16-bit signed integer. This operation, while safe in Ariane 4’s profile, was not suitable for
Ariane 5’s faster trajectory. Both IRS modules (primary and redundant)—using identical
software—crashed due to the overflow. The modules switched to diagnostic mode and
broadcasted error data on the standard bus, which the flight computer misinterpreted as
valid positional input. Extreme, un-commanded nozzle deflections ensued, causing the
launcher to break up, after which the automated destruct sequence triggered.

3.2 Software Reuse Without Adaptation

1. Legacy Code Reuse:
The IRS software was carried over from Ariane 4 to Ariane 5 to save time and leverage
proven reliability, with inadequate revalidation. The higher velocities and different flight
dynamics of Ariane 5 resulted in input values outside the design envelope of the legacy
code, exposing vulnerabilities.

2. Obsolete Functions and Disabled Exception Handling:

Certain alignment functions needed only before launch were left running into flight,
contrary to updated operational needs. Additionally, exception handlers were deliberately
disabled to save processor resources, based on now-invalid assumptions that dangerous
values could never occur.

3.3 System Engineering and Requirements Capture Failures

1. Incomplete, Ambiguous Requirements:
The Ariane 5 specifications failed to comprehensively capture the rocket’s new operational
context, leading to dangerous assumptions about input value ranges, hardware-software
interactions, and the exigencies of mission phases.

2. Undocumented Assumptions:
Critical design premises were untracked, and evolving mission needs were not reflected in
the final software or requirements documents. The error-handling configuration intended
for Ariane 4 remained unchanged, despite requirements drift for Ariane 5.
3.4 Validation, Verification, and Testing Shortcomings
1. Lack of Realistic Simulations:
Software and integrated system tests did not employ Ariane 5-specific trajectory and data.
Testing therefore failed to trigger the value overflow conditions, and the potentially
catastrophic scenario did not appear during pre-flight validation.

2. Absence of Model-Based or Formal Verification:

Tools and methodologies— such as formal model checking, boundary value analysis, and
static code analysis—were inadequately used. The opportunity for model-driven system
validation went unrealized, despite the project’s scale and available resources.

3.5 System and Organizational Oversight

1. Separation of Responsibilities:
The boundaries between system engineering (who defines requirements and integration)
and software engineering (who codes and tests) were unclear. Key system-level
considerations, like mission-specific input ranges and redundancy needs, were not
conveyed or enforced within the software domain.

2. Redundancy Not Diversified:

Both IRS units operated the same software, exposing both to common-mode software
failures; the concept of redundancy was thus rendered ineffective.

3. Process Governance Weaknesses:

Political, financial, and scheduling pressures dominated project planning, suppressing
iterative review, risk assessment, and systems thinking. Team divisions and siloed work
discouraged holistic risk reconsideration as new mission parameters emerged.

3.6 Peripheral Safety and Hardware Concerns

1. ACS Passivation Risks:
Further post-flight investigation revealed that high-pressure tanks in the Attitude Control
System (ACS), if struck by debris after a failed mission, could explode—demonstrating
that risks transcended software and extended into rocket hardware.
4. Recommendations
4.1 System Engineering and Requirements Management
Rigorous, Formal Proof-Based Engineering:

- Employ proof-based system engineering: document, verify, and formally validate

requirements, architectural design, and system dimensioning ahead of code
implementation.
- Maintain clear and updated requirements documents. Establish unambiguous ownership
of requirements capture, integration, and verification processes.

4.2 Robust Software Developments and Testing

Stringent Software Revalidation:
- All reused code—whether algorithmic routines, communication protocols, or exception
handlers—must be re-examined and tested in the context of new mission data and
performance thresholds.
- Employ defensive programming: handle all exceptions, even those deemed “impossible.”
Safe fallback behavior must be prioritized over marginal gains in efficiency.
- Include mission-specific, worst-case, and edge-case data in all levels of simulation and
validation.

4.3 Diversifying Redundancy and Fault Tolerance

1. Redundant Systems Diversity:
Eschew identical redundancy for safety-critical systems. Redundant sensors or control
systems should differ in design or implementation to avoid single-point, common-mode
failures.

2. Robust Fault Management Strategies:

Develop real-time diagnostics with clear downstream handling: errant data must be
unmistakably flagged and quarantined, never interpreted as valid in worst-case scenarios.
4.4 Continuous Process and Risk Management
1. Iterative Risk Assessment:
Risk analysis should be an ongoing, integrated process—not a single project-phase
milestone. As system requirements, architecture, or operational context evolve, so too must
the risk model and contingency planning.

2. Active Review and Documentation:

All significant engineering decisions, like disabling exception handlers, must be recorded,
justified, and periodically re-assessed in collaborative, cross-disciplinary forums.

4.5 Organizational and Cultural Excellence

- Foster Cross-Disciplinary Collaboration:
- Bridge silos and clarify roles between system, software, and hardware engineering teams.
- Embed organizational learning processes: encode lessons from Ariane 5 and similar
failures into project launch checklists, ongoing education, and formal design milestones.

4.6 Hardware and Environmental Safety

- Post-Flight Passivation :
- Limit ACS tank pressures to verified safe thresholds on mission completion, using
combined fracture mechanics, experimental verification, and robust simulation.
- Thorough Hardware-Software Interface Testing:
- Treat interface testing as a critical discipline, verifying all data boundary conditions and
response to extreme or “off-nominal” values.
5. Conclusion
The Ariane 5 launch failure stands as a multifaceted lesson in how technical, organizational,
and procedural weaknesses can converge, dooming even the most ambitious engineering
projects. What outwardly appeared to be a software bug was in truth the product of
incomplete and ambiguous requirements, deficient verification routines, insufficient
adaptation of legacy systems, and a culture that prioritized expediency over thorough,
collaborative risk management. Future high-reliability engineering projects—whether in
aerospace, medical systems, or critical infrastructure—must heed the following lessons:
robust, iterative, and proof-driven system engineering; formal, scenario-grounded
requirements and validation; diversified redundancy and error handling; continuous active
risk management; and a culture of learning that institutionalizes insights from past failures.
The Ariane 5 disaster galvanized the aerospace sector to reform industry standards, adopt
advanced validation methodologies, and emphasize the integration of software, hardware,
and organizational best practices as inseparable dimensions of reliability and safety. The
enduring legacy of Ariane 5 is the recognition that mission success depends on the vigilant,
disciplined engineering of the whole life cycle—where every requirement, decision, and
contingency is scrutinized through the lens of reliability, safety, and holistic system
integrity.
[Link]
Ben-Ari, M. (n.d.). The bug that destroyed a rocket. Department of Science Teaching,
[Link]
[Link]

Dowson, M. (1997, March). The ARIANE 5 software failure. ACM SIGSOFT Software
Engineering Notes, 22(2). [Link]

Kamoulakos, A., Schneider, E., Lambert, M., Greff, P., & Bonnal, C. (1997). ARIANE 5
attitude control system passivation: Theoretical and experimental determination of the
explosion threshold pressure. International Journal of Impact Engineering, 20. Retrieved from
[Link]

Le Lann, G. (1996, December). The Ariane 5 Flight 501 failure — A case study in system
engineering for computing systems (Research Report No. 3079). Institut National de
Recherche-en-Informatique-et-en-Automatique-(INRIA).Retrievedfrom
[Link]

Le Lann, G. (1997, January). An analysis of the Ariane 5 flight 501 failure: A system
engineering perspective. In Proceedings of the 1997 Workshop on Engineering of Computer-
Based-Systems-(ECBS'97).Retrievedfrom
[Link]
01_failure-a_system_engineering_perspective

Nuseibeh, B. (1997, June). Ariane 5: Who dunnit? IEEE Software. Retrieved from
[Link]

Ober, I., Graf, S., & Lesens, D. (2006). Modeling and validation of a software architecture for
the Ariane-5 launcher. In Proceedings of the 8th IFIP WG 6.1 International Conference on
Formal Methods for Open Object-Based Distributed Systems (FMOODS 2006). Retrieved
from [Link]