Re: Not intended for use in medical devices

["Robert C. Leif, Ph.D." <rleif@RLEIF.COM>]

To: Prof. Robert Dewar
From: Bob Leif, Ph.D.

There are 3 levels of criticality in medical devices.  I have spent my time
on level 2 devices which were used primarily for clinical laboratory
diagnosis.  The quality of the object code was often checked as a means of
selecting a compiler.  However, I have not observed every line of object
code being scrutinized.  I do believe that a compiler code generation error
could cause a problem.  However, the probability is low, providing one puts
some care into the choice of the compiler and makes sure that it has been
tested. Of course, the easiest way to do this is to acquire a compiler that
has both been previously tested and is used by a highly skilled, vocal group.

On the other side, you mentioned optimizations. This is where I worry.
However, for purposes of performance, optimization is often needed.  I
would suggest that, where possible, Ada compiler manufacturers include the
facility to produce modified Ada source code showing what the compiler did.
 For instance, if an item is removed from a loop or a loop is unrolled,
this can be described in Ada syntax.  If the compiler eliminates uncalled
code, it could show this by annotating the listing including showing a
strike-through or similar marking.  I strongly believe that the software
should be described to humans in a manor easiest for us to understand.

For those interested in this field, I most strongly suggest that you read
Nancy Leveson's book Safeware System Safety and Computers, Addison Wesley,
1995 ISBN 0-201-11972-2. Most of you will agree with her comments on
languages, bottom of page 412 to top page 413.  Prof. Leveson emphasizes
that most mishaps are the result of systems errors. The discussion of the
Arriane rocket on Comp.Lang.Ada was a very good example of this.

One item that has been missing from Comp.Lang.Ada is any information on
device drivers for PC boards, such as analog to digital convertors. I might
add from experience, a systems engineer should consider hardware solutions
for items that are not weight nor power limited nor produced in huge
quantities.  Often, the use of hardware such as direct memory access,
fifos, and timers can greatly simplify a system.
----------------------------------------------------------------------------
-------------------------------
Date:    Sat, 3 May 1997 22:52:08 -0400
From:    Robert Dewar <dewar@MERV.CS.NYU.EDU>
Subject: Re: Not intended for use in medical devices

Robert Leif says

<<I have very strong reservations about reviewing object code.  Although
configuration management tools could be configured to prevent changes in
the object code, I believe that there would be a very strong temptation for
some of the programmers to hand optimize the object code.>>


How can you possibly avoid reviewing object code for safety critical
programs? Certainly I am unaware of any acceptable methodology that
can be used today that avoids reviewing object code. I agree that we
need to develop such techn9ologies, but we are not there yet.

I think the concern about optimizing object code is misplaced. The typical
procedures followed for reviewing object code do not begin to allow for
this kind of optimization, and I have never seen that be a problem. Indeed
usually for safety critical code, a common demand is that the compiler
NOT do any optimization (of course that is not a very well defined
requirement)
----------------------------------------------------------------------------
----------------------------------