Papers on the Ariane-5 crash and Design by Contract 
Author Message
 Papers on the Ariane-5 crash and Design by Contract

We have made available on-line the paper that Jean-Marc Jezequel
and I published in the January issue of IEEE Computer about the
June 1996, software-induced $500-million crash of the Ariane 5
mission, and the lessons it holds for software development
--  in particular the role of contracts for reusable software.

The paper can be found by following the "Ariane 5" link at

        http://www.*-*-*.com/

We have used this opportunity to update the technology
paper that summarizes the theory of Design by Contract
( http://www.*-*-*.com/ ).

--
Bertrand Meyer, President, ISE Inc., Santa Barbara (California)

ftp://ftp.eiffel.com
Visit our Web page: http://www.*-*-*.com/
        (including instructions to download Eiffel 4 for Windows)



Wed, 01 Sep 1999 03:00:00 GMT  
 Papers on the Ariane-5 crash and Design by Contract

Thomas says

<<In that note you essentially argue that if only the Ariane 5 software
had used Eiffel preconditions, the rocket would not have crashed.
You suggest a precondition of the form:>>

Indeed .. anyone can argue that their favorite language, if used properly,
would have avoided the Ariane 5 bug. That's true even for assembly language.

The fact of the matter is that this bug was a result of the approach
used, and had nothing to do with the particular language chosen. Indeed
the Ariane 5 crash serves as a useful reminder that Ada is not some magic
panacea that prevents incompetent design and implementation!



Thu, 02 Sep 1999 03:00:00 GMT  
 Papers on the Ariane-5 crash and Design by Contract

Quote:

>Thomas says

><<In that note you essentially argue that if only the Ariane 5 software
>had used Eiffel preconditions, the rocket would not have crashed.
>You suggest a precondition of the form:>>

>Indeed .. anyone can argue that their favorite language, if used properly,
>would have avoided the Ariane 5 bug. That's true even for assembly language.

>The fact of the matter is that this bug was a result of the approach
>used, and had nothing to do with the particular language chosen. Indeed
>the Ariane 5 crash serves as a useful reminder that Ada is not some magic
>panacea that prevents incompetent design and implementation!

I agree with Robert Dewar.
Please do not start a language war! It is made crystal clear in the paper that
*THIS IS NOT A LANGUAGE PROBLEM*
let me repeat it in case it is not clear:
*THIS IS NOT A LANGUAGE PROBLEM*

Basically, our claim in this paper is that it is a reuse issue (and in a lesser extent, a
system integration test problem).
Reusing a component without a precise specification of it is dangerous.
That the component is written in Ada, Eiffel, C, assembly language has nothing to do with
the way it is specified.

The all point of the paper is that Design by Contract helps in the precise specification
of components: signatures (a la CORBA) are not enough to specify a behavior, pre- and post
conditions are needed to give more details.

I'm willing to discuss this last point, but I will not answer any language issue
in this thread.

Best regards,

--
Jean-Marc Jezequel               Tel : +33 2 99847192        
IRISA/CNRS                       Fax : +33 2 99847171        

F-35042 RENNES (FRANCE)          http://www.irisa.fr/pampa/PROF/jmj.html



Fri, 03 Sep 1999 03:00:00 GMT  
 Papers on the Ariane-5 crash and Design by Contract


Quote:
>What was required here was a simple check that a function argument was
>within a certain range.  That check could have been expressed as an
>Ada type declaration and checked by the compiler at compile time, or
>as a runtime assertion/check.

The whole point of Eiffel is that the assertions are more than just a
run-time check.  In fact the run-time checking is the least important
aspect of Eiffel assertions.  Far more important are the self-documenting
aspects.  This is where Ada misses out: the fatal exception occured
because the limitations were not properly documented.

Quote:
>The design team apparently decided that
>either approach was too costly in terms of design or speed and instead
>opted for leaving the code unsafe and documenting the conditions under
>which the function could be used safely.

They did this by commenting the code, rather than writing it into the
documentation.  Furthermore the exception occured (as I understand it)
because the compiler included explicit range checks in the compiled code,
and the programmers had opted not to include manual range checking and
limiting because of CPU limits.  In other words they had a choice between
checking it once or twice (redundantly), and the single check option had
catastrophic consequences.  The important thing is that neither of these
checks were actually very useful at run-time.  The real cause of the
Arianne 5 failure was the policy that any exception be treated as fatal
while identical software was used on both inertial guidence units.  Hence
any bug that caused an exception would inevitably lead to self-destruction.

In practice, due to the time at which the exception occured it would have
been better to continue processing because the results in question were not
actually being used.  However if they had been in use then its difficult
to see how any kind of run-time checking could have helped: range limiting
only ensures that the wrong results are produced, and this would have been
as fatal as the exception.

[On annotation and documentation]

Quote:
>And if the programmer culture on a project is such that
>they don't use Ada assertions, why would they use Eiffel
>preconditions?

Because Ada assertions don't form part of the documentation.  Eiffel
assertions do.  So by writing one piece of code you get both benefits.

Furthermore the "Eiffel culture" is very different to the "Ada culture".
In Eiffel the external assertions are seen as a key component of the
software, while in Ada they are just an optional extra.

Quote:
>   The exception was due to a floating-point error: a conversion from a
>   64-bit integer to a 16-bit unsigned integer, which should only have
>   been applied to a number less than 2^16, was erroneously applied to a
>   greater number, representing the "horizontal bias" of the flight.
>   There was no explicit exception handler to catch the exception, so it
>   followed the usual fate of uncaught exceptions and crashed the entire
>   software, hence the on-board computers, hence the mission.
>I don't understand these statements at all.

Bertrand is accurately paraphrasing the published report, except for one
point: there was a high-level policy in the Arianne programme that any
exception should cause the shutdown of whatever unit of hardware it
occured in.  The assumption seems to have been that the software was
perfect, and so any exception must indicate a hardware flaw.  Therefore
the correct thing to do with an exception is to shut down and let the
backup unit take over.  Unfortunately the backup in this case was running
exactly the same software and was receiving basically the same data.
Hence they crashed within a fraction of a second of each other.

There was no exception handler: the exception error message was actually
dumped onto the system bus and interpreted by the guidance mechanism as
real data.  This would have probably destroyed the rocket anyway, but
the fact that both inertial sensors went permanently down made it
inevitable.

Paul.

--
Paul Johnson            | GEC-Marconi Ltd is not responsible for my opinions. |
+44 1245 242244         +-----------+-----------------------------------------+




Fri, 03 Sep 1999 03:00:00 GMT  
 Papers on the Ariane-5 crash and Design by Contract

Quote:

> convert (horizontal_bias: INTEGER): INTEGER is
>             require
>                   horizontal_bias <= Maximum_bias
>             do
>                   ...

>             ensure
>                   ...

>             end

> What was required here was a simple check that a function argument was
> within a certain range.  That check could have been expressed as an
> Ada type declaration and checked by the compiler at compile time, or
> as a runtime assertion/check.  The design team apparently decided that
> either approach was too costly in terms of design or speed and instead
> opted for leaving the code unsafe and documenting the conditions under
> which the function could be used safely.  Also, they apparently did
> not have a practice of annotating their code with assertion statements
> for testing, and you suggest that they didn't have a standard
> practice for documenting unchecked preconditions.

> I don't see how the different notation that Eiffel uses for the same
> purpose helps.  Eiffel's conditions are also enforced either at
> compile time or at runtime, and exactly the same tradeoffs apply as
> they do in the Ada program: you incur costs for type conversions and
> range checks.  And if the programmer culture on a project is such that
> they don't use Ada assertions, why would they use Eiffel
> preconditions?

Eiffel does type checking at compile time. You can check type at runtime
but the need to do this is such that you should query if you write code
that uses this feature.

        x ?= y

x will be Void if y does not conform to they type of x.

The point about culture and assertions is an interesting one. I have
moved to a company that uses Eiffel. Initially I was very sceptical
about assertions, for the same reason you are, that I don't see people
using them, or that they remove them when the release the code.

In practice though, you write them because as part of developing
software they make a huge difference to development. This has an effect
in various areas.

1) Documentation. You need less of this. Documentation which say 'This
feature expects this and does that' is no longer need. Documentation
that is needed is the 'intent' of the routine, and high level intent or
overviews. There are tools that can produce what is called the short
form, the code without the implementation built into most compilers.
These will also produce HTML and other outputs.

