Re: Ariane 5 - not an exception?

[rav@goanna.cs.rmit.edu.au (++ robin)]

	Richard Riehle <rriehle@nunic.nu.edu> 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