Buy or Build an RTOS: Does it Matter for Medical Devices? - Embedded.com

Buy or Build an RTOS: Does it Matter for Medical Devices?

Perhaps the most interesting thing about working with embedded systems is variability. Each device has a unique hardware and software architecture and its own individual functionality. As a result, it's a difficult challenge to design software development tools and operating systems that accommodate the enormous range of requirements.

And during tough economic conditions, it can be unwise for developers to compromise their core competencies by outsourcing. Developers are however, more likely to outsource non-differentiated components that are available commercially (Figure 1 below ).

Figure 1. As much as 30% of the design cycle is focused on non-differentiated activity.

Embedded Systems for Medical Devices
There are common characteristics that broadly encompass certain embedded device market segments. One such segment growing in prominence is medical devices and instrumentation.

The range of electronics found in a modern medical facility is staggering. Medical devices and systems range from gigantic machines that fill a room such as an MRI scanner, to portable and hand-held instruments, to implanted devices like a heart pacemaker. Every one of these is an embedded system.

When designing an embedded system, there are four key facets a software developer must keep in mind:

* Safety ” The well-being of the patient (and the medical staff) is of paramount importance. Whatever the other criteria applied to a design, compromising safety is not an option.

* Performance ” Most embedded systems have some performance criteria, but for many medical devices their performance can be life-critical.

* Economics ” The costs of healthcare are escalating worldwide. An aging population and advances in medical treatment are key drivers. Because electronics are behind many of these advances, controlling development costs is one of the keys to affordable healthcare.

* Functionality ” Obviously the point behind designing any device is to provide some specific set of facilities to the user.

In this article, we will look at how embedded software, in particular how the selection and implementation of a real-time operating system, impacts these four areas.

Safety
When a patient visits a hospital, he or she is expected to find relief or a cure without being harmed. Medical facilities are obligated to operate with the patient's safety in mind. This dictates a clear set of standards for safety in instruments and systems. But what about embedded software?

Usage . Nowhere can operator error be more costly than in medicine. There are many different devices made by different manufacturers which operate in many different ways.

These devices are used in high-stress environments often by an over-stretched and exhausted staff. It's hard to imagine a doctor, who has been on duty around the clock, carefully studying the manual for each piece of equipment required for use.

It is essential that any “smart” medical device has an intuitive user interface (UI). Increasingly, UIs are being implemented as high-resolution graphical displays with well-structured menus and multimedia capabilities. Developing software to render a high-quality UI is no easy feat.

UI development packages must be available with commercial operating systems to offer a cost-effective way to build state-of-the art UI features into sophisticated medical devices.

Reliability . Hardware designers of medical devices choose highly reliable components. Similarly, building reliable software should use field-proven components such as a commercially available and widely deployed operating system (OS) which is suited for the job at hand (i.e. real-time instead of desktop derived).

It is not acceptable for a medical device to require frequent power cycling in order to “reset.” Popping up a dialog box that reports that an obscure error has occurred is not an option.

Proof . What makes a device “safe?” In most countries, regulatory bodies test and certify that equipment complies with a specific standard. The certification of software is a complex and expensive process, typically applied at the system level. So it's just not possible to purchase a “certified real-time operating system (RTOS)” as this would be one component utilized in a complete application.

However, three factors improve the likelihood of achieving certification depending on the RTOS. One is to start with an RTOS that has a proven track record of passing device certifications. The second is the question of size–the cost of software certification is directly related to the amount of code it contains.

A highly scalable OS with small footprint would clearly be beneficial in keeping costs down. And third, the availability of source code for the OS facilitates easy modifications during the certification, and enables ultimate control over exactly what code should be included in the final design.

Performance
For many types of systems ” like desktop computers ” performance can be increased by simply throwing more CPU power or memory capacity at it. However, for many embedded systems ” and definitely most medical devices ” such an approach is not an option. Instead, a target performance must be realized using the most modest CPU and smallest amount of memory. This is achieved by efficiently running software built on the foundation of a “fast” OS.

Most medical systems run in “real time.” This does not necessarily mean they are fast, but rather they respond within a defined timeframe, which is characterized as predictability or determinism. The response to an event must occur on time ” not too early or too late. The first step in achieving predictability is to use a deterministic, or true real-time operating system.

Economics
The medical device and system market is highly competitive and minimizing cost is paramount. A few cost areas to consider:

