Re: Ariane 5 failure

[Steve O'Neill <smoneill@sanders.lockheed.com>]

@@ robin wrote:
> ---Definitely not.  No floating-point overflow occurred.  In
> Ariane 5, the overflow occurred on converting a double-precision
> (some 56 bits?) floating-point to a 16-bit integer (15
> significant bits).
> 
>    That's why it was so important to have a check that the
> conversion couldn't overflow!
> Agreed.  Yes, the basic reason for the destruction of a billion dollar 
vehicle was for want of a couple of lines of code.  But it relects a 
systemic problem much more damaging than what language was used.

I would have expected that in a mission/safety critical application 
the proper checks would have been implemented, no matter what. And in a 
'belts-and-suspenders' mode I would also expect an exception handler to 
take care of unforeseen possibilities at the lowest possible level and 
raise things to a higher level only when absolutely necessary.  Had these 
precautions been taken there would probably be lots of entries in an 
error log but the satellites would now be orbiting.  

As outsiders we can only second guess as to why this approach was not 
taken but the review board implies that 1) the SRI software developers 
had an 80% max utilization requirement and 2) careful consideration 
(including faulty assumptions) was used in deciding what to protect and 
not protect.

>It was designed to shut down if any interrupt occurred.  It wasn't                                       ^^^^^^^^^ exception, actually
>intended to be shut down for a routine thing as a conversion of 
>floating-point to integer.

This was based on the (faulty) system-wide assumption that any exception 
was the result of a random hardware failure.  This is related to the 
other faulty assumption that "software should be considered correct until 
is proven to be at fault".  But that's what the specification said.

> ---No, the backup SRI experienced the programming error (UNCHECKED
> CONVERSION from floating-point to integer) first, and shut itself
> down, then the active SRI computer experienced the same programming
> error, then it shut itself down.

Yes, according to the report the backup died first (by 0.05 seconds).  
Probably not as a result of an unchecked_conversion though - the source 
and target are of different sizes which would not be allowed.  Most 
likely just a conversion of a float to an sixteen-bit integer.  This 
would have raised a Constraint_Error (or Operand_Error in this 
environment).  This error could have been handled within the context of 
this procedure (and the mission continued) but obviously was not.  
Instead it appears to have been propagated to a global exception handler 
which performed the specified actions admirably.  Unfortunately these 
included committing suicide and, in doing so, dooming the mission.

-- 
Steve O'Neill                      | "No,no,no, don't tug on that!
Sanders, A Lockheed Martin Company |  You never know what it might
smoneill@sanders.lockheed.com      |  be attached to." 
(603) 885-8774  fax: (603) 885-4071|    Buckaroo Banzai