From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: fac41,f66d11aeda114c52
X-Google-Attributes: gidfac41,public
X-Google-Thread: 103376,f66d11aeda114c52
X-Google-Attributes: gid103376,public
From: WhiteR@nospamplease.CRPL.Cedar-Rapids.lib.IA.US (Robert S. White)
Subject: Re: Critique of Ariane 5 paper (finally!)
Date: 1997/08/22
Message-ID: <5til7i$boi$1@flood.weeg.uiowa.edu>#1/1
X-Deja-AN: 267799200
References: <872172435.980@dejanews.com> <33FC66AD.9A0799D4@calfp.co.uk>
Organization: does hard real time thingys
Newsgroups: comp.lang.ada,comp.lang.eiffel
Date: 1997-08-22T00:00:00+00:00
List-Id: <comp.lang.ada>


In article <33FC66AD.9A0799D4@calfp.co.uk>, nickle@calfp.co.uk says...

>Let us say for the moment that in some circumstances DBC helps.
>For those that have been critising DBC, since DBC is optional, and is an
     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^


  Nobody that I know of on this thread has been "critising DBC"!
What all the furor is about, is the claims that DBC _must_ be
used to create reliable software.  

  Ken, myself, and a few others have been arguing that you can 
not always employ the executable code aspects of DBC (or Ada
run time checks) in hard real time systems with constrained
resources.  

  The other issue is that in the Ariane 5 case, the 
methodology that was in place (system requirements review and
software requirements specification), was not followed 
adequately.  To quote the inquiry report once more: 

  "the overriding means of preventing failures are the reviews 
   which are an integral part of the design and qualification 
   process, and which are carried out at all levels and involve 
   all major partners in the project (as well as external 
   experts)"

The Ariane 4 IRS software as-is reuse should not have made it
by such reviews.  Please read Ken's rebuttal paper:

  http://www.progsoc.uts.edu.au/~geldridg/eiffel/ariane/

  My reading of it does not indicate a general "critising DBC"
but rather it summerizes:

  "In the specific case of the Ariane IRS design fault, there
  is not clear and compelling evidence that DBC/Eiffel 
  assertions were likely to have uncovered the fault prior to 
  operational use, either through their documentation, test, 
  or execution value. Furthermore, alternative means were 
  available to the Ariane team to isolate the particular 
  fault, even without the use of DBC/Eiffel. Therefore, 
  although there may be a compelling claim to use DBC/Eiffel 
  in real-time safety-critical systems, the Ariane case 
  (and the Eiffel paper describing this case) does not 
  support such a claim."

  My complaint is against the claim in the Eiffel paper:

  "Does this mean that the [Ariane 5] crash would 
  automatically have been avoided had the mission used 
  a language and method supporting built-in assertions 
  and Design by Contract? Although it is always risky 
  to draw such after-the-fact conclusions, the answer 
  is probably yes..."
     ^^^^^^^^^^^^

    I say, IMO, probably no for the Ariane 5 case.  But I
think it is a "good thing" to use assertions and/or a DBC
methodology whenever practical.  Unfortunately, IME, it is
often not practical for resource constrained hard real time
systems.  
_____________________________________________________________________
Robert S. White         -- An embedded systems software engineer