Re: Ariane 5 - not an exception?

[john@assen.demon.co.uk (John McCabe)]

Richard Riehle <rriehle@nunic.nu.edu> 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 <john@assen.demon.co.uk>