Re: C.A.R. Hoare on liability

[Mark Biggar <mark.a.biggar@attbi.com>]

Robert Dewar wrote:
> 
> "Robert I. Eachus" <rieachus@attbi.com> wrote in message news:<3D1390D0.7040709@attbi.com>...
> 
> > I agree with the point, but not the example.  For Ariane 4, the analysis
> > was carried out, and whether or not you agree with the final decision
> > for Ariane 4, the decision was well thought out.  The disaster was that
> > the Araine 4 analysis was carried out absent the Ariane 5 requirements
> > for political reasons, and the Ariane 5 requirements analysis was never
> > done.
> 
> I disagree. Here you have a case in the Ariane4 code where a check was being
> made at runtime which had the quality that if the check failed, disaster
> would occur. There are two possibilities
> 
> 1. In the Ariane4 code, it was demonstrated that this check could never fail.
> In that case, the check should not have been there.
> 
> 2. In the Ariane4 code, it was NOT demonstrated that this check could
> never fail. In that case, they were just lucky that no Ariane4 blew up.
> 
> I will repeat. You should NEVER have a runtime check in your code where it
> is the case that failing the check is a more serious situation than not doing
> it at all. Casually putting in checks is very likely to generate such cases.
> 
> My understanding of the Ariane case is that this check was casually put in,
> in other words it was put in WITHOUT any analysis that said this check was
> needed. Deployed code should not have such checks.

No the situation was more complicated then that.  Ariane 4 
had, like most rocket systems, redundant hardware sets each 
with its own, independent sensor set.  Careful analysis 
was done that showed that given the possible flight profiles, 
the only way the code should see an overflow was if the 
sensor suite was packed up and sending bogus data.  The check 
for overflow was thus used to detect hardware problems and 
the exception raised was to notify the upper control code 
that that particular hardware set was offline and to ignore 
it.  Ariane 5 had a very different flight profile including 
much higher accelerations.  So when the software was reused, 
without rechecking the analysis against the new Ariane 5 
flight profile, it saw a real overflow that didn't have 
anything to do with hardware faults, so all the redundent
hardware suites overflowed and threw an exception all at the 
same time.  This put the rocket out of control and I believe 
it was destroyed by the range safety system.

So both the check and the exception were reasonable and 
correct for the Ariane 4 and would not have crashed it.  So it
was reusing the code without redoing the analysis or even 
testing it against the new flight profile that cause the 
problems, not the check in the code.  This problem would have 
arisen regardless of the language used.

--
Mark Biggar
mark.a.biggar@attbi.com