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: 103376,3d3f20d31be1c33a
X-Google-Attributes: gid103376,public
From: "Marin David Condic, 561.796.8997, M/S 731-96" <condicma@PWFL.COM>
Subject: Re: Safety-critical development in Ada and Eiffel
Date: 1997/07/18
Message-ID: <97071809230923@psavax.pwfl.com>#1/1
X-Deja-AN: 257556157
Sender: Ada programming language <INFO-ADA@LISTSERV.NODAK.EDU>
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
X-Vms-To: SMTP%"INFO-ADA@VM1.NODAK.EDU"
Newsgroups: comp.lang.ada
X-Vms-Cc: CONDIC
Date: 1997-07-18T00:00:00+00:00
List-Id: <comp.lang.ada>


Nick Leaton <nickle@CALFP.CO.UK> writes:
>Separate point. One of the valid objections that has been raised with
>assertions is question of execution time being different with them on
>from when they are off.
>
>>From other posters, it seems that with life critical systems (avionics)
>that this is an important consideration. Am I the only one who finds
>this worrying, that systems you have to trust depend on some calculation
>as to how the program is going to run? What happens if a new compiler
>comes out that has a different optimisation technique?
>
    With lots of embedded systems, you're running near the limits of
    processor speed. This is especially true of deep space systems
    where the environment limits you to a very small set of processors
    & memory devices which are of very old design and run *real* slow
    in comparison to what is available today. Hence, you turn off all
    the runtime checks because you simply can't afford them. You
    compensate for this by careful software design and very rigorous
    testing across every condition you can imagine (or until the
    budget runs out or the schedule is shot ;-)

    Typically, when a critical computer such as an engine control or a
    navigation computer reaches the point where you're ready to go to
    flight certification, you freeze the compiler version. (Usually, a
    long time before you go for certification because you're
    verification can't be done against a moving target.) The compiler
    version (and a bunch of other stuff) is frozen for exactly the
    concern you express: "What if something were to change the code
    that is output when we recompile module X?"

    I don't know of any systems that are capable of enabling/disabling
    runtime checks dynamically, so if you compiled the code to perform
    the checks and it ran within its time budget, cool. If you can't
    run with checks enabled, you compile the code that way and it's
    not going to change in flight, so it won't suddenly and
    inexplicably jump up it's CPU utilization.

    With all these sort of systems, you shoot for a highly predictable
    performance behavior and it's not that hard to achieve if your
    execution model is appropriate. So relax - we won't accidentally
    shut down your critical flight control computer by uploading new
    code to it via Internet/Java scripts. :-)

    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
===============================================================================
    "A government that is big enough to give you all you want is big
    enough to take it all away."
        --  Barry Goldwater
===============================================================================