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: f74ae,eca28648989efca9 X-Google-Attributes: gidf74ae,public X-Google-Thread: 101deb,885dab3998d28a4 X-Google-Attributes: gid101deb,public X-Google-Thread: 103376,885dab3998d28a4 X-Google-Attributes: gid103376,public X-Google-Thread: 107079,eca28648989efca9 X-Google-Attributes: gid107079,public From: lou@alumnae.caltech.edu (Louis K. Scheffer) Subject: Re: Ariane 5 failure Date: 1996/09/29 Message-ID: <52l667$c8r@gap.cco.caltech.edu>#1/1 X-Deja-AN: 185988791 distribution: inet references: <52a572$9kk@goanna.cs.rmit.edu.au> <52bm1c$gvn@rational.rational.com> <1780E8471.KUNNE@frcpn11.in2p3.fr> organization: California Institute of Technology, Pasadena newsgroups: sci.astro,sci.math.num-analysis,comp.lang.pl1,comp.lang.ada Date: 1996-09-29T00:00:00+00:00 List-Id: KUNNE@frcpn11.in2p3.fr (Ronald Kunne) writes: >The problem of constructing bug-free real-time software seems to me >a trade-off between safety and speed of execution (and maybe available >memory?). In other words: including tests on array boundaries might >make the code saver, but also slower. > >Comments? True in this case, but not in the way you might expect. The software group decided that they wanted the guidance computers to be no more than 80 percent busy. Range checking ALL the variables took too much time, so they analyzed the situation and only checked those that might overflow. In the Ariane 4, this particular variable could not overflow unless the trajectory was wildly off, so they left out the range checking. I think you could make a good case for range checking in the Ariane software making it less safe, rather than more safe. The only reason they check for overflow is to find hardware errors - since the software is designed to not overflow, then any overflow must be because of a hardware problem, so if any processor detects an overflow it shuts down. So on the one hand, each additional range check increases the odds of catching a hardware error before it does damage, but increases the odds that a processor shuts down while it could still be delivering useful data. (Say the overflow occurs while computing unimportant results, as on the Ariane 5). Given the relative odds of hardware and software errors, it's not at all obvious to me that range checking helps at all in this case! The real problem is that they did not re-examine this software for the Ariane 5.If they had eitehr simulated it, or examined it closely, they would probably have found this problem. -Lou Scheffer