Re: Ariane 5 failure

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

Alan Brain <aebrain@DYNAMITE.COM.AU> writes:
>more, tolerances. And with diamond-grade Hard Real Time slices, where
>any
>over-run, no matter how slight, means disaster. In this case, Formal
>Proof
>and strict attention to the no of CPU cycles in all possible paths seems
>the only way to go.
>But this leaves you so open to error in all but the simplest, most
>trivial
>tasks, (just the race analysis would be nightmarish) that these slices
>had
>better be a very small part of the task, or the task itself must be very
>simple indeed. Either way, not having much bearing on the vast majority
>
    In my experience with this sort of "Hard Real Time" code, you are
    typically talking about relatively straightforward code - albeit
    difficult to develop. (Ask A. Einstein how long it took him to
    write the "E := M * C**2 ;" function.)

    The parts which typically have hard deadlines tend to be heavy on
    math or data motion and rather light on branching and call chain
    complexity. You want your "worst case" timing to be your nominal
    path and you'd like for it to be easily analyzed and very
    predictable. Usually, it's a relatively small part of the system
    and maybe (MAYBE!) you can turn off runtime checks for just this
    portion of the code, leaving it in for the things which run at a
    lower duty cycle.

    Of course the truly important thing to remember is that compiler
    generated runtime checks are not a panacea. They *may* have helped
    with the Ariane 5, if there was an appropriate accommodation once
    the error was detected. (Think about it. If the accommodation was
    "Shut down the channel and pass control to the other side" {Very
    common in a dual-redundant system} it would have made no
    difference.) But most of the errors I've encountered in realtime
    systems have been of the "logic" variety. ("Gee! We thought 'x'
    was the proper course of action when this condition comes up and
    really it should have been 'y'" or "I didn't know the control
    would go unstable if parameter 'x' would slew across its range
    that quickly!?!?!") Runtime checks aren't ever going to save us
    from that sort of mistake - and those are the ones which show up
    most often. (Unless, of course, you program in C ;-)

    An aside which has something to do with Ada language constructs:
    In most of our work (control systems) it would be far more useful
    for math over/underflows to saturate and continue on, rather than
    raise an exception and halt processing. Ada never defined any
    numeric types with this sort of behavior - and I find it difficult
    to believe that many others in similar embedded applications
    wouldn't also desire this behavior from some predefined floating,
    fixed, and integer types. Of course, the language allows us to
    define our own types and (if there's proper hardware and compiler
    support for dealing with it) efficient "home-brew" solutions can
    be built. Still, it would have seemed appropriate for the language
    designers to have built some direct support for a very common
    embedded need.

    MDC

Marin David Condic, Senior Computer Engineer    ATT:        561.796.8997
M/S 731-96                                      Technet:    796.8997
Pratt & Whitney, GESP                           Fax:        561.796.4669
P.O. Box 109600                                 Internet:   CONDICMA@PWFL.COM
West Palm Beach, FL 33410-9600                  Internet:   CONDIC@FLINET.COM
===============================================================================
    "The speed with which people can change a courtesy into an
    entitlement is awe-inspiring."

        --  Miss Manners, February 8, 1994
===============================================================================