comp.lang.ada
 help / color / mirror / Atom feed
From: john@assen.demon.co.uk (John McCabe)
Subject: Re: Ariane Crash (Was: Adriane crash)
Date: 1996/07/29
Date: 1996-07-29T00:00:00+00:00	[thread overview]
Message-ID: <838663243.4334.0@assen.demon.co.uk> (raw)
In-Reply-To: 4ta1vu$m1u@goanna.cs.rmit.edu.au


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>





  parent reply	other threads:[~1996-07-29  0:00 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1996-07-23  0:00 Adriane crash Jerry van Dijk
1996-07-25  0:00 ` Ariane Crash (Was: Adriane crash) John McCabe
1996-07-26  0:00   ` ++           robin
1996-07-29  0:00     ` Bob Gilbert
1996-07-30  0:00       ` ++           robin
1996-07-31  0:00         ` Bob Gilbert
1996-07-31  0:00           ` William Clodius
1996-08-01  0:00           ` ++           robin
1996-08-02  0:00       ` root
1996-07-29  0:00     ` John McCabe [this message]
1996-07-25  0:00 ` Adriane crash Peter Hermann
1996-07-27  0:00   ` Jerry van Dijk
1996-07-25  0:00 ` Steve O'Neill
1996-07-26  0:00 ` David Verrier
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox