Operating Systems
A Critical Look at Embedding Windows into Medical Instrumentation Applications
Windows is the most widely available operating system for the PC platform, but what are its benefits and limitations for deterministic responsiveness?
Kim Hartman
Trade and business publications are full of articles about mission- and time-critical applications. Discussions of real-time operations abound in manufacturing, communications, power generation, stock transactions, and data storage and transfer—the list is endless. Today's jargon degrades the expression real time to mean something that is merely "live" or "dynamic." However, the term, as it relates to hard real-time, deterministic, submillisecond executions, is vital to the design and development of medical electronics.
The market for medical instrumentation demands that hard real-time systems be based on a platform with proven reliability, longevity, and rock-solid performance. Beyond product requirements are some basic but vital business considerations. As with any application, the key to profitability lies in reduced development costs and faster time to market with a versatile and flexible architecture. When exploring the hardware and operating system (OS) architecture on which to base a medical device or instrumentation, there are many essential considerations such as the following:
- How much does the core hardware cost? Is it necessary to adopt a custom-designed platform or will a standard PC-based architecture be sufficiently secure and robust?
- Should the system be based on an obscure OS or a mainstream OS? How easy is it to find developers who are fluent in the chosen OS? Is it affordable to cultivate custom-built engineering resources—both internal and outsourced?
- Can the development environment be simplified so that common tools and languages can be used consistently across all elements? How easy will it be to design upgrades?
- How much will it cost to stay on the technology treadmill—managing hardware and software component obsolescence?
- What about the user interface? Can it be built on standard tools? Will customers find it easy to use? Can it be readily customized?
- Customers might need to integrate the product into their existing workflow. How will this influence OS selection?
- What about networking? Will the system be isolated or does it need to connect to other systems?
When exploring possible architectures, it is wise to perform due diligence on the state of the technology. The PC/Windows OS architecture has sizeable market share in the embedded systems industry. Leveraging this standard platform can reduce time to market as it delivers reduced system complexity, uses standardized tools, and makes outsourced engineering talent more readily available. In addition, it renders a familiar user interface and integrates easily with third-party applications and networks. For example, a picture archiving and communication system (PACS) image database manager might be layered right onto the acquisition instrument that feeds directly into the user's standard communication protocol to exchange data files (such as patient records) or graphic files (such as x-rays).
RTOS: A Step Beyond Windows
Windows is quickly becoming the preferred platform for building highly intelligent automated systems. It is full featured, reliable, and secure, even in the rigors of the medical environment. As capable as the Windows OS is, it is not built for deeply embedded applications. The Windows kernel has been optimized to balance system performance and response time.
Although Windows is capable of providing fast overall response times, it is not appropriate for applications requiring hard determinism. For example, a Windows application thread, regardless of its priority, is susceptible to being preempted by any interrupt source—including something as simple as a mouse interrupt or as problematic as a 700-millisecond video driver.
Windows XP Embedded is a tool set developed to manage the OS build. This is critical to a disciplined development organization (especially in medical instrumentation) that needs to know exactly what is in the build—nothing extraneous, unknown, or undocumented. But for all of its advantages, Windows XP Embedded still does not address determinism. Although the number of processes available for Windows to run can be controlled, the system's overall determinism cannot be controlled.
Masking interrupts for time-critical tasks is not possible without resorting to writing Widows kernel-mode applications. In the Windows kernel, there is a mechanism known as the deferred procedure call (DPC). When handling interrupts, it is typical to perform as little as possible in the interrupt service routine (ISR) and then queue a procedure containing additional processing for later execution. The DPC is placed into a queue on a first-in, first-out (FIFO) basis with no provisions for priority. This means that a low-priority DPC will be executed first if it is the first in line, regardless of the priority of DPCs queued behind it. In addition, DPCs will not be able to execute until all interrupts cease—even low-priority device interrupts.
Window's thread synchronization mechanisms (e.g., semaphores and mutexes) are FIFO based, not priority based. Therefore, two threads waiting for the completion of an operation will get a chance to run based on the order in which they entered the waiting queue, not based on the priority of the threads. Win32 is an extensive application program interface (API). However, many of the calls (especially the graphical user interface [GUI] portion) operate in a synchronous manner so that the threads are blocked until the called operation is completed.
) |
|
Figure 1. Standard Windows
soft real-time capabilities can be enhanced by a hard real-time extension.
(Click to enlarge) |
Real-time tasks may be held off from completion until other lower-priority activities are completed. This means that any thread that uses these calls is at the mercy of other (lower-priority) threads in the system. Because this priority inversion is not a documented feature of the Win32 APIs, using any native Win32 APIs may compromise the determinism of the application.
With this in mind, developers often design multiple computing subsystems—one that handles the soft real-time execution of networking, user interface, and other noncritical functions, and another that performs time-critical, or hard real-time, executions (see Figure 1). These executions may be simple, such as reading a pressure transducer timed to the millisecond, but they are vital and should not be interrupted by any noncritical operations.
The time-critical subsystem is controlled by a real-time OS (RTOS) that works on top of, inside, or in parallel with the resident Windows OS. A hard real-time system can be described as any system in which a timely response by the computer to external stimuli is vital. An OS must include the following elements to be considered an RTOS:
- The OS must be multithreaded and preemptive.
- The OS must support thread priority.
- The OS must support priority inheritance.
- The OS must support predictable thread synchronization mechanisms.
Options for Real-Time Windows Environments
Suppose that a decision has been made to base an instrument or device on the PC/Windows platform, what are some options for achieving real-time control?
Restrict Windows to Soft Real-Time Applications. If the application can function with missed events and with timing variations averaging in the 1–20 millisecond range, then Windows can be used for soft real-time control. In this application, the cost of missing deadlines should be minimal.
Create a Finely Tuned, Highly Constrained Environment. This requires a very high skill level of Windows programming. By creating a closed system, Window's unpredictable behavior can be limited. Most of the application will probably be written in Windows kernel mode. Developing any substantial applications would be very difficult, neutralizing the benefits of using Windows and resulting in code that is difficult to create and support.
Provide a Win32 API Wrapper Around an RTOS. This approach does not leverage Windows; it merely provides an alternative API to an existing RTOS. Standard Windows applications cannot be utilized with this approach, which limits available options for future expandability. Because the target system is not Windows, specialized tools must be used for development. Moreover, it would be difficult for product modifications to keep pace with changes and upgrades to Win32 as they are introduced.
Couple an RTOS with Windows on Separate Hardware. This usually refers to running Windows and an RTOS on physically distinct systems. This scenario increases the cost of the total system by requiring at least two separate computers. The developer must also overcome the differences between two APIs, work in multiple development environments, and deal with the slow and difficult coupling of application parts.
Modify the Windows Kernel. Windows offers a variety of mechanisms to protect processes and threads from each other. The protection mechanisms result in improved reliability in Windows. However, these features are only available to user-mode (Ring 3) or application-level programs.
) |
|
Figure 2. User-mode programming
is suitable for developing reliable real-time programs.
(Click to enlarge) |
Kernel-mode (Ring 0) programming, which is required for device drivers, gives programmers complete access to the entire address space, including access to the kernel itself. (See Figure 2 for a comparison of Ring 0 and Ring 3.) Some real-time solutions essentially create a real-time scheduler or device driver inside the Windows kernel to manage timing priorities.
Although kernel-mode programming can offer the developer greater access to hardware and process timing control, it comes at the cost of reduced protection. Because the real-time object code lives inside Ring 0, it is not buffered from faults of any type. This makes writing any substantial real-time applications in Windows kernel mode impractical for all but the most experienced developers, and a risky proposition at best. A Windows blue-screen crash means that the kernel is no longer functioning, and therefore neither are any applications and device drivers. In certain control applications, this can have catastrophic consequences on equipment and, potentially, lives.
Complement the Standard Windows Kernel with a Real-Time Kernel. Solutions that claim to bring hard real-time performance to Windows must provide an alternate kernel to handle real-time task scheduling and execution. The alternate kernel runs in conjunction with the standard Windows kernel. In fact, the three major solutions to real-time Windows available on the market today have taken this approach. Introducing such a kernel into the Windows environment, however, may actually decrease system reliability unless the kernel is at least as reliable as the Windows kernel. Therefore, it is critical that the real-time kernel be proven in real-life applications, with extensive testing that can only come through repeated usage over time. Other important considerations are memory and address space protection, as well as the ability to survive catastrophic system failures (Windows blue-screen crashes). Finally, clean integration with the Windows environment (e.g., leveraging the same development tools and APIs when possible) is critical for the general usability of the solution.
Complementary Real-Time Kernels
Specialization in a machine's architecture sometimes requires that elements of a real-time system be distributed, physically, from the center of logical operation.
In many cases, an RTOS requires dedicated, redundant hardware for operation. These systems are necessarily expensive and complex. However, there are real-time extensions available that use the same hardware without compromising real-time performance. These extensions essentially divide one cpu into two separate virtual machines, both sharing the same silicon. These real-time solutions make Windows an entirely suitable OS for medical instrumentation applications.
) |
|
Figure 3. Two virtual machines
can be crated on a single cpu for a reliable real-time control solution.
(Click to enlarge) |
In the real-time solution shown in Figure 3, a Windows extension application interface (NTX) facilitates both communication and synchronization between real-time processes and non-real-time processes. Access to the hardware abstraction layer (HAL) has been modified to guarantee system determinism, even from within Windows. Most important, the system manages the concurrent operation of both the Windows and real-time kernel.
Unlike real-time device drivers that reside within the Windows kernel, once the hardware has been divided into virtual separate machines, there is isolation and protection between the two kernels. The real-time system encapsulates Windows as the lowest-priority task, enabling transparent, simultaneous operation of Windows and the real-time kernel while giving priority to real-time operations. Because the real-time kernel and Windows system are implemented as separate hardware tasks, address isolation between Windows and the real-time subsystem is maximized. The use of distinct descriptor tables and unique memory segments and page directories provides further protection. If there is a catastrophic failure in the Windows kernel, it will not affect the real-time kernel. Interception of HAL access guarantees real-time interrupt determinism and traps attempts to modify the rate of the system clock and hardware interrupts reserved for real-time threads.
A key advantage to this approach is that real-time applications based on creating separate virtual machines have numerous memory protection mechanisms. In a virtual-machine solution, real-time applications can take advantage of the address isolation features of the cpu itself. The real-time kernel uses these features to isolate each real-time process from all other real-time processes, and from the whole of the Windows system. If a thread attempts to access an address outside of its virtual address space, a fault is generated. The fault is handled so as not to affect other processes. In contrast, solutions that require real-time threads to run in the context of the Windows kernel have no address isolation between multiple real-time processes or Windows kernel resources; any faults that occur can have a catastrophic effect on the entire system.
Windows Benefits
Adopting a PC/Windows architecture can be beneficial in many ways:
- It is the leading general-purpose OS—robust and fully featured.
- It delivers a standard, powerful GUI.
- It provides seamless connectivity for enterprise-level networking.
- It gives access to thousands of third-party applications—and the engineering talent that develops them.
- It has available extensions to accommodate real-time control for time-critical executions.
Adopting an RTOS
When adopting a RTOS to complement the PC/Windows platform, consider the following:
- How important is protection and reliability to the system?
- How will the real-time system chosen affect the cost of goods?
- How tightly coupled are the RTOS solution and the chosen hardware (cpu)?
There are several alternate real-time kernel solutions available in which the heavy-lifting programming has already been done. So perhaps the most important consideration is this: Should resources be expended programming within the Windows kernel or should a real-time solution be utilized? A real-time solution can allow resources to be redirected to efforts that make a product unique, affordable, and first to market.
Kim Hartman is director of sales and marketing at TenAsys Corp. (Beaverton, OR). She can be reached at kim.hartman@tenasys.com.
Copyright © 2002 Medical Electronics Manufacturing
