Re: Ariane 5 failure

[rav@goanna.cs.rmit.edu.au (@@ robin)]

	molagnon@ifremer.fr (Michel OLAGNON) writes:

	>In article <532k32$r4r@goanna.cs.rmit.edu.au>, rav@goanna.cs.rmit.edu.au (@@           robin) writes:
	>>	john@assen.demon.co.uk (John McCabe) writes:
	>>
	>>	>Just a point for your information. From clari.tw.space:
	>>
	>>	>	 "An inquiry board investigating the explosion concluded in  
	>>	>July that the failure was caused by software design errors in a 
	>>	>guidance system."
	>>
	>>	>Note software DESIGN errors - not programming errors.
	>>
	>>	>Best Regards
	>>	>John McCabe <john@assen.demon.co.uk>
	>>
	>>---If you read the Report, you'll see that that's not the case.
	>>This is what the report says:
	>>
	>>    "* The internal SRI software exception was caused during execution of a
	>>     data conversion from 64-bit floating point to 16-bit signed integer
	>>     value. The floating point number which was converted had a value
	>>     greater than what could be represented by a 16-bit signed integer.
	>>     This resulted in an Operand Error. The data conversion instructions
	>>     (in Ada code) were not protected from causing an Operand Error,
	>>     although other conversions of comparable variables in the same place
	>>     in the code were protected.
	>>
	>>    "In the failure scenario, the primary technical causes are the Operand Error
	>>    when converting the horizontal bias variable BH, and the lack of protection
	>>    of this conversion which caused the SRI computer to stop."
	>>
	>>---As you can see, it's clearly a programming error.  It's a failure
	>>to check for overflow on converting a double precision value to
	>>a 16-bit integer.

	>But if you read a bit further on, it is stated that

	>    The reason why three conversions, including the horizontal bias variable one,
	>    were not protected, is that it was decided that they were physically bounded
	>    or had a wide safety margin (...) The decision was a joint one of the project
	>    partners at various contractual levels.

	>Deciding at various contractual levels is not what one usually means by
	>``programming''. It looks closer to ``design'', IMHO. But, of course, anyone
	>can give any word any meaning.
	>And it might be probable that the action taken in case of protected conversion,
	>and exception, would also have been stop the SRI computer because such a high
	>horizontal bias would have meant that it was broken....

	>| Michel OLAGNON                       email : Michel.Olagnon@ifremer.fr|

But if you read further on ....

   "However, three of the variables were left unprotected. No reference to
    justification of this decision was found directly in the source code. Given
    the large amount of documentation associated with any industrial
    application, the assumption, although agreed, was essentially obscured,
    though not deliberately, from any external review."

.... you'll see that there was no documentation in the code to
explain why these particular 3 (dangerous) conversions  were
left unprotected.  There is the implication that one or more
of them might have been overlooked . . . ..  Don't place
too much reliance on the conclusion of the report, when
the detail is right there in the body of the report.