Python from Wise Guy's Viewpoint
cezary at nodomain.invalid
Mon Nov 3 17:55:02 CET 2003
On 10/20/2003 5:49 AM, Kenny Tilton wrote:
> Dennis Lee Bieber wrote:
>> Just check the archives for comp.lang.ada and Ariane-5.
>> Short version: The software performed correctly, to
>> specification (including the failure mode) -- ON THE ARIANE 4 FOR
>> WHICH IT WAS DESIGNED.
> Nonsense. From: http://www.sp.ph.ic.ac.uk/Cluster/report.html
> "The internal SRI software exception was caused during execution of a
> data conversion from 64-bit floating point to 16-bit signed integer
>> LISP wouldn't have helped -- since the A-4 code was supposed
>> to failure with values that large... And would have done the same
>> thing if plugged in the A-5. (Or are you proposing that the A-4 code
>> is supposed to ignore a performance requirement?)
> "supposed to" fail? chya. This was nothing more than an unhandled
> exception crashing the sytem and its identical backup. Other conversions
> were protected so they could handle things intelligently, this bad boy
> went unguarded. Note also that the code functionality was pre-ignition
> only, so there is no way they were thinking that a cool way to abort the
> flight would be to leave a program exception unhandled.
> What happened (aside from an unnecessary chunk of code running
> increasing risk to no good end) is that the extra power of the A5 caused
> oscillations greater than those seen in the A4. Those greater
> oscillations took the 64-bit float beyond what would fit in the 16-bit
> int. kablam. Operand Error. This is not a system saying "whoa, out of
> range, abort".
"To determine the vulnerability of unprotected code, an analysis was performed
on every operation which could give rise to an exception, including an Operand
Error. [...] It is important to note that the decision to protect certain
variables but not others was taken jointly by project partners at several
"There is no evidence that any trajectory data were used to analyse the
behaviour of the unprotected variables, and it is even more important to note
that it was jointly agreed not to include the Ariane 5 trajectory data in the
SRI requirements and specification."
"It was the decision to cease the processor operation which finally proved
fatal. Restart is not feasible since attitude is too difficult to re-calculate
after a processor shutdown; therefore the Inertial Reference System becomes
useless. The reason behind this drastic action lies in the culture within the
Ariane programme of only addressing random hardware failures. From this point of
view exception - or error - handling mechanisms are designed for a random
hardware failure which can quite rationally be handled by a backup system."
> As for Lisp not helping:
"It has been stated to the Board that not all the conversions were protected
because a maximum workload target of 80% had been set for the SRI computer"
More information about the Python-list