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: 103376,5ac12f5a60b1bfe
X-Google-Attributes: gid103376,public
X-Google-Thread: 101deb,f96f757d5586710a
X-Google-Attributes: gid101deb,public
X-Google-Thread: f43e6,5ac12f5a60b1bfe
X-Google-Attributes: gidf43e6,public
From: Richard Riehle <rriehle@nunic.nu.edu>
Subject: Re: Ariane 5 - not an exception?
Date: 1996/08/04
Message-ID: <Pine.GSO.3.92.960804145456.23377A-100000@nunic.nu.edu>#1/1
X-Deja-AN: 172073624
references: <Dv45EJ.8r@fsa.bris.ac.uk> <4t9vdg$jfb@goanna.cs.rmit.edu.au>
 <4tiu6e$kpm@news2.cais.com>
content-type: TEXT/PLAIN; charset=US-ASCII
organization: National University, San Diego
mime-version: 1.0
newsgroups: comp.software-eng,comp.lang.ada,comp.lang.pl1
Date: 1996-08-04T00:00:00+00:00
List-Id: <comp.lang.ada>


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

     b) Ada is far more suitable for safety-sensitive software than Pl/I

     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.


  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.

  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.

  6) Exception Handling

     Anyone remember C.A.R Hoare's Turing Lecture?

  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.


   Richard Riehle