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.4 required=5.0 tests=AC_FROM_MANY_DOTS,BAYES_00 autolearn=no 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-08 20:48:20 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!deine.net!news-x2.support.nl!psinet-eu-nl!psiuk-p4!uknet!psiuk-p3!uknet!psiuk-n!news.pace.co.uk!nh.pace.co.uk!not-for-mail From: "Marin David Condic" Newsgroups: comp.lang.ada,comp.software.extreme-programming Subject: Re: Ariane Failure Date: Mon, 8 Apr 2002 09:59:25 -0400 Organization: Posted on a server owned by Pace Micro Technology plc Message-ID: References: <3CA50E9A.CBF24F1B@lanl.gov> NNTP-Posting-Host: dhcp-200-133.miami.pace.co.uk X-Trace: nh.pace.co.uk 1018274366 18808 136.170.200.133 (8 Apr 2002 13:59:26 GMT) X-Complaints-To: newsmaster@news.cam.pace.co.uk NNTP-Posting-Date: 8 Apr 2002 13:59:26 GMT X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Xref: archiver1.google.com comp.lang.ada:22251 comp.software.extreme-programming:13020 Date: 2002-04-08T13:59:26+00:00 List-Id: "Dennis Lee Bieber" wrote in message news:a8oo51$tsk$2@slb2.atl.mindspring.net... > > I do have to confess to having only the general explanation of the > problem, not details of the code internals -- it does sound, from a quick > perusal of this message thread, that some sort of overflow in integer > processing occurred. This is new to me; the general report tended to the > concept that the measured rates were accurate, but exceeded what the > Ariane IV code deemed proper, and attempts to correct this "faulty rate" > led to vehicle instability... > Yes and no. The report was clearly not written by software guys since it otherwise would have explained in more accurate terms exactly what happened at the software level. Hence, you kind of have to read between the lines and interpret it some from the perspective of a more generalized engineer's view. 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. The ISR for that overflow error did just that. So the design was valid and correct for the Ariane 4. The problem for Ariane 5 was that nobody tested or checked the assumptions on the software intended to run on a different rocket. Had they run the unit through the flight profile, they would have spotted the error in a cocaine heartbeat. MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com