Re: Not intended for use in medical,

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

To: J. Florio et al.
From: Bob Leif, Ph.D.(RCL)

My (RCL) experience has been predominantly with clinical laboratory
instrumentation. A power-out or even an exception that locked up an
instrument in many instruments was not a major hazard.  Bad data or
incorrect assignment of the data to the wrong sample (patient) are major
hazards.  Of course, cessation of operation of a pacemaker or
defibrillators is quite a different story.

(RCL) Design mistakes can happen in any language. However, if a compiler
can "pass" the validation suite, compile itself, and work for several
reasonably large programs, incorrect code generation though a potential
source of hazards becomes a low probability source of hazards.  Ada type
checking will also help.  This is what I meant by significant evidence.

At this point, I start worrying about all of the other items that have a
much higher probability of going wrong. My one theological discovery is
that Murphy, the law giver, is the patron saint of computers including
software.

I (RCL) might also add to the annoyance of many of the readers of
Comp.Lang.Ada, realistically, if the choice is between C++ and Ada for a
medical device, one should not limit Ada to a safe subset.  Compared to
C++, all of Ada is a safe subset.  However, if one has a well trained
software engineering group which uses Ada, then the benefits of a safe
subset should be considered.  Simply put, until the manufactures stop
coding pacemakers and other Class III (highest level of hazard) medical
devices in C++, I will do nothing to dissuade a company from using Ada
except to point out the values of compile-time assignment as opposed to
true run-time dispatching.  There evidently is still a problem testing
run-time dispatching.
----------------------------------------------------------------------------
--------------------

(J F) If one could provide such evidence (or prove it) it wouldn't solve the
problem.  What you really need to do is warrent that the program does
what it's supposed to (all the compiler does is convert the instructions
from one form to another -- granted that's an opportunity for additional
errors to be injected).  If you write an instruction to add 2 numbers
and you were supposed to subtract them, the compiler won't save you.

(J F) I would guess you see such disclaimers (opinion on) because the
manufacturer doesn't want to warrent that the hardware itself doesn't
have some insidious little problem (remember the big pentium flap when
they first came out?).  There's more than one or two gates on those
little buggers these days!  Life-critical systems need to worry about
uninterruptable power as well as their "correctness".  There are some
problem domains that have made progress in proving the "correctness" of
the application (e.g. communications), but to my knowledge, most complex
systems that are life critical still focus on rigor in the development
process and test, test , test, test (e.g. space shuttle) as well as
approaches such as redundent systems, voting systems, separately
developed systems, etc.  Do a search for "high availability systems" and
you'll probably come up with a few pointers....

(RCL) Unfortunately, I would scare off virtually all of the possible users.
----------------------------------------------------------------------------
------------------