Re: Ariane 5 failure

Re: Ariane 5 failure

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

Matthew Heaney <mheaney@NI.NET> writes:
>
>Why, yes.  If the rocket blows up, at the cost of millions of dollars, then
>I'm not clear what the value of "faster execution" is.  The rocket's gone,
>so what difference does it make how fast the code executed?  If you left
>the range checks in, your code would be *marginally* slower, but you'd
>still have your rocket, now wouldn't you?
>
    It's not a case of saving a few CPU cycles so you can run Space
    Invaders in the background. Quite often (and in particular in
    *space* systems which are limited to rather antiquated
    processors) the decision is to a) remove the runtime checks from
    the compiled image and run with the possible risk of undetected
    constraint errors, etc. or b) give up and go home because there's
    no way you are going to squeeze the necessary logic into the box
    you've got with all the checks turned on.

    It's not as if we take these decisions lightly and are just being
    stingy with CPU cycles so we can save them up for our old age. We
    remove the checks typically because there's no other choice.

    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
===============================================================================
    "Some people say a front-engine car handles best. Some people say
    a rear-engine car handles best. I say a rented car handles best."

        --  P. J. O'Rourke
===============================================================================

Re: Ariane 5 failure

[Robert I. Eachus]

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

   Marin David Condic

   > It's not a case of saving a few CPU cycles so you can run Space
   > Invaders in the background. Quite often (and in particular in
   > *space* systems which are limited to rather antiquated
   > processors) the decision is to a) remove the runtime checks from
   > the compiled image and run with the possible risk of undetected
   > constraint errors, etc. or b) give up and go home because there's
   > no way you are going to squeeze the necessary logic into the box
   > you've got with all the checks turned on.

   > It's not as if we take these decisions lightly and are just being
   > stingy with CPU cycles so we can save them up for our old age. We
   > remove the checks typically because there's no other choice.

   In this case though, management threw out the baby with the
bathwater.  To preserve a 20% margin in the presence of a kludge
already known to be applicable only to the Ariane 4, they took out
checks that would be vital if the kludge ran on the Ariane 5, then
forgot to take the kludge out.

   The proper solution was to recognize in the performance specs that
the load was 81% or whatever until the intertial alignment software
shut down after launch.


--

					Robert I. Eachus

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

Re: Ariane 5 failure

[Ken Garlington]

Robert I. Eachus wrote:
> 
> In article <96100111162774@psavax.pwfl.com> "Marin David Condic, 407.796.8997, M/S 731-93" <condicma@PWFL.COM> writes:
> 
>    Marin David Condic
> 
>    > It's not a case of saving a few CPU cycles so you can run Space
>    > Invaders in the background. Quite often (and in particular in
>    > *space* systems which are limited to rather antiquated
>    > processors) the decision is to a) remove the runtime checks from
>    > the compiled image and run with the possible risk of undetected
>    > constraint errors, etc. or b) give up and go home because there's
>    > no way you are going to squeeze the necessary logic into the box
>    > you've got with all the checks turned on.
> 
>    > It's not as if we take these decisions lightly and are just being
>    > stingy with CPU cycles so we can save them up for our old age. We
>    > remove the checks typically because there's no other choice.
> 
>    In this case though, management threw out the baby with the
> bathwater.  To preserve a 20% margin in the presence of a kludge
> already known to be applicable only to the Ariane 4, they took out
> checks that would be vital if the kludge ran on the Ariane 5, then
> forgot to take the kludge out.

The critical part of this correct statement, of course, being "In this 
case..". In another context, this might have been the right decision.

It's also important to remember that Ariane 5 didn't exist when the 
Ariane 4 team made this decision. They may have been short-sighted, but 
they weren't idiots based on what they knew at the time.

The Ariane _5 management not doing sufficient re-analysis and re-test of 
this "off-the-shelf" system is, to me, much less excusable.

-- 
LMTAS - "Our Brand Means Quality"
For more info, see http://www.lmtas.com or http://www.lmco.com

Re: Ariane 5 failure

[Matthew Heaney]

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

    It's not a case of saving a few CPU cycles so you can run Space
>    Invaders in the background. Quite often (and in particular in
>    *space* systems which are limited to rather antiquated
>    processors) the decision is to a) remove the runtime checks from
>    the compiled image and run with the possible risk of undetected
>    constraint errors, etc. or b) give up and go home because there's
>    no way you are going to squeeze the necessary logic into the box
>    you've got with all the checks turned on.
>
>    It's not as if we take these decisions lightly and are just being
>    stingy with CPU cycles so we can save them up for our old age. We
>    remove the checks typically because there's no other choice.

