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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,f039470e8f537101 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-07-22 05:29:04 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!newshub.sdsu.edu!elnk-nf2-pas!newsfeed.earthlink.net!stamper.news.pas.earthlink.net!stamper.news.atl.earthlink.net!harp.news.atl.earthlink.net!not-for-mail From: Marin David Condic Newsgroups: comp.lang.ada Subject: Re: Ariane5 FAQ Date: Tue, 22 Jul 2003 08:28:58 -0400 Organization: MindSpring Enterprises Message-ID: <3F1D2E0A.8060103@noplace.com> References: <1058799152.775376@master.nyc.kbcfp.com> <1058810510.375902@master.nyc.kbcfp.com> <1058813341.841940@master.nyc.kbcfp.com> <1058816605.566685@master.nyc.kbcfp.com> <3F1CC443.FD2BA89D@adaworks.com> NNTP-Posting-Host: d1.56.bf.ee Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Server-Date: 22 Jul 2003 12:29:03 GMT User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 (OEM-HPQ-PRS1C03) X-Accept-Language: en-us, en Xref: archiver1.google.com comp.lang.ada:40634 Date: 2003-07-22T12:29:03+00:00 List-Id: As a designer of realtime embedded systems that use sensors in a similar manner, I'd dispute that it was a "design error". It was a deliberate decision based on analysis of the flight path, etc., that arrived at a conclusion that any data big enough to trigger the overflow would most likely be caused by a bad sensor. We do this *all*the*time* when looking at data coming across an A/D or F/D converter - we range check it and if it is outside some expected range, we declare the sensor failed and transfer to the other channel. Hence, it was working exactly as designed - it detected what it thought was a bad sensor and took its pre-programmed accommodation. On systems with a little more compute horsepower and better data communication links, it may have been possible to design alternative detection/accommodation schemes that would have avoided a false-detect. One might have cross-channeled the data and determined that *both* sides were seeing the same thing - but what accommodation would you take for a dual sensor failure? Shut down both units? It was built on a relatively slow 1750a microprocessor and they had to live within the limits of the compute power they had, so they devised a reasonable FDA scheme that would work well in the context for which it was designed. At the end of the day the only logical conclusion to come to is that the software was properly designed for the Ariane 4 because it worked successfully there and in that context *would*have* done the proper thing had it seen the same data. (A ten amp fuse is *supposed* to blow when it sees more than ten amps. If you plug it into a twenty amp circuit, are you going to call that "bad design" on the part of the fuse engineers because it didn't do what it was "supposed to do" in this different application?) Putting it *untested* into the Ariane 5 was wherein the fault originated. MDC Richard Riehle wrote: > not have happened. While I don't agree that Eiffel would have > been better for the job, a contract model such as that found in > SPARK might have been successful in detecting the design > error early on. -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jast.mil/ Send Replies To: m c o n d i c @ a c m . o r g "In general the art of government consists in taking as much money as possible from one class of citizens to give to the other." -- Voltaire ======================================================================