2) Design. Writting assertions makes design easier. This is a personal
observation and harder to justify. I find being clear about what
something does helps clear up what I am doing. Having complex
preconditions is not a good idea, again you probably don't have the
right structure.

3) Debugging / Testing. Running with assertions enabled detects bugs
earlier. This is the real saver in time and costs.

4) Reviews. If you review code, then having the assertions in place
is very useful. A large part of reviewing C++ is working out what
assertions have been assumed, and checking code against them. Having
them written into the code makes this easier.

There are other more complex parts to Eiffels assertion system, in
relation to inheritance, and soon in relation to parallel processing.

But in conclusion, my experience is that people write assertions in
their code, because it is effective.

--

Nick



Fri, 03 Sep 1999 03:00:00 GMT  
 Papers on the Ariane-5 crash and Design by Contract

<snip irrelevant example on Eiffel assertions>

The problem was with the Requirements flowdown and verification and
with the testing process.

Quote:
>1) Documentation. You need less of this. Documentation which say 'This
>feature expects this and does that' is no longer need. Documentation
>that is needed is the 'intent' of the routine, and high level intent or
>overviews. There are tools that can produce what is called the short
>form, the code without the implementation built into most compilers.
>These will also produce HTML and other outputs.

Self documenting code is the usual standard for most languages in use
today but self documenting code is for documenting the code, not the
design.  Design documentation belongs in a Requirements Flowdown
and Requirements Verification documents and any limits should be
coppied in the Version Description Document.  But the bigger issue is these
documents need to be reviewed for a new application.

