No one operating system is right for every medical device. Deciding whether you need an RTOS, a general-purpose OS, or whether you should “roll your own” depends on the features and functions you require.
The energy and finance worlds were forever changed by the events that surrounded Enron and their desire to make huge profits, which resulted in the creation of the Sarbanes-Oxley Act and increased industry regulation. Clearly, there was a need to prevent companies from becoming what Enron had become. The same might also be true for the medical device industry. Look no further than the Therac-25 incidents in the mid-1980s, when the equipment manufacturers were blind to the fact that their equipment was causing permanent damage and even death because the machines were not well founded in their engineering and were assumed to be correctly architected and adequately safeguarded. Those assumptions of correctness proved fatal. We must hold medical equipment that’s designed to either diagnose or administer therapy to a higher standard than say, a multimedia player, where it may skip a beat, but it will not cause harm to a patient.
Further, modern medical devices are becoming more complex and have more features than those of the past. How do we build these new systems to meet future demand? And how do we make sure that the system software that controls these devices won’t harm the patient?
The medical industry has many different kinds of devices that vary in size and complexity. While some devices are used purely for data collection, others are used for more critical tasks like administering therapy, including many that are regulated by the FDA (Figure 1).
1. As these categories indicate, devices with the potential to cause harm must be regulated by the FDA. Most of today’s software-controlled devices fall under the moderate and major categories.
A medical embedded device is usually managed by some sort of operating system (OS). The OS can vary from a simple “roll your own” execution loop to a more complex home-grown OS managed and maintained (hopefully) by someone in your organization. Another type of OS is the general purpose operating system, such as Linux or Android. A general-purpose OS provides a feature-rich platform for application development, but is often quite large with many contributors. There’s also the real-time OS (RTOS), where there are specific requirements that the system may need to provide, such as a deterministic preemptive kernel. Somewhere in the mix is an ideal candidate for your application and hardware. But one thing is certain—one size does not fit all.
We must first consider the use cases. How will the system be used? Will the device be used primarily by a healthcare provider, by the patient at home, or both? What about manufacturing? How will the device be tested and how will the data be collected for use during product creation? What about special service modes that allow access to only a trained technician? Are there special modes that are only available for testing and manufacturing? How do you provision a device for use inside a hospital where security is paramount whenever patient data is involved?
Does the device have communication modes, or is it purely a stand-alone device? It’s also important to think about power use cases. Will it be wall powered, battery powered, or both? Are there charging cycles? Is the device usable when it’s charging?
When looking at manufacturing, what is the device’s expected unit volume? If the unit volume is large, there may be sensitivities to the bill-of-materials (BOM) costs. If it’s a consumer device, you may need to consider price point sensitivities. Perhaps the device is a critical piece of equipment, which reduces the sensitivity to cost. These considerations will directly affect the need to minimize the BOM, which in turn, results in possibly minimizing the memory you’ll need to effectively build the complete application with some margin. Systems that employ a general-purpose OS typically aren’t as sensitive to the memory footprint and the cost of memory is outweighed by the need to have all the middleware available in a general-purpose OS.
Are there any real-time needs identified? For some devices, there’s no requirement for real-time behavior. If an interrupt is serviced 100 ms late, it may cause the results to be delayed by 100 ms, but that won’t cause a failure. However, if it’s a laser involved in eye surgery, this can have catastrophic effects if the laser doesn’t turn on and off at the appropriate time. Or if the laser has eye tracking guidance, then it must move in lockstep with a predefined pattern to improve eyesight.
Is there a need for fault tolerance? A huge consideration might be whether the system can withstand an application crashing and a subsequent restart of an application, and continue operation. While you can’t tolerate the laser doing something to harm the patient, it may be okay to delay the laser pulses for a few seconds while a portion of the application restarts.
Is there confidential patient data on the device? If so, how does it get handled with regard to HIPPA? Patient data must be secure and available to doctors and nurses, but (possibly) no one else. While records are transferred from the device, is it securely encrypted to maintain confidentiality?
Identifying the hardware
Once the use cases have been defined, it’s time to scrutinize and find the appropriate hardware platforms. Medical systems can be extremely small, with an 8-bit microcontroller (MCU) clocked at less than 25 MHz and only 8 kbytes of memory, to more feature-rich SoCs clocked at hundreds of MHz and multiple megabytes of memory. Some hybrid systems have special-purpose processors or DSPs, or SMP-capable multicore chips. What’s best for your design comes from the use cases and expectations for how the system behaves.
An 8-bit MCU with a basic scheduler may be all that’s needed to measure a patient’s vitals and report it to a host computer with a basic display. But is that ideal? Looking back on the Therac-25 incidents, some of them were caused by a faulty user interface (UI) that wasn’t intuitive and actually reported bad data.
If the system displays data directly to a user or physician, then using hardware that can handle a more complex, feature-rich UI may be ideal for minimizing confusion during the device’s operation. Today, a single-core SoC with a DSP is common, but multicore CPU SoCs are entering this market in significant numbers. How will multicore be used in medical?
There are two main reasons for selecting multicore: pure processing speed or low power—or a combination of the two. Do you have a need for greater processing power in your application, even for short bursts? If so, then being able to employ several cores and balance the application across all the available cores may be a good thing.
Multicore for low power
Those who are concerned with extreme low power may want to use a multicore SoC simply because it can utilize all the available cores at a lower clock frequency rather than clocking a main processor at a much higher frequency. And when not needed, it can power down the extra cores to save power.
While both power and performance are good reasons to go to multicore, the question is more about finding the best way to allocate the CPUs. With symmetric hardware, you can use one OS across all the available cores as a type of symmetric multicore processing (SMP). Most general-purpose OSs (and some RTOSs) has this capability. But this complicates the scheduling across all cores as there may be some real-time hits due to cache misses in one core, which causes a cache flush in the other core, invariably leading to large delays in the system. There are some features common to all SMP-capable OSs like spinlocks, where if not employed correctly, a can cost in system performance as one core stalls for an indeterminate time waiting for the resource on another core to be freed.
The other way to build the system (even with symmetric hardware) is to apply asymmetric multicore processing (AMP) techniques. This involves two or more separate OSs interacting through some type of communication channel using hardware like a series of FIFOs or through shared memory. There’s a standard from the Multicore Association that makes the application development portable, called the Multi-Core Application Programmers Interface (MCAPI). This high-level protocol specification doesn’t specifying the communication layer, so today it is implementation specific. But once employed on both sides, an application using these APIs can easily migrate from one operating environment to another. Using AMP can simplify a design and keep things deterministic as each cache will be full of the data they care about and there’s no need for spinlocks. Also, you can deploy all the real-time tasks on the RTOS, and keep the UI and protocols on the side with the general-purpose OS.
Finally, a hybrid is available for systems that have more than two cores, where a combination of both SMP and AMP can be ideal (Figure 2).
2. Pictured is an example of an AMP multicore system using MCAPI for inter-processor communication.
If a multi-operating system environment is deployed, how do you protect one OS environment from the other? Some developers use a system called a hypervisor which virtualizes the different OS environments from the other, or there’s a master that owns the memory and manages the use of memory for the other system, depending on the type of OS.
Product example: glucose meter
Let’s look at a battery-operated, blood glucose meter with a user display (Figure 3). This device is not only meant for doctor use, but a large portion of diabetic patients rely on it daily to calculate proper insulin dosage. While the device isn’t administering the therapy, giving the wrong dosage can have adverse affects on a patient, so the need for being accurate in measurement, calculation, and display must be paramount.
3. The blood glucose meter pictured here is one example of a high-volume medical device designed specifically for personal use.
We need to start with our requirements for the device and answer the following questions:
A battery operated device needs to be frugal with its power use. If the user picks it up and it doesn’t work because the battery is dead, it’s a useless device until it’s charged, the battery is changed, or it’s plugged in.
The primary function of a blood glucose meter is to take a blood sample that the patient collects on a sample strip, and then process the sample to ascertain the current blood sugar level, and display the data in a relatively short period of time. It must be portable, battery operated, and communicate with a keypad (for input) and an LCD (for output), and a barcode scanner to associate the reading with a specific patient.
The user communicates with the device via the keypad as well as through the sample itself. The device also needs USB support so it can upload the day’s readings to a host computer for direct access from a physician who can check the readings and monitor for any abnormalities.
In the development phase, the hardware must be chosen to match the set of peripherals needed for the device. In this case, an ARM9-based SoC can be used with built in peripherals like the LCD controller and expansion ports like SPI or I2C to provide connectivity with the sensor.
Once the hardware has been selected, the system integrator must choose the system software. This involves assessing what architecture is appropriate for the design. Is a general-purpose OS in order, or are there specific requirements that may suggest an RTOS? Perhaps the system is simple enough that only a background loop with a simple scheduler is necessary.
Seeing the needs of the system and its responsiveness to interrupts is the measure of how “real time” the system needs to be. With modern SoCs, much can be accomplished with a fast CPU. But if you need the level of service provided by a low-latency preemptive kernel, an RTOS is probably your best choice. There are other reasons for selecting an RTOS. It has a smaller memory footprint than Linux or Android and accomplishes much of the same activities. And with less code in the operating system, an RTOS is better understood and easier to certify. Low power is another good reason to choose an RTOS, especially one that has the ability to control how power is being used and clock frequencies to maximize battery life.
A general-purpose OS can be a good choice if you need an application framework that’s feature rich with a large complement of middleware. An added benefit is the available pool of developers who know how to design applications around that OS. While a general-purpose OS supports SMP, not all RTOSs do, so if you’re considering multicore, you may want to ensure that the RTOS you choose supports SMP.
In an AMP framework, where several operating systems are deployed, all of the OSs must work together. This begins with provisioning the operating systems with the set of hardware devices they must each control and the software to interoperate. It’s critical to use this topology. Tools are a key part of the strategy. When you’re designing the system, having the ability to see a bottleneck in the lab may prevent a failure in the field. It’s important that the system software capture enough of the problem so that it can be diagnosed or analyzed to provide details on the problem.
In conclusion, it’s not easy making the right OS choice for your system. Having a compelling and intuitive UI can make the difference between a lay person being able to use the device successfully or having him guess wrong and suffer unintended consequences. Having a system that’s power aware and able to harness all the horsepower available when necessary is also critically important.
While there’s no ideal system software case for all medical devices, there is a choice that each designer must make. Choosing to build your own system in-house may seem to be the right call, but is that really where you want to invest? You understand the medical domain in which the product is destined to work. Unless the product is using a microcontroller where an RTOS may not fit adequately, then using off-the-shelf or open-source system software may keep you from creating, enhancing, and maintaining the system side of things, which could ultimately prevent you from focusing on your product’s core functionality.
Stephen Olsen is a technical marketing engineer for Mentor Embedded, Mentor Graphics’ embedded software division. He has over 20 years of embedded software experience. During his tenure at Mentor, Olsen has co-chaired VSIA’s Hardware dependent Software (HdS) design working group, worked on the MRAPI specification for the Multicore Association, and authored several papers on system design and power management. He holds a BS degree in Physics from Humboldt State University in California.