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 From: JP Thornley Subject: Re: Ariane 5 - not an exception? Date: 1996/08/02 Message-ID: <248081750wnr@diphi.demon.co.uk>#1/1 X-Deja-AN: 171714486 x-nntp-posting-host: diphi.demon.co.uk references: <285641259wnr@diphi.demon.co.uk> <483202904wnr@diphi.demon.co.uk> <687081688wnr@diphi.demon.co.uk> <4tqkst$be01@red.interact.net.au> x-mail2news-path: disperse.demon.co.uk!post.demon.co.uk!diphi.demon.co.uk organization: None reply-to: jpt@diphi.demon.co.uk newsgroups: comp.lang.ada Date: 1996-08-02T00:00:00+00:00 List-Id: Alan Brain writes: > Umm. It appears I may have a small but critical difference of opinion here. IMHO > safety-critical software _in particular_ should be assumed to be faulty, (perhaps) > _even though_ shown to be correct. > We definitely have a difference of opinion here - a software component of a system is classified as safety-critical if failure of that component *alone* creates a significant risk of the system suffering or causing a catastrophic accident. If the system is designed so that the risk only becomes significant when both this software component and some other component of the system (wholly independent of this software component) fail, then the software is not safety-critical. So, assuming that the software is faulty (which I take to mean 'can be expected to suffer a hazardous failure') results in an assumption that the catastrophic accident *will occur*. My favorite example at the moment is the Flight Control System on the Boeing 777 - running on three separate and diverse boxes (I think that one is a 68K, another is a 486 and I can't remember the third) but all programmed from the same Ada source. No single box is safety-critical, as there are two wholly independent back-ups, but the software clearly is. An assumption that this software is faulty must lead to the conclusion that the plane should never be certified. Clearly this isn't the case, and the software must have been created using a rigorous process that gives adequate assurance that it will not suffer a hazardous failure (and that's what I think the report means when it talks about "applying the currently accepted best practice methods" in order to "demonstrate that it is correct" ). Phil Thornley -- ------------------------------------------------------------------------ | JP Thornley EMail jpt@diphi.demon.co.uk | ------------------------------------------------------------------------