Re: Safety-critical development in Ada and Eiffel

["Marin David Condic, 561.796.8997, M/S 731-96" <condicma@PWFL.COM>]

Ken Garlington <kennieg@FLASH.NET> writes:
>> Depends on the application.  Generally they print an error report, dump
>> stack information to a file, and ask the user to phone the vendor.  Note
>> that I am not proposing this for real-time embedded applications.  However
>> there are safety-critical applications which are not real-time.
>
>True. Furthermore, there are safety-critical real-time applications that
>are not required to be fail-operational. In both cases, I can at least
>see
>the glimmer of hope that assertions might have some value. (However,
>even
>a non-real-time system monitoring a nuclear power plant, for example,
>might
>not want to print out a message saying "phone the vendor, and I hope the
>reactor doesn't go supercritical while you're on hold :)
>
>However, for _at least_ certain classes of safety-critical systems, this
>behavior is completely unacceptable. Unfortunately, most people who
>advocate
>liberal use of exceptions are working on systems where it is quite
>acceptable.
>
    Well, here's one way of dealing with exceptions in a real-time
    safety critical application:

    If you have a control loop executing code, say, every 5mSec,
    sensing some inputs and doing some loop closure, you know by the
    rules of Ada that there are some exception possibilities you can't
    disable. Hence they could be raised by code beyond your control.
    You insert an exception handler in the loop to catch any of these,
    possibly logging them for telemetry (or at least ticking off a
    counter somewhere so you know it happened in lab testing!) then
    allow the loop to restart.

    What you're saying is this: "On pass N everything was fine. On
    pass N+1, something went haywire and interrupted normal execution.
    Because quitting operation is not an acceptable alternative, what
    I'm betting on is that on pass N+2, the problem will clear
    itself."

    This would potentially give you a viable use for raising
    exceptions on the fly. Granted, you wouldn't do this for any sort
    of expected conditions with planned for accommodations, but
    strictly for those sorts of errors that should never occur, but
    might just do so anyway. Your accommodation at that point might be
    something like resetting all of memory to its initial state and
    hoping that the next batch of inputs gets you back to where you
    should be.

    MDC

Marin David Condic, Senior Computer Engineer     ATT:        561.796.8997
Pratt & Whitney GESP, M/S 731-96, P.O.B. 109600  Fax:        561.796.4669
West Palm Beach, FL, 33410-9600                  Internet:   CONDICMA@PWFL.COM
===============================================================================
    "You spend a billion here and a billion there. Sooner or later it
    adds up to real money."
        --  Everett Dirksen
===============================================================================