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: Martin Tom Brown Subject: Re: Ariane 5 - not an exception? Date: 1996/07/29 Message-ID: <838637917snz@nezumi.demon.co.uk>#1/1 X-Deja-AN: 171014724 x-nntp-posting-host: nezumi.demon.co.uk references: <4tb8vv$bna@zeus.orl.mmc.com> x-mail2news-path: nezumi.demon.co.uk organization: Nezumi reply-to: Martin@nezumi.demon.co.uk newsgroups: comp.software-eng,comp.lang.ada Date: 1996-07-29T00:00:00+00:00 List-Id: In article <4tb8vv$bna@zeus.orl.mmc.com> rgilbert@unconfigured.xvnews.domain "Bob Gilbert" writes: > 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. Yes - one can argue about the reasonableness of killing the active SRI when the backup has already failed. And also about the decision made during s/w development that out of 7 variables at risk of overflow only 4 were fully protected, and 3 unprotected which were felt not at risk to keep CPU load inside bounds <80% (for Ariane 4 flight trajectories). It adds insult to injury that the calculation code which failed was only valid when the system was on the *ground* awaiting launch. It's a very good report and makes interesting reading. > 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 > > > The Ariane failure has little or nothing to do with language selection > or even correct coding. The software performed exactly as designed. Again you can question the wisdom of shutting down the active IRS when the backup is already dead - continuing with best guess data would have been a marginally better option at that stage. The defect is traceable back to the requirements specification, and the assumption that single point hardware failure is more likely than systematic software error in a redundant system. > 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. The report's recommendations seem generally applicable to a large number of systems engineering projects with a software component. Regards, -- Martin Brown __ CIS: 71651,470 Scientific Software Consultancy /^,,)__/