Re: Safety-critical development in Ada and Eiffel

[WhiteR@nospamplease.CRPL.Cedar-Rapids.lib.IA.US (Robert S. White)]

In article <33D9B8F9.4693018C@munich.netsurf.de>, 
joachim.durchholz@munich.netsurf.de says...

>Plus the assertion themselves will take time to check, which influences
>timing.
>I'm not in the hard real-time business (and have never been), so I might
>be grossly off the mark. What I currently think is that no harm should
>result if the code runs faster after disabling assertion checking. (Some
>informed people in this group have claimed otherwise, but I haven't seen
>convincing arguments why this should be the case.)

  I hope you never have to do safety-critical hard real-time programming
with more than a very few tasks running.  You have never hear of a 
deadlock?  Race condition?  Sure you try to design to avoid such things,
but you can never be sure that you have really successsfully avoided
all timing sensitivities until you _test_ for them!  The cold HARD rule
is that if the machine code changes, then regression tests _must_ be 
done.

>
>Checking assertions (in the Eiffel sense) must not have observable
>effects, except that the program may run slower (or similar irrelevant
>differences). There are some style guidelines and hard rules that
>enforce this.

  Not a suitable guard for hard real-time!  Just what is the protection
mechanism for this "must not"?  Who validates Eiffel compiler object 
code to not have any "observable effect" when release code turns off
assertion checks?

>The possibility to switch off assertion checking without
>affecting the program's semantics is an *axiom* in Eiffel; the language
>and the guidelines go to great lengths to achieve this.

  But it has not convinced me that it (assertions one during 
development, off later for the released version) are suitable for 
hard real-time without doing a set of regression tests that would expose
timing sensistivity problems.  The FAA with DO-178B would be very unhappy
that all of the object code paths are not thoroughly tested in the final
released code version.
_____________________________________________________________________
Robert S. White         -- An embedded systems software engineer