The Occasion[edit]

On June 4th, 1996, the European Area Company launched the Ariane 5 rocket, Flight 501 from Kourou, French Guiana[1]. The objective of the rocket was to launch business payloads into orbit, specifically, 4 Cluster satellites[2]. The satellites would have been positioned into excessive elliptical orbits to conduct analysis on Earth’s Magnetosphere[3], thus making Europe outstanding within the business house enterprise[4]. The European Area Company had spent 10 years and $7 billion to provide the rocket[4].

That day, all the trouble that the Company had expended into constructing the rocket went to waste, together with $370 million[3], when the launcher veered off its flight path, disintegrated and exploded solely about 40 seconds after flight sequence initiation at an altitude of three,700 meters, scattering fiery rubble throughout French Guiana[4][5]. Thankfully, no lives have been misplaced. Engineers from the Ariane 5 venture groups of CNES and Business instantly started investigating the failure, which a small laptop program attempting to stuff a 64-bit quantity right into a 16-bit house induced[4][5].

As a result of incorrect management indicators that have been despatched to the engines and swiveled the rocket 37 seconds after take off, the Inertial Reference System, which is used to calculate and information a rocket’s velocity, place, and orientation, failed[2]. The explosion of the rocket elevated the aluminum oxide content material within the floor and water, damaging the setting of the French Guianese swamps[1].

Technical Failure[edit]

An impartial inquiry board was arrange days after the incident, and one among its conclusions was attributable to specification and design errors within the Inertial Reference System (SRI), the launcher’s system misplaced steering and altitude data 37 seconds after the primary engine ignition sequence began. The Inquiry Board discovered that the next design faults within the SRI software program induced the Flight 501 failure: the upkeep after the lift-off of the pre-launch operate (alignment mode) was incompatible with flight[1]. Roughly 0.05 seconds after the pc throughout the back-up SRI, which was engaged on stand-by for steering and angle management, grew to become inoperative, the lively SRI, which was equivalent to the back-up system in {hardware} and software program, failed for equivalent causes. Because the back-up inertial system was already inoperative, appropriate steering and angle data may now not be obtained. As a result of the back-up SRI failed, the lively SRI transmitted diagnostic data to the launcher’s principal laptop, which interpreted it as flight knowledge and used it for flight management calculations. Primarily based on these calculations, the primary laptop commanded the booster nozzles and the primary engine nozzle to make a big correction for an altitude deviation that had not occurred. As a result of aerodynamic forces, the ensuing fast change of altitude induced the launcher to disintegrate at 39 seconds after the primary engine ignition sequence began. Destruction was robotically initiated upon disintegration, as designed[5].

The entire varied programme exams and critiques, which had in any other case proved efficient, had not revealed these anomalies, and the bottom/flight mode interface had been inadequately recognized[1]. A paper from the European Area Company, offered by the NASA Astrophysics Knowledge System, defined that the Inertial Measurement Unit program on Flight 501 failed attributable to a code fragment that the flight section didn’t use, so it was essential to exhaustively determine the useless code and unused however lively code, and reveal that the unused executable code may by no means end in a run time error[6].

Although intensive critiques and exams occurred through the Ariane 5 Growth Programme, they didn’t embody adequately analyzing and testing the SRI or the whole flight management system, which may have detected the potential failure[5]. The Company erroneously assumed that as a result of the SRI labored for Ariane 4, it will work for Ariane 5, which had a distinct technical specification[7].

The Standing Quo Bias[edit]

With greater than 100 profitable launches, the Ariane Four was one of the profitable rockets in ESA historical past[8]. It was in service for greater than 20 years and got here to be referred to as the “workhorse” of the ESA’s fleet of launch automobiles. The Ariane 5 venture workforce was tasked with designing a successor to the Ariane 4. The brand new rocket needed to outperform its predecessor in payload capability with out compromising reliability.

With the Ariane 4’s success in thoughts, engineers engaged on the Ariane 5 started borrowing main elements from the Ariane Four program, together with the Ariane 4’s software program bundle[5]. A lot of the Ariane 4’s software program was designed as a “black field,” which means it could possibly be reused in numerous launch automobiles with out main modifications. Ariane 5 engineers recycled the whole lot from steering management techniques to flight path optimization software program, as a result of the Ariane Four software program bundle had a 100% success charge[8].

The Ariane 4’s elements basically grew to become the established order. Given the choices of designing a brand new system and utilizing an Ariane Four element, engineers took the simpler, cheaper path. To revamp a system is to imagine duty for that system’s success. Engineers didn’t need to change what they thought already labored, and ended up borrowing greater than they need to have.

The software program which led to Flight 501’s failure was borrowed from the Ariane 4[5]. It was not as adaptable as Ariane 5 engineers thought, and didn’t operate because it was presupposed to. Engineers put an excessive amount of religion within the SRI. By attempting to keep away from extra threat, the Ariane 5 design workforce inadvertently decided which resulted in catastrophic failure of the rocket.

Diffusion of Accountability[edit]

