From: "Marin David Condic, 561.796.8997, M/S 731-93" <condicma@PWFL.COM>
Subject: Re: Ariane-5: can you clarify? (Re: Please do not start a
Date: 1997/03/19
Date: 1997-03-19T00:00:00+00:00 [thread overview]
Message-ID: <97031917192223@psavax.pwfl.com> (raw)
Jon S Anthony <jsa@ALEXANDRIA.AMERICAN.EDU> writes:
>In article <01bc3389$46204f70$b280400a@gavinspc> "Gavin Collings"
><gcollings@sperry-sun.com> writes:
>
>> (2) To treat the software as intrinsically more reliable than the
>> hardware seems to go against all experience and indeed against
>> common sense.
>
>Truer words have never been spoken or written in software circles.
>This should be framed and required to be hung on the wall in all such
>circles.
>
It's true that software is historically more apt to have design
errors in it than hardware. But its important to note that the
reason for the dual redundancy on computers such as the Ariane is
that hardware breaks. Software never breaks or wears out.
In a sense, you're asking the question of the software: "Do I
trust this set of logical rules to operate my vehicle properly?"
If the answer is yes, then applying an exact duplicate set of
rules on redundant hardware should be fine. Ask the same question
of the hardware design: How can you be sure that in some obscure
case of hardware state or mode that some specific diode or
transistor isn't going to fry? (While the hardware itself may not
be subject to "common mode" failures due to independent
components, they both share the same design and could hence have
the same logic flaw which burns up both boards.)
So in a way, the software is safer because, while both hardware
and software can suffer a fatal design flaw, the software cannot
break or wear out in usage.
I've heard of projects where they design two different computers
and two different sets of software deliberately to be dissimilar
so that the problem of a common design flaw is avoided. (I imagine
that thi$ $ort of $tuff gets *real $pendy!) But then,
one can always object that they are both operating to the same set
of requirements and if a requirement is bad, both will do the
same, wrong thing and fail. Nothing built by the hand of man is
without flaws. Guess we just gotta learn to live with an
occasional failure, 'cause they're gonna happen!
MDC
Marin David Condic, Senior Computer Engineer ATT: 561.796.8997
M/S 731-96 Technet: 796.8997
Pratt & Whitney, GESP Fax: 561.796.4669
P.O. Box 109600 Internet: CONDICMA@PWFL.COM
West Palm Beach, FL 33410-9600 Internet: CONDIC@FLINET.COM
===============================================================================
In Vegas, I got into a long argument with the man at the
roulette wheel over what I considered to be an odd number.
-- Steven Wright
===============================================================================
next reply other threads:[~1997-03-19 0:00 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
1997-03-19 0:00 Marin David Condic, 561.796.8997, M/S 731-93 [this message]
1997-03-20 0:00 ` Ariane-5: can you clarify? (Re: Please do not start a Jon S Anthony
1997-03-21 0:00 ` Ken Garlington
1997-03-25 0:00 ` Requirements failure (was Re: Ariane-5: can you clarify?) Robert I. Eachus
-- strict thread matches above, loose matches on Subject: below --
1997-03-26 0:00 Ariane-5: can you clarify? (Re: Please do not start a Marin David Condic, 561.796.8997, M/S 731-93
replies disabled
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox