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: 107079,eca28648989efca9 X-Google-Attributes: gid107079,public X-Google-Thread: f74ae,eca28648989efca9 X-Google-Attributes: gidf74ae,public X-Google-Thread: 103376,885dab3998d28a4 X-Google-Attributes: gid103376,public X-Google-Thread: 101deb,885dab3998d28a4 X-Google-Attributes: gid101deb,public From: rav@goanna.cs.rmit.edu.au (@@ robin) Subject: Re: Ariane 5 failure Date: 1996/10/09 Message-ID: <53fh23$s9g$1@goanna.cs.rmit.edu.au>#1/1 X-Deja-AN: 188186820 expires: 1 January 1997 00:00:00 GMT distribution: inet references: <532k32$r4r@goanna.cs.rmit.edu.au> <533687$pf@ys.ifremer.fr> 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-10-09T00:00:00+00:00 List-Id: molagnon@ifremer.fr (Michel OLAGNON) writes: >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 OLAGNON email : Michel.Olagnon@ifremer.fr| But if you read further on .... "However, three of the variables were left unprotected. No reference to justification of this decision was found directly in the source code. Given the large amount of documentation associated with any industrial application, the assumption, although agreed, was essentially obscured, though not deliberately, from any external review." .... you'll see that there was no documentation in the code to explain why these particular 3 (dangerous) conversions were left unprotected. There is the implication that one or more of them might have been overlooked . . . .. Don't place too much reliance on the conclusion of the report, when the detail is right there in the body of the report.