The Ariane 5 Flight 501 explosion represents a diffusion of duty as a result of nobody individual or group was accountable for the catastrophe. A report issued by an impartial inquiry board arrange by the French and European Area Companies acknowledged that 5 separate teams engaged on the spacecraft may have prevented the explosion[9]. These teams have been:

  • Programmers: Higher programming apply would have prevented the software program error that resulted from a knowledge conversion of a 64-bit floating level to a 16-bit signed integer worth.
  • Designers: A greater design that disallowed software program exceptions from halting {hardware} items that have been functioning accurately would have prevented the SRI from shutting down.
  • Requirement Engineers: Higher requirement evaluation and trace-ability would have prevented the rogue piece of alignment code from earlier fashions of the Ariane from activating and ensuing within the spacecraft failure.
  • Take a look at Engineers: A check to confirm that the SRI would behave accurately when being subjected the to flight sequence and trajectory of the Ariane 5 would have uncovered the failure.
  • Undertaking Managers: Improved venture administration processes that facilitate nearer engineering cooperation with clear authority and duty in addition to constant code and documentation would have elevated the possibilities of exposing the failure[9].

Whereas many teams may have been blamed, the European investigators selected to not single out any explicit contractor or division. They mentioned that “a call was taken. It was not absolutely analyzed or absolutely understood. The attainable implications of permitting it to proceed to operate throughout flight weren’t realized[4].”

Normalization of Deviance[edit]

The error might have been caught in time if engineers had extra proactive testing procedures. Nevertheless, engineers took shortcuts throughout design testing in response to a collection of funds cuts throughout the board[5]. The ESA specifies very rigorous software program testing procedures designed to catch the kind of downside that introduced down Flight 501, however they weren’t adopted. Very like the Challenger catastrophe, dangerous habits slowly grew to become the norm.

When engineers have been testing the Ariane 5 software program bundle, price was a significant factor of their choices. Engineers had two choices:

  1. Run a full simulated launch with all software program examined concurrently[9].
  2. Run a number of impartial exams which check solely software program subsystems[9].

The workforce selected possibility two as a result of it was considerably cheaper than possibility one. As a result of the software program was examined independently, the fault which led to the failure of Flight 501 was not detected.

Value-cutting prompted using dangerous testing procedures in lots of features of the Ariane 5’s software program design. Evaluation by the Inquiry Board after the incident revealed that main elements of the software program bundle have been stuffed with bugs that had been neglected[5]. As a result of software program represents a singular level of failure the place redundant techniques are troublesome to implement, exercising due-diligence via testing is very vital. Ariane 5 software program engineers didn’t train this due-diligence.

The European Inquiry Board investigated the catastrophe and made suggestions on what may have been completed to stop it. Out of the 14 suggestions that the Inquiry Board produced, suggestions 12-14, specifically, consult with flaws or failures of the method. These three suggestions present how the flight failed and the right way to stop failure sooner or later.

  • Advice 12: “Give the justification paperwork the identical consideration as code. Enhance the approach for protecting code and its justifications constant[10].”
  • Advice 13: “Arrange a workforce that may put together the process for qualifying software program, suggest stringent guidelines for confirming such qualification, and confirm that specification, verification and testing of software program are of a constantly prime quality within the Ariane 5 programme. Together with exterior RAMS consultants is to be thought of[10].”
  • Advice 14: “A extra clear organisation of the cooperation among the many companions within the Ariane 5 programme should be thought of. Shut engineering cooperation, with clear minimize authority and duty, is required to attain system coherence, with easy and clear interfaces between companions[10].”

Wanting ahead, these three suggestions will assist promote a extra cohesive, clear, {and professional} working setting to mitigate future confusion.


Classes realized from the Ariane 5 Flight 501 catastrophe might be generalized to different circumstances. First, even the smallest particulars matter and may have huge penalties. The conversion error of a 64 bit floating level quantity induced the explosion of an enormous, multi-million greenback spacecraft. In lots of techniques, small particulars are simply as vital as giant ones.

Second, in addition to testing for what a system ought to do, one must also check for what a system shouldn’t do. If the system had examined for the failure of the floating level quantity conversion, then the error that induced the explosion may have been caught. Testing for conditions that ought to not happen can enhance reliability[11].

Third, authority and tasks needs to be apparent. Nobody was held accountable for the error that resulted in Flight 501’s explosion. It’s more durable to search out an issue and to keep away from future issues when nobody is held accountable for a failure. When tasks amongst teammates are clear-cut, issues are simpler to search out, and communication and cooperation enhance.

Fourth, don’t design a system the place a single element failure may trigger the complete system to fail – single level of failure. For Flight 501, a software program error not solely resulted within the failure of the SRI, a software program system, but in addition it resulted within the explosion of the complete spacecraft. A system the place one failure would not break the complete system is extra dependable and safer.


  1. abcd de Dalmau, J. & Gigou, J. (1997). Ariane-5: Studying from Flight 501 and Getting ready for 502. European Area Company.
  2. ab Sommerville, I. (2014). Ariane 5 launcher failure. Slideshare. http://www.slideshare.web/software-engineering-book/ariane5failure-pres
  3. ab Cluster (spacecraft). (2015). In Wikipedia.
  4. abcde Gleick, J. (1996). Little Bug, Huge Bang. The New York Occasions.
  5. abcdefgh Lions, J.L. (1996). ARIANE 5 Failure-Full Report. European Area Company.
  6. Lacan, P., Monfort, J. N., Ribal, L. V. Q., Deutsch, A., & Gonthier, G. (1998). ARIANE 5 – The Software program Reliability Verification Course of. European Area Company.
  7. Georgiadou, E. and George, C. (2006). Info Programs Failures: Can we make professionals extra accountable?. Software program High quality Administration XIV.
  8. ab Ariane 4.
  9. abcd Nuseibeh, B. (1997). Ariane 5: Who Dunnit? IEEE Xplore.
  10. abc The Inquiry Board’s Suggestions.
  11. Sommerville, I. (2014). Ariane Launch failure. YouTube.

Leave a Reply

Your email address will not be published. Required fields are marked *