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: 103376,c615e41a65104004 X-Google-Attributes: gid103376,public From: rav@goanna.cs.rmit.edu.au (robin) Subject: Re: Ariane 5 failure (Was: Size code Ada and C) Date: 1998/07/03 Message-ID: <6ng8ua$1jp$1@goanna.cs.rmit.edu.au>#1/1 X-Deja-AN: 368110212 Expires: 2 October 1998 00:00:00 GMT References: <35921271.E51E36DF@aonix.fr> <6mtiv0$9j3@gcsin3.geccs.gecm.com> <6n7jut$al0$1@nnrp1.dejanews.com> <6navqt$shc$1@goanna.cs.rmit.edu.au> <359A53E2.41C6@lanl.gov> Organization: Comp Sci, RMIT University, Melbourne, Australia. NNTP-Posting-User: rav Newsgroups: comp.lang.ada Date: 1998-07-03T00:00:00+00:00 List-Id: William Clodius writes: >robin wrote: >> >> It's never a good idea in a real-time system to >> avoid run-time checks. A run-time check on the magnitude >> would have caught the error and would not have caused >> the total failure of Ariane 5. >> >But an implicit runtime check on the magnitude did catch the error. You're stretching the meaning of run-time check a bit. The report called it an "unchecked conversion". By "run-time check" I mean a specific test in the code. The interrupt was trapped by the OS, which then shut down the SRI computer. > It >was the way the error was handled when caught, by turning off the >computer(s), that caused the Ariane 5 to fail so rapidly. No, it was the unchecked conversion. If the conversion had undergone a magnitude check, the OS would have never shut down the SRI. Any kind of error would cause the SRI computer to shut down. Thus, the programmer should have undertaken every proecaution to ensire that each and every possible cause of an interrupt could not occur. Nevertheless, it was foolosh not to include some fail-safe mechanism to trap any unexpected interrupts. Miss one, and it was sudden death to the mission. > It was not >clear to me that not handling the error in this case would have caused >problems, because the software where the error occurred was intended for >prelaunch (and early launch?) analysis and control and was not clearly >useful for the operation of the system at the time the error occurred >(tens of seconds into launch). >William B. Clodius Phone: (505)-665-9370