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=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: ffc1e,a48e5b99425d742a X-Google-Attributes: gidffc1e,public X-Google-Thread: fac41,a48e5b99425d742a X-Google-Attributes: gidfac41,public X-Google-Thread: 103376,a48e5b99425d742a X-Google-Attributes: gid103376,public X-Google-Thread: 1108a1,5da92b52f6784b63 X-Google-Attributes: gid1108a1,public X-Google-Thread: 107d55,a48e5b99425d742a X-Google-Attributes: gid107d55,public X-Google-Thread: f43e6,a48e5b99425d742a X-Google-Attributes: gidf43e6,public From: peb@transcontech.co.uk ("Paul E. Bennett") Subject: Re: Papers on the Ariane-5 crash and Design by Contract Date: 1997/03/21 Message-ID: <858904941snz@transcontech.co.uk>#1/1 X-Deja-AN: 227125551 References: <332B5495.167EB0E7@eiffel.com> X-Mail2News-User: peb@transcontech.co.uk X-Mail2News-Path: tcontec.demon.co.uk Organization: Transport Control Technology Ltd. Reply-To: peb@transcontech.co.uk Newsgroups: comp.lang.eiffel,comp.object,comp.software-eng,comp.programming.threads,comp.lang.ada,comp.lang.java.tech Date: 1997-03-21T00:00:00+00:00 List-Id: In article nouser@nohost.nodomain "Thomas" writes: > In article <332d95c9.1004852@news.demon.co.uk> john@assen.demon.co.uk (John > McCabe) writes: > > >I think the lesson to be learned from this is that projects should > >choose hardware that is sufficiently powerful to let the software > >engineers implement their software without making dangerous > >compromises and without having to spend a lot of their time on > >worrying about how to squeeze complex algorithms into inadequate > >hardware. > > That's far easier said than done. It's not necessarily cost/power/mass > that's the problem with computers used in the space industry, it's > availability of radiation tolerant or hardened processors and memory > and so on. Memory is generally too much of a problem, you can easily > get hold of Radiation Tolerant memories from Harris and Honeywell or > MHS, however hardly any microprocessor manufacturers build devices > specifically for the space industry, and those that do generally don't > build very fast devices. > > Thanks for pointing this out. I realize that using more powerful > hardware must have been a difficult choice for various reasons, > otherwise it would have been done. After all, the people working > on the project were experienced professionals. > > Given a higher performance version of the same processor, the extra > hardware costs are unlikely to be significant, the MA31750 we've been > using costs aroun $13000 (Thirteen Thousand Dollars - 1.3 MIPS, 10MHz > - Value for money?), and 8kx8 RAMs are around $2500 a piece. For such a slow processor at that clock speed, they could have made a better selection of device and had at least 10 times the performance for the same clock speed. Other benefits are really low power, very cool running and (oh yes) rad-hard (more or less as standard). NASA have a load of them but maybe Harris might be persuaded to make some more. If you persuade them to make some more please send me a few more too. The device? .... The RTX2000. > Well, what if a lot more money had been budgeted for hardware? Could > the space agency have paid the processor manufacturers to come out > with a version that was 30% faster (that should have been sufficient > to use runtime checks everywhere without changing the design)? > Another option could have been to add more individual processors and > use them in parallel (almost certainly harder than it sounds, but > still a possibility). Or what about choosing a less ambitious flight > trajectory and maybe lower payload so that control required less > computation? The option you did not mention, of course, was a much better basic design of processor which is able to check it's own operation. There have been a number of experiments on this line and some of the techniques are well worth consideration. > Of course, none of those would have been easy choices to make. Design > by contract and other methodologies are useful, but I still think > without a solid foundation of runtime checks in the production code > and multiple exception handlers and recovery blocks, no methodology > alone is going to give sufficient protection from failure. In fact, > Eiffel itself, which has been mentioned here because of its assertion > system, is built on a foundation of runtime safety. > > It's good to hear from someone in the industry, by the way; thanks > for participating. Whatever language you use for producing the eventual machine instructions the best "defensive programming" techniques should always be used. Such defenses need rigorous "assault withstand" testing to prove they will work every time. However, getting back to the original thread, it was obvious that within the design process certain verification steps must have been missed out from consideration. This left critical elements of the systems functionality in potential (and finally actual) jeopardy. In ordinary engineering the phrase "measure three times - cut once" is often brought to mind when some critical dimension has to be acheived without wasting precious material. In systems development we could paraphrase that as "test three times - release once" correctly!. -- Paul E. Bennett Transport Control Technology Ltd. +44 (0)117-9499861 Going Forth Safely