comp.lang.ada
 help / color / mirror / Atom feed
From: fdebruin@xs3.xs4all.nl (fdebruin)
Subject: Re: Ariane Failure
Date: 11 Apr 2002 12:12:16 GMT
Date: 2002-04-11T12:12:16+00:00	[thread overview]
Message-ID: <a93uj0$1be$1@news1.xs4all.nl> (raw)
In-Reply-To: 3CB435A4.8A011DF1@gbr.msd.ray.com

Steve O'Neill <oneils@gbr.msd.ray.com> writes:

>John Roth wrote:
>> 
>> "Steve O'Neill" <oneils@gbr.msd.ray.com> wrote in message
>> > 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.

>Well, no matter where you assume the failures will or will not occur you
>should never design a dual-redundant system where both strings are
>identical.

The strings were not identical because they were using physically different
hardware components. 

You could argue that the strings should have no commonalities at
at all for maximum safety and robustness. This will only work if you
have endless resources in terms of money and time.

For example, in the case of Ariane 501 the IRS software in the two units
could have been developed indepently by two different companies. Maybe
the problem would have occurred in only one of them.

This will immediately raise the issue of deciding which software is 
roviding you the correct data, in case they differ. This will lead to
some kind of arbitrator (a new single point of failure) or a third
software package to allow majority voting.

You will easily tripple the cost of your software. In addition, I am not
convinced that the added robustness makes up for the added complexity.
Furthemore, you are still not fully covered because your software
specification might contain an error that will be common to all indepently
developed software.

Redundancy is a vital concept but it is not *the* solution, it is just
contributing to it. It all boils down to a tradeoff. To the extreme: the
costs of your redunancy should not be higher than the recurrent costs
for building a new launcher.


Frank de Bruin





  parent reply	other threads:[~2002-04-11 12:12 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <ee2a195b.0203260725.a02dbfe@posting.google.com>
2002-03-29 18:56 ` Ariane Failure Richard Riehle
2002-03-29 20:56   ` Michael Feathers
2002-03-30  1:02     ` Bill
2002-03-30  3:20       ` Keith Ray
2002-03-30 12:12         ` John Roth
2002-03-30 13:36       ` Michael Feathers
2002-04-01 15:22         ` Marin David Condic
     [not found]         ` <a8oo51$tsk$2@slb2.atl.mindspring.net>
2002-04-08 13:59           ` Marin David Condic
2002-04-09 12:49             ` John Roth
2002-04-09 14:58               ` Steve O'Neill
2002-04-09 15:04             ` Steve O'Neill
2002-04-09 23:00               ` John Roth
2002-04-10 12:52                 ` Steve O'Neill
2002-04-10 12:59                   ` Marin David Condic
2002-04-11  0:48                     ` Steve O'Neill
2002-04-11 13:17                       ` Marin David Condic
2002-04-11 13:47                     ` Ted Dennison
2002-04-11 14:15                       ` Marin David Condic
2002-04-11 12:12                   ` fdebruin [this message]
2002-04-11 14:33                     ` Larry Kilgallen
2002-04-11 18:16                       ` Ted Dennison
2002-04-11 18:30                         ` Marin David Condic
2002-04-09 19:07             ` Bill
2002-04-09 19:44               ` Marin David Condic
2002-04-01 15:08   ` Marin David Condic
2002-04-02 18:32     ` Wes Groleau
2002-04-02 18:42       ` Marin David Condic
1996-06-28  0:00 Robert B. Love 
1996-07-01  0:00 ` Ken Garlington
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox