Re: Ariane 5 Failure - Summary Report

[john@assen.demon.co.uk (John McCabe)]

Ken Garlington <garlingtonke@lmtas.lmco.com> wrote:

>Alan Brain wrote:
>> 
>> Thirdly, assuming either of the above, not checking that an arithmetic operation of
>> this kind before it's fully complete is just plain silly. And such a check is un
>> morceau de gateaux. This is an implementation fault.

>It's a question of perception. If a system designer says, "Don't add this check," and
>I as an implementer don't add this check (possibly only after asking the designer,
>"Are you _sure_"?), is this a design or an implementation fault?

>It appears to me, from reading the report, that the lack of a check was an intentional
>_design_ decision, not just something that was required but inadvertantly left out of
>the code. I consider this a design fault (if not a specification fault).

I agree entirely, the rest of this article is my response to a similar
comment in a similar thread, but I thought it may interest people who
missed the other thread through a spelling error (Adriane crash).

rav@goanna.cs.rmit.edu.au (++           robin) wrote:

>	john@assen.demon.co.uk (John McCabe) writes:

>	>JOINT ESA/CNES PRESS RELEASE N  33-96  -  Paris, 23 July 1996

>	>Ariane 501 - Presentation of Inquiry Board report

>	>-------------------------------------------------------------------

>	>Hope this is useful. So basically it _was_ a software fault

>---Is this a euphemism for a programming error?  because that's
>what it was -- a programming error.

Having read the report, I don't consider it to be a programming error,
it was a design and management error. It sounds like whoever designed
the system didn't pay enough attention to the requirements, and
whoever was managing it didn't pay enough attention to its conformance
to the requirements.

I think the fact that the overflow occurred was not due to a
programming oversight, after all the analyses had been done and a
decision to not check that variable had been made (*see additional
note below), but seeing as that variable should not have been in use
at that point, I don't think you can blame whoever wrote that code.

>   The error was in assuming that a value would not overflow.
>The specific error was that a conversion of a double-precision
>floating-point value (~58 significant bits) to 15 significant
>bits caused fixed-point overflow.  The conversion was not
>checked for overflow.  It should have been.  This is, after all,
>a real-time system.  It's a fundamental check that a programmer
>experienced in real-time systems should have carried out.

>   Control was then passed to the interrupt handler, which
>shut down the system.

>   The question is, basically, why was Ada used for this work?

ESA Ada preference/mandate(?).

<..snip..>

*Note: I hope this makes ESA llok a bit closer at why they want to
limit processor loading and how the margin should be reduced through
the design and development phases. My own project has an ESA enforced
limit of 70% which is quite ridiculous given the equipment we're using
(GPS MA31750 10MHz MIL-STD-1750 processor). We cannot meet that but
have requested a waiver on that - I believe that's much better than
compromising the safety of the mission.

ESA's loading margins are really supposed to take account of a
requirement for future modifications to software once it has been
delivered. There's no way this should have been enforced for Ariane 5.


From the sound of the report,I think a pretty poor job has been done,
not by the programmers who wrote the code and performed the analysis
of what variables could safely be left unchecked, instead I think
whoever performed the requirement analysis and all levels of
management / reviewers above that havebeen completely negligent.

Best Regards
John McCabe <john@assen.demon.co.uk>


Best Regards
John McCabe <john@assen.demon.co.uk>