Development Costs . The development process of a medical device is impacted by many factors. Perhaps most important is time-to-market performance. Software design, development, and certification must be completed in a very tight window.

Reuse of proven software, such as a real-time operating system, can speed the process. Developing an RTOS in-house is expensive and demands a long-term commitment to support.

Using a commercial OS also eases compliance with a wide range of standards, and can simplify and reduce the cost of the certification process. Knowing that the code has been certified successfully on previous occasions is critical to keeping development costs down.

The hardware/software integration phase is often the most demanding, yet is typically sandwiched between the final product release date and late availability of the prototype hardware.

Manufacturing Costs . Efficient software that runs in a smaller memory footprint and with a lower-spec CPU cuts down the cost of components resulting in reduced bill of materials. A commercial real-time OS helps in this regard and if its business model is flexible, it will not negatively impact costs itself.

Functionality
It is the essential role of application software to deliver specific device functionality. However, there are certain instances where the implementation of required functionality can be particularly taxing.

Device Support. Device support is one of the more interesting challenges of embedded software development, the consequence of working close to the hardware. Programming to accommodate the peculiarities of a hardware device is a skill that is in short supply.

The good news is that most electronic designs rely on commercially available standard peripheral devices. Driver software for these devices is readily available for most commercial operating systems. Using proven code that has been deployed many times before makes the hardware/software integration task much simpler.

Portability .An increasing number of medical devices require portability. Although portability begins as a hardware requirement, it has significant implications to the software. The key issue is reducing power consumption in order to maximize the useful battery life. Software can contribute to portability in a number of ways:

* Reduce memory size ” Minimizing the software memory footprint reduces the amount of memory required, thus decreasing power consumption. A commercial OS is likely to be compact and scale efficiently so that only the code that is used gets configured. Figure 2 below illustrates a hypothetical OS that has 271 service calls available and an application that uses just three of these calls.

* Efficient CPU usage ” Efficient software may run satisfactorily on a CPU at a lower clock frequency, which can have a dramatic affect on power consumption. It may even be possible to use a device of lower specification and still achieve the required performance. An efficient real-time OS ensures that the right code is run at the right time and does not introduce any significant overhead in doing so.

* Power management ” If the chosen CPU (or hardware design) supports active power management, the operating system can take control of this facility. Power management enables parts of the device to be powered down when not in use, or the CPU clock speed to be adjusted dynamically according to the usage.

Figure 2. Scalability: Only required OS service calls contribute to memory footprint

Connectivity . Increasingly medical instruments and systems are becoming more connected. There is a wide selection of connectivity technologies that can be deployed, but two in particular come to mind as being both useful and challenging:

* USB is the most ubiquitous protocol today for connecting computers to peripherals. The software that handles USB protocols is very sophisticated. Class drivers are needed for different types of devices.

This is further complicated because a USB device might be a controller (“Host”) ” as a PC normally is ” or it might be a peripheral (“Function”) each of these requires a different protocol stack.

It's even possible that a medical device could behave as both a Host and a Function. When choosing among USB stacks available alongside a commercial real-time OS, it's critical to select a “USB certified” implementation.

* Wireless networking takes on various forms from point-to-point connections such as Bluetooth and ZigBee, to peer-to-peer networking like WiFi (801.11 protocols). The benefit of medical devices communicating wirelessly goes far beyond convenience.

The de-cluttering of cables has implications for hygiene and accident prevention in hospitals, which are real sources of concern around the world. But wireless networking can't compromise safety and security. To ensure security, it's essential that patient data is broadcast in a way that prevents eavesdropping. Encryption is available in various forms, including the 802.11i protocol. Some commercial real-time OS vendors offer complete pre-integrated WiFi solutions.

Conclusion
As with most embedded applications, the development of an electronic medical device requires the consideration of a wide range of issues both technical and commercial. Having the right technology to work reliably, achieving certification, and getting to market on time with the right product ” at the right price ” are together, quite a feat. Reuse of available proven technology is just common sense, and a commercial real-time operating system is a good place to start.

Colin Walls has over twenty-five years experience in the electronics industry, largely dedicated to embedded software. A frequent presenter at conferences and seminars and author of numerous technical articles and two books on embedded software, and based in the U. K., Colin is a member of the marketing team for the Nucleus Real Time OS and the EDGE Developer Suite in the Mentor Graphics Embedded Systems Division.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.