Re: Ariane 5 - not an exception?

[kurtz@mustang.nrl.navy.mil (Bob Kurtz)]

In article <4tiu6e$kpm@news2.cais.com>, wtangel@cais3.cais.com (Bill
Angel) wrote:

> In article <4t9vdg$jfb@goanna.cs.rmit.edu.au>,
> ++           robin <rav@goanna.cs.rmit.edu.au> wrote:
> >In Ariane, both the active processor and the backup failed at
> >the same time, because it was a *programming* error that was
> >encountered at the same time in both processors, and both
> >processors were shut down at the same time by their respective
> >error handlers.
> 
>         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.
> 
>  -- Bill Angel

A number of people have posted on this topic, about the space shuttle, the
A340, etc.  And I'll admit, there is some value (though expensive) to this
approach.  But...

Very frequently, errors are introduced into large software systems in the
requirements specification and design phases.  These are often problems
that dwarf mere coding errors, and are much more difficult to detect
("Gosh, it all passed unit testing okay...").  The Ariane 501 failure is,
in my opinion, an error of this type.  The root cause of the inertial
navigation system failure was the support for an Ariane 4 alignment
requirement not valid for Ariane 5, along with Ariane 4 trajectory
constraints also not valid for Ariane 5.

This sounds like a serious requirements/design oversight.  It's not clear
that having several developer teams working independently would not result
in two completely different programs that exhibit the same disasterous
behavior.

-- 
Bob Kurtz (kurtz@mustang.nrl.navy.mil)
Hughes STX Corp., US Naval Research Lab, Washington DC