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=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f74ae,eca28648989efca9 X-Google-Attributes: gidf74ae,public X-Google-Thread: 101deb,885dab3998d28a4 X-Google-Attributes: gid101deb,public X-Google-Thread: 103376,885dab3998d28a4 X-Google-Attributes: gid103376,public X-Google-Thread: 107079,eca28648989efca9 X-Google-Attributes: gid107079,public From: molagnon@ifremer.fr (Michel OLAGNON) Subject: Re: Ariane 5 failure Date: 1996/10/04 Message-ID: <533687$pf@ys.ifremer.fr>#1/1 X-Deja-AN: 187523737 distribution: inet references: <532k32$r4r@goanna.cs.rmit.edu.au> organization: Ifremer reply-to: molagnon@ifremer.fr newsgroups: sci.astro,sci.math.num-analysis,comp.lang.pl1,comp.lang.ada Date: 1996-10-04T00:00:00+00:00 List-Id: In article <532k32$r4r@goanna.cs.rmit.edu.au>, rav@goanna.cs.rmit.edu.au (@@ robin) writes: > john@assen.demon.co.uk (John McCabe) writes: > > >Just a point for your information. From clari.tw.space: > > > "An inquiry board investigating the explosion concluded in > >July that the failure was caused by software design errors in a > >guidance system." > > >Note software DESIGN errors - not programming errors. > > >Best Regards > >John McCabe > >---If you read the Report, you'll see that that's not the case. >This is what the report says: > > "* The internal SRI software exception was caused during execution of a > data conversion from 64-bit floating point to 16-bit signed integer > value. The floating point number which was converted had a value > greater than what could be represented by a 16-bit signed integer. > This resulted in an Operand Error. The data conversion instructions > (in Ada code) were not protected from causing an Operand Error, > although other conversions of comparable variables in the same place > in the code were protected. > > "In the failure scenario, the primary technical causes are the Operand Error > when converting the horizontal bias variable BH, and the lack of protection > of this conversion which caused the SRI computer to stop." > >---As you can see, it's clearly a programming error. It's a failure >to check for overflow on converting a double precision value to >a 16-bit integer. But if you read a bit further on, it is stated that The reason why three conversions, including the horizontal bias variable one, were not protected, is that it was decided that they were physically bounded or had a wide safety margin (...) The decision was a joint one of the project partners at various contractual levels. Deciding at various contractual levels is not what one usually means by ``programming''. It looks closer to ``design'', IMHO. But, of course, anyone can give any word any meaning. And it might be probable that the action taken in case of protected conversion, and exception, would also have been stop the SRI computer because such a high horizontal bias would have meant that it was broken.... Michel -- | Michel OLAGNON email : Michel.Olagnon@ifremer.fr| | IFREMER: Institut Francais de Recherches pour l'Exploitation de la Mer|