Python from Wise Guy's Viewpoint

[CezaryB]

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 
contractual levels."

"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"



CB