Re: Ariane 5 failure

[lou@alumnae.caltech.edu (Louis K. Scheffer)]

KUNNE@frcpn11.in2p3.fr (Ronald Kunne) writes:

>The problem of constructing bug-free real-time software seems to me
>a trade-off between safety and speed of execution (and maybe available
>memory?). In other words: including tests on array boundaries might
>make the code saver, but also slower.
> 
>Comments?

True in this case, but not in the way you might expect.  The software group
decided that they wanted the guidance computers to be no more than 80 percent 
busy.  Range checking ALL the variables took too much time, so they analyzed 
the situation and only checked those that might overflow.  In the Ariane 4,
this particular variable could not overflow unless the trajectory was wildly 
off, so they left out the range checking.

I think you could make a good case for range checking in the Ariane
software making it less safe, rather than more safe.  The only reason they
check for overflow is to find hardware errors - since the software is designed
to not overflow, then any overflow must be because of a hardware problem, so
if any processor detects an overflow it shuts down.  So on the one hand, each
additional range check increases the odds of catching a hardware error before
it does damage, but increases the odds that a processor shuts down while it
could still be delivering useful data. (Say the overflow occurs while 
computing unimportant results, as on the Ariane 5).   Given the relative
odds of hardware and software errors, it's not at all obvious to me that
range checking helps at all in this case!

The real problem is that they did not re-examine this software for the Ariane 5.If they had eitehr simulated it, or examined it closely, they would probably
have found this problem.
   -Lou Scheffer