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,c617ae447ca32f2f X-Google-Attributes: gid103376,public X-Google-Thread: ff121,3ae3fa74ecb04ab8 X-Google-Attributes: gidff121,public X-Google-ArrivalTime: 2002-04-09 08:04:58 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!cpk-news-hub1.bbnplanet.com!cambridge1-snf1.gtei.net!news.gtei.net!bos-service1.ext.raytheon.com!bos-service2.ext.raytheon.com.POSTED!not-for-mail Message-ID: <3CB3031A.26E08904@gbr.msd.ray.com> From: Steve O'Neill X-Mailer: Mozilla 4.7 [en] (X11; U; HP-UX B.11.11 9000/785) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.lang.ada,comp.software.extreme-programming Subject: Re: Ariane Failure References: <3CA50E9A.CBF24F1B@lanl.gov> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 09 Apr 2002 11:04:58 -0400 NNTP-Posting-Host: 192.199.125.16 X-Complaints-To: news@ext.ray.com X-Trace: bos-service2.ext.raytheon.com 1018364698 192.199.125.16 (Tue, 09 Apr 2002 11:04:58 EDT) NNTP-Posting-Date: Tue, 09 Apr 2002 11:04:58 EDT Organization: Raytheon Company Xref: archiver1.google.com comp.lang.ada:22269 comp.software.extreme-programming:13026 Date: 2002-04-09T11:04:58-04:00 List-Id: Marin David Condic wrote: > The software module in question was originally analyzed on Ariane 4 with a > veiw toward improving speed. They had a shortage of CPU cycles and had > identified this one module as a major consumer of resources. They changed > the code to eliminate all the range checking and other "safety features" > (not at all uncommon in this business) in order to speed it up. This was not > without analysis that examined the possible valid ranges for various numbers > and mathematically reasoning about it & coming to the conclusion that any > values that would possibly generate a hardware overflow error could not be > in the valid flight path of the Ariane 4 - hence it was likely to be a > sensor failure and the proper accommodation would be to transfer control to > the other channel. And here was another of the fatal system design flaws that should never have been made... it seems that this 'other channel' was an *identical* system which, of course, reacted in the same manner. Leaving the poor flight control computer with no valid data. Ooops!