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: ff121,3ae3fa74ecb04ab8 X-Google-Attributes: gidff121,public X-Google-Thread: 103376,c617ae447ca32f2f X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-04-09 05:43:36 PST Path: archiver1.google.com!news1.google.com!sn-xit-02!sn-post-01!supernews.com!news.supernews.com!not-for-mail From: "John Roth" Newsgroups: comp.lang.ada,comp.software.extreme-programming Subject: Re: Ariane Failure Date: Tue, 9 Apr 2002 08:49:21 -0400 Organization: Posted via Supernews, http://www.supernews.com Message-ID: References: <3CA50E9A.CBF24F1B@lanl.gov> 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 X-Complaints-To: newsabuse@supernews.com Xref: archiver1.google.com comp.lang.ada:22267 comp.software.extreme-programming:13021 Date: 2002-04-09T08:49:21-04:00 List-Id: "Marin David Condic" wrote in message news:a8s7nu$ibo$1@nh.pace.co.uk... > "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. I think the technical report went into more detail. However, this particular thread got started by a post that referenced an article which claimed that if the implementers had used Eifel with Design by Contract, the problem would not have occured. This is patently absurd. The proximate cause, as several posters have pointed out, was the failure to recertify and test a component designed for one rocket for use with a different rocket with different characteristics. Drilling deeper, the next level cause was attempting to do too much function for a given combination of processor / language. This caused performance-motivated shortcuts in the implementation. Thus the 'solution' would have been to use a processor with higher performance, or a language with less overhead. Pursuing this path, we come to the inescapable conclusion that the problem would not have occured if the implementors had used either Assembler or Forth! > 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 John Roth >