Re: Ariane Failure

["John Roth" <johnroth@ameritech.net>]

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in
message news:a8s7nu$ibo$1@nh.pace.co.uk...
> "Dennis Lee Bieber" <wlfraed@ix.netcom.com> wrote in message
> news:a8oo51$tsk$2@slb2.atl.mindspring.net...
> >
> >         I do have to confess to having only the general explanation
of the
> > problem, not details of the code internals -- it does sound, from a
quick
> > perusal of this message thread, that some sort of overflow in
integer
> > processing occurred. This is new to me; the general report tended to
the
> > concept that the measured rates were accurate, but exceeded what the
> > Ariane IV code deemed proper, and attempts to correct this "faulty
rate"
> > led to vehicle instability...
> >
> Yes and no. The report was clearly not written by software guys since
it
> otherwise would have explained in more accurate terms exactly what
happened
> at the software level. Hence, you kind of have to read between the
lines and
> interpret it some from the perspective of a more generalized
engineer's
> view.

I think the technical report went into more detail. However, this
particular thread got started by a post that referenced an article which
claimed that if the implementers had used Eifel with Design by Contract,
the problem would not have occured.

This is patently absurd. The proximate cause, as several posters
have pointed out, was the failure to recertify and test a component
designed for one rocket for use with a different rocket with different
characteristics.

Drilling deeper, the next level cause was attempting to do too much
function for a given combination of processor / language. This caused
performance-motivated shortcuts in the implementation.

Thus the 'solution' would have been to use a processor with higher
performance, or a language with less overhead. Pursuing this path,
we come to the inescapable conclusion that the problem would
not have occured if the implementors had used either Assembler
or Forth!

> The software module in question was originally analyzed on Ariane 4
with a
> veiw toward improving speed. They had a shortage of CPU cycles and had
> identified this one module as a major consumer of resources. They
changed
> the code to eliminate all the range checking and other "safety
features"
> (not at all uncommon in this business) in order to speed it up. This
was not
> without analysis that examined the possible valid ranges for various
numbers
> and mathematically reasoning about it & coming to the conclusion that
any
> values that would possibly generate a hardware overflow error could
not be
> in the valid flight path of the Ariane 4 - hence it was likely to be a
> sensor failure and the proper accommodation would be to transfer
control to
> the other channel. The ISR for that overflow error did just that. So
the
> design was valid and correct for the Ariane 4.
>
> The problem for Ariane 5 was that nobody tested or checked the
assumptions
> on the software intended to run on a different rocket. Had they run
the unit
> through the flight profile, they would have spotted the error in a
cocaine
> heartbeat.
>
> MDC
> --
> Marin David Condic
> Senior Software Engineer
> Pace Micro Technology Americas    www.pacemicro.com
> Enabling the digital revolution
> e-Mail:    marin.condic@pacemicro.com

John Roth

>