Re: Ariane 5 - not an exception?

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

++ robin wrote:
> 
>         simonb@pact.srf.ac.uk (Simon Bluck) writes:
> 
>         >The Ariane 501 flight failure was due to the raising of an unexpected
>         >Ada exception,
> 
> ---An exception, yes, but not unexpected.
> 
>    The programming mistake made was in assuming that a
> floating-point value of some 58 significant bits would
> somehow "fit" into a 15-bit integer.

Actually, you have values much larger than 58 significant bits
fit into a 15-bit (or 16-bit) integer. You just have to throw
out enough precision!

>    There was no check that the data conversion would not
> result in overflow, so the problem went to the error
> handler, which shut down the system.

This is certainly true.

> ---To continue in this case probably would need the value to
> be set to the maximum. And it wouldn't be corrupt data.

No. But it might still generate an incorrect vector to the flight
controls, which would still have crashed the vehicle. It's just that
the IRS would be spewing data right up to that last "hard landing."

> There are other better approaches.  One is to continue
> with the maximum value; another is to avoid the use of
> a 16-bit variable, and to use a variable as the same
> size and type (here floating-point storage),
> thus avoiding the problem altogether.

Not always easy to do. Do much MIL-STD-1553 processing between
dissimilar CPUs?

> ---This is more of a lack of communication between the two
> programs.  Another design error.

Actually, the amount of communication between a primary and a
backup system is another tough system problem. We went through
this on the F-16. In general, the backup shouldn't trust state
data from the primary, since this can create a common mode failure.
On the other hand, with _no_ state data, the backup may be unable
to take over from the primary. Add to this the desire to keep the
backup software identical to the primary, to reduce the amount of
unique software to analyze and test, and it's a non-trivial thought
process.

> ---I think the real lessons are that
> 1. real-time programming requires special expertise.

Amen to this. Safety-critical real-time programming even more so.

> 2. the choice of language is suspect.  A better-established
>    language such as PL/I -- specifically designed for
>    real-time programming -- with robust compilers, and
>    with its base of experienced programming
>    staff could well have prevented this disaster.

Every claim you just made for PL/I can amply be made for Ada.

Am I using anything you've built in PL/I?

-- 
LMTAS - "Our Brand Means Quality"