Quote:
>2) Design. Writting assertions makes design easier. This is a personal
>observation and harder to justify. I find being clear about what
>something does helps clear up what I am doing. Having complex
>preconditions is not a good idea, again you probably don't have the
>right structure.

The code is going to assert "I will not run correctly in this new rocket?"
The problem was with Exceptions that did not try and recover and
due to ...

Quote:
>3) Debugging / Testing. Running with assertions enabled detects bugs
>earlier. This is the real saver in time and costs.

Not simulated flight was made for the new design so the first flight
was also the first test.  A simulated flight would have found this time
limit and allowed a fix.

Quote:
>4) Reviews. If you review code, then having the assertions in place
>is very useful. A large part of reviewing C++ is working out what
>assertions have been assumed, and checking code against them. Having
>them written into the code makes this easier.

And reviews are where someone says that  the Requirements Flowdown
and Requirements Verification documents have been read and updated  
for the new requirements.  Or where someone mentions a difference in
requirements and someone else says "Oh Sh...".     pardon my French 8-)

Quote:
>There are other more complex parts to Eiffels assertion system, in
>relation to inheritance, and soon in relation to parallel processing.

>But in conclusion, my experience is that people write assertions in
>their code, because it is effective.

Languages cannot review the design and catch this type of a change in
requirements problem.  The only language issue is too much complexity that
prevented someone from seeing this problem.

Designing code for reuse is a difficult and expensive task and
                  May NOT Be Cost Efficve In Many Application !!!!.  
I have seen several books and magazine articles on this though much of it is
about designing out limits such as this.

Richard Kaiser



Fri, 03 Sep 1999 03:00:00 GMT  
 Papers on the Ariane-5 crash and Design by Contract

  > But in conclusion, my experience is that people write assertions in
  > their code, because it is effective.

    How many times do people have to be told that the lack of an
assertion was NOT the problem here.  The assertion existed, and the
deliberate decision, apparently thrashed around in several meetings at
different management levels, was that on Arianne 4, this condition
could only occur through hardware failure.

    The software designers were under no illusions about what would
happen if this constraint was violated, or the conditions under which
that could occur: the rocket could be way off course--which would tend
to indicate a guidance failure, or one part or another of the guidance
system was malfunctioning.

    The real problem was that the software was used unchanged and
without review on Arianne 5, where these assumptions were not true.
The Arianne 5 was much faster off the pad, and although it was
possible to follow a trajectory which would not have run into this
problem the actual trajectory did exceed the (built-in, appropriate
for Arianne 4) limits.

--

                                        Robert I. Eachus

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



Fri, 03 Sep 1999 03:00:00 GMT  
 Papers on the Ariane-5 crash and Design by Contract

<..snip..>

Quote:
>I think the lesson to be learned from this is that projects should
>choose hardware that is sufficiently powerful to let the software
>engineers implement their software without making dangerous
>compromises and without having to spend a lot of their time on
>worrying about how to squeeze complex algorithms into inadequate
>hardware.  With more powerful hardware, you don't have to disable the
>runtime checks in a language like Ada in the first place, and you can
>afford to add adequate exception handling code.  While on a rocket
>every gram and watt counts, we are talking maybe 10-20% more memory
>and performance.  More powerful hardware might also have permitted a
>simpler, more easily tested and maintained design overall.

That's far easier said than done. It's not necessarily cost/power/mass
that's the problem with computers used in the space industry, it's
availability of radiation tolerant or hardened processors and memory
and so on. Memory is generally too much of a problem, you can easily
get hold of Radiation Tolerant memories from Harris and Honeywell or
MHS, however hardly any microprocessor manufacturers build devices
specifically for the space industry, and those that do generally don't
build very fast devices.

The most commonly used device in the european space industry at the
moment is the GPS MA31750 (probably), a MIL-STD-1750 implementation
that runs at 10MHz and gives a performance of 1.3 MIPS. It is,
however, available radiation hardened. 200MHz Pentium Pros are not.

