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: 107079,eca28648989efca9 X-Google-Attributes: gid107079,public X-Google-Thread: 103376,885dab3998d28a4 X-Google-Attributes: gid103376,public X-Google-Thread: 101deb,885dab3998d28a4 X-Google-Attributes: gid101deb,public X-Google-Thread: f74ae,eca28648989efca9 X-Google-Attributes: gidf74ae,public From: Ken Garlington Subject: Re: Ariane 5 failure Date: 1996/10/01 Message-ID: <3251319E.E41@lmtas.lmco.com>#1/1 X-Deja-AN: 186530602 references: <52a572$9kk@goanna.cs.rmit.edu.au> <52bm1c$gvn@rational.rational.com> <1780E8471.KUNNE@frcpn11.in2p3.fr> <1780FB1E3.KUNNE@frcpn11.in2p3.fr> <324F1157.625C@dynamite.com.au> content-type: text/plain; charset=us-ascii organization: Lockheed Martin Tactical Aircraft Systems mime-version: 1.0 newsgroups: sci.astro,sci.math.num-analysis,comp.lang.pl1,comp.lang.ada x-mailer: Mozilla 2.02 (Macintosh; I; 68K) Date: 1996-10-01T00:00:00+00:00 List-Id: Alan Brain wrote: > > 1. Suppressing all checks in Ada-83 makes about a 5% difference in > execution speed, in typical real-time and avionics systems. (For > example, B2 simulator, CSU-90 sonar, COSYS-200 Combat system). If your > hardware budget is this tight, > you'd better not have lives at risk, or a lot of money, as technical > risk is > appallingly high. Actually, I've seen systems where checks make much more than a 5% difference. For example, in a flight control system, checks done in the redundancy management monitor (comparing many redundant inputs in a tight loop) can easily add 10% or more. I have also seen flight-critical systems where 5% is a big deal, and where you can _not_ add a more powerful processor to fix the problem. Flight control software usually exists in a flight control _system_, with system issues of power, cooling, space, etc. to consider. On a missile, these are important issues. You might consider the technical risk "appalingly high," but the fix for that risk can introduce equally dangerous risks in other areas. > 2. If you know the range is 0-100, and you get 101, what does this show? > a) A bug in the code (99.9999....% probable). b) A hardware fault. c) A > soft failure, as in a stray cosmic ray zapping a bit. d) a faulty > analysis of your "can't happen" situation. As in re-use, or where your > array comes from an IO channel with noise on.... You forgot (e) - a failure in the inputs. The range may be calculated, directly or indirectly, from an input to the system. In practice, at least for the systems I'm familiar with, that's usually where the error came from -- either a connector fell off, or some wiring shorted out, or a bird strike took out half of your sensors. I definitely would say that, when we have a failure reported in operation, it's not usually because of a bug in the software for our systems! > Type a) and d) failures should be caught during testing. Most of them. > OK, some of them. Range checking here is a neccessary debugging aid. But > type b) and c) can happen too out in the real world, and if you don't > test for an error early, you often can't recover the situation. Lives or > $ lost. > > Brain's law: > "Software Bugs and Hardware Faults are no excuse for the Program not to > work". Too bad that law can't be enforced :) -- LMTAS - "Our Brand Means Quality"