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,d1df6bc3799debed
X-Google-Attributes: gid103376,public
From: "J. Florio" <jfflorio@erols.com>
Subject: Re: Not intended for use in medical,
Date: 1997/04/24
Message-ID: <33601B64.666B32C2@erols.com>#1/1
X-Deja-AN: 237172975
References: <3.0.32.19970423164855.00746db8@mail.4dcomm.com>
X-Priority: 3 (Normal)
Organization: Erol's Internet Services
X-Received-On: 24 Apr 1997 22:44:09 GMT
Newsgroups: comp.lang.ada
Date: 1997-04-24T00:00:00+00:00
List-Id: <comp.lang.ada>



Robert C. Leif, Ph.D. wrote:

> To: Tim Behrendsen, Kaz Kylheku et al.
> From: Robert C. Leif, Ph.D.
> Vice President Ada_Med
>
> The quote," Intel products are not intended for use in medical, life
>
> saving, or life sustaining applications."  as you stated is in
> Pentium
> Processor Specification Update_ from Intel, January 1997.   I called
> Intel.
> The document can be ordered at 800.548.4725.  Intel said that there
> was no
> charge.  The National 32 bit processor had a similar disclaimer.  Do
> you or
> any of the other readers of Comp.Lang.Ada know of other similar
> disclaimers?  Many medical instruments use  Intel  486 and Pentium
> devices.
>
> This quote may provide an excellent opportunity in the medical
> device
> business, which is NOT puny.  My question is, Does validation of an
> Ada
> compiler on a platform provide significant evidence that the
> processor
> produces valid object code?  Would any of the other Ada test suites
> help?
> I deliberately used the word significant rather than sufficient.  If
> anyone
> knows how to prove sufficiency, I would also like a comment.  Any
> other
> suggestions that would permit realistic development of medical
> devices
> would be appreciated.

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.

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