Quote:
>Of course, those hardware costs might have been noticeable, resulting
>in either lower payload or noticeably higher overall project costs.
>But if you want your rockets to fall out of the sky less often, that's
>the price you have to pay.

Given a higher performance version of the same processor, the extra
hardware costs are unlikely to be significant, the MA31750 we've been
using costs aroun $13000 (Thir{*filter*} Thousand Dollars - 1.3 MIPS, 10MHz
- Value for money?), and 8kx8 RAMs are around $2500 a piece. However
as I said, in the Space Industry, you are probably using the highest
performance device available to you anyway so cost is irrelevant
(unless of course you want to use hundreds of millions of dollars of
project money to package and qualify a new processor!).

Best Regards



Fri, 03 Sep 1999 03:00:00 GMT  
 Papers on the Ariane-5 crash and Design by Contract

Quote:

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

Where?

Quote:
> [...] 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.

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

Successful reuse requires that what you reuse be equipped with a
specification - a contract. That's the point made Jean-Marc Jezequel
and I made in the article at
http://www.eiffel.com/doc/manuals/technology/contract/ariane/index.html.

--
Bertrand Meyer, President, ISE Inc., Santa Barbara (California)

ftp://ftp.eiffel.com
Visit our Web page: http://www.eiffel.com
        (including instructions to download Eiffel 4 for Windows)



Fri, 03 Sep 1999 03:00:00 GMT  
 Papers on the Ariane-5 crash and Design by Contract

Quote:


> >Thomas says

> ><<In that note you essentially argue that if only the Ariane 5 software
> >had used Eiffel preconditions, the rocket would not have crashed.
> >You suggest a precondition of the form:>>

> >Indeed .. anyone can argue that their favorite language, if used properly,
> >would have avoided the Ariane 5 bug. That's true even for assembly language.

> >The fact of the matter is that this bug was a result of the approach
> >used, and had nothing to do with the particular language chosen. Indeed
> >the Ariane 5 crash serves as a useful reminder that Ada is not some magic
> >panacea that prevents incompetent design and implementation!

>  I agree with Robert Dewar.  Please do not start a language war! It

Agreed.  That sort of moronicy is the _last_ thing we need.

Quote:
> is made crystal clear in the paper that
> *THIS IS NOT A LANGUAGE PROBLEM*
> let me repeat it in case it is not clear:
> *THIS IS NOT A LANGUAGE PROBLEM*

Exactly.  And this has been discussed to death and the same
conclusions reached several times.

Quote:
> The all point of the paper is that Design by Contract helps in the
> precise specification of components: signatures (a la CORBA) are not
> enough to specify a behavior, pre- and post conditions are needed to
> give more details.

Yes, CORBA style interface specifications are no help here whatsoever.
None.  Zero.  The problem revolves around explicitly capturing the
semantic context of the "components" so that (re)usage of them will
not go beyond that prescribed scope.  This is non trivial and NO,
repeat NO, programming language currently has more than the most
primitive support for even the most rudimentary aspects required for
this.  While certainly better than nothing, pre and post conditions
should be seen as merely an example of such rudimentary capability.

Quote:
> I'm willing to discuss this last point, but I will not answer any
> language issue in this thread.

Seems reasonable to me.

/Jon
--
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383



Fri, 03 Sep 1999 03:00:00 GMT  
 Papers on the Ariane-5 crash and Design by Contract

Dear gentlemen,
I've missed the original post, and I can't find it with DejaNews.
Would anybody post again it (or tell me if any other archive exists)?

Thanks in advance.

Enrico Facchin

ing. Enrico Facchin - Ufficio Tecnico

****************************************************************************
Sartori Elettronica Telecomunicazioni - tel. 049 772188 - fax 049 772946

http://www.intercity.shiny.it/sartori
Impianti per telecomunicazioni professionali civili e militari.
Forniture per impianti d'antenna di qualsiasi genere.
Laboratorio riparazioni e centro assistenza (Tv sat., tel. cellulare).
****************************************************************************



Fri, 03 Sep 1999 03:00:00 GMT  
 
 [ 358 post ]  Go to page: [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24]

 Relevant Pages 

1. Papers on the Ariane-5 crash and Design by Contract

2. Ariane Crash (Was: Adriane crash)

3. Software Bug crashes European Rocket, Ariane 5.

4. GNAT and Ariane 5 crash

5. Critique of Ariane 5 paper (finally!)

6. Rebuttal to Ariane paper

7. Critique of Ariane 5 paper (finally)

8. Critique of Ariane 5 paper (finally!)

9. Rebuttal to Ariane paper

10. Critique of Ariane 5 paper (finally)

11. Design Automation Conference Seeks Design Papers

12. Design Automation Conference Seeks Design Papers

 

 
Powered by phpBB® Forum Software