Re: Would You Fly an Airplane with a Linux-Based Control System?

["Alexander E. Kopilovich" <aek@VB1162.spb.edu>]

Mike Silva wrote:

> A small but, I think, important correction.  The hardware at the
> center of the failure was apparently built around the Motorola
> 68020/68881 chips, not the MIL-STD-1750.  The "Operand Error" that
> triggered the failure is a hardware exception generated by the FPU
> when, among other conditions, a float-to-integer conversion exceeds
> the capacity of the integer, exactly as occurred.  The reason this is
> important is because it shows that the exception was not generated by
> the Ada compiler code but by the hardware, and would therefore have
> occurred regardless of the programming language used.  If that's the
> case then the "it wouldn't have exploded if it were written in C"
> argument evaporates, unless they want to argue that the exception
> handler behavior would have been specified differently if the
> implementation language was C -- not likely!

I think that the fact that the chain of events was initiated by FPU exception
really deserves to be mentioned. Therefore I'm going to update my own
Ariane 5 FAQ appropriately. Currently, 8th Q-A pair of it reads as follows:

----------------------------------------------------------------------------

Q. Can you explain in several words what was the actual cause of the launch
failure, technically?

A. There are several points which are different for Ariane 5 vs. Ariane 4,
one of which was instrumental to the events: Ariane 4 is a vertical launch
vehicle where as Ariane 5 is slightly tilted.
  Ariane 4 software was developed to tolerate certain amount of inclination
but not as much as required by Ariane 5. The chain of events were as follows:

- The on-board software detects that one of the accelerometers is out of range,
this was interpreted as hardware error and caused the backup processor to take
over;
- The backup processor also detects that one of the accelerometers is out of
range (the same way), which caused the system to advice an auto destruction.

----------------------------------------------------------------------------

It seems that the following modification of the description of the chain of
events takes your suggestion into account:

----------------------------------------------------------------------------

- The on-board software detects that one of the accelerometers is out of
range (actually, there was FPU exception generated when float-to-integer 
conversion exceeded the capacity of the integer), this was interpreted as
hardware error and caused the backup processor to take over;
- The backup processor also detects that one of the accelerometers is out of
range (the same way), which caused the system to advice an auto destruction.

----------------------------------------------------------------------------

Do you agree that this addition is enough there? Or particular processor
model is of some importance also?





Alexander Kopilovich                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia