Medical Electronics Manufacturing Fall 1999
EMBEDDED SYSTEMS
Operating Systems: Exploring Windows CE for Medical Devices
Operating system standards can minimize costs and development time of devices and improve integration with synergistic devices and information systems.
Don Chouinard, Clifford Goldsmith, Geoff Hirsch, and Danelle Darroch-Conners
Imagine a world in which a hospital's office systems communicated seamlessly with its admittance system, patient monitoring devices, the central station, and the stat lab system. A patient's admittance information would be linked immediately to the patient monitor at the bedside. Irregular and critical changes in a patient's condition would be communicated instantly to the central station of nurses and physicians, as well as logged into the office system that records the patient's progress. Lab results would be accessible as soon as tests were completed. Hospital care workers would be largely freed from note taking, message running, and instinctual decision making by using embedded systems that connect seamlessly, reliably, and in real time (Figure 1).
Figure 1. Integrating hospital systems.
ADVERTISEMENT |
What is Windows CE?
Windows CE is a general-purpose operating system for small-form-factor devices, typically diskless systems with limited memory capacities. Unlike other Windows operating systems, Windows CE is modular to provide flexibility. Designers can custom-build the system for each product by selecting from a set of software modules. Selecting the minimum set of required modules and components that meet the system requirements enables OEMs to minimize the memory footprint, thereby reducing the cost of the device.
The operating system's platform builder provides the system libraries, tools, documentation, and sample code to enable medical device manufacturers to customize it for specific hardware platforms. The platform builder includes a device driver kit (DDK) and a software development kit (SDK). The DDK provides documentation and sample code for writing device drivers. The SDK provides libraries, header files, sample code, and documentation that enable developers to write applications for Windows CE platforms.

Figure 2. Windows CE architecture.
The operating system facilitates embedded system development from hardware design to operating system customization, as well as from selection of development tools to application programming (Figure 2).
Designing Hardware
Windows CE is portable to other architectures through its open adaptation layer (OAL). OEMs use the supplied kernel component, which is tailored for the supported microprocessor used in the device hardware. OEMs can implement, for example, hardware-specific power management, serial and parallel port functionality, interrupt-handling functions, a real-time clock, and an interval timer in the OAL.
Processors. The operating system supports a variety of standard processors, including MIPS, SH3/4, X86, PPC, and Arm/StrongArm processor cores, as well as many processors that are based on these cores.
Peripherals. Windows CE supports PCMCIA, PC Card, PCI, USB, and ISA buses. It can be used with myriad input/output (I/O) devices, including modem, Ethernet, serial port, parallel port, interrupts, keyboards, displays, flash, rotating media, wireless, touch screens, and voice. For manufacturers that require additional peripheral support, the operating system is extensible and ships with code samples that facilitate the writing of device drivers for custom peripherals.
Instant On. The operating system's power management functions enable devices with battery-backed RAM to be powered off and turned on instantly. Device manufacturers can design devices that turn off unnecessary hardware components in conjunction with the operating system's state transitions from full on to standby to suspend. The advanced power management function reduces energy consumption and bypasses warm-up times when turning on devices such as patient monitors, defibrillators, and ambulatory equipment.
Customizing the Operating System
Operating system developers can design a customized operating system for a specific embedded device. The Windows CE version 2.11 operating system includes support for Win32 graphics, windowing, event management, color, fonts, dialog boxes, shell, printing, sound, I/O, and files.
The operating system includes a built-in database, loadable device drivers, and loadable file systems. For real-time support, it has 32 protected processes and an unlimited number of threads. It also supports preemptive, priority-based scheduling on a single processor, includes eight priority levels, and handles priority inversion. A thorough discussion of real-time capabilities follows later in this article.
Small Size. The small memory and storage footprint of the operating system makes it suitable for diskless medical embedded systems. Because developers choose from various modules and components, a custom operating system with a kernel, file system, and registry can require as little as 256 Kbyte read-only memory (ROM) and 40 Kbyte random access memory (RAM). If developers add communications stacks, the footprint grows to 500 Kbyte. With windowing and graphics, the footprint reaches 1 Mbyte. A typical handheld PC with kernel, drivers, communications, file system, database, graphics, and shell requires a maximum of 2.5 Mbyte ROM and 600 Kbyte RAM.
Removing the need for a hard drive and a disk drive with a Windows CEbased embedded system increases the supportability and reliability of the system. With minimal moving parts, electronics are kept cool, reducing the maintenance requirements and decreasing the need for replacement parts. The operating system is designed to run on hardware that can withstand surgical environments that require moisture resistance and heat tolerance.
Low Power Consumption. Low power consumption ensures long battery life and low heat generation, eliminating the need for fans and contributing to the small size and weight of medical devices. The operating system minimizes power consumption by including power-up routines for device drivers and ports and enabling designers to select the lowest possible power processor.
Wireless Communication. The operating system supports a variety of communication protocols that enable embedded systems developers to integrate wireless communication capabilities into medical devices. Wireless handheld devices provide constant access to vital patient information. Providers can enter data such as observations and courses of treatment directly into the hospital systems. Windows CE supports TCP/IP, WinSock, IP Multicast, Dial-Up Networking, WinInet, SSL 2.0 and 3.0 for security, PCT, PPP, SLIP, CSLIP, PAP, CHAP, TAPI outbound, IrDA, and irSock.
Real-Time Capabilities
Windows CE, which supports a maximum of 32 simultaneous processes, is a preemptive multitasking operating system. As such, it allows multiple applications, or processes, to run within the system at the same time.
Priorities. A priority-based time-slice algorithm schedules the execution of threads. It supports eight discrete priority levels, from 0 through 7, where 0 represents the highest priority.
Levels 0 and 1 are used for real-time processing; levels 24 for kernel threads and normal applications; and levels 57 for applications that can always be preempted by other applications. Preemption is based solely on the thread's priority. Threads with a higher priority are scheduled to run first. Threads at the same priority level run in a round-robin fashion with each thread receiving a quantum, or slice of execution time. (The quantum has a default value of 25 ms. Modifications to this default are supported on MIPS platforms.) Threads at the highest priority level of 0 do not share the time slice with other threads at the highest priority level; rather, they continue executing until they have finished. The priority-based preemptive multitasking design of the scheduler ensures that a thread running at the highest priority can be guaranteed to execute within a known period of time.
Synchronization. Real-time systems must ensure that processes and threads are synchronized. Synchronization ensures that interaction between the application threads occurs correctly. A set of wait objects enables thread synchronization, such as critical section, event, and mutex objects.
Interrupt Processing. Real-time applications are designed to respond to external events within a specified time interval. Real-time applications use interrupts as a way of ensuring that external events are quickly identified by the operating system. Within Windows CE, the kernel and the OAL are tuned to optimize interrupt delivery and event dispatching to the rest of the system. The operating system balances performance and ease of implementation by splitting interrupt processing into two steps: an interrupt service routine (ISR) and an interrupt service thread (IST).
Each hardware interrupt request line (IRL) is associated with one ISR. When interrupts are enabled and an interrupt occurs, the kernel calls the registered ISR for that interrupt. The ISR's responsibility is to direct the kernel to launch the appropriate IST. Most of the interrupt handling occurs within the IST. The two highest thread priority levels (0 and 1) are usually assigned to ISTs, ensuring that these threads run as quickly as possible.
Interrupt Latency. Interrupt latency is the amount of time that elapses between the arrival of an external interrupt at the processor and the commencement of interrupt processing. Because ISRs are processed as soon as they occur, it is possible to imagine a case in which a constant stream of ISRs are generated, indefinitely postponing the start of IST. OEMs have complete control over the number of interrupts present in the system and can create a custom version of the operating system for a specific operating environment. Therefore, they can use constraints within the target operating environment to optimize the system design. To minimize latency times, device manufacturers can control the processing times of the ISR and the IST, interrupt priorities, and thread priorities.
With Windows CE 2.x, the worst-case start of ISR on a 75-MHz processor is less than 20 µs, the typical start of IST is 200 µs, and the worst-case start of IST is less than 500 µs. (Start of IST can be reduced to 100 µs with a 300-MHz Pentium processor, but this is usually not ideal for small-form-factor devices.)
Creating a Custom Device
The operating system provides a wide array of development tools. A platform builder allows designers to create a custom Windows CEbased device. Embedded developers can write custom drivers by using the sample OAL and device driver. A configuration tool enables developers to select only those components and modules required for implementing their operating system. A ROM image maker is also included for burning the custom operating system into an erasable programmable ROM. A remote debugger ensures that the operating system runs correctly on custom hardware.
A terminal emulator enables developers to write applications on a standard PC that can be run on a small device. Developers can use subsets of standard programming languages specifically geared for the operating system, including the Windows CE tool kit for Visual C++, Visual Basic, or Visual J++.
Programming Applications. Software content is playing an increasing role in embedded and dedicated systems. Because the operating system is a 32-bit operating system that adheres to the Win32 API, application programmers require little to no training to build applications on this operating system. Because Windows CE uses a subset of the Win32 API, existing Win32 applications or modules written for Windows NT and Windows 95/98 can be ported to Windows CE. Windows CE supports object-oriented programming through Microsoft's component object model (COM) and also provides a Web browser based on Internet Explorer 4.0.
The Export SDK feature of platform builder enables manufacturers to separate operating system work from application work. With the Export SDK, designers can automatically generate an SDK specific to their platform to be used by application developers. In this way, manufacturers of embedded systems for medical devices can enable in-house and external developers to write applications for custom Windows CEbased platforms.
Because Windows CE supports industry standard communications protocols, such as TCP/IP, Winsock, and dial-up networking through wired or wireless links, it can be integrated with Windows NT and Windows 95/98based office servers, query admission, discharge and transfer systems, central nursing stations, and laboratory systems.
Case Study. Data General (Westborough, MA), a supplier of servers, storage systems, and services for information systems users, recently completed development of a point-of-care (POC) device based on the Windows CE operating system. The WiiN-PAD provides POC technology to doctors, nurses, and other healthcare providers. The lightweight WiiN-PAD is designed for clinical applications such as acute patient care, ambulatory, emergency, and in-home care, patient registration, and materials management. The device supports information access through network and Internet communication channels.
The WiiN-PAD is designed specifically for communication with wireless networks and traditional local area networks (LANs) that support patient care information systems. It also supports the porting of applications from traditional environments to a mobile platform. A shell program enables application programs to be launched from the flash file system and provides an on-screen task bar for selecting menu items. An integrated digital camera enables the device to recognize bar codes and capture monochrome photo images for application use. The POC device supports a full-VGA backlit liquid-crystal color display and a choice of radio-frequency, LAN, and modem communication options (see photo, right).
A Standardized Future
The Windows CE 3.0 release is expected to provide improved real-time capabilities and native distributed COM (DCOM) support. With version 3.0, the time from interrupt to service thread will be 10 times faster than is currently possible with version 2.x. The goal for the start of IST is 50 µs for a 75-MHz processor.
Without operating system standards, device manufacturers create machines that are difficult to integrate with other systems. Medical device manufacturers develop systems and launch products that require additional integration work to connect with synergistic devices. Without standards, there are minimal exchange of ideas and product concepts, minimal interoperability, higher development costs, and increased maintenance costs. A standardized operating system reduces the need for device manufacturers to dedicate resources to developing proprietary operating systems, interfaces, and other tools. By using a standard operating system as the basis for their embedded systems, manufacturers can focus on building hardware and developing applications.
References
1. Lynne Barstow, "The Future: Looking Ahead to Windows CE 2.12 and 3.0," Start, July 1999.
2. Kimberly Gregory, Embedded Development With Microsoft Windows CE, Microsoft, 1999 (Redmond, WA).
3. Real-Time Systems With Microsoft Windows CE, Microsoft Technology Brief, 1997 (Redmond, WA: Microsoft).
Don Chouinard is marketing manager, Windows CE operating systems and tools, for Microsoft (Redmond, WA). Clifford Goldsmith is a consultant to Microsoft, and Geoff Hirsch is senior ISV account executive for Microsoft. Danelle Darroch-Conners is principal of Ink (Seattle, WA).
Back to the Fall 99 Table of Contents



