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 16:44:51 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" <johnroth@ameritech.net>
Newsgroups: comp.lang.ada,comp.software.extreme-programming
Subject: Re: Ariane Failure
Date: Tue, 9 Apr 2002 19:00:15 -0400
Organization: Posted via Supernews, http://www.supernews.com
Message-ID: <ub6v7img833q49@news.supernews.com>
References: <ee2a195b.0203260725.a02dbfe@posting.google.com>
 <a82kea$blp$1@slb0.atl.mindspring.net> <3CA50E9A.CBF24F1B@lanl.gov>
 <a84f5p$nlm$1@slb5.atl.mindspring.net> <a8oo51$tsk$2@slb2.atl.mindspring.net>
 <a8s7nu$ibo$1@nh.pace.co.uk> <3CB3031A.26E08904@gbr.msd.ray.com>
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:22289
 comp.software.extreme-programming:13060
Date: 2002-04-09T19:00:15-04:00
List-Id: <comp.lang.ada>


"Steve O'Neill" <oneils@gbr.msd.ray.com> wrote in message
news:3CB3031A.26E08904@gbr.msd.ray.com...
> 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!

Not exactly. The assumption was that failures would be hardware,
so dual coding the software wasn't an objective.

John Roth