Re: Ariane-5: can you clarify? (Re: Please do not start a

Re: Ariane-5: can you clarify? (Re: Please do not start a

[Marin David Condic, 561.796.8997, M/S 731-93]

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
===============================================================================

Re: Ariane-5: can you clarify? (Re: Please do not start a

[Jon S Anthony]

In article <97031917192223@psavax.pwfl.com> "Marin David Condic, 561.796.8997, M/S 731-93" <condicma@PWFL.COM> writes:

>     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.

I agree it never wears out.  From a certain point of view I can also
see why you might say it never breaks.  But in that case, I would
expect that the prudent assumption would be that it is simply _always_
broken.  Not true per se, but a much safer rule of thumb than the
opposite.


>     In a sense, you're asking the question of the software: "Do I
>     trust this set of logical rules to operate my vehicle properly?"

That's actually only a small piece of it.  There are all the other
issues even assuming the correctness of the rules: Were they
communicated correctly?  Were they implemented correctly?  Will they
be used in the proper context for which they were conceived? Etc.
Generally speaking, software practice does a much more miserable job
of this than hardware, with the exception of engine and flight control
software.


>     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.

It can simply _always_ have been broken.  Just waiting to blow up in
your face.


>     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!

Absolutely agree.

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: Ariane-5: can you clarify? (Re: Please do not start a

[Ken Garlington]

Marin David Condic, 561.796.8997, M/S 731-93 wrote:
> 
>     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.

Not only can they object, there is a significant amount of experimental
and anecdotal evidence that says the error will be in the requirements.
See, for example, the work of Levison and Knight.

Ariane-5 is a perfect example of this. As the final report says, the
specification did not contain the Ariane V flight profile as a
requirement.
Given that, I would not be at all surprised if the same design fault
occured in multiple design variants.

>     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
> ===============================================================================

--
LMTAS - The Fighter Enterprise - "Our Brand Means Quality"
For job listings, other info: http://www.lmtas.com or
http://www.lmco.com

Requirements failure (was Re: Ariane-5: can you clarify?)

[Robert I. Eachus]

In article <3332BA72.72F8@lmtas.lmco.com> Ken Garlington <GarlingtonKE@lmtas.lmco.com> writes:

  > Ariane-5 is a perfect example of this. As the final report says,
  > the specification did not contain the Ariane V flight profile as a
  > requirement.  Given that, I would not be at all surprised if the
  > same design fault occured in multiple design variants.

   I just realized...  The guidance SYSTEM was not tested or evaluated
against the Ariane 5 requirements.  Also, according to the report the
software was not modified for Ariane 5.  And we know from the actual
failure mode, that there was nothing to prevent the engines from being
deflected enough to cause the stack to disintegrate.

   So independent of the alignment software, one strong gust of wind,
and the Ariane 5 crashes because the deflection limits in both
hardware and software are for the Ariane 4.

   I think that makes it clear it was a failure in the requirements
process...
--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Ariane-5: can you clarify? (Re: Please do not start a

[Marin David Condic, 561.796.8997, M/S 731-93]

David Starr <david.starr@ANALOG.COM> writes:
>I say the crash was caused by the requirement for the inertial nav
>software to shut down and enter hardware test mode upon exception.  In
>other words, the program did what it was asked to do, and it was asked to
>destroy the rocket upon any kind of unforseen problem.  Be careful what
>you ask for, you might get it.

    Be a bit careful here. Remember that the software ran just fine
    and dandy on the Ariane 4. Hence the requirements, design,
    implementation, etc, must have been adequate to get the job done.
    (One of many possible "right answers") What caused the crash was
    more a case of lifting software out of Ariane 4 and making the
    assumption that it would be sufficient for Ariane 5.

>   If the inertial nav software had been required to press on regardless
>there is an excellent chance the mission would have flown.
>   I don't think a clever programming language could be so good as to
>guarantee no exceptions ever.  The software was required to shut down
>upon exeception.  It got an exception and it shut down.
>
    Pressing on in the face of an exception is probably better than a
    shutdown because on a dual redundant system the software design is
    common and you can presume that if you divided by zero on your
    side, your partner probably did as well. But you'll note my
    favoring the word "probably". I could easily imagine a situation
    where the rocket is flying along, divides by zero, and continues
    to fly along right into a schoolyard full of kids. You might want
    to presume that if you're seeing an exception in software that you
    didn't see in test, that you've got either broke hardware causing
    the exception or crazy software which is real dangerous to run.
    Design philosophies such as this can be debated right up until the
    project is cancelled. Sooner or later, you have to pick one and
    fly with it.

    Your point is well taken. The software did exactly what it was
    designed to do. It just didn't do what you wanted it to do.

    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
===============================================================================