Funny you mention that, because I would have said take option b.  My
attitude is that there is a state of the art today, and it's not cost
effective to try to push too far beyond that.

I'm not unsympathetic to your situation, as my own background is in
real-time (ground-based) systems.  But when you try to push the technology
envelope beyond what is (easily) available today, the cost of your system
and the risk of failure shoots up.

To do what you wanted to do with your existing hardware meant you had to
turn off checks.  Fair enough.  But that decision very much increased your
risk that something bad would happen from which you wouldn't be able to
recover.

I heard those satellites cost $500 million dollars.  Was turning off those
checks really worth the risk of losing that much money?  To me you were
just gambling.

I would have said that, no, the risk is too great.  Scale back the
requirements and let's do something less ambitious.  If you really want to
do that, wait 18 months and Dr. Moore will give you hardware that's twice
as fast.  But if you want to do it today, and you have turn the checks off,
well then, you're just rolling the dice.

The state of software art today is such that we can't deploy a provably
correct system, and we have resort to run-time checks to catch logical
flaws.  I accept this "limitation," and I accept that there are certain
kinds of systems we can't do today (because to do them would require
turning off checks).

Buyers of mission-critical software should think very carefully before they
commit any financial resources to implementing a software system that
requires checks be turned off.  I'd say take your money instead to Las
Vegas: your odds for success are better there.

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
mheaney@ni.net
(818) 985-1271

Re: Ariane 5 failure

[Ken Garlington]

Matthew Heaney wrote:
> 
> Buyers of mission-critical software should think very carefully before they
> commit any financial resources to implementing a software system that
> requires checks be turned off.  I'd say take your money instead to Las
> Vegas: your odds for success are better there.

Better not drive or fly there: more than likely, the software systems running
in your car, plane, etc. are written in a language without any built-in
support for checks.

Checks are not a magic wand. They do not inherently make systems safer. What
matters is how you use the checks. If your ABS software fails in the middle
of winter, printing out a stack dump is not going to make you much safer!

-- 
LMTAS - "Our Brand Means Quality"
For more info, see http://www.lmtas.com or http://www.lmco.com

Re: Ariane 5 failure

[Robert Dewar]

Matthew said

"> Buyers of mission-critical software should think very carefully before they
> commit any financial resources to implementing a software system that
> requires checks be turned off.  I'd say take your money instead to Las
> Vegas: your odds for success are better there."

