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: 101deb,f96f757d5586710a X-Google-Attributes: gid101deb,public X-Google-Thread: f43e6,5ac12f5a60b1bfe X-Google-Attributes: gidf43e6,public X-Google-Thread: 103376,5ac12f5a60b1bfe X-Google-Attributes: gid103376,public From: john@assen.demon.co.uk (John McCabe) Subject: Re: Ariane 5 - not an exception? Date: 1996/08/05 Message-ID: <839266818.26317.1@assen.demon.co.uk>#1/1 X-Deja-AN: 172266046 x-nntp-posting-host: assen.demon.co.uk references: <4t9vdg$jfb@goanna.cs.rmit.edu.au> <4tiu6e$kpm@news2.cais.com> newsgroups: comp.software-eng,comp.lang.ada,comp.lang.pl1 Date: 1996-08-05T00:00:00+00:00 List-Id: Richard Riehle wrote: <..snip..> > 1) redundant processors > The idea of using different processor architectures is a good > one and often employed for other systems such as the Boeing 777. > However, if I recall correctly, Ariane has a "rad-hard" requirement > (right or wrong) and uses Mil-Std 1750A processors to satisfy that > requirement. This would not permit using multiple processors of > differing architectures. As far as I know, from a much earlier post, Ariane 5 used 68000 series processors. I don't see why it should have a rad-hard requirement, but even then that should not enforce the use of MIL-STD-1750A processors, as there are a number of alternatives e.g. 8086, RTX2010, and some versions of the ADSP2100 are apparently rad-tolerant. Even if MIL-STD-1750 processors were necessary, there is more than one rad-hard version produced. However, I don't really think that it is the processor architecture itself that is a issue, more the system architecture as it is possible to design completely differet systems round a single processor to do the same job. > 2) Pl/I <..snip..> > c) This failure was not a language issue. It is a management issue. > Specifically, it is a failure of engineering management. > d) Given the incorrect specifications against which the program was > designed, the same failure would have occurred in Pl/I or any > other language. Exactly. > 3) Turning off the Computer > Not always an incorrect decision in embedded computing. This time > it clearly was. It sounds to me like not enough analysis was performed to make a reasonable judgement on whether computer shutdown was sensible in this case. It obviously was not sensible in this case because there was a comon-mode failure of both SRIs. > 4) Software Reuse > If one intends to "reuse" software, such as Ariane 4xx software in > Ariane 5xxx, in a significantly different architecture, there is some > virtue in extensive testing. Exactly. And even more virtue in correctly analysing and specifying the requirements. > 5) Unchecked Conversion > Ada practitioners have been preaching for years that this should not > be done without substantial examination and testing. One more example > of why unchecked_conversion is usually not a good idea. Sometimes it > is unavoidable, I know. Mmm. Despite the language used in the report, I don't think it was the Ada feature Unchecked_Conversion that was involved here, merely that a conversion from float to integer was used. Unchecked_Conversion wouldn't be used to convert a 64bit float into a 16bit integer by anyone unless they were really stupid. > 6) Exception Handling > Anyone remember C.A.R Hoare's Turing Lecture? Not me. Any more information on it? > 7) Ada > This is still the best language for doing this kind of system. But > stupid management is something no programming language can change. > Given other engineering constraints on this project, Ada is really > the only reasonable language to choose. Or PL/I :-) Only joking! Best Regards John McCabe