Global Sources
EE Times-Asia
Stay in touch with EE Times Asia
EE Times-Asia > Embedded

Designing medical devices with real-time kernel

Posted: 28 Sep 2011 ?? ?Print Version ?Bookmark and Share

Keywords:medical device? real-time kernel? interrupt service routines?

An example kernel-based ISR is shown in figure 4. The line in the ISR reading "Signal USB task" would correspond to a kernel function call in an actual application. This call could be used to notify the task of an available USB packet and to enable the task to run. Based on the call, the kernel could conclude the ISR by switching to the signaled USB task, instead of returning to the task that was originally interrupted.

The ability to signal tasks from ISRs is important, because it allows developers to keep ISRs brief without sacrificing performance. In a foreground/background system, code that has been moved from the foreground to the background must wait its turn to execute, just like everything else in the background. {pagination007D

In a kernel-based application, however, signaling can be used to write tasks that promptly respond to events, such as the reception of a USB packet. There are multiple data structures through which a kernel can implement signaling, but the most common is probably the semaphore. Essentially, a semaphore is a counter that tracks the occurrence of events: a zero value corresponds to no activity, while a non-zero value means that events have taken place. This data structure is managed not by application code but by the kernel and is tied to the kernel's scheduling mechanisms. If a task calls a kernel function to wait on a particular semaphore and that semaphore's counter has a zero value (meaning that the event associated with the semaphore has not yet occurred), then the kernel begins running other tasks.

Figure 4: ISRs in a kernel-based application are capable of signaling tasks.?

Semaphores and other data structures used for signaling are part of a kernel's synchronization services.

The primary job of a kernel is to manage tasks, but most kernels also offer a variety of other services. In addition to synchronization, these services typically include inter-task communication (which often involves providing queues for message passing) and mutual exclusion. Together, the services allow developers to use a kernel to put together robust multitask applications.

The various services common to real-time kernels are available to developers of practically any type of product. In determining if a kernel would meet their needs, though, developers in the medical field must weigh the benefits that these services could bring against risks that don't exist in every other industry. Perhaps the most obvious potential downside to kernel use in a medical product is the need for additional certification work. Typically, the software used in a medical device is required to undergo a certification process that involves extensive testing. The cost of this process is commensurate with code size; the addition of more code in the form of a kernel means more money must be spent on certification.

If kernel use necessarily entailed going through the complete certification process for an entire kernel, then many developers might be better off taking their chances with a foreground/background system. However, a handful of the commercial real-time kernels that are currently available to developers have a history of use in medical devices. Accordingly, these kernels have already been through the certification process, and the documents that would be needed in order for them to again be used in a medical product have already been generated. By selecting one of these kernels, developers can avoid uncertainties relating to certification efforts.

Beyond certification, an issue that should be examined by developers of medical devices who are deciding whether or not to use a kernel is code complexity. In particular, developers addressing the question of kernel use should consider how many different features their application will incorporate and how many peripheral devices their code will be responsible for managing. Modern medical devices can be incredibly complex; a device used primarily for taking patient measurements might also be capable of displaying the results of the measurements on an LCD, storing patient data on a USB flash drive, and communicating with a hospital via TCP/IP. A kernel, by enabling developers to easily divide these responsibilities amongst different tasks, affords a means of managing the complexity.

For developers of battery-powered medical devices, power management is an issue that is just as important, if not more so, than code complexity and management of peripheral devices. A kernel can be highly useful in projects demanding power efficiency, in part because of the multitask structure of a kernel-based application. In a foreground/background system, code enabling a transition to a low-power mode may need to be inserted at multiple locations where the application waits for data or for an event to occur. In a kernel-based application, though, the low-power code is typically needed in just one task: the idle task that the kernel executes when no application tasks are able to run. Most kernels provide some sort of hook function that allows developers to easily customize the idle task with their power-management code.

The benefits of kernel use, including assistance in dealing with complexity and managing power, are not always obvious. However, any developer who has struggled to implement a high-performance, full-featured product around a foreground/background system knows that this application structure is not suitable for all projects. Even in the highly regulated medical field, a real-time kernel can help developers avoid the problems associated with foreground/background systems.

Although most kernels provide somewhat similar services, only a few of the kernels currently available to developers are suitable for medical applications. The kernels belonging to this select group have a history of use in medical devices, and have undergone the rigorous testing required to certify software for such devices. Developers who chose such a kernel substantially increase their odds of completing their next medical project on schedule and under budget.

About the author
Matt Gordon is a senior applications engineer at Micrium. He has several years of experience developing kernel ports, device drivers, and example applications for Micrium's customers. Drawing on this experience, Matt has written multiple articles on embedded software. Additionally, he has led Micrium's training program since its inception. Matt holds a bachelor's degree in computer engineering from Georgia Tech.

To download the PDF version of this article, click here.

?First Page?Previous Page 1???2

Article Comments - Designing medical devices with real-...
*? You can enter [0] more charecters.
*Verify code:


Visit Asia Webinars to learn about the latest in technology and get practical design tips.

Back to Top