To the extent that checks are used for catching hardware failures this might
be true, but in practice the runtime checks of Ada are not a well tuned
tool for this purpose, although I have seen programs that work hard to take
more advantage of such checks. For example:

   type My_Boolean is new Boolean;
   for My_Boolean use (2#0101#, 2#1010#);

so that 1 bit errors cannot give valid Boolean values (check and see if your
compiler supports this, it is not required to do so!)

However, to the extent that checks are used to catch programming errors,
I think that I would prefer that a safety critical system NOT depend on
such devices. A programming error in a checks on program may indeed result
in a constraint error, but it may also cause the plane to dive into the sea
without raising a constraint error.

I find the second outcome here unacceptable, so the methodology must simply
prevent such errors completely. Indeed if you look at safety critical
subsets for Ada they often omit exceptions precisely because of this
consideration. After all exceptions make the language and compiler more
complex, and that itself may introduce concerns at the safety critical
level.

Note also that exceptions are a double edged sword. An exception that is
not handled properly can be much worse than no exception at all. If you
have a section of code doing non-critical calculations (e.g. how much
time to wait before showing the movie in the main cabin), it really does
not matter too much if that calculation overflows and shows the movie a
bit early, but if it causes an unhandled exception that wipes out the
entire passenger control system, and turns out all the reading lights
etc. that can be much worse. Even in a safety critical system, there will
be calculations that are relatively unimportant.

For example, a low priority task may cause an overflow. If ignored, an
unimportant result is simply wrong. if not ignored, the handoling of the
exception mayh cause that low priority task to overrun its CPU slice, and
cause chaos elsewhere.

As Ken says, checks are not a magic wand. They are a powerful tool, but
like any tool, subject to abuse. A chain saw with a kickback guard on the
end is definitely a safer tool to use, especially for an amateur, than
one without (something I appreciate while clearing paths through the woods
at my Vermont house), but it does not mean that now the tool is a completely
safe one, and indeed a real expert with a chain saw will often feel that it
is safer to operate without the guard, because then the behavior of the
chainsaw is simpler and more predictable.

Re: Ariane 5 failure

[Keith Thompson]

In <dewar.844518011@schonberg> dewar@schonberg.cs.nyu.edu (Robert Dewar) writes:
> To the extent that checks are used for catching hardware failures this might
> be true, but in practice the runtime checks of Ada are not a well tuned
> tool for this purpose, although I have seen programs that work hard to take
> more advantage of such checks. For example:
> 
>    type My_Boolean is new Boolean;
>    for My_Boolean use (2#0101#, 2#1010#);
> 
> so that 1 bit errors cannot give valid Boolean values (check and see if your
> compiler supports this, it is not required to do so!)

But then there's still no guarantee that an invalid Boolean value will
be detected.  The code generated for an if statement, for example, is
unlikely to check its Boolean condition for validity.

Of course, there will probably be a runtime call to a routine that
converts from My_Boolean to Boolean, and this routine will *probably*
do something sensible (raise Program_Error) for an invalid argument.

Anyone something this tricky presumably is already examining the generated
code to make sure there are no surprises.

-- 
Keith Thompson (The_Other_Keith) kst@thomsoft.com <*>
TeleSoft^H^H^H^H^H^H^H^H Alsys^H^H^H^H^H Thomson Software Products
10251 Vista Sorrento Parkway, Suite 300, San Diego, CA, USA, 92121-2706
FIJAGDWOL

Re: Bullet-Proof or Bullet-Resistant (Was Ariane 5 failure)

[Alan Brain]

Robert Dewar wrote:

> However, to the extent that checks are used to catch programming errors,
> I think that I would prefer that a safety critical system NOT depend on
> such devices. A programming error in a checks on program may indeed result
> in a constraint error, but it may also cause the plane to dive into the sea
> without raising a constraint error.

A good point. Unless you use multiple exception handlers at all levels
of the program, it might be better to leave the bug to fester. I guess
you've really got to know what you're doing. Fortunately the concept of
making sure exceptions are trapped everywhere is simple.
 
> I find the second outcome here unacceptable, so the methodology must simply
> prevent such errors completely. Indeed if you look at safety critical
> subsets for Ada they often omit exceptions precisely because of this
> consideration. After all exceptions make the language and compiler more
> complex, and that itself may introduce concerns at the safety critical
> level.

I don't believe in bug-free code. Even if it is bug-free, there's always
the miniscule chance of hardware and soft failures. Now I'm not saying
that error-trapping will save you every time from every failure: but a
"layered defence" of 40 layers, each of which only catches 50% of
errors, is one heck of a lot more effective than one layer that works
99.99999% of the time. 

> Note also that exceptions are a double edged sword. An exception that is
> not handled properly can be much worse than no exception at all. 

Concur.

> For example, a low priority task may cause an overflow. If ignored, an
> unimportant result is simply wrong. if not ignored, the handoling of the
> exception mayh cause that low priority task to overrun its CPU slice, and
> cause chaos elsewhere.

And not handling it may cause the same thing, or even violate memory
constraints etc. No Handling means no chance of tolerating such an
error: The ability to handle PLUS someone who knows how to use
exceptions means there is such a chance.
 
> As Ken says, checks are not a magic wand. They are a powerful tool, but
> like any tool, subject to abuse.

Concur. My conclusion though is that checks are better than no-checks;
even if the person using them is realtively incompetent. Trouble is, I
only have anecdotal evidence of this, not a proper study.  

----------------------      <> <>    How doth the little Crocodile
| Alan & Carmel Brain|      xxxxx       Improve his shining tail?
| Canberra Australia |  xxxxxHxHxxxxxx _MMMMMMMMM_MMMMMMMMM
---------------------- o OO*O^^^^O*OO o oo     oo oo     oo  
                    By pulling Maerklin Wagons, in 1/220 Scale

Re: Ariane 5 failure

[Ken Garlington]

Robert Dewar wrote:
> 
> I find the second outcome here unacceptable, so the methodology must simply
> prevent such errors completely. Indeed if you look at safety critical
> subsets for Ada they often omit exceptions precisely because of this
> consideration. After all exceptions make the language and compiler more
> complex, and that itself may introduce concerns at the safety critical
> level.

I'm also starting to be convinced, after some anecdotal evidence with the systems
I work, that _suppressing_ checks can also make the compiler more fragile. My guess is
that fewer people in general suppress all checks for most compilers, so those
paths in the compiler that run with checks suppressed are used less often,
and so they have a higher probability of containing bugs. I also suspect that most
vendors do not run their standard tests suites (including ACVCs) with checks
suppressed (how could you, for the part of the test suite that validates exception
raising and handling?), so there's less coverage from that source as well.

I'm not saying that it's dumb to suppress checks (or not suppress checks) for
safety-critical systems. I'm just saying the answer appears to be a lot more
complicated than I thought it was 10 years ago (or even 2 years ago).

-- 
LMTAS - "Our Brand Means Quality"
For more info, see http://www.lmtas.com or http://www.lmco.com

Re: Ariane 5 failure

[Matthew Heaney]

In article <dewar.844518011@schonberg>, dewar@schonberg.cs.nyu.edu (Robert
Dewar) wrote:

>As Ken says, checks are not a magic wand. They are a powerful tool, but
>like any tool, subject to abuse. A chain saw with a kickback guard on the
>end is definitely a safer tool to use, especially for an amateur, than
>one without (something I appreciate while clearing paths through the woods
>at my Vermont house), but it does not mean that now the tool is a completely
>safe one, and indeed a real expert with a chain saw will often feel that it
>is safer to operate without the guard, because then the behavior of the
>chainsaw is simpler and more predictable.

I think we're all in basic agreement.

As you stated, exceptions are only a tool.  They don't replace the need for
(mental) reasoning about the correctness of my program, nor should they be
used to guard against sloppy programming.  Exceptions don't correct the
problem for you, but at least they let you know that a problem exists.

And in spite of all the efforts of the Ariane 5 developers, a problem did
exist, significant enough to cause mission failure.  Don't you think an
exception was justified in this case?

Yes, I agree that there may be times when you don't need any sophisticated
exception handling, and you could safely turn checks off.  But surely there
are important sections of code, say for a critical algorithm, that justify
the use of checks.

Believe me, I would love to write a software system that I knew were
(formally) correct and didn't require run-time checks.  But I am not able
to build that system today.  So what should I do?

Though I may be the most practiced walker of tightropes, I still like
having that safety net underneath me.

-matt

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
mheaney@ni.net
(818) 985-1271

Re: Ariane 5 failure

[Robert Dewar]

Matthew says

"Believe me, I would love to write a software system that I knew were
(formally) correct and didn't require run-time checks.  But I am not able
to build that system today.  So what should I do?"


First of all, I would object to the "formally" and even the word "corect"
here. These are technical terms which relate to, but are not identical with,
the impoortant concept which is reliability.

It *is* possible to write reliable programs, though it is expensive. If you
need to do this, and are not able to do it, then the answer is to investigate
the tools that make this possible, and understand the necessary investment
(which is alarmingly high). Some of these tools are related to correctness,
but that's not the main focus. There are reliable incorect programs and
correct unreliable programs, and what we are interested in is reliability.

For an example of toolsets that help achieve this aim, take a look at the
Praxis tools. There are many other examples of methodologies and tools that
can be used to achieve high reliability. 

Now of course informally we would like to make all programs realiable, but
there is a cost/benefit trade off. For most non-safety critical programming
(but not all), it is simply not cost effective to demand total reliability.

Re: Ariane 5 failure

[Ken Garlington]

Matthew Heaney wrote:
> 
> As you stated, exceptions are only a tool.  They don't replace the need for
> (mental) reasoning about the correctness of my program, nor should they be
> used to guard against sloppy programming.  Exceptions don't correct the
> problem for you, but at least they let you know that a problem exists.
> 
> And in spite of all the efforts of the Ariane 5 developers, a problem did
> exist, significant enough to cause mission failure.  Don't you think an
> exception was justified in this case?

Not necessarily. Keep in mind that an exception _was_ raised -- a predefined 
exception (Operand_Error according to the report). There was sufficient telemetry 
to determine where the error occured (obviously, otherwise we wouldn't know what 
happened!). If the real Ariane 5 trajectory had been tested in an integrated 
laboratory enviroment, then (assuming the environment was realistic enough to 
trigger the problem), the fault would have been seen (and presumably analyzed and 
fixed) prior to launch. So, the issue is not the addition of a user-defined 
exception to find the error -- the issue is the addition of a new exception 
_handler_ to _recover_ from the error in flight.

Assuming that a new exception _handler_ had been added, then it _might_ have made 
a difference. If it did nothing more than the system exception handler (shutting 
down the channel), then the only potential advantage of the exception _handler_ 
might have been to allow fault isolation to happen faster (e.g. if the exception 
were logged in some manner). This assumes that either the exception message was 
sent out with the telemetry, or else the on-board fault logging survived the 
crash. On the other hand, if it had shut down just the alignment function, then 
it might have saved the system. Without more knowledge about the IRS 
architecture, there's no way to say.

> Yes, I agree that there may be times when you don't need any sophisticated
> exception handling, and you could safely turn checks off.  But surely there
> are important sections of code, say for a critical algorithm, that justify
> the use of checks.
> 
> Believe me, I would love to write a software system that I knew were
> (formally) correct and didn't require run-time checks.  But I am not able
> to build that system today.  So what should I do?
> 
> Though I may be the most practiced walker of tightropes, I still like
> having that safety net underneath me.

Just make sure that your safety net isn't lying directly on the ground. Without 
the use of a frame (exception handlers that actually do the right thing to 
recover the system), you'll find the landing is just as hard with or without the 
net!

You might also want to make sure that the net isn't suspended so high that you're 
walking _below_ it, or even worse that you hit your head on the net and it knocks 
you off the rope (just to stretch this analogy a bit further). In other words, a 
complex exception handling structure might actually _detract_ from the 
reliability of your system. There is some merit to the Keep It Simple, Stupid 
principle.

> 
> -matt
> 
> --------------------------------------------------------------------
> Matthew Heaney
> Software Development Consultant
> mheaney@ni.net
> (818) 985-1271

-- 
LMTAS - "Our Brand Means Quality"
For more info, see http://www.lmtas.com or http://www.lmco.com

Re: Ariane 5 failure

[Keith Thompson]

In <326506D2.1E40@lmtas.lmco.com> Ken Garlington <garlingtonke@lmtas.lmco.com> writes:
[...]
> Not necessarily. Keep in mind that an exception _was_ raised -- a
> predefined exception (Operand_Error according to the report).

This is one thing that's confused me about this report.  There is no
predefined exception in Ada called Operand_Error.  Either the overflow
raised Constraint_Error (or Numeric_Error if they were using an Ada
83 compiler that doesn't follow AI-00387), or a user-defined exception
called Operand_Error was raised explicitly.

-- 
Keith Thompson (The_Other_Keith) kst@thomsoft.com <*>
TeleSoft^H^H^H^H^H^H^H^H Alsys^H^H^H^H^H Thomson Software Products
10251 Vista Sorrento Parkway, Suite 300, San Diego, CA, USA, 92121-2706
FIJAGDWOL

Re: Ariane 5 failure

[Samuel T. Harris]

Keith Thompson wrote:
> 
> In <326506D2.1E40@lmtas.lmco.com> Ken Garlington <garlingtonke@lmtas.lmco.com> writes:
> [...]
> > Not necessarily. Keep in mind that an exception _was_ raised -- a
> > predefined exception (Operand_Error according to the report).
> 
> This is one thing that's confused me about this report.  There is no
> predefined exception in Ada called Operand_Error.  Either the overflow
> raised Constraint_Error (or Numeric_Error if they were using an Ada
> 83 compiler that doesn't follow AI-00387), or a user-defined exception
> called Operand_Error was raised explicitly.
> 

Remember, the report does NOT state that an unchecked_conversion
was used (as some on this thread have assumed). It only states
a "data conversion from 64-bit floating point to 16-bit signed
integer value". As someone (I forget who) pointed out early
in the thread weeks ago, a standard practice is to scale down
the range of a float value to fit into an integer variable.
This may not have been an unchecked_conversion at all, but
some mathimatical expression.

Whenever software is reused, it must be reverified AND
revalidated. The report cites several reasons for not
reverifying the reuse of the SRI from the Ariane 4. Any
one of which may be justifiable. However, a cardinal rule
of risk management is that any risk to which NO measures
are applied remains a risk. Here they justified their way
into applying no measures at all toward insuring the stuff
would work.

The report also states that the code which contained the
conversion was part of a feature which was now obsolete
for the Ariane 5. It was left in "presumably based on the view that,
unless proven necessary, it was not wise to make changes in software
which worked well on Ariane 4." While this does make good sense,
it is not by any means a verification nor a validation.
It just seems to mitigate your risk, but it really does
no such thing. You can't let such thinking lull you into
a false sense of security.

The analysis which lead to protecting four variables from
Operand_Error and leaving 3 unprotected was not revisited
with the new environment in mind. How could it be since
the Ariane 5 trajectory data was not included as a function
requirement. Hence this measure does not apply to the risk
of the Ariane 5, though some in the decision may have relied
upon it for just that protection.

Then they went as far as not revalidating the SRI in an
Ariane 5 environment, which was the real hurt. While the
report states the Ariane 5 flight data was not included as
a functional requirement, someone should have asked for it
if they needed it. Its omission means any verification testing
which was done would not have taken it into account.
So it would have been verified (which is testing against what
the user said he wanted). However, validation testers (who
test what the user actually wants and are supposed to be
smart enough NOT to take the specification at face value)
should have insisted on such data, included or not.
That's the silly part about the whole affair, validation
testing also was not performed.

The report then goes on to discuss why the SRI's were not
included in a closed-loop test. So even if the Ariane 5
trajectory data had been included as a functional requirement,
it would not have helped. While the technical reasons
cited are appropriate for a verification test, the report
correctly points out that the goals of validation testing
are not so strigently dependent on the fidelity of the test
environment so those reasons just don't justify not having
the SRI's in at least one validation test using Arian 5
trajectory data, especially when other measures have NOT
been taken to insure a compatible reuse of software.

In fact, section 2.1 states "The SRI internal events that
led to the failure have been reproduced by simulation calculations."
I wonder if they compiled and ran the Ada code on another
platform (which is a viable way of doing a lot of testing
for embedded software prior to embedding the software).
The report does not state if such testing was performed
by the developer. If the developer done such testing, then
the Ariane 5 trajectory data would have spotted the flaw.
If such testing was done, someone would have to ask
explicitly for such data.

The end of secion 2.3 summarizes the fact that the reviews
did not pick up the fact that of all potential measures which
could have been applied to determine a compatible reuse of
software into the Ariane 5 operational environment, NONE of
them were actually performed. Which left the reviewers
blissfully ignorant of an unmitigated risk glaring them in
the face.

Of the SRI, I conclude ...

No design error (though it could have done something better).
No programming error (given the design).
An arguable specification error (but without appropriate testing).
A lapse in validation testing (assuming other non-existance measures).
A grave risk management and oversite problem.

Bottom line, a management (both customer and contractor) problem.

The OBC and main computer are another matter entirely.

I've not seen anyone on this thread address the entries
3.1.f and g concerning the SRI sending diagnostic data (item f)
which was interpreted as flight data by the launcher's main
computer (item g). Section 2.1 states the backup failed first and
declared a failure and the OBC could not switch to it because
it already ceased to function. It seems the OBC knew about
the failures, so why did the main computer still interpret
any data from a failed component as flight data.

That seems like a design or programming problem. It is
blind luck that the diagnostic data caused the main computer
to try to correct the trajectory via extreme positions of the
thruster nozzles which caused the rocket to turn sideways
to the air flow which caused buckling in the superstructure
which caused the self-destruct to engage.

Given the design philosophy of the designers, had the main
computer known both SRI had failed, it should have signaled a
self-destruct right then and there. What would have happened
if the "diagnostic" data caused minor course corrections and
brought the rocket over a population area before the subsequent
course or events (or the ground flight controllers themselves)
signaled a self-destruct?

The report does not delve into this aspect of the problem
which I consider to be even more important. This tends to
tell me the SRI simulators in the closed-loop testing which
was performed were not used to check malfunctions, or if
they were, then the test scenarios are incomplete or flawed.

How many other interface/protocol/integration problems
are waiting to crop up? Which reused Arian 4 software component
will fail next? Stay tuned for these and other provocative
questions on "As the Arian Burns" ;)

I wonder how the payload insurance companies will repond with
their pricing for the next couple of launches.

-- 
Samuel T. Harris, Senior Engineer
Hughes Training, Inc. - Houston Operations
2224 Bay Area Blvd. Houston, TX 77058-2099
"If you can make it, We can fake it!"

Re: Ariane 5 failure

[Ken Garlington]

Samuel T. Harris wrote:
> 
> Keith Thompson wrote:
> >
> > In <326506D2.1E40@lmtas.lmco.com> Ken Garlington <garlingtonke@lmtas.lmco.com> writes:
> > [...]
> > > Not necessarily. Keep in mind that an exception _was_ raised -- a
> > > predefined exception (Operand_Error according to the report).
> >
> > This is one thing that's confused me about this report.  There is no
> > predefined exception in Ada called Operand_Error.  Either the overflow
> > raised Constraint_Error (or Numeric_Error if they were using an Ada
> > 83 compiler that doesn't follow AI-00387), or a user-defined exception
> > called Operand_Error was raised explicitly.
> >
> 
> Remember, the report does NOT state that an unchecked_conversion
> was used (as some on this thread have assumed). It only states
> a "data conversion from 64-bit floating point to 16-bit signed
> integer value". As someone (I forget who) pointed out early
> in the thread weeks ago, a standard practice is to scale down
> the range of a float value to fit into an integer variable.
> This may not have been an unchecked_conversion at all, but
> some mathimatical expression.

In fact, I would be very surprised if unchecked_conversion was used.
It wouldn't make much sense to convert from float to fixed using UC.
More than likely, the constraint error/hardware interrupt was raised
due to an overflow of the 16-bit value during the type conversion part
of the scaling equation.

-- 
LMTAS - "Our Brand Means Quality"
For more info, see http://www.lmtas.com or http://www.lmco.com

Re: Ariane 5 failure

[Ken Garlington]

Keith Thompson wrote:
> 
> In <326506D2.1E40@lmtas.lmco.com> Ken Garlington <garlingtonke@lmtas.lmco.com> writes:
> [...]
> > Not necessarily. Keep in mind that an exception _was_ raised -- a
> > predefined exception (Operand_Error according to the report).
> 
> This is one thing that's confused me about this report.  There is no
> predefined exception in Ada called Operand_Error.  Either the overflow
> raised Constraint_Error (or Numeric_Error if they were using an Ada
> 83 compiler that doesn't follow AI-00387), or a user-defined exception
> called Operand_Error was raised explicitly.

It confused me too. I'm guessing that language differences are part of the
answer here, but I have no idea. It's also possible that the CPU hardware
specification has something called an "Operand Error" interrupt which is
generated during an overflow, which I assume gets mapped into Constraint_Error
(as is common with the MIL-STD-1750 CPU, for instance).

I also world be interested in any information about "Operand_Error".

> 
> --
> Keith Thompson (The_Other_Keith) kst@thomsoft.com <*>
> TeleSoft^H^H^H^H^H^H^H^H Alsys^H^H^H^H^H Thomson Software Products
> 10251 Vista Sorrento Parkway, Suite 300, San Diego, CA, USA, 92121-2706
> FIJAGDWOL

-- 
LMTAS - "Our Brand Means Quality"
For more info, see http://www.lmtas.com or http://www.lmco.com

Re: Ariane 5 failure

[robin]

	Ken Garlington <garlingtonke@lmtas.lmco.com> writes:

	>Matthew Heaney wrote:
	>> 
	>> As you stated, exceptions are only a tool.  They don't replace the need for
	>> (mental) reasoning about the correctness of my program, nor should they be
	>> used to guard against sloppy programming.  Exceptions don't correct the
	>> problem for you, but at least they let you know that a problem exists.
	>> 
	>> And in spite of all the efforts of the Ariane 5 developers, a problem did
	>> exist, significant enough to cause mission failure.  Don't you think an
	>> exception was justified in this case?

	>Not necessarily. Keep in mind that an exception _was_ raised -- a predefined 
	>exception (Operand_Error according to the report). There was sufficient telemetry 
	>to determine where the error occured (obviously, otherwise we wouldn't know what 
	>happened!). If the real Ariane 5 trajectory had been tested in an integrated 
	>laboratory enviroment, then (assuming the environment was realistic enough to 
	>trigger the problem), the fault would have been seen (and presumably analyzed and 
	>fixed) prior to launch. So, the issue is not the addition of a user-defined 
	>exception to find the error -- the issue is the addition of a new exception 
	>_handler_ to _recover_ from the error in flight.

---The issue was not the addition of a new exception handler.
The issue was that a magnitude check should have been
performed on a conversion from double precision floating
point to 16-bit integer, but it wasn't.
Of course, having an exceptin handler for this specific purpose
would have helped, and should have been included as a fallback.

	>Assuming that a new exception _handler_ had been added, then it _might_ have made 
	>a difference.

You can be absolutely certain that it would have helped.