Didier Kryn <kryn@???> writes:
> Le 08/07/2016 15:25, Rainer Weikusat a écrit :
>> 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,
>
> I tell that, for anyone who has a little of experience with Ada,
> the concepts of a 64-bit floating point doesn't exist and the concept
> of a 16-bit integer is only used when dealing with matching with an
> hardware interface,
This is completely besides the point because the above is a description
of the actual events which occurred on the hardware in question which
ultimatively caused the disaster.
> My personnal understanding is this was a total jeopardy: the
> company in charge produced a code in Ada because it was a requirement,
> but they didn't hire a skilled Ada programmer;
[more of this]
As I already pointed out two times: The software behaved exactly
according to its specification,
In the event of any kind of exception, the system specification
stated that: the failure should be indicated on the databus, the
failure context should be stored in an EEPROM memory (which was
recovered and read out for Ariane 501), and finally, the SRI
processor should be shut down.
which could be regarded as deficient. But this has to be taken with a
grain of salt as the software was developed for the predecessor model
(Ariane 4) where the condition which triggered the operand error
couldn't have occurred.
In Ariane 4 flights using the same type of inertial reference
system there has been no such failure because the trajectory
during the first 40 seconds of flight is such that the
particular variable related to horizontal velocity cannot reach,
with an adequate operational margin, a value beyond the limit
present in the software.
But some bonehead decided that "if it ain't broken, don't fix it" and
moved the software as-is to completely different hardware,
[explanation of the purpose of this computer]
The same requirement does not apply to Ariane 5, which has a
different preparation sequence and it was maintained for
commonality reasons, presumably based on the view that, unless
proven necessary, it was not wise to make changes in software
which worked well on Ariane 4.
Where the now useless feature blew up (quite literally) because the
software was used in a scenario it was never designed for.
::
Re: [DNG] Ariane-5 explosion
