From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 101deb,885dab3998d28a4,start X-Google-Attributes: gid101deb,public X-Google-Thread: 107079,eca28648989efca9 X-Google-Attributes: gid107079,public X-Google-Thread: 103376,885dab3998d28a4,start X-Google-Attributes: gid103376,public X-Google-Thread: f74ae,eca28648989efca9 X-Google-Attributes: gidf74ae,public From: rav@goanna.cs.rmit.edu.au (@@ robin) Subject: Re: Ariane 5 failure Date: 1996/09/25 Message-ID: <52a572$9kk@goanna.cs.rmit.edu.au>#1/1 X-Deja-AN: 185165675 expires: 1 January 1997 00:00:00 GMT distribution: inet references: organization: Comp Sci, RMIT, Melbourne, Australia newsgroups: sci.astro,sci.math.num-analysis,comp.lang.pl1,comp.lang.ada nntp-posting-user: rav Date: 1996-09-25T00:00:00+00:00 List-Id: agraps@netcom.com (Amara Graps) writes: >I read the following message from my co-workers that I thought was >interesting. So I'm forwarding it to here. >(begin quote) >Ariane 5 failure was attributed to a faulty DOUBLE -> INT conversion >(as the proximate cause) in some ADA code in the inertial guidance >system. Diagnostic error messages from the (faulty) inertial guidance >system software were interpreted by the steering system as valid data. >English text of the inquiry board's findings is at > http://www.esrin.esa.it/htdocs/tidc/Press/Press96/ariane5rep.html >(end quote) >Amara Graps email: agraps@netcom.com >Computational Physics vita: finger agraps@best.com THere's a little more to it . . . The unchecked data conversion in the Ada program resulted in the shutdown of the computer. The backup computer had already shut down a whisker of a second before, Consequently, the on-board computer was unable to switch to the backup, and used the error codes from the shutdown computer as flight data. This is not the first time that such a programming error (integer out of range) has occurred. In 1981, the manned STS-2 was preparing to take off, but because some fuel was accidentally spilt and some tiles accidentally dislodged, takeoff was delayed by a month. During that time, the astronauts decided to get in some more practice with the simulator. During a simulated descent, the 4 computing systems (the main and the 3 backups) got stuck in a loop, with the complete loss of control. The cause? An integer out of range -- the same problem as with Ariane 5, where an integer became out of range. In the STS-2 case, the precise cause was a computed GOTO with a bad index (similar to a CASE statement without an OTHERWISE clause). In both cases, the programing error could have been detected with a simple test, but in both cases, no test was included. One would have thought that having had one failure (at least) for integer out-of-range, that the implementors of the software for Ariane 5 would have been extra careful in ensuring that all data conversions were within range -- since any kind of interrupt would result in destruction of the spacecraft. There's a case for a review of the programming language used.