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: ffc1e,a48e5b99425d742a X-Google-Attributes: gidffc1e,public X-Google-Thread: fac41,a48e5b99425d742a X-Google-Attributes: gidfac41,public X-Google-Thread: 107d55,a48e5b99425d742a X-Google-Attributes: gid107d55,public X-Google-Thread: f43e6,a48e5b99425d742a X-Google-Attributes: gidf43e6,public X-Google-Thread: 103376,a48e5b99425d742a X-Google-Attributes: gid103376,public X-Google-Thread: 1108a1,5da92b52f6784b63 X-Google-Attributes: gid1108a1,public From: john@assen.demon.co.uk (John McCabe) Subject: Re: Papers on the Ariane-5 crash and Design by Contract Date: 1997/03/20 Message-ID: <33307a43.1705970@news.demon.co.uk>#1/1 X-Deja-AN: 226832961 X-NNTP-Posting-Host: assen.demon.co.uk References: <332B5495.167EB0E7@eiffel.com> <332d95c9.1004852@news.demon.co.uk> Newsgroups: comp.lang.eiffel,comp.object,comp.software-eng,comp.programming.threads,comp.lang.ada,comp.lang.java.tech Date: 1997-03-20T00:00:00+00:00 List-Id: nouser@nohost.nodomain (Thomas) wrote: >Well, what if a lot more money had been budgeted for hardware? The bid would probably never have been accepted. >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)? The European Space Agency has been funding a lot of development work over the years, effectively the GPS MA31750 was funded by ESA, and look at the performance that has produced (as I mentioned before 1.3MIPS @ 10MHz for the I iteration). When we first looked at using the MA31750, GPS data books spoke of a 22Mhz version (the JMA31750), but that was never built. We then found out that the latest version available was the G Iteration which, while specced at 10MHz, didn't work at >6MHz. We then looked at the H which was again specced at 10MHz but didn't work properly above 8! We finally used the I version which was specced at 10MHz, and almost worked at that speed apart from a few data dependent instructions (which didn't work at any speed!). So again, it's not as simple as it looks. ESA's thrust now is on a project called ERC32 (see the ESA web pages at http://www.estec.esa.nl/ (I think)), which is basically a Rad-Hard Sparc chipset being developed by the French company MHS. It is very powerful compared to any previous attempts at using up-to-date technology in space (at least Rad-Hard technology anyway), but because of this uses a lot of watts! >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? You would of course increase cost and power consumption in this way, and also complexity, however, I'm not so sure about that being harder than it sounds, there's a lot of this technique about these days**. A lot more thought would have to have gone into it to repartition the functionality of the system, but this would probably have been a very good thing to do anyway by the sounds of the original ESA/CNES report. **The system I have just finished working on uses 1 microprocessor and 2 ASICs. One of the ASICs is very complex and includes a 1553 protocol handler and a DMA controller interfacing with the processor. That functionality could have been implemented by another microprocessor except we had certain restrictions that made that impossible. >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. I am a bit unhappy with the way the paper has been written. As I mentioned in another posting on this thread, the fundamental problem was that the developers did not have Ariane 5 trajectory data to work with. It was apparently "agreed at various contractual levels" that this would not be provided, so using the Ariane 5 failure as a demonstration of how useful Eiffel's assertions (or even Design by Contract possibly) could have helped is fundamentally flawed! >It's good to hear from someone in the industry, by the way; thanks >for participating. You're welcome, I'm happy to be contributing. Best Regards John McCabe