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: 101deb,f96f757d5586710a X-Google-Attributes: gid101deb,public X-Google-Thread: f43e6,5ac12f5a60b1bfe X-Google-Attributes: gidf43e6,public X-Google-Thread: 103376,5ac12f5a60b1bfe X-Google-Attributes: gid103376,public From: Steve O'Neill Subject: Re: Ariane 5 - not an exception? Date: 1996/07/30 Message-ID: <31FE35BC.1A0D@sanders.lockheed.com>#1/1 X-Deja-AN: 171084768 references: <4t9vdg$jfb@goanna.cs.rmit.edu.au> content-type: text/plain; charset=us-ascii organization: Sanders, A Lockheed-Martin Company mime-version: 1.0 newsgroups: comp.software-eng,comp.lang.ada,comp.lang.pl1 x-mailer: Mozilla 2.01 (Win16; I) Date: 1996-07-30T00:00:00+00:00 List-Id: ++ robin wrote: > ---I think the real lessons are that > 1. real-time programming requires special expertise. Agreed wholeheartedly > 2. the choice of language is suspect. A better-established > language such as PL/I -- specifically designed for > real-time programming -- with robust compilers, and > with its base of experienced programming > staff could well have prevented this disaster. I disagree completely! The language was not the problem the design decisions in how the language was used were. Ada is completely capable the realm of real-time programming, has robust compilers and tools, and has quite a few experienced software engineers capable of implementing just about any requirements thrown their way (been there, done that). Had the designers of the system allowed the implementors to use Ada exception mechanisms fully and properly they could have localized the failure to, at worst, the alignment function (which was not necessary at the time of the failure anyway) without shutting down the entire device. Instead, as is common practice in the safety-critical world, local exception handlers are frequently banned and a global 'shut it all down' handler is the only stop gap measure. Unbelievably the rationale for disallowing local handlers is because they make it difficult to verify complete code coverage since they are only executed in the case of exceptional conditions (i.e. given the expected data (Ariane 4 profile) the handlers are not executed and therefore we can't prove that all of our code has been exercised at least once). I find this logic suspect in the extreme! As somebody once said "expect the unexpected". In addition to trying for fault avoidance through analysis we should also be planning for fault resiliency in the presence of reality. You're other conclusions are right on target though - you should never shut a system down (unless its presence is impacting system performance as in the case of babbling nodes et.al.) but do indicate its distress to a higher authority who then can take this into account in using the information provided. -- Steve O'Neill | "No,no,no, don't tug on that! Sanders, A Lockheed Martin Company | You never know what it might smoneill@sanders.lockheed.com | be attached to." (603) 885-8774 fax: (603) 885-4071| Buckaroo Banzai