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: 101deb,885dab3998d28a4 X-Google-Attributes: gid101deb,public X-Google-Thread: 103376,885dab3998d28a4 X-Google-Attributes: gid103376,public X-Google-Thread: f74ae,eca28648989efca9 X-Google-Attributes: gidf74ae,public From: Ken Garlington Subject: Re: Ariane 5 failure Date: 1996/09/28 Message-ID: <324D0486.7C20@lmtas.lmco.com>#1/1 X-Deja-AN: 185848356 references: <52a572$9kk@goanna.cs.rmit.edu.au> <52bm1c$gvn@rational.rational.com> <1780E8471.KUNNE@frcpn11.in2p3.fr> <324C8405.F8B@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-09-28T00:00:00+00:00 List-Id: Alan Brain wrote: > > Ronald Kunne wrote: > > > 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? > > Bug-free software is not a reasonable criterion for success in a > safety-critical system, IMHO. A good program should meet the > requirements for safety etc despite bugs. An OK statement for a fail-safe system. How do you propose to implement this theory for a fail-operate system, particularly if there are system constraints on weight, etc. that preclude hardware backups? > Also despite hardware > failures, soft failures, and so on. A system which will always meet its requirements despite any combination of failures is in the same regime as the perpetual motion system. If you build one, you'll probably make a lot of money, so go to it! > A really good safety-critical > program should be remarkably difficult to de-bug, as the only way you > know it's got a major problem is by examining the error log, and > calculating that it's performance is below theoretical expectations. > And if it runs too slow, many times in the real-world you can spend 2 > years of development time and many megabucks kludging the software, or > wait 12 months and get the new 400 Mhz chip instead of your current 133. I really need to change jobs. It sounds so much simpler to build software for ground-based PCs, where you don't have to worry about the weight, power requirements, heat dissipation, physical size, vulnerability to EMI/radiation/salt fog/temperature/etc. of your system. -- LMTAS - "Our Brand Means Quality"