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: f43e6,5ac12f5a60b1bfe X-Google-Attributes: gidf43e6,public X-Google-Thread: 101deb,87f6968ed41c9df1,start X-Google-Attributes: gid101deb,public X-Google-Thread: 103376,5ac12f5a60b1bfe X-Google-Attributes: gid103376,public From: rav@goanna.cs.rmit.edu.au (++ robin) Subject: Re: Multiple reasons for failure of Ariane 5 (was: Re: Ariane 5 - not an exception?) Date: 1996/07/26 Message-ID: <4ta0iu$kks@goanna.cs.rmit.edu.au>#1/1 X-Deja-AN: 171132173 expires: 1 October 1996 00:00:00 GMT references: organization: Comp Sci, RMIT, Melbourne, Australia newsgroups: comp.software-eng,comp.lang.ada,comp.lang.pl1 nntp-posting-user: rav Date: 1996-07-26T00:00:00+00:00 List-Id: johndoe@zaphod.nosc.mil (Kirk Beitz) writes: >after reading the failure analysis, it seems a little irresponsible to even >hint about the failure of the rocket being based solely on the lack of proper >exception handling. ---The failure of the project was, as the report stated, "ultimately" due to the exception handler which shut down the system (in fact, both the main system and the backup system, since they both experienced the problem at the same time). >yes, it does seem clear that this was the final straw, and one of the heavy >hands from within the report comes down on the initial specification that >exceptions should be handled in such a manner. but there were several >choices made over the course of a long period of development that helped lead >to the situation. ---The basic problem was due to 3 programming errors: 1. Converting from double precision foating-point to integer, without a magnitude check. The conversion was programmed, and lacked the check. 2. assuming that a 58-bit value was going to fit into a 15-bit integer. 3. failure to include an error handler in the immediate routine to trap trivial errors (such as fixed-point overlow), and continuing. The other failures were: 1. failure to simulate the effects of the error arising (can be done easily with PL/I's SIGNAL statement). 2. failure to OBJECT to the stupid design of the error handler, which was to shut down the system. An experienced real-time programmer would have done this. And certainly, a PL/I programmer would have NOT written an error-handler to shut down the system in the event of a fixed-point overflow.