Published on Medical Electronics Design (http://www.medicalelectronicsdesign.

com)
Home > A Comparison and Analysis of Software Development Platforms for Embedded Computer-Controlled Medical Devices

A Comparison and Analysis of Software

Development Platforms for Embedded
Computer-Controlled Medical Devices
Created 2000-10-01 03:00
[1]

A Comparison and Analysis of Software Development

Platforms for Embedded Computer-Controlled Medical
Devices
[2]

October 01, 2000

Share [3]
Find more content on: Feature [4]

Integrated Circuits [5]

EMBEDDED SYSTEMS

Thomas Wolfgang Burger

Comparison and analysis of the many platforms available takes a little effort, but can pay off
by increasing the chances for a successful product launch.
A trend in medical technology is increasingly to include software-controlled components in
medical devices. Internal software is instrumental in gathering, storing, displaying, and
distributing large amounts of meaningful data and then processing that data into useful
information. Embedded device controls enhance the accuracy and flexibility of the device, make
the device safe and easy to use, and extend device capabilities while lowering the operating
cost.

The basis of any embedded softwarecontrolled device is the programming that creates the
software. That programming is done via the application programming (or programmer's)
interface (API). The API allows the developer to build a program that can communicate with the
underlying operating system (OS) that, for its part, controls the computer hardware and the
components connected to that hardware. Four major components constitute the API: the
developer interface, which includes the debugging tools; the libraries, which are subprograms
the program uses to perform standard, predefined tasks; the compiler, or, seen another way, the
language the compiler understands; and the linker that combines the compiled code and the
libraries into a working program.
The combination of the API and the OS is called the development platform (DP). The correct
choice of a software DP for an embedded medical system during product development can
spell the difference between project success and failure.
Choosing a Development Platform
Selection of an embedded medical device DP should be based on the following criteria (listed
in rough order of importance):
The ability of the DP to do the required job.
The accuracy and ease of testing and debugging the software code via the API.
The support available from the manufacturer of the DP, and the manufacturer's service
record.
The DP's adherence to industry standards and its ability to meet government standards
related to medical device software.
A design specifically supportive of embedded control architecture.
Its adaptability to future needs and standards.
Its user-interface design facilities.
The availability of component libraries.
The range of hardware supported.
The range of central processing units (CPUs) supported.
The familiarity the current development staff has with the product.
Its cost.
To take up discussion of these in the reverse of this order, cost is the least
Embedded
important consideration in the selection of a development platform in that cost
System
has no significance if the DP cannot perform the required tasks. Cost is
Development
important only as a factor in the evaluation of the project as a whole. Use of the
Assistance [6]
most expensive alternative component can lead to the lowest cost per unit for a
device, and the converse is also true. Concern about the up-front costs or royalty costs of a
particular DP is misguided. The true price of a platform should be analyzed on a per-unit basis.
An embedded system should use as little memory as possible and the slowest processor that
maintains desired performance. This remains true no matter how much the hardware price-toperformance ratio decreases in the future. The cost of development and the often much greater
costs of support and upgrades are also more germane to the analysis of project costs than the
initial DP price.
It is a common misconception that DP selection must be driven by the current abilities of the
development staff. Any competent programmer can learn to be productive in any DP in typically

less than a month and often half that time. Conceptual knowledge based on theoretical training
and experience is the key to being able to use a DP, not specific platform familiarity. Although
maintaining familiar interfaces and syntax may be desirable, it is often detrimental in the long
term to do so, both for the company and for staff members. Identifying the correct tool for the job
must be the guiding rule.
The CPUs that are supported by the DP can be a criterion of significance in the selection
process: a device may have particular requirements that limit choice of a CPU to a single
processor. This is also true with respect to system hardware. What hardware is supported by the
DP, for instance, driver libraries, may dictate the selection of a DP.
Component libraries are the collections of previously written software that can be used to build
the device software components. It is desirable to write as little code as possible for a new
piece of software. Component libraries tend to be very well tested and optimized for the
purposes for which they were designed.
Facilities for design of the operator or user interface are very important to the success of the
development project. Nowadays, even the smallest and simplest devices have a GUI (graphical
user interface) built into them. Even if it is not necessary, the market often expects the interface
to be GUI based. Embedded-device GUI interfaces must allow ease, versatility, and speed of
design.
The adaptability of a DP depends on many criteria. Most important is its scalability, the ability of
the DP to be resized to fit the intended purpose while allowing for future expansion on the
unchanged base configuration in order to extend device capabilities. Scalable DPs tend to be
microkernel based. A microkernel is a tiny (64K or less) core OS around which ever more
complex layers or shells can be applied as needs dictate.
The platform should have been specifically designed for embedded-device development
purposes. Attempting to adapt a system that was created to be a desktop OS is an enterprise
fraught with probabilities of design failure.
Industry standards are established to provide economies of scale and baselines of method and
quality. They minimize the unknown quantities involved in a project and establish a foundation of
previous works to use as a guide. Standards also allow a choice between compatible platforms
because previous work can be used in the new DP. It may be desirable to use a DP with
proprietary components, however, if there are significant competitive advantages in doing so.
The recognition of advantage may be countered by the knowledge that the project is now at the
mercy of a single supplier and will not be able to benefit from future collaborative improvements
to the standard that has been forgone.
Medical devices are subject to government regulations that, unlike industry standards, cannot be
ignored. To be selectable for an embedded-device application, a DP must meet regulatory
requirements.
The top three criteria for choosing a development platform are obvious. Still, they cannot be
emphasized enough. The quality and usability of the debugging system is a consideration often
ignored, with disastrous results. A debugging system not only needs to find faults in the coding
logic when running as a simulation, but also must be capable of debugging the code running on

the embedded device. This is the only way to ensure the viability of the programming prior to the
beta-testing phase of the project. With medical devices, the beta phase is often not a true realworld test but, owing to the life-and-death nature of the device's function, a laboratory simulation.
This circumstance makes the ability to maximize programming integrity through thorough
debugging especially important.
Live device testing was done by trial and error in the past. The program was burned into the
erasable programmable read-only memory (EPROM), and the device was run, with results as to
success or failure of the program being recorded. It would be typical to modify the standard code
with debugging code inserted into the program to monitor the progress. This introduced two
problems. First, the debugging code altered the nature of the programming by introducing
elements that would not be in the final product. Thus, the real code could never truly be tested.
Second, the details of the program run could not be seen. Debugging is essentially ad hoc;
debug requirements cannot be predetermined. Currently, live device debugging is facilitated in
many available DPs by means of a connection between the development machine, acting as a
debug terminal, and the target device, which has been altered to incorporate a compatible
connector. This is often done using a Transmission Control Protocol/Internet Protocol (TCP/IP)
network connection through a standard RJ45 Ethernet port.
Embedded Architecture
The operator of a device containing an embedded OS is
not aware of the embedded software, of the OS it uses
to control the CPU, or of the CPU itself. What the user
sees is the control interface and the system's response
to the use of the controls in terms of speed and desired
result.
Unlike that in a personal computer, the software in a
microprocessor-controlled device is not loaded from a
hard drive but is actually embedded"burned" intothe
hardware. This offers several advantages. The device is
instantly on; there is no perceptible load or boot time.
Also, the possibility of a load error due to disk failure is
eliminated. And, if it is properly designed, the
programming cannot be altered by the operator or
affected by a virus.
FDA Requirements for Medical Device Software
An FDA guidance document on software validation states the situation clearly:
"Software validation is a requirement of the Quality System Regulation [QSR], 21 CFR Part 820,
[. . .] Validation requirements apply to software used in medical devices, to software that is itself
a medical device (e.g., software used in blood establishments), as well as to software used in
production of the device or in implementation of the device manufacturer's quality system.

"Unless specifically exempted in a classification regulation, all medical device software

developed after June 1, 1997 [the effective date of the QSR], regardless of its device class, is
subject to applicable design control provisions of 21 CFR 820.30. This includes completion of
current development projects, all new development projects, and all changes made to existing
medical device software. Specific requirements for validation of device software are found in 21
CFR 820.30(g). In addition, formal design reviews and software verification are integral parts of
an overall software validation, as required by 21 CFR 820.30(e) and (f)."1
Any development platform must have passed the requirements listed in 21 CFR 820.30(g) in
order to be a candidate for embedded-device use. An exception to this may be possible, if the
OS source code is available and the device software will be tightly integrated into the OS code.
Then it would be up to the developer to certify all of the code, including the OS.
The design validation regulation says that "each manufacturer shall establish and maintain
procedures for validating the device design. Design validation shall be performed under defined
operating conditions on initial production units, lots, or batches, or their equivalents. Design
validation shall ensure that devices conform to defined user needs and intended uses and shall
include testing of production units under actual or simulated use conditions. Design validation
shall include software validation and risk analysis, where appropriate. The results of the design
validation, including identification of the design, method(s), the date, and the individual(s)
performing the validation, shall be documented in the DHF [design history file]."2
In essence, then, the device manufacturer has to be able to prove, through documentation of the
project, that the software was produced with due diligence. FDA considers any DP selected for
inclusion in a device to be off-the-shelf (OTS) software. To be used, it must satisfy the criteria
presented in the agency document "Off-the-Shelf Software Use in Medical Devices."3 It would be
reasonable for FDA to ask for a sworn statement from a company officer in charge of
development that the OS and any other parts of the DP used in the device meet these criteria.
Even better would be to produce third-party certification of the OS and other components of the
DP. Testing specialists exist who produce software to test OTS products to certify that they meet
certain requirements.
Choosing an Operating System
In the past, embedded systems were developed entirely in-house, usually with Assembler
programming language. About half of all embedded systems are still being developed in-house
today.4 But, except for the simplest devices, it is inadvisable to write an entire system from
scratch when a large number of proven alternatives are available to choose from.
Embedded applications ideally call for a real-time operating system (RTOS). An RTOS is
designed to allow the system to run multiple tasks, or threads, at the same time and to ensure
that all of these tasks are given a predefined amount of time to function within a given cycle. Any
operation requested of the RTOS concludes within a given, very short, time constraint.
An RTOS application can be characterized as either hard or soft real time. Hard real time
describes any case where, if a task exceeds a time limit, the application will fail. Soft real time
refers to applications that can tolerate some time-limit violations.

Non-real-time applications do not require any task to be concluded within a given time period,
nor must any operation to be performed by the OS finish within a particular time frame.
An embedded system typically involves a combination of tasks that fit into all three of these
operational time sensitivity categories. A device that measures a rate or requires the timestamping of data is a hard real-time device. A soft real-time device is one that requires
operations to be completed within a certain time tolerance but does not require precise timing.
A true RTOS uses a time-sharing methodology called preemptive multitasking multithreading
(PMT). PMT suspends or preempts one task so that another task with a higher priority can begin
to be performed. The allocation of time for tasks can be done on a priority basis, on a
percentage basis, or through absolute time slicing. A true RTOS is able to schedule tasks via
absolute time slicing and has a guaranteed OS interrupt latency of 10 microseconds or less.
Choosing a Programming Language
Two standard programming languages have been the principal choices for embedded-systems
development: Assembler and C/C++. Lately, Visual BASIC and Java have been increasing in
popularity along with the increase in power and speed of small-device hardware.
Assembler offers the advantages of ensuring absolute control over the functioning of the
program and of being potentially the fastest-running program. Its disadvantages are that the
language is difficult to write in, debug, and adapt to new uses. Another disadvantage, possibly
the biggest, is that the code is CPU-specific and cannot be adapted to another hardware
platform.
C and C++ are popular, easy to program, and versatile. C allows the incorporation of assembly
language, by means of the Inline function, in places where speed or special coding is required. A
disadvantage of C and C++ is that these compilers are notoriously conducive to the
programmer's creation of subtle yet devastating errors. The most common sources of error of
this kind are typecasting and memory allocation/deallocation.
Visual BASIC is available for development in Windows CE (see below). That language
facilitates rapid development. Another attraction is that a large number of programmers are
already familiar with it.
Java is the latest offering and the first to be designed specifically for embedded systems. It is
the easiest language to program and the least prone to developer-introduced errors. The reason
for this is that Java takes care of the allocation and deallocation of required memory, with no
specific coding required from the programmer, and is very strict with regard to the use of defined
types. Memory-use control is handled by a process called "garbage collection." Java senses
when storage is no longer needed and then frees the portion of memory involved for future use.
This "service" is also Java's greatest weakness. There is no way for a programmer to anticipate
where and when garbage collection will occur. This makes standard Java currently unacceptable
for hard RTOS applications, even though hard RTOS versions of Java are available.
Java is not a compiled language. The source is processed into byte code and is interpreted by
the Java virtual machine (JVM) at run time. The JVM is a program that is designed to convert the
Java code into machine-specific instructions. This, in theory, will allow any Java program to run

on any hardware that has a JVM written for it. The JVM is not an OS (though there are
exceptions to this); it is a layer of programming that resides between the device program and
the OS. Because of this, Java adds further memory and processing overhead and can be
criticized for being comparatively slow and large. Real-time Java-like languages have been
developed by some DP vendors. These usually involve combination of the JVM and the OS into
a hybrid OS that processes Java instructions directly.
Development Platforms Now Available
On-Line Sources
of Information
about
Embedded
Operating
System Software

The following DPs are among the many available for use in the production of
embedded devices. They are discussed in no particularly meaningful order.
The author has not worked with all of them, so some discussions are minimal.
Readers are advised to consult Web sites for more information.

Microsoft Corp. (Redmond, WA): Windows CE and NT Embedded.

Windows CE was originally, in the first release, Windows 95 with much
[7]
removed in order to make it compact enough for an embedded system. This
is not to say that it is a stripped-down version of the full Windows code. CE was developed as a
separate OS with its own code. However, many of the elements of Windows found their way into
CE. This is not surprising, considering that about 1500 Win32 API calls are supported by CE.
Windows CE version 3.0, recently released, features great improvements, making it a true OS
for embedded systems. It is now more modular, and the GUI programming components are
better designed for small devices. Microsoft has added real-time-like processing support. CE
now has nested interrupts, additional priority levels, semaphores, and guaranteed interrupt
latency times between 90 and 250 microseconds. This is still too slow for most hard real-time
purposes. The design is not a true RTOS, although CE 3.0 is much closer to the real thing.
Advantages of CE include brand recognition, a familiar look and feel, and support of the Win32
API with about 1500 supported function calls in a scalable library format. It offers a programming
model that is almost the same as the desktop OS.
Disadvantages of CE are that it is based on a desktop OS model that was adapted to work in
embedded environments, that it is not a true RTOS, and that it is probably the largest embedded
OS, typically with 1.52.5 Mbyte of ROM and 600K of RAM, although a core installation of about
256K of ROM is possible. Four megabytes of RAM in a device using CE is not unusual.
Windows NT Embedded is meant for larger-scale, full PC-based embedded systems requiring
extensive networking and communications protocols, large-scale applications, back office
integration, and remote management. It is a good choice for a feature-rich device that does not
require extremely time-critical controls.
The Windows Embedded Family Web Site [8]
Real-Time Systems with Microsoft Windows CE 2.1 [9]
QNX (Kanata, ON, Canada): Neutrino RTOS and Photon microGUI. QNX is one of the few
embedded-OS vendors specifically targeting the medical device market. Clients include
medical imaging, pharmaceutical, and aerospace organizations in the United States, Europe,
and Asia. QNX is unusual in that its OS also can be run on a PC as a desktop OS for

development and testing. The company has been providing embedded-OS technology since
1980.
The QNX Neutrino microkernel RTOS is compliant with POSIX (the portable OS interface for
UNIX) and can run Linux applications with no modifications. A JVM is available. The
disadvantage with QNX is the limited choice of hardware platforms. The OS supports only x86,
MIPS, and PowerPC CPUs.
Neutrino is a partially open source and is free for noncommercial use. QNX uses a sourcelicensing scheme to extend to developers the benefits of source code access while maintaining
full intellectual property rights, an option not available with some Linux licenses. IBM has
partnered with QNX, and the VisualAge Micro Edition Java development kit for embedded
systems with Neutrino can be integrated.
QNX Neutrino RTOS [10]
QSSL Medical Applications [11]
QNX Technical Support [12]
LynuxWorks [13] (San Jose, CA): LynxOS RTOS. LynxOS is a hard RTOS designed for missioncritical applications such as flight control systems. LynxOS is UNIX and POSIX compliant and
supports Java.
Wind River [14] (Alameda, CA): pSOSystem. Wind River offers perhaps the greatest array of
embedded-OS products of any vendor and is likely to be able to supply a platform to fulfill any
need.
Mentor Graphics [15] (Wilsonville, OR): VRTX. VRTX is a highly regarded RTOS with a 16-year
history. It supports Java, POSIX, and TCP/IP networking. Customers include Samsung and
Lucent Technologies.
Red Hat Inc. [16] (Research Triangle Park, NC): eCos and Embedded Development Kit. The
Linux-based eCos DP was introduced since the merger of Red Hat and Cygnus Solutions. It is
an open-source run-time system supported by the Red Hat GNUPro and GNU open-source
development tools. It has RTOS capabilities and is royalty free.
The Red Hat Embedded Development Kit [17] is a full Linux distribution with modifications and
tools to allow development of embedded systems in full PC architectures.
GORDIAN [18] (Santa Ana Heights, CA). GORDIAN is a development firm with extensive
experience in embedded systems, including an RTOS. To eliminate third-party licensing, the
company has developed its own embedded OS that is multitasking, with a preemptive scheduler
and a UNIX-like programming interface. The company develops for a fee or will do contract
development on a cooperative royalty or shared-revenue basis.
In business since 1986, GORDIAN develops stand-alone applications along with its large RTOS
code base. It also offers cross-platform configuration software, Java-based configuration
software, and a CCD camera/tracker interface.
Sun Microsystems Inc. [19] (Palo Alto, CA): ChorusOS. ChorusOS is a scalable embedded
operating system targeted for telecommunication devices. It is a component-based RTOS that

supports real-time POSIX and Java applications. Its microkernel design allows running in as little
as 10K of memory. The OS supports third-party protocol stacks, legacy applications, and realtime and Java technologybased applications.
Green Hills Software Inc. [20] (Santa Barbara, CA): Integrity and ThreadX RTOSs. Green Hills
Software supplies a large range and assortment of development tools and OSs. The company
offers the Ada language for embedded development and C/C++ tools for 20 hardware
platforms.
JMI Software Systems Inc. [21] (San Jose, CA): C Executive. C Executive is an embedded
multitasking RTOS that can occupy as little as 5K of ROM space. It is available on a wide variety
of processors. JMI offers training and consulting worldwide. See also the company's European
branch. [22]
Precise Software Technologies Inc. [23] (Nepean, ON, Canada): MQX RTOS. This RTOS is
royalty free and includes full source code. It offers safety features such as run-time error
detection. Precise also provides embedded Internet protocols.
Esmertec Inc. [24] (San Jose, CA): Jbed. Jbed reportedly fills the void between JavaCard and
Embedded Java with its integration of the RTOS kernel and a Java virtual machine. It offers a
hard RTOS with Java development, with nonblocking garbage collection and exception handling.
Accelerated Technology Inc. [25] (Mobile, AL): Nucleus RTOS. This royalty-free RTOS comes with
complete source code. A limited version is available for free download. Accelerated Technology
products support complex-instruction-set CPUs from Intel/AMD, Hitachi, Motorola (68K series),
NEC, and Panasonic and reduced-instruction-set CPUs made by ARM, Hitachi, IBM, Intel,
various MIPS, Lucent, Motorola (MCORE, ColdFire, and PowerPC), National, NEC, Tensilica,
Texas Instruments, and Toshiba, along with Analog Devices, Texas Instruments, and Hitachi
digital signal processors.
On Time Software [26] (Setauket, NY): RTOS-32. This Win32/NT-compatible RTOS uses a
Windows NT subset. It is available for Intel x86compatible embedded systems. The RTOS is
royalty free, and source code can be purchased.
Sakamura Laboratory, University of Tokyo [27] (Japan): ITRON RTOS is an embedded RTOS that
supports Java. It was reported that in 1998 about 20% of all embedded medical devices and
50% of all personal information devices made in Japan used ITRON as the OS.
Lineo [28] (Herndon, VA): RealTime Linux. This operating system is a real-time version of Linux
that can be used as, but was not specifically designed to be, an embedded OS. Zentropix
RealTime Linux version 1.0 is optimized for fast, hard real-time response. It is based on Linux
kernel 2.0.36 and version 0.9j of the NMT RTLinux extension.
Micrim Inc. [29] (Weston, FL): C/OS-II. A portable, ROM-able, scalable, preemptive, real-time
multitasking kernel, C/OS-II is certified as a DO178B Level B product for safety-critical systems
and is rated for medical use. This OS is very inexpensive, but it is limited to 63 user tasks.
Microware Systems Corp. [30] (Des Moines, IA): OS-9 RTOS. This RTOS includes multiprotocol
networking and advanced multimedia support. It is a scalable real-time system that can be used

in devices ranging from deeply embedded applications to high-end consumer products.

Dexdyne [31] (Cirencester, Glos, UK): Subliminal Linux. This is a non-RTOS full version of Linux
that is flash ready and can be fitted into 2 Mbyte of ROM. Its producer also designs and
manufactures a variety of embedded controllers for use in medical instrumentation, process
control, data logging, and other applications.
Conclusion
A development platform for the creation of software for embedded computercontrolled medical
devices must meet the objectives of the project, the requirements of government regulations,
and the needs of the user. The great variety of DP offerings on the market must each be carefully
examined in order to select the best fit for the development project. With so many platforms
available, a firm that has done the research can select a different platform for each project, if that
is the appropriate approach, rather than limit its choice for a new development to a familiar but
perhaps unsuitable DP.
References
1. FDA, "General Principles of Software Validation [32] ," Draft Guidance, Version 1.1, Part II,
Sect. C [on-line] (Rockville, MD: FDA, Center for Devices and Radiological Health, 1997 [cited
17 August 2000]); available from Internet.
2. Code of Federal Regulations, 21 CFR 820.30(g).
3. FDA, Off-the-Shelf Software Use in Medical Devices [33] [on-line] (Rockville, MD: FDA,
Center for Devices and Radiological Health, 1999 [cited 17 August 2000]).
4. Venture Development Corp., "World of Proprietary Operating Systems" (Natick, MA: Venture
Development, 2000); see www.vdc-corp.com [34] . [The actual report cited is not available there,
except to be ordered for $5000.]
Thomas Wolfgang Burger is a programmer, systems analyst, teacher, and technical writer. He
can be reached at twburger@bigfoot.com [35] .
Back to the Fall 2000 Table of Contents

[36]

Copyright 2000 Medical Electronics Manufacturing

Feature
Privacy Policy | Contact | Advertise | Subscribe | Sitemap
2014 UBM Canon

Integrated Circuits

Related Sites from UBM Canon:

- Qmed - Qualified Medical
Suppliers
- Medical Device +
Diagnostic Industry
- European Medical Device
Technology
- Medical Product
Manufacturing News

- IVD Technology
- OrthoTec
- China Medical Device
Manufacturer
- medtechinsider

- medtechinsider auf Deutsch

- Pharmaceutical & Medical
Packaging News
- Pharmalive

Source URL: http://www.medicalelectronicsdesign.com/article/comparison-and-analysis-software-developmentplatforms-embedded-computer-controlled-medicalLinks:

[1] http://www.medicalelectronicsdesign.com/
[2] http://www.medicalelectronicsdesign.com/article/comparison-and-analysis-software-development-platformsembedded-computer-controlled-medical[3] http://www.facebook.com/sharer.php
[4] http://www.medicalelectronicsdesign.com/department/feature
[5] http://www.medicalelectronicsdesign.com/categories/embedded-systems
[6] http://www.devicelink.com/mem/archive/00/10/004table3.html
[7] http://www.devicelink.com/mem/archive/00/10/004table.html
[8] http://www.microsoft.com/windows/embedded/default.asp
[9] http://www.microsoft.com/windows/embedded/ce/previous/developer/hardware/architecture/realtime.asp
[10] http://www.qnx.com/products/os/neutrino.html
[11] http://www.qnx.com/realworld/index.html#medical
[12] http://www.techsi.com/techsi/qnx.htm
[13] http://www.lynuxworks.com/products/whatislos.html
[14] http://www.wrs.com
[15] http://www.mentor.com/embedded/vrtxos/index.html
[16] http://sourceware.cygnus.com/ecos/
[17] http://www.redhat.com/products/edk/edk_desc.html
[18] http://www.gordian.com
[19] http://www.sun.com/chorusos/
[20] http://www.ghs.com/products.html
[21] http://www.jmi.com
[22] http://webservice.mcb.net/jmi
[23] http://www.psti.com
[24] http://www.esmertec.com
[25] http://www.atinucleus.com/intro.htm
[26] http://www.on-time.com
[27] http://tron.um.u-tokyo.ac.jp/TRON/ITRON/home-e.html
[28] http://www.zentropix.com/products/realtimelinux
[29] http://www.ucos-ii.com
[30] http://www.microware.com/Products/Software/OS9.html
[31] http://www.dexdyne.com/products/products.htm
[32] http://www. fda.gov/cdrh/comp/swareval.html
[33] http://www.fda.gov/cdrh/ode/1252.html
[34] http://www.vdc-corp.com
[35] mailto:twburger@bigfoot.com
[36] http://www.medicalelectronicsdesign.com/mem/archive/00/10/contents.html