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: f43e6,5ac12f5a60b1bfe X-Google-Attributes: gidf43e6,public X-Google-Thread: 101deb,f96f757d5586710a X-Google-Attributes: gid101deb,public X-Google-Thread: 103376,5ac12f5a60b1bfe X-Google-Attributes: gid103376,public From: Martin Tom Brown Subject: Re: Ariane 5 - not an exception? Date: 1996/07/31 Message-ID: <838805582snz@nezumi.demon.co.uk>#1/1 X-Deja-AN: 171249451 x-nntp-posting-host: nezumi.demon.co.uk references: <4t9vdg$jfb@goanna.cs.rmit.edu.au> <31FE35BC.1A0D@sanders.lockheed.com> x-mail2news-path: nezumi.demon.co.uk organization: Nezumi reply-to: Martin@nezumi.demon.co.uk newsgroups: comp.software-eng,comp.lang.ada,comp.lang.pl1 Date: 1996-07-31T00:00:00+00:00 List-Id: In article <31FE35BC.1A0D@sanders.lockheed.com> smoneill@sanders.lockheed.com "Steve O'Neill" writes: > ++ robin wrote: > > 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. It goes further back than that - the requirement specifications were seriously at fault and incomplete. It was *not* a stated requirement that the unit would function correctly on the Ariane 5 trajectory. An implementation of the algorithms in any language which detects numerical overflow would have shut down the IRS to comply with spec. > 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 ... I agree that the language is in the clear. > 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. This was what surprised me - coming from an environment (not safety critical) where continued function even if degraded is preferred to hard shutdown. It seems unduly perverse to guarantee total system failure once an untrapped exception occurs. Is it really safer to blow the thing out of the sky than inject its payload into an inaccurate orbit? After all the hardware failsafe *will* destroy it automatically if the trajectory deviates sufficiently - as happened when the IRS started feeding the navigation computer diagnostic bit patterns as data. > 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. This is an interesting insight. > 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 can see there is a point there, OTOH perhaps there is something wrong with a test philosophy that don't attempt to push the envelope of valid data to find what happens if ... Designing test data to execute each and every path is part of the game. Regards, -- Martin Brown __ CIS: 71651,470 Scientific Software Consultancy /^,,)__/