Re: Ariane 5 - not an exception?

[Martin Tom Brown <Martin@nezumi.demon.co.uk>]

In article <4tb8vv$bna@zeus.orl.mmc.com>
           rgilbert@unconfigured.xvnews.domain "Bob Gilbert" writes:

> In article <Dv45EJ.8r@fsa.bris.ac.uk>, simonb@pact.srf.ac.uk (Simon Bluck)
>  writes:
> > The Ariane 501 flight failure was due to the raising of an unexpected
> > Ada exception, which was handled by switching off the computer.
> 
> The failure was due to the reuse of software, a software design, and software
> requirements specification which was purposely designed to raise the said
> exception and perform a SRI shutdown should certain limits be exceeded. 

Yes - one can argue about the reasonableness of killing the active SRI
when the backup has already failed. And also about the decision made
during s/w development that out of 7 variables at risk of overflow only
4 were fully protected, and 3 unprotected which were felt not at risk
to keep CPU load inside bounds <80% (for Ariane 4 flight trajectories).

It adds insult to injury that the calculation code which failed was 
only valid when the system was on the *ground* awaiting launch.
It's a very good report and makes interesting reading.

> Unfortunately these limits were well within normal operating budget of the
> Ariane 5, but would be considered a failure (most probably hardware) if 
> encountered on the Ariane 4 from which the software/design/requirements
> were borrowed.
> 
> >  The report on this:
> > 
> >    http://www.esrin.esa.it/htdocs/tidc/Press/Press96/ariane5rep.html
> > 

> The Ariane failure has little or nothing to do with language selection
> or even correct coding.  The software performed exactly as designed.

Again you can question the wisdom of shutting down the active IRS
when the backup is already dead - continuing with best guess data
would have been a marginally better option at that stage. 
The defect is traceable back to the requirements specification, and
the assumption that single point hardware failure is more likely 
than systematic software error in a redundant system.

> The problem resulted in an oversight in the design limitations and
> differences between the Ariane 4 and Ariane 5 systems.  I think the 
> lessons to be learned here are about the reuse of software (especially
> design and requirements) and testing.

The report's recommendations seem generally applicable to a large
number of systems engineering projects with a software component.

Regards,
-- 
Martin Brown  <martin@nezumi.demon.co.uk>     __                CIS: 71651,470
Scientific Software Consultancy             /^,,)__/