Re: Papers on the Ariane-5 crash and Design by Contract

[eachus@spectre.mitre.org (Robert I. Eachus)]

   I said:

   >     How many times do people have to be told that the lack of an
   > assertion was NOT the problem here.  The assertion existed

In article <332DA14C.41C67EA6@eiffel.com> Bertrand Meyer <bertrand@eiffel.com> writes:

   > Where?

   In lots of places, including the code.  The assertion was quite
clear, as was the run-time action: out of range data here indicates a
hardware failure.  Switch to the other processor, run the diagnostics
and send the data down the telemetry channel.

  Let me interrupt for a second.  There has been a lot of discussion
about the fact that this condition was not "handled" correctly in the
code.  But the assertion was there, it was detected by the compiler
that this condition could not be ruled out at compile time, and the
software engineers suggested a "better" way to deal with it.  It is
only at this point that the error handling becomes an issue.  But the
compilers and other development tools, AND their users made no silly
mistakes or omissions.

  The software was explicit, and the compiler diagnostics essentially
said: "Rocket can crash here."  Whether to change this was
debated--look at the report--by several layers of management, and in
the end five of seven such issues were closed by adding local handlers
in the code.  Two, including this one, were closed with a proof that
if the software detected that condition, it indicated a hardware flaw.
This was perfectly correct--on the Arianne 4.

  The fact that the hardware "switched to the other computer" and
resulted in diagnotic data going to the engine actuators was extremely
bad hardware design, but that is not the issue here.

   (I said:) 

   > [...] The real problem was that the software was used unchanged and
   > without review [from Ariane 4 to] Ariane 5, where these assumptions
   > were not true.

  (Back to Bertrand:)

  > The real problem was that the assertion was not part of the software.

  However, the assertion was implicit and explicitly in the code.  But
that was not where this reuse went wrong...

  > Successful reuse requires that what you reuse be equipped with a
  > specification - a contract.

  Exactly.  Good specifications existed, but no one was ever tasked to
see if there were any conflicts between the specification of the
Ariane 5, and the specifications of the Ariane 4 guidance software.
This was not a "one-line" miss.  There were pages and pages on the
float to integer conversion issue, and volumes on running the
alignment software after liftoff.  (Including the fact that this
capability had been used on at least one Ariane 4 launch.)

  My guess is that tasking one software or systems engineer to do such
a review would have found the problem--and resulted in a much more
thorough requirements scrub!

  By the way, even worse was the fact that the Ariane 4 software
designers were told they had no "need-to-know" the Ariane 5 specs when
designing the system for the Ariane 4.  I'm sure if they had been
allowed to see the Ariane 5 specs, the specs would have been used as
"ammunition" in the local handler debate.

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...