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.9 required=5.0 tests=BAYES_00 autolearn=ham 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: 103376,5ac12f5a60b1bfe X-Google-Attributes: gid103376,public X-Google-Thread: f43e6,5ac12f5a60b1bfe X-Google-Attributes: gidf43e6,public From: rav@goanna.cs.rmit.edu.au (++ robin) Subject: Re: Ariane 5 - not an exception? Date: 1996/08/13 Message-ID: <4up8pi$lvi@goanna.cs.rmit.edu.au> X-Deja-AN: 173859990 expires: 1 November 1996 00:00:00 GMT references: <4t9vdg$jfb@goanna.cs.rmit.edu.au> <4tiu6e$kpm@news2.cais.com> organization: Comp Sci, RMIT, Melbourne, Australia newsgroups: comp.software-eng,comp.lang.ada,comp.lang.pl1 nntp-posting-user: rav Date: 1996-08-13T00:00:00+00:00 List-Id: Richard Riehle writes: >On 29 Jul 1996, Bill Angel wrote: >> I am under the impression that for the US manned spaceflight >> program (to get to the moon) ,an on-board computer that was serving as a >> backup to the primary computer would have been performing its computations >> using completely different software than the primary computer. By >> utilizing this methodology, the same software "glitch" would not halt both >> systems simultaneously. Perhaps a group of software developers could be >> tasked with producing a version of the on-board software for Ariane in a >> different computer language than that used by the primary processor. The >> two processors, running simultaneously, would serve to check each other's >> results with greater independence that they apparently do now. > I have been following this thread with interest. I am no expert on > Ariane, but lack of expertise has not an obstacle to others who have > posted on this topic. > 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. > 2) PL/I > a) There is no PL/I compiler for the 1750A ---Not an obstacle. How was an Ada compiler written for it? > b) Ada is far more suitable for safety-sensitive software than Pl/I ---Nonsense. PL/I has a long (30 years) record in excellent real-time facilities, and with people with experience in error-recovery and fail-soft in routine commercial applications as well as real-time programming. > c) This failure was not a language issue. ---Isn't it? One of the arguments put forward was that an Ada condition couldn't be raised and leave a trace, and that it would be argued that there was no guarantee whether a piece of code was executed. In PL/I, a SIGNAL statement (which can be used for program checkout) leaves a printed record that it was executed. It gives a message that the condition was raised, and comes with line numbers, etc. There is absolutely no doubt that the statement did not execute! > It is a management issue. > Specifically, it is a failure of engineering management. ---There are lots of things for which one can blame management, but the lack of a check for overflow has to come down to the programmer. > d) Given the incorrect specifications against which the program was > designed, the same failure would have occurred in PL/I or any > other language. ---No it wouldn't. The lack of a test for overflow was the problem. But even supposing for a moment that all conversions were checked, then an interrupt handler could be included for fixed-point overflow. This would have trapped any unchecked overflow. A R/T (and even non R/T) PL/I programmer routinely puts in error control. > 3) Turning off the Computer > Not always an incorrect decision in embedded computing. This time > it clearly was. > 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. ---In this case, with simulated inputs, and with SIGNAL statements to check out what happens when an interrupt occurs. If this had been done (routine in PL/I), the effect of an unchecked conversion would have been observed. > 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. > 7) Ada > This is still the best language for doing this kind of system. ---PL/I would be clearly better, as it meets the requirments for audit trails in program and system checkout (in addition to the other facilities that it offers). > 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. ---Scarcely convincing, in view of the failure. > Richard Riehle