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: 103376,5ac12f5a60b1bfe X-Google-Attributes: gid103376,public X-Google-Thread: f43e6,5ac12f5a60b1bfe X-Google-Attributes: gidf43e6,public X-Google-Thread: 101deb,f96f757d5586710a X-Google-Attributes: gid101deb,public From: Steve O'Neill Subject: Re: Ariane 5 - not an exception? Date: 1996/08/05 Message-ID: <32065615.77C7@sanders.lockheed.com>#1/1 X-Deja-AN: 172279874 references: <4t9vdg$jfb@goanna.cs.rmit.edu.au> <31FE35BC.1A0D@sanders.lockheed.com> <4totv7$o9f@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-08-05T00:00:00+00:00 List-Id: ++ robin wrote: > Steve O'Neill writes: > >I disagree completely! The language was not the > >problem the design decisions in how the language > >was used were. > > ---The choice of language is indeed very relevant. > What I wrote in an earlier posting on this topic is highly > apt: > > "A PL/I programmer > experienced with real time systems, would have CHALLENGED > such a stupid requirement that the computer be shut down by the > error-handler in the event of a fixed-point overflow. He would > have had it changed. > > "I'd go further to say that no experienced PL/I programmer > would have shut down the system as a result of a fixed-point > overflow. Substitute Ada (or C or FORTRAN or Assembly) for PL/I here and you see my point. It's not the language that makes the developer challange the ridiculous requirement to shut down it is the developer "experienced with real-time systems". Just because I am programming in PL/I doesn't mean I am magically a better real-time developer. As a real-time designer concerned with the system-wide aspects of completely shutting down any sensor I would question this approach regardless of the language in use. This has nothing to do with the fact that much of my experience is with Ada. The (flawed) reasoning for why certain conversions were not protected was also covered in the report. Invalid assumptions were made and we know what assuming does don't we (makes an ASS out of U and ME). This was compounded by the requirement for 20% spare capacity. Spare capacity for what we don't know. Especially considering that the very software which failed didn't need to be and should not have been running at the time consuming some of that precious spare. Certainly you and I would not have shut down the system but what about the vast majority of developers without as much experience or who thought that their job was to implement the requirements that they were given? > > "Furthermore, he would have included a check that the value > did not go out of range;" > > ---But all it needed was a check that the value was in range. > Such checks had been included on other similar conversions in > the vicinity! > Yes, and there was mention in the report that 'they' thought that this would violate that precious spare requirement. So they set about picking and choosing which conversions to protect. I find it extremely hard to believe that the (small) handful of instructions to do a range check would have been too much! And, in hindsight, well worth it. The issue of the OBC interpreting the 'essentially diagnostic data' as valid sensor data really makes me wonder. In a system with a reasonable interface between the two devices this should *never* happen. I am surprised that this misinterpretation didn't cause a similar overflow in the OBC and resulting shutdown! :( I think that we agree in our assessment of the situation and the fact that these problems could have been avoided with a better overall system design and more extensive testing. Essentially the same conclusions that the review board came to. My only disagreement is with your _opinion_ that the simple choice of a different language would have saved the day. And with this point I will continue to disagree. -- 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