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: 103376,5ac12f5a60b1bfe X-Google-Attributes: gid103376,public X-Google-Thread: f43e6,5ac12f5a60b1bfe X-Google-Attributes: gidf43e6,public From: rgilbert@unconfigured.xvnews.domain (Bob Gilbert) Subject: Re: Ariane 5 - not an exception? Date: 1996/07/26 Message-ID: <4tb8vv$bna@zeus.orl.mmc.com>#1/1 X-Deja-AN: 170942843 references: organization: The unconfigured xvnews people reply-to: rgilbert@unconfigured.xvnews.domain newsgroups: comp.software-eng,comp.lang.ada Date: 1996-07-26T00:00:00+00:00 List-Id: In article , simonb@pact.srf.ac.uk (Simon Bluck) writes: > The Ariane 501 flight failure was due to the raising of an unexpected > Ada exception, which was handled by switching off the computer. The failure was due to the reuse of software, a software design, and software requirements specification which was purposely designed to raise the said exception and perform a SRI shutdown should certain limits be exceeded. Unfortunately these limits were well within normal operating budget of the Ariane 5, but would be considered a failure (most probably hardware) if encountered on the Ariane 4 from which the software/design/requirements were borrowed. > The report on this: > > http://www.esrin.esa.it/htdocs/tidc/Press/Press96/ariane5rep.html > > is clear and hard-hitting: it will result in much improved software. > But does it get right to the bottom of the issues, and does the > software community appreciate that there are fundamental software > control problems which can directly give rise to such enormous > failures, in this particular case thankfully without loss of life? > > It is most unfortunate, but must be accepted as true, that if the > Ariane software had been written in a less powerful language the > numeric overflow might have gone unnoticed, the computers would have > remained switched on, and the rocket would have continued its upward > flight. A "less powerful" language *might* have continued and the numeric overflow gone unnoticed, or a similar catostrophic failure could have occured with little chance of tracing the source of the failure. But even if a "less powerful" language were used, it is probable that the resulting code would have been designed to the same faulty logic contained in the requirements specification. The Ariane failure has little or nothing to do with language selection or even correct coding. The software performed exactly as designed. The problem resulted in an oversight in the design limitations and differences between the Ariane 4 and Ariane 5 systems. I think the lessons to be learned here are about the reuse of software (especially design and requirements) and testing. -Bob