comp.lang.ada
 help / color / mirror / Atom feed
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
===============================================================================




             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