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: 103376,82c2596e4584d057 X-Google-Attributes: gid103376,public X-Google-Thread: 101deb,e8bee2f0c75c8235 X-Google-Attributes: gid101deb,public X-Google-Thread: 12b42c,cefd160f01546cf0,start X-Google-Attributes: gid12b42c,public From: rav@goanna.cs.rmit.edu.au (++ robin) Subject: Re: Ariane 5 Failure - Summary Report Date: 1996/07/25 Message-ID: <4t6opg$4cp@goanna.cs.rmit.edu.au>#1/1 X-Deja-AN: 170342835 expires: 1 October 1996 00:00:00 GMT references: <31F60E8A.2D74@lmtas.lmco.com> <31F629B8.5FFB@lmtas.lmco.com> organization: Comp Sci, RMIT, Melbourne, Australia newsgroups: comp.lang.ada,comp.lang.pl1,rmit.cs.100 nntp-posting-user: rav Date: 1996-07-25T00:00:00+00:00 List-Id: Ken Garlington writes: >Ken Garlington wrote: >Don't know what happened there, but I was just going to point out >that the Ariane 5 report is at: > http://www.esrin.esa.it/htdocs/tidc/Press/Press96/press33.html >Be sure to read the full report, which is linked to this page. It >goes into some length about the sequence of events (which includes >an Ada exception I never heard of before, Operand Error? ---That's fixed-point overflow. Converting a 64-bit floating-point value to a 16 bit signed integer. The conversion was unchecked (programming error-- the other conversions in the same module were checked; the assumption was made that the value would be within range); consequently the error condition was raised. The exception-handling routine was to record the status of the error and to then shut down the system. Maybe it's user >defined, or there's a language difference at work). >Definitely good "lessons learned" about: >1. The limits of exceptions (they are only as good as what you can do >when they are raised). >2. The problems with reusing items outside their original environment. >3. The need to check inputs and outputs aggressively. >4. The pitfalls of assuming that testing all of the components of a >system equates to testing the system, as well as the need to use >realistic test scenarios. >5. The problems with isolating the safety-critical components of a >system. >So, anyway, we now have another software package written in Ada that >caused the loss of a system, and again specification and design issues >outside Ada's control are the culprit.