From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 101deb,12d7915e86ce849c X-Google-Attributes: gid101deb,public X-Google-Thread: 103376,5f645669103080a8 X-Google-Attributes: gid103376,public X-Google-Thread: 12b42c,12d7915e86ce849c X-Google-Attributes: gid12b42c,public From: john@assen.demon.co.uk (John McCabe) Subject: Re: Ariane Crash (Was: Adriane crash) Date: 1996/07/29 Message-ID: <838663243.4334.0@assen.demon.co.uk>#1/1 X-Deja-AN: 170881223 x-nntp-posting-host: assen.demon.co.uk references: <838316030.18052.0@assen.demon.co.uk> <4ta1vu$m1u@goanna.cs.rmit.edu.au> newsgroups: comp.lang.ada,comp.lang.pl1,rmit.cs.100 Date: 1996-07-29T00:00:00+00:00 List-Id: 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