Selecting an RTOS for an embedded application can be a complex process. If the embedded system is a medical device, that decision becomes even more complicated because the device’s operation has life or death implications. Therefore, it is incumbent upon the software developer to exercise extra caution during the selection process.
The four key areas to consider are:
- Safety: Does the RTOS contribute to the device’s safety or compromise it? Is it prone to user error?
- Performance: Can the RTOS facilitate the development of application code? Does the code perform within required parameters?
- Reliability: Does the RTOS impact the device’s reliability?
- Functionality: Does the RTOS have the facilities required to do the job?
Safety
No doubt safety is of paramount importance for a medical device and must be designed in at every opportunity. To some designers, it is not entirely obvious how an RTOS makes a contribution to the overall safety of the device beyond reliability. However, two areas are of particular interest in terms of RTOS safety: avoiding operator error and device certification.
Avoiding operator error
Designing a rational user interface is the best contribution the designer can make to avoid operator error. If the device only has buttons, lights, and sound, it’s best to include clear labeling to make sure there is a noticeable distinction between acknowledgements and error indications.
Many modern devices are fitted with high-resolution graphical displays like touch screens. With careful use, such an interface is ideal; the user can be led through operational steps with errors being avoided by means of carefully designed hierarchical menus and informational dialogs. Doing this requires hard work, so starting with a set of user interface services provided with an RTOS is advisable.
Certification
In most countries, medical equipment safety is ensured by a requirement to follow a regulatory procedure. The certification process is very rigorous, time consuming, and expensive, with the procedure looking at all aspects of the piece of equipment and the certification covering the complete device. Because the OS is one component, it cannot be certified by itself; it is part of the overall device software.
However, careful RTOS selection can simplify the certification process and reduce cost. The source code must be available, and the more readable and well-documented it is, the better. Availability means the code can be easily changed if modifications are necessary. Having the code readily available can directly affect cost. Because the total cost of certification is significantly related to the size of the code, a small OS memory footprint provides a definite cost advantage.
Performance
The obvious performance measure for an RTOS is speed. For a real-time application such as a medical device, the RTOS must respond in a timely fashion for the application to behave correctly.
But speed is not the entire story. An RTOS must be able to respond to a demand at the right time – not too late or too early. Real time means that an OS responds within a defined time frame. To achieve this, the RTOS must be truly deterministic (that is, have completely predictable behavior).
Size or memory footprint is another aspect of RTOS performance. Using less memory has clear benefits, but like speed, the measurement of size is not completely obvious. Most OS products are scalable, which means that only the code required for specific functionality is included in the final memory footprint. Looking for granular scalability in an OS is a worthwhile endeavor, as it minimizes memory usage.
Reliability
Building a reliable product involves using top-quality components and construction techniques. While this is evident for hardware design, the same ideas also apply to software development. Writing reliable software requires adhering to good design practices and selecting proven software components that have been deployed in numerous embedded systems with a successful track record.
Additionally, having high-quality tools like an OS-aware debugger and performance profiler available with the selected RTOS can help produce reliable code.
Functionality
The final consideration for choosing the right RTOS is whether it has the necessary capabilities. The kernel must support the required multitasking model with suitable scheduling alternatives. The rest of the OS is a set of options providing broad swathes of functionality. While this is a subject worthy of long discussion, a few areas stand out as particularly interesting factors when focusing on RTOS selection for a medical device.
Wireless connectivity
Dispensing with cables is a great convenience that streamlines operations. In a medical environment, decluttering cables has implications for hygiene and accident prevention, which are real concerns for medical facilities around the world.
Most wireless technologies utilize radio frequencies. Ensuring that the right data is transmitted and received is partly an applications issue, but also requires that the wireless connectivity stack be correctly implemented. Data security (maintaining patient confidentiality) requires that designers use the latest protocol components.
USB
Like wireless networking, the convenience of USB connectivity has resulted in its universal popularity. To operate correctly in accordance with USB standards, great care must be taken when implementing a USB stack. This is further complicated because a USB device can act as either a host or function. A USB host stack differs greatly from a USB function stack. Some devices must be able to work in both modes.
As medical instruments often need easy connectivity and interoperability, USB is a common choice (see Figure 1). Selecting an RTOS for such a device requires that all available USB stacks be fully certified and verified.
 |
| Figure 1: Innovative medical devices like a convertible ultrasound not only require a stable and proven RTOS, but also an RTOS with built-in middleware components such as fully certified and verified USB. |
Portability
The key to portability is the use of battery power. For an embedded device, the hardware design and the RTOS play important roles in ensuring that power consumption is reduced.
If the OS is small, memory use can be minimized. The less memory fitted, the less power consumed. If the OS is fast and efficient, the CPU’s clock speed can also be minimized, given that the processor clock’s frequency has a direct and profound effect upon power consumption. An efficient RTOS can make a lower-specification CPU viable and reduce power even further.
Finally, if the CPU or hardware design has power management facilities, which may switch off parts of the system and/or adjust the CPU clock according to demand, they are logically controlled via the RTOS. The greater the amount of power that can be saved, the longer the battery charge will last, ensuring the likely availability of a vital instrument when it’s urgently needed.
Making the safe choice
When developing a medical device, selecting an RTOS is a complex decision that has life or death implications. Paying careful attention to an RTOS product’s technical features as well as its track record in life-critical device implementations is the only safe way to proceed.
Many medical device developers have already taken these considerations to mind and used products such as Nucleus Real Time OS from Mentor Graphics, which offers a high level of deterministic, real-time performance with a very low bill of materials. Because Nucleus is market proven, software engineers can take confidence in their RTOS decision when developing their next medical device or application.