EMBEDDED SYSTEMS
A Comparison and Analysis of Software Development Platforms for Embedded Computer-Controlled Medical Devices
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.
|
|
ADVERTISEMENT |
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.
| Embedded System Development Assistance |
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 real-world 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" into—the 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 time-stamping 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 |
Microsoft Corp. (Redmond, WA): Windows CE and NT Embedded. Windows CE was originally, in the first release, Windows 95 with much 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.5–2.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
Real-Time Systems with Microsoft Windows CE 2.1
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 source-licensing 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
QSSL Medical Applications
QNX Technical Support
LynuxWorks (San Jose, CA): LynxOS RTOS. LynxOS is a hard RTOS designed for mission-critical applications such as flight control systems. LynxOS is UNIX and POSIX compliant and supports Java.
Wind River (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 (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. (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 is a full Linux distribution with modifications and tools to allow development of embedded systems in full PC architectures.
GORDIAN (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. (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 real-time and Java technology–based applications.
Green Hills Software Inc. (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. (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.
Precise Software Technologies Inc. (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. (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. (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 (Setauket, NY): RTOS-32. This Win32/NT-compatible RTOS uses a Windows NT subset. It is available for Intel x86–compatible embedded systems. The RTOS is royalty free, and source code can be purchased.
Sakamura Laboratory, University of Tokyo (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 (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.
Micriµm Inc. (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. (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 (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 computer–controlled 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," 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 [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. [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.
Back to the Fall 2000 Table of Contents
