Re: Ariane 5 - not an exception?

[Ken Garlington <garlingtonke@lmtas.lmco.com>]

++ robin wrote:

[Editing ++robins statement to remove unnecessary words...]

> "A [...] programmer
> experienced with real time systems, would have CHALLENGED
> such a stupid requirement that the computer be shut down by the
> error-handler in the event of a fixed-point overflow.  He would
> have had it changed.
> 
> "I'd go further to say that no experienced [...] programmer
> would have shut down the system as a result of a fixed-point
> overflow.
> 
> "Furthermore, he would have included a check that the value
> did not go out of range;"

I can certainly agree that the absence of a check should have been
challenged, and that the system should have been analyzed to show
that the check was not needed.

However, the report states that the analysis was done. If you're saying
(1) that they should have done the analysis correctly, who can argue with
that? If you're saying (2) that the programmer should have ignored the analysis,
put the check in anyway, and said "Screw you, guys, I'm a [...] programmer
and I know better than you!", well, you might have a point. However, such
an action certainly requires a very brave (or very foolhardy) [...] programmer.

> 
>         >(which
>         >was not necessary at the time of the failure anyway)
> 
> ---what?  The OBC was using the attitude information to
> direct the nozzles.  It was their [the nozzles] sudden change
> that caused the space vehicle to break up, thereby forcing
> the vehicle to self-destruct automatically [that sudden
> change was the result of the OBC interpreting the error
> readout from the shut-down SRI computer as attitide data.]

I had to read the report a few times to catch the jist of this myself.
Although it's confusing, it sounds like the alignment function was
running, but was not providing correction vectors to the SRI output.
Therefore, the alignment function did not have to be executing at all.

This, to me, is very strange. From my limited experience with IRS
alignments, the alignment function shuts down as soon as the IRS moves (or the
alignment is complete), since you can't usually align a moving IRS
without a fixed reference input (like you get on shipboard systems).
The rationale in the report, that keeping the alignment system running
made it easier to realign the SRI close to liftoff, makes some sense.
But it's still an unusual approach.

Translating additional remarks into format appropriate to the
selected newsgroups:

> "This project might well have been written in [a real-time programming
> language], which
> has excellent real-time facilities, including error
> handling, error simulation and validation facilities.
> The language has robust compilers, and experts with many
> years of [real-time language] programming experience.

Of course, just because there are experts in a particular language,
this doesn't mean that all systems written in that language are
written by experts. I don't know the average experience level for
the Ariane V, so there's no way to know in this case...

> "As to [language] facilities, I refer to the statement
> [called SIGNAL in PL/I and RAISE in Ada],
> with which given conditions (errors such as fixed-point
> overflow) can be signalled as if the condition (error)
> actually occurred.
> 
> "This alone would have showed up the deficiency of the
> overall design (that the system would shut itself down for
> fixed-point overflow)."

Of course, the programmer (and tester) must employ these facilities
for them to be useful. If the programmer fails to use these facilities,
or defeats these facilities
(e.g., suppressing the built-in fixed-point overflow checks in Ada),
there's precious little the language can do.

As you noted earlier, the way in which the system handles the exception
is also important. In this case, clearly the exception was handled
inappropriately given the Ariane V environment.

It is also interesting to note one subtle distinction: The designers knew
that fixed-point overflow would shut the system down. They just didn't
believe the specific calculations could overflow. I suspect that, if a
SIGNAL or RAISE statement were inserted in the code, these same engineers
would say, "But you can't reach that statement in practice!" and so their
effect on the analysis might have been irrelevant.

> 
>         >(i.e. given the expected data (Ariane 4 profile)
>         >the handlers are not executed and therefore we
>         >can't prove that all of our code has been
>         >exercised at least once).
> 
> ---But they can be, and shown to be, in [a real-time language] -- the language
> with the right tools -- with the [SIGNAL, RAISE, etc.] statement.  That
> statement leaves an indisputable footprint!

Again, this depends upon the programmer using the statement for it to be
an "indisputable footprint." Some languages, such as Ada, attempt to overcome
this issue by _also_ inserting implicit exception raises for certain events.
However, if the programmer turns these features off, or fails to handle them,
their effect can be blunted.

-- 
LMTAS - "Our Brand Means Quality"