Re: Safety-critical development in Ada and Eiffel

[Ken Garlington <kennieg@flash.net>]

Marin David Condic, 561.796.8997, M/S 731-96 wrote:
> 
> Ken Garlington <kennieg@FLASH.NET> writes:
> >> What does this have to do with the problem under discussion?  I agree that
> >> this can happen, but why does the ability to enable and disable assertions
> >> cause any new problems?
> >
> >Because I have seen compilers that generate correct code with one set of
> >compiler options enabled, and a different (incorrect) set with a
> >different
> >set of options enabled. As with the timing issue above, I can do all of
> >my testing with assertions enabled, and have no clue whether or not the
> >code will still work after I disable those assertions (due to a compiler
> >bug). Again, this is a Bad Thing for safety-critical systems.
> >
>     Let me ask a question about the way you work in your environment.
>     I presume you have some group who is responsible for verification
>     of whatever code you produce. Would they find it at all acceptable
>     to change the contents of so much as one bit in an image without
>     requiring some level of reverification of that image?

No.

> 
>     We sort of tolerate *some* change, limited to a set of constants
>     which need to be tuned for engine trim - sometimes overall trim
>     for a type of engine, sometimes trim for a specific engine.
>     (Depends on the project) But even then, the constants are given
>     their own part number and are run through some abbreviated set of
>     tests in the lab before being accepted as safe to send out the
>     door.

Yes. We do the same thing, under the same conditions (in fact, on one
project I
work, the data file contains the expected version of the Pratt engine
software,
so that we can do on-board cross-checking of the environment
consistency!)

> 
>     But the question of changing even a single word in the program
>     image is unacceptable to our test group unless I can guarantee
>     that by changing that word there is no conceivable way of causing
>     the engine to come to harm or otherwise causing the control to
>     malfunction. Since I can't do that, we never change an image in
>     any way without reverification. Hence, verifying with compiler
>     switch X set to "assertions enabled" then recompiling with switch
>     X set to "assertions disabled" and presuming this is O.K. is not
>     an option. Verification for us is also quite expensive and will
>     eventually involve engine test stand time, so doing it twice is
>     not economically viable.

Exactly correct, as I said above.

> 
>     What I'd like to know is if we're unique in this requirement. Your
>     IRS computers are also tasked with mission critical
>     responsibilities and I'd like to get the thumbnail sketch as to
>     what your verification and CM people find acceptable.

Actually, I build flight controls that integrate with IRSs (and engines
:),
but we hold all three organizations to the process you describe. The
IRSs, by the say, are safety-critical on one project I work.

Say hello to Louie Celiberti for me!


> 
>     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
> ===============================================================================