Ariane flight V88

File:Ariane 501 Cluster.svg

File:Ariane 501 Fallout Zone.svg

File:Ariane 501 Fragment.jpg

The Ariane 5 reused the code from the inertial reference platform from the Ariane 4, but the early part of the Ariane 5's flight path differed from the Ariane 4 in having higher horizontal velocity values. This caused an internal value BH (Horizontal Bias) calculated in the alignment function to be unexpectedly high. The alignment function was operative for approximately 40 seconds of flight, which was based on a requirement of Ariane 4, but served no purpose after lift-off on the Ariane 5. The greater values of BH caused a data conversion from a 64-bit floating point number to a 16-bit signed integer value to overflow and cause a hardware exception.{{cite journal | title = Ariane 5: Who Dunnit?| first = Bashar | last = Nuseibeh |date=May 1997 | volume = 14 | issue = 3 | journal = IEEE Software| pages = 15–16 | url = http://www.inf.ed.ac.uk/teaching/courses/seoc/2008_2009/resources/ariane5.pdf | doi = 10.1109/MS.1997.589224 | s2cid = 206482665}} The programmers had protected only four out of seven critical variables against overflow to keep within a required maximum workload target of 80% for the on-board Inertial Reference System computer, and relied on assumptions which were correct for the trajectory of Ariane 4, but not Ariane 5, regarding the possible range of values for the three unprotected variables.{{cite journal |last1=Jézéquel |first1=Jean-Marc |last2=Meyer |first2=Bertrand |date=January 1997 |title=Put it in the contract: The lessons of Ariane |url=http://www.irisa.fr/pampa/EPEE/Ariane5.html |url-status=live |journal=Computer |volume=30 |issue=2 |pages=129–130 |doi=10.1109/2.562936 |archive-url=https://web.archive.org/web/20160604043553/http://www.irisa.fr/pampa/EPEE/Ariane5.html |archive-date=4 June 2016 |via=Irisa}} The exception halted both of the inertial reference system modules, although they were intended to be redundant. The active module presented a diagnostic bit pattern to the On-Board Computer which was interpreted as flight data, in particular causing full nozzle deflections of the solid boosters and the Vulcain main engine. This led to an angle of attack of more than 20 degrees, causing separation of the boosters from the main stage, the triggering of the self-destruct system of the launcher, and the destruction of the flight.

The official report on the crash (conducted by an inquiry board headed by Jacques-Louis Lions) noted that "An underlying theme in the development of Ariane 5 is the bias towards the mitigation of random failure. The supplier of the inertial navigation system (SRI) was only following the specification given to it, which stipulated that in the event of any detected exception the processor was to be stopped. The exception which occurred was not due to random failure but a design error. The exception was detected, but inappropriately handled because the view had been taken that software should be considered correct until it is shown to be at fault. [...] Although the failure was due to a systematic software design error, mechanisms can be introduced to mitigate this type of problem. For example the computers within the SRIs could have continued to provide their best estimates of the required attitude information. There is reason for concern that a software exception should be allowed, or even required, to cause a processor to halt while handling mission-critical equipment. Indeed, the loss of a proper software function is hazardous because the same software runs in both SRI units. In the case of Ariane 501, this resulted in the switch-off of two still healthy critical units of equipment."{{Cite report |url=https://www-users.cse.umn.edu/~arnold/disasters/ariane5rep.html |title=ARIANE 5 Failure - Full Report |author=Lions |first=J. L. |date=19 July 1996 |publisher=Inquiry Board set up by ESA and CNES |archive-url=https://web.archive.org/web/20140426233419/http://www.ima.umn.edu/~arnold/disasters/ariane5rep.html |archive-date=2014-04-26 |url-status=live}}

Other issues identified in the report focused on testing:

• The purpose of the review process, which involves all major partners in the Ariane 5 programme, is to validate design decisions and to obtain flight qualification. In this process, the limitations of the alignment software were not fully analysed and the possible implications of allowing it to continue to function during flight were not realised.
• The specification of the inertial reference system and the tests performed at equipment level did not specifically include the Ariane 5 trajectory data. Consequently, the realignment function was not tested under simulated Ariane 5 flight conditions, and the design error was not discovered.
• It would have been technically feasible to include almost the entire inertial reference system in the overall system simulations which were performed. For a number of reasons it was decided to use the simulated output of the inertial reference system, not the real system or its detailed simulation. Had the system been included, the failure could have been detected. Post-flight simulations have been carried out on a computer with software of the inertial reference system and with a simulated environment, including the actual trajectory data from the Ariane 501 flight. These simulations have faithfully reproduced the chain of events leading to the failure of the inertial reference systems.

Another perspective of the failure, based on systems engineering, focuses on requirements:{{cite conference | title = An Analysis of the Ariane 5 Flight 501 Failure – A System Engineering Perspective | first = Gérard | last = Le Lann | book-title = Proceedings of the 1997 international conference on Engineering of computer-based systems (ECBS'97) |publisher=IEEE Computer Society |date=March 1997| pages = 339–346 |isbn=0-8186-7889-5|doi=10.1109/ECBS.1997.581900}}

• The ranges of variables such as horizontal velocity and the quantity BH computed from it should have been explicitly quantified. Instead, a 16-bit range was assumed.
• The alignment task should have been deactivated at an appropriate moment. Instead, the alignment task was running after lift-off.
• A failure model of the inertial reference platforms should have been analyzed to ensure that service would be continuously delivered throughout the flight, rather than assuming that at most one module would fail. Instead, both modules failed, and rather than killing the flight gracefully, output diagnostic messages were interpreted as flight data.

Cluster consisted of four {{convert|1200|kg}} cylindrical, spin-stabilised spacecraft, powered by 224 watt solar cells. The spacecraft were to have flown in a tetrahedral formation, and were intended to conduct research into the Earth's magnetosphere. The satellites would have been placed into highly elliptical orbits; {{convert|17200|by|120600|km|mi}}, inclined at 90 degrees to the equator.{{cite web|last=Krebs|first=Gunter|title=Cluster 1, 2, 3, 4, 5, 6, 7, 8|url=http://space.skyrocket.de/doc_sdat/cluster.htm|access-date=29 November 2011|work=Gunter's Space Page}}

Following the failure, four replacement Cluster II satellites were built. These were launched in pairs aboard Soyuz-U/Fregat rockets in 2000.

The launch failure brought the high risks associated with complex computing systems to the attention of the general public, politicians, and executives, resulting in increased support for research on ensuring the reliability of safety-critical systems. The subsequent automated analysis of the Ariane code (written in Ada) was the first example of large-scale static code analysis by abstract interpretation.{{cite web|title=PolySpace Technologies History | last=Faure | first=Christèle | url=http://christele.faure.pagesperso-orange.fr/polyspace.html | access-date=3 October 2010}}

The failure also harmed the excellent success record of the European Space Agency's rocket family, set by the high success rate of the Ariane 4 model. It was not until 2007 that Ariane 5 launches were recognised as being as reliable as those of the predecessor model.{{Cite news

| last = Todd

| first = David

| title = ASCEND Space Intelligence News

| date = March 2007

| url=http://www.ascendworldwide.com/content/spacetrak/sinsample.pdf

| archive-url=https://web.archive.org/web/20070214142051/http://www.ascendworldwide.com/content/spacetrak/sinsample.pdf

| url-status=dead

| archive-date=14 February 2007

}}

• Mars Climate Orbiter software that had been adapted from an earlier Mars Climate Orbiter was not adequately tested before launch
• Apollo guidance computer – PGNCS trouble, another case where a spacecraft guidance computer suffered from having a subsystem inappropriately left running
• List of software bugs

{{reflist|colwidth=30em}}

• {{Cite journal |last=Thomas |first=L. D. |date=2007 |title=Selected systems engineering process deficiencies and their consequences |url=https://ntrs.nasa.gov/citations/20070002067 |journal=Acta Astronautica |volume=61 |issue=1–6 |pages=406–415 |doi=10.1016/j.actaastro.2007.01.005 |bibcode=2007AcAau..61..406T |issn=0094-5765 |via=NTRS|hdl=2060/20070002067 |hdl-access=free }}

• Jacques-Louis Lions et al., [http://esamultimedia.esa.int/docs/esa-x-1819eng.pdf Ariane 501 Inquiry Board report] ()
• {{webarchive |url=https://web.archive.org/web/20150325171826/http://spaceflightnow.com/cluster2/000714feature/ariane501_qt.html |date=25 March 2015 |title=Spaceflight Now – Cluster II – Ariane 501 explodes }}, [https://web.archive.org/web/20000831014916/http://216.92.181.8/video/000714ariane501blows.mov direct link to video file] — Footage of the final seconds of the rocket flight.
• [http://archive.wired.com/software/coolapps/news/2005/11/69355?currentPage=all Wired – History's Worst Software Bugs] — An article about the top 10 software bugs. The Ariane 5 Flight 501 software glitch is mentioned as one of these bugs.
• {{in lang|de}} [http://www.sarahandrobin.com/ingo/swr/ariane5.html Ariane 5 – 501 (1–3)] — A good article (in German) where the actual code in question is given.

{{European Space Agency}}

{{Ariane}}

Category:1996 in spaceflight

Category:Ada (programming language)

Category:Satellite launch failures

Category:Software bugs

V88, Ariane flight