Re: Ariane 5 - not an exception?

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

In article <31FE35BC.1A0D@sanders.lockheed.com>
           smoneill@sanders.lockheed.com "Steve O'Neill" writes:

> ++ robin wrote:

> > 2. the choice of language is suspect.  A better-established
> >    language such as PL/I -- specifically designed for
> >    real-time programming -- with robust compilers, and
> >    with its base of experienced programming
> >    staff could well have prevented this disaster.
> 
> I disagree completely!  The language was not the problem the design decisions
>  in how the language was used were.  

It goes further back than that - the requirement specifications were
seriously at fault and incomplete. It was *not* a stated requirement 
that the unit would function correctly on the Ariane 5 trajectory.

An implementation of the algorithms in any language which detects
numerical overflow would have shut down the IRS to comply with spec.

> Ada is completely capable the realm of real-time programming,
>  has robust compilers and tools, and has quite a few experienced 
> software engineers capable of implementing ...

I agree that the language is in the clear.

> Had the designers of the system allowed the implementors to use Ada exception
>  mechanisms fully 
> and properly they could have localized the failure to, at worst, the alignment
>  function (which 
> was not necessary at the time of the failure anyway) without shutting down the
>  entire device.  

This was what surprised me - coming from an environment (not safety critical)
where continued function even if degraded is preferred to hard shutdown.
It seems unduly perverse to guarantee total system failure once an 
untrapped exception occurs. Is it really safer to blow the thing out of
the sky than inject its payload into an inaccurate orbit?

After all the hardware failsafe *will* destroy it automatically 
if the trajectory deviates sufficiently - as happened when the IRS
started feeding the navigation computer diagnostic bit patterns as data.

> Instead, as is common practice in the safety-critical world, local exception
>  handlers are 
> frequently banned and a global 'shut it all down' handler is the only stop gap
>  measure.  

This is an interesting insight.

> Unbelievably the rationale for disallowing local handlers is because they make
>  it difficult to 
> verify complete code coverage since they are only executed in the case of
>  exceptional conditions 

I can see there is a point there, OTOH perhaps there is something wrong
with a test philosophy that don't attempt to push the envelope of valid
data to find what happens if ...
Designing test data to execute each and every path is part of the game.

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