* Re: Ariane-5: can you clarify? (Re: Please do not start a
@ 1997-03-19 0:00 Marin David Condic, 561.796.8997, M/S 731-93
1997-03-20 0:00 ` Jon S Anthony
1997-03-21 0:00 ` Ken Garlington
0 siblings, 2 replies; 5+ messages in thread
From: Marin David Condic, 561.796.8997, M/S 731-93 @ 1997-03-19 0:00 UTC (permalink / 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
===============================================================================
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Ariane-5: can you clarify? (Re: Please do not start a
1997-03-19 0:00 Ariane-5: can you clarify? (Re: Please do not start a Marin David Condic, 561.796.8997, M/S 731-93
@ 1997-03-20 0:00 ` Jon S Anthony
1997-03-21 0:00 ` Ken Garlington
1 sibling, 0 replies; 5+ messages in thread
From: Jon S Anthony @ 1997-03-20 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Ariane-5: can you clarify? (Re: Please do not start a
1997-03-19 0:00 Ariane-5: can you clarify? (Re: Please do not start a Marin David Condic, 561.796.8997, M/S 731-93
1997-03-20 0:00 ` 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
1 sibling, 1 reply; 5+ messages in thread
From: Ken Garlington @ 1997-03-21 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Requirements failure (was Re: Ariane-5: can you clarify?)
1997-03-21 0:00 ` Ken Garlington
@ 1997-03-25 0:00 ` Robert I. Eachus
0 siblings, 0 replies; 5+ messages in thread
From: Robert I. Eachus @ 1997-03-25 0:00 UTC (permalink / raw)
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...
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Ariane-5: can you clarify? (Re: Please do not start a
@ 1997-03-26 0:00 Marin David Condic, 561.796.8997, M/S 731-93
0 siblings, 0 replies; 5+ messages in thread
From: Marin David Condic, 561.796.8997, M/S 731-93 @ 1997-03-26 0:00 UTC (permalink / raw)
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
===============================================================================
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~1997-03-26 0:00 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1997-03-19 0:00 Ariane-5: can you clarify? (Re: Please do not start a Marin David Condic, 561.796.8997, M/S 731-93
1997-03-20 0:00 ` 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
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox