Re: C++ Should not be used for Medical Devices

Re: C++ Should not be used for Medical Devices

[Dr. Robert Leif]

To: Robert Dewar et al.
From: Bob Leif

The quotation below attributed to me was from Jim Chelini
<jchelini@east.alsys.com>
I did not write it; nor do I agree with it. I previously posted my comments
on this subject to this news group. I am glad to see that I can now use
tasking. In fact, the Coulter Onyx successfully used tasking under Alsys
Ada 32 bit for DOS.

R. C. Leif, J. Sara, I. Burgess, M. Kelly, S. B. Leif, and T. Daly, "The
Development of Software in the Ada Language for a Mid-Range Hematology
Analyzer". Tri-Ada '93 340-346 (1993).

 From a marketing point  of view, for most medical products, it is NOT cost
effective to use a true embedded system. What a commercial instrument
developer wants is a pseudo-embedded system. We need the device drivers and
GUI of a standard operating system; but, would like to remove from the
operator the ability to run other programs while he/she runs our
application. I suspect the US DoD has very similar requirements.

Robert Dewar wrote:
----------------------------------------------------------------------------
----------
Date:    Sun, 26 Jan 1997 11:08:57 -0500
From:    Robert Dewar <dewar@MERV.CS.NYU.EDU>
Subject: Re: C++ Should not be used for Medical Devices

Robert Leif said

"When it comes to safety critical software, I would certainly agree with the
use
of Ada. However, I would avoid a number of features including tasking and
dynamic
allocation. In the cases where a life is at risk whether it is a medical
device, aircraft, or a rail system, stick to deterministic constructs.
Once the program has completed elaboration, it should not perform dynamic
operations.  Also, make sure the run-time is developed, documented, and
TESTED to the same degree as the application.  If you don't, you have left
a very large hole in the system."


Robert replies:

Tasking in Ada 95 is deterministic if your compiler implements Annex
D faithfully (be careful to check validation results here, even some
compilers that purport to support Annex D in fact fail some critical
tests -- read the VSR's carefully!)

This means that there is no a priori reason for avoiding tasking in
safety critical software. Of course there may be reasons for avoiding
the additional complexity in the runtime, but this is a reason for
avoiding many things. In fact we are working now on a variant of GNAT
we call GNORT (or GNAT with NO RunTime at all), precisely because the
avoidance of runtime code has advantages.

Similarly dynamic allocation is not necessarily non-deterministic. If
you use the storage pool facility in Ada 95 to control your own use
of dynamic allocation, it may be perfectly safe and provably reliable,
and again, there is no a priori reason to avoid the notion of pointers
in safety critical programs.

----------------------------------------------------------------------------
-------------


Robert C. Leif, Ph.D., PMIAC,
Vice President & Research Director
Ada_Med, A Division of Newport Instruments
Tel. & Fax (619) 582-0437
Please send e-mail to my new address, rleif@rleif.com
Thank you.

Re: C++ Should not be used for Medical Devices

[Dr. Robert Leif]

From: Bob Leif
To: Jim Chelini et al.

You wrote:
----------------------------------------------------------------------------
-----
Date:    Thu, 23 Jan 1997 15:51:01 GMT
From:    Jim Chelini <jchelini@EAST.THOMSOFT.COM>
Subject: Re: C++ Should not be used for Medical Devices

When it comes to safety critical software, I would certainly agree with the
use
of Ada. However, I would avoid a number of features including tasking and
dynamic
allocation. In the cases where a life is at risk whether it is a medical
device, aircraft, or a rail system, stick to deterministic constructs.
Once the program has completed elaboration, it should not perform dynamic
operations.  Also, make sure the run-time is developed, documented, and
TESTED to the same degree as the application.  If you don't, you have left
a very large hole in the system.

This limits some of the more interesting features of the language, but the
goal
is to develop a safe system.
----------------------------------------------------------------------------
---------------------
There are 3 levels of medical devices. My experience is with FDA Class 2
devices.  I have worked with clinical laboratory instrumentation.
Pacemakers are Class 3. The only dynamic feature of Ada I insist upon is
conformant arrays.  The data from my systems can be very large. The size of
the arrays must be set at run time. However, as opposed, to your past
experience, my systems can crash without significant harm!  My major hazard
is producing incorrect data. Our previous systems worked under Alsys Ada
for DOS. Our next target is Windows 95.

I also wish to modify your last statement. My goal is to develop a safer
system.  Since the competing technologies like C++ are really lousy, I do
NOT wish to put constraints on the use of Ada. I believe that you agree
that, if you are going to do real-time (tasking) and dynamic allocation, it
is safer to use Ada '95 then C++, C. SmallTalk, etc.  Please remember in
the real world, safer is where we start.

I just visited the exhibits of a Laboratory Automation Meeting here in San
Diego. Virtually all of the software was in C and C++. How about next year,
the local SigAda with the help of the Ada vendors pay and man a booth
together.

I decided to post this to Comp.Lang.Ada because there are three good
reasons for encouraging the use of Ada for medical devices.

1. It is technically correct.
2. The Ada vendors should start selling to this market.
3. None of us want to take the chance that improperly programmed medical
devices will be used on themselves or their loved ones?

Now, you and Aonix can help medical devices by providing a warning on your
compilers including the one for Windows 95 when the code is forced to do
run-time dispatching. This feature is just too hard to test. Unfortunately,
most medical device programmers are not as talented as many members of this
news group. The second is to provide "Windows 97" and other operating
systems with an inexpensive real-time core written in Ada.  The third is to
make 4 bit Nibbles (Nybbles) a supported data type.  Ada arrays (strings)
of Nibbles are a very good model for the nucleic acid polymers, DNA and RNA.

Yours,
Bob Leif



Robert C. Leif, Ph.D., PMIAC,
Vice President & Research Director
Ada_Med, A Division of Newport Instruments
Tel. & Fax (619) 582-0437
Please send e-mail to my new address, rleif@rleif.com
Thank you.

Re: C++ Should not be used for Medical Devices

[Robert Dewar]

Robert Lief said

"When it comes to safety critical software, I would certainly agree with the
use
of Ada. However, I would avoid a number of features including tasking and
dynamic
allocation. In the cases where a life is at risk whether it is a medical
device, aircraft, or a rail system, stick to deterministic constructs.
Once the program has completed elaboration, it should not perform dynamic
operations.  Also, make sure the run-time is developed, documented, and
TESTED to the same degree as the application.  If you don't, you have left
a very large hole in the system."


Robert replies:

Tasking in Ada 95 is deterministic if your compiler implements Annex
D faithfully (be careful to check validation results here, even some
compilers that purport to support Annex D in fact fail some critical
tests -- read the VSR's carefully!)

This means that there is no a priori reason for avoiding tasking in
safety critical software. Of course there may be reasons for avoiding
the additional complexity in the runtime, but this is a reason for
avoiding many things. In fact we are working now on a variant of GNAT
we call GNORT (or GNAT with NO RunTime at all), precisely because the
avoidance of runtime code has advantages.

Similarly dynamic allocation is not necessarily non-deterministic. If
you use the storage pool facility in Ada 95 to control your own use
of dynamic allocation, it may be perfectly safe and provably reliable,
and again, there is no a priori reason to avoid the notion of pointers
in safety critical programs.

Re: C++ Should not be used for Medical Devices

[Matthew Heaney]

In article <3.0.32.19970125203845.006e91c0@mail.4dcomm.com>, "Dr. Robert
Leif" <rleif@RLEIF.COM> wrote:

Robert, thank you for your cogent points about Ada's suitability for use in
medical devices.

The third is to
>make 4 bit Nibbles (Nybbles) a supported data type.  Ada arrays (strings)
>of Nibbles are a very good model for the nucleic acid polymers, DNA and RNA.

I do that already:

type Nibble is range 0 .. 15;
for Nibble'Size use 4;

type Nibble_Array is array (Positive range <>) of Nibble;
for Nibble_Array'Component_Size use 4;

Or were the values of Nibble type character literals?  If so, let me know
and I'll show you how to declare it that way, too.

Ada: the language for a complex ... medical device!

matt

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271

C++ Should not be used for Medical Devices

[Dr. Robert Leif]

From: Bob Leif, Ph.D.
Vice President Ada_Med

To: Macarthur Drake jr.
Biomedical Engineering
The Cleveland Clinic Foundation

& Readers of Comp.Lang.Ada (Ada programming language)

The best help you can get from Comp.Lang.Ada, where this appeared, is not
how to find the best C++ Debugger; but, the simple statement, Try Ada 95.
What you have demonstrated below is the unpredictability of C++. Take a
look at the warranty on your compiler. Would you use any other
manufacturing tool with that lack of a warranty? Ada compilers are both
validated by the US Government and subjected to very professional criticism
and questioning by this news group.  C and C++ should not be used for
significant medical device programs.  They are a very poor choice for the
education of students who will be employed developing medical devices.

The best general arguments concerning the relative safety of C and its
derivatives versus Ada have been made by others. Please see:

N. G. Leveson (1) states, =93Not only must a language be simple, but it must
encourage the production of simple and understandable programs. Although
careful experimental results are limited, some programming language
features have been found to be particularly prone to error --among them
pointers, control transfers of various kinds, defaults and implicit type
conversions, and global variables. Overloading variable names so that they
are not unique and do not have a single purpose is also dangerous. On the
other hand, the use of languages with static type checking and the use of
guarded commands (ensuring that all possible conditions are accounted for
in conditional statements and that each branch is fully specified as to the
conditions under which it is taken) seem to help eliminate potential
programming errors, Some of the most frequently used languages (such as C)
are also that, according to what is known about language design, are the
most error prone.=94 Riehle (2) makes a very strong case for Ada where safet=
y
is required.

(1) N. G. Leveson, =93Safeware, System Safety and Computers, Addison-Wesley,
ISBN 0-201-11972-2 pages 412-413 (1995).

(2) R. Riehle, =93Can Software Be Safe? --An Ada Viewpoint, Embedded Systems
Programming, Vol. 9 (13) pages 28-40 (Dec. 1996).


Below are a list of my groups' papers on Ada software for medical devices.

R. C. Leif, I. Rosello, D. Simler, G. P. Garcia, and S. B. Leif; "Ada
Software for Cytometry". Analytical and Quantitative Cytology and Histology
13 pp. 440-450 (1991).

S. B. Leif and R. C. Leif; "Producing Quality Software According to Medical
Regulations for Devices". Computer Based Medical Systems, Proceedings of
the Fifth Annual IEEE Symposium 265-272 (1992).

R. C. Leif, J. Sara, I. Burgess, M. Kelly, S. B. Leif, and T. Daly, "The
Development of Software in the Ada Language for a Mid-Range Hematology
Analyzer". Tri-Ada =9193 340-346 (1993).

Suzanne B. Leif, Stephanie H. Leif (Aha), and Robert C. Leif; "Setting Up a
Pre-production Quality Management Process in the Medical Device Industry".
in Software Quality Management II Vol. 1: Managing Quality Systems Ed. M.
Ross, C. A. Brebbia, G. Staples, J. Stapleton, Computational Mechanics
Publications, Southampton, Boston pp. 63-78 (1994).

R. C. Leif, S. B. Leif, S. H. Leif, and E. Bingue, "A Simple Solution to
The Medical Instrumentation Software Problem". Progress in Biomedical
Optics, Proceedings of Ultrasensitive Instrumentation for DNA Sequencing
and Biochemical Diagnostics". Ed. G. E. Cohn, J. M. Lerner, K. J. Liddane,
A. Scheeline, and S. A. Soper.  A. Katzir Biomedical Optics Series Editor
SPIE Proceedings Series, Vol. 2386, pp 236-249 (1995).

R. C. Leif, R. Rios, M. C. Becker, C. K. Becker, J. T. Self, and S. B.
Leif, "The Creation of a Laboratory Instrument Quality Monitoring System
with AdaSAGE". Advanced Techniques in Analytical Cytology, Optical
Diagnosis of Living Cells and Biofluids, Ed. T. Askura, D. L. Farkas, R. C.
Leif, A. V. Priezzhev, , and B. J. Tromberg.. A. Katzir Progress in
Biomedical Optics Series Editor SPIE Proceedings Series, Vol. 2678, 232-239
(1996).

You wrote:
------------------------------------------------------------------
Date:    Thu, 16 Jan 1997 22:22:29 -0500
From:    Macarthur Drake <drake@BME.RI.CCF.ORG>
Subject: Help you C++ Debuggers!

I am in the mist of completing a major piece of code in C++. However I
keep comming across a particularly difficult bug. Can you help?

        I am simply trying to declare a three D array:


float objects[9000][10][10];

        However, sometimes while compiling I get a strange compilation error
like one of the following:

1. segmentation violation


2.
ld:
Can't have archive/object only 0 bytes long: displayer3.o

3.

ld:
Fatal error in writing to final object file (<=82)
Fatal error in writing to final object file (<=82)
16.983u 5.929s 1:09.16 33.1% 0+0k 1736+538io 270pf+0w

        now I am convinced that my error is related to this array in some=
 way
because if I change the size of the array to say  900 by 10 by 10 then I
don't have any problems. Am I declaring this array properly? I have
plenty of RAM and i don't think that a 900K element array of floats is
too big. Can I dynamically allocate this array somehow?

         What is really strange is that sometimes the code compiles and runs
with no problem....and then I turn around and compile it with no changes
and I get an compilation error. Furthermore my problem is not that I am
trying to write to an element that does not exist (like if i were trying
to write to element objects[9001][10][10]) because an error like that
would be a run time error not an compilation error.....any help it truly
appreciated.........thanks alot,

--
Macarthur Drake jr.
Biomedical Engineering
The Cleveland Clinic Foundation
Phone (216) 445 3411, Fax (216) 444 9198
drake.79@postbox.acs.ohio-state.edu, drake@bme.ri.ccf.org
----------------------------------------------------------------------------
-------------------------


Robert C. Leif, Ph.D., PMIAC,=20
Vice President & Research Director
Ada_Med, A Division of Newport Instruments
Tel. & Fax (619) 582-0437
Please send e-mail to my new address, rleif@rleif.com
Thank you.=20

Re: C++ Should not be used for Medical Devices

[David C. Hoos, Sr.]

Dr. Robert Leif <rleif@RLEIF.COM> wrote in article
<3.0.32.19970119225145.006fce98@mail.4dcomm.com>...
The best help you can get from Comp.Lang.Ada, where this appeared, is not
how to find the best C++ Debugger; but, the simple statement, Try Ada 95.

Date:    Thu, 16 Jan 1997 22:22:29 -0500
From:    Macarthur Drake <drake@BME.RI.CCF.ORG>
Subject: Help you C++ Debuggers!

I am in the mist of completing a major piece of code in C++. However I
keep comming across a particularly difficult bug. Can you help?

        I am simply trying to declare a three D array:

float objects[9000][10][10];

Hi Macarthur,

I cannot agree too strongly with Robert Leif that you should use Ada95 for
safety-critical systems.

However, there is one aspect of the problem -- i.e., the runtime
segmentation faults which could happen even with Ada, since you are
declaring the variable on the stack, or in the static data segment of your
program (you didn't provide enough context to show which).  The size of
your array amounts to 3,600,000 bytes and could be more than is allowed by
the default stack size of your program.

Dynamic allocation (as you suggest) is the solution to the run-time
problem.

E.g., in C/C++ you could write:
#define DIM_1 9000
#define DIM_2 10
#define DIM_3 10
void main (void)
{
float * * * objects;
objects = malloc (
    DIM_1 * DIM_2 * DIM_3 * sizeof (float)
    );
exit (0);
}

Or in Ada, you could write
procedure Macarthur is
  Dim_1 : constant Natural := 9000;
  Dim_2 : constant Natural := 10;
  Dim_3 : constant Natural := 10;
  type Object_Array_Type is
       array (0 .. Dim_1 - 1, 0 .. Dim_2 - 1, 0 .. Dim_3 - 1) of Float;
   type Object_Array_Access_Type is access Object_Array_Type;
   Objects : Object_Array_Access_Type := new Object_Array_Type;
 begin
   null;
 end Macarthur;

In Ada you would raise an exception any time you attempted to access
outside the array.

As to why the compile-time failures, it's difficult to say without knowing
the compiler/platform, but maybe it's because the compiler is written in C?

Hope this helps

-- 
David C. Hoos, Sr.,
http://www.dbhwww.com
http://www.ada95.com
 

Re: C++ Should not be used for Medical Devices

[Ted Dennison]

David C. Hoos, Sr. wrote:
> 
> From:    Macarthur Drake <drake@BME.RI.CCF.ORG>
> 
> I am in the mist of completing a major piece of code in C++. However I
> keep comming across a particularly difficult bug. Can you help?
> 
>         I am simply trying to declare a three D array:
> 
> float objects[9000][10][10];

This looks more like C than C++ to me. 

By my reckoning that is about 7,200,000 bytes.

> Dynamic allocation (as you suggest) is the solution to the run-time
> problem.
...
> float * * * objects;
> objects = malloc (
>     DIM_1 * DIM_2 * DIM_3 * sizeof (float)
>     );

Of course this doesn't just require that you have 7 Meg free on your
machine. You must have 7 Meg free in one contiguous block! It is quite
possible that this will run once, but crash when run later. If you do
this, make sure to check for malloc failure! 

As for the compiler errors, it looks like your compiler is buggy. I sure
hope this C program, compiled with a buggy C++ compiler, is not going to
run in an actual biomedical device (or at least in one that will ever be
pointed at me :-)  ).

-- 
T.E.D.          
             |  Work - mailto:dennison@escmail.orl.lmco.com  |
             |  Home - mailto:dennison@iag.net               |
             |  URL  - http://www.iag.net/~dennison          |

Re: C++ Should not be used for Medical Devices

[Jim Chelini]

David C. Hoos, Sr. wrote:
> 
> Dr. Robert Leif <rleif@RLEIF.COM> wrote in article
> <3.0.32.19970119225145.006fce98@mail.4dcomm.com>...
> The best help you can get from Comp.Lang.Ada, where this appeared, is not
> how to find the best C++ Debugger; but, the simple statement, Try Ada 95.
> 
> Date:    Thu, 16 Jan 1997 22:22:29 -0500
> From:    Macarthur Drake <drake@BME.RI.CCF.ORG>
> Subject: Help you C++ Debuggers!
> 
> I am in the mist of completing a major piece of code in C++. However I
> keep comming across a particularly difficult bug. Can you help?
> 
>         I am simply trying to declare a three D array:
> 
> float objects[9000][10][10];
> 
> Hi Macarthur,
> 
> I cannot agree too strongly with Robert Leif that you should use Ada95 for
> safety-critical systems.
> 
> However, there is one aspect of the problem -- i.e., the runtime
> segmentation faults which could happen even with Ada, since you are
> declaring the variable on the stack, or in the static data segment of your
> program (you didn't provide enough context to show which).  The size of
> your array amounts to 3,600,000 bytes and could be more than is allowed by
> the default stack size of your program.
> 
> Dynamic allocation (as you suggest) is the solution to the run-time
> problem.
> 

When it comes to safety critical software, I would certainly agree with the use of Ada.
However, I would avoid a number of features including tasking and dynamic allocation. In the 
cases where a life is at risk whether it is a medical device, aircraft, or a rail system, stick 
to deterministic constructs.  Once the program has completed elaboration, it should not perform 
dynamic operations.  Also, make sure the run-time is developed, documented, and TESTED to the 
same degree as the application.  If you don't, you have left a very large hole in the system.

This limits some of the more interesting features of the language, but the goal is to develop a 
safe system.

Jim Chelini

jchelini@aonix.com

> E.g., in C/C++ you could write:
> #define DIM_1 9000
> #define DIM_2 10
> #define DIM_3 10
> void main (void)
> {
> float * * * objects;
> objects = malloc (
>     DIM_1 * DIM_2 * DIM_3 * sizeof (float)
>     );
> exit (0);
> }
> 
> Or in Ada, you could write
> procedure Macarthur is
>   Dim_1 : constant Natural := 9000;
>   Dim_2 : constant Natural := 10;
>   Dim_3 : constant Natural := 10;
>   type Object_Array_Type is
>        array (0 .. Dim_1 - 1, 0 .. Dim_2 - 1, 0 .. Dim_3 - 1) of Float;
>    type Object_Array_Access_Type is access Object_Array_Type;
>    Objects : Object_Array_Access_Type := new Object_Array_Type;
>  begin
>    null;
>  end Macarthur;
> 
> In Ada you would raise an exception any time you attempted to access
> outside the array.
> 
> As to why the compile-time failures, it's difficult to say without knowing
> the compiler/platform, but maybe it's because the compiler is written in C?
> 
> Hope this helps
> 
> --
> David C. Hoos, Sr.,
> http://www.dbhwww.com
> http://www.ada95.com
>

Re: C++ Should not be used for Medical Devices

[Stephen Bull]

Jim Chelini <jchelini@east.thomsoft.com> writes:

>  When it comes to safety critical software, I would certainly agree with
>  the use of Ada. However, I would avoid a number of features including
>  tasking and dynamic allocation. In the cases where a life is at risk
>  whether it is a medical device, aircraft, or a rail system, stick 
>  to deterministic constructs.  Once the program has completed elaboration,
>  it should not perform dynamic operations.  Also, make sure the run-time
>  is developed, documented, and TESTED to the same degree as the
>  application.  If you don't, you have left a very large hole in the
>  system.
>
>  This limits some of the more interesting features of the language
>  but the goal is to develop a safe system.

SPARK is designed to support the development of software used in
applications where correct operation is vital. Examples include avionic
and air traffic systems, railway signalling, nuclear protection systems
and medical equipment. 

The SPARK Language is a secure subset of Ada, augmented by annotations.
SPARK is formally defined and SPARK programs are predictable and can
be rigorously analysed. With its support tool, the SPARK Examiner,
and the high quality mainstream Ada products, SPARK provides a solid
engineering basis for all complex computer based systems. 

The SPARK Examiner checks the conformance of a program to the rules of
SPARK, carries out a flow analysis of the code, and supports formal
verification. Absence of run-time errors can be demonstrated rigorously. 

SPARK is a product of Praxis, a Software Engineering firm specialising
in complex systems in a variety of markets.

For further information please contact:

Denton Clutterbuck
Praxis Critical Systems
20 Manvers Street
Bath
BA1 1PX
UK

email: sparkinfo@praxis.co.uk 
tel:   +44 (0)1225 444700
fax:   +44 (0)1225 465205 

or visit our web pages:

http://www.praxis.co.uk/technols/spark/spark.htm
http://www.praxis.co.uk/services/critsys/critsys.htm

-- 
-----------------------------------------------------------------------------
 Stephen Bull  Praxis Critical Systems  20 Manvers Street  BATH  BA1 1PX  UK
    +1225 444700 (switchboard)  +1225 739286 (direct)  +1225 739281 (fax)
-----------------------------------------------------------------------------
-- 
-----------------------------------------------------------------------------
 Stephen Bull  Praxis Critical Systems  20 Manvers Street  BATH  BA1 1PX  UK
    +1225 444700 (switchboard)  +1225 739286 (direct)  +1225 739281 (fax)
-----------------------------------------------------------------------------