Android is the best operating system choice for many medical applications

Android stacks up well against the traditional competitors when developing medical devices.

Interest in “heavier” mainstream operating systems (OSs) such as Windows, Windows CE, and Linux for use in medical devices has grown dramatically in the past decade, and particularly in the past few years. This interest is driven by several factors. Today’s device users desire rich, sophisticated interfaces and many developers are experienced in using these OSs and related tools on desktop PCs and servers. Until recently, if one wanted to use a full-featured OS for medical embedded development, there were two typical choices: Microsoft Windows CE (and occasionally desktop Windows itself) or Linux (or other Unix variant).
Of these two, Windows CE has the advantage of being a fully integrated development platform, from device drivers all the way up through the application framework. Some developers may not be enamored of Windows CE, but few would argue against it being a fast and easy way to get a project started with minimal hassle. CE has disadvantages as well: there’s a royalty for use and the code base is controlled by Microsoft. Note that the latter carries some benefits as well.
Linux and other Unix variants have the advantage of being free and open source, but there have traditionally been significant hurdles for their use in embedded devices, particularly in devices with sophisticated user interfaces. Linux is designed as a desktop/server OS, and typical distributions contain lots of features (megabytes and CPU cycles) that are rarely if ever needed in embedded systems. Thus, starting a new embedded project in Linux has traditionally required several person-weeks of creating a lightweight software image with the desired subset of functionality, and with additions appropriate for embedded use. And while hand crafting the Linux image goes a good way towards optimizing things, the result is still not fully optimized—many important bits can’t be pared down from their desktop orientation and are inefficient in their use of memory, CPU, and/or power.
So, the choice has been to use a proprietary system that’s easy to get started with (Windows CE), or a free and open system that requires a good bit of work to get started (Linux and brethren).
Google’s Android OS is a relatively new player in the embedded space. Fundamentally, Android’s purpose is to build on the Linux OS by providing a full-featured embedded systems framework. In short, Android aims to bring to the Linux/free software world the same out-of-the-box, ease-of-use found in Windows CE.
Android was first released by Google in November 2007, as an OS targeted at smart phones. Its success has been phenomenal: in less than three years, it’s become the most popular OS for smart phones, currently shipping on almost half of these phones worldwide. Android phones are shipping at a rate of almost 100 million per year.
Developers quickly recognized that Android has much to offer in embedded applications beyond phones. Most of today’s embedded devices share several attributes with phones: small form-factor LCD/touch screens, rich GUIs, low-power processors, broad connectivity options (cellular, WiFi, Bluetooth, etc), battery operation, etc.
Because of reliability concerns, medical device developers have traditionally lagged slightly behind in the adoption of new technologies. It often makes sense to wait for a technology to mature a bit before committing its use into an FDA-regulated device. But Android represents a hybrid: while it’s relatively new, it’s based on tried-and-true Linux technology that’s well-understood in our industry.
What is Android?
Android is an operating system and complete application framework designed for ARM-based processors. That can be clearly observed in the schematic diagram (Figure 1).

1. A schematic diagram of Android depicts its framework. This image is reproduced from work created and shared by Google and used according to terms described in the Creative Commons 3.0 Attribution License.
Android fundamentally uses Linux, but Google has updated and extended it in a number of ways to build a complete framework for rapid development:

1. The Android kernel supports extensions for more aggressive power management and modified inter-process communications.
2. Glibc library is replaced with Android’s own Bionic, which is small and fast, and supports the BSD license rather than GPL, thereby keeping the GPL out of user space.
3. Several libraries commonly needed for embedded use are included, such as WebKit (web page rendering), Media Framework, SQLLite, and others.
4. There’s a hardware abstraction layer that defines the interface needed by hardware drivers.
5. Android Runtime, which consists of Dalvik, a Java virtual machine optimized for embedded use, and core Java APIs for application development. While application development under Java is Android’s “dominant paradigm,” applications can be written in C and other languages and then compiled down to native ARM code using the Native Development Kit.
6. The Android Application Framework that’s used to implement the standard object-oriented structure of Java Android applications.

Android is open source, but a design goal was to better insulate commercial developers against the viral nature of the GPL. The Linux kernel remains under the GPL but most of the rest of Android is released under the more relaxed Apache license, which allows it to be used in both proprietary and open-source endeavors. The short story is that Android makes licensing simpler and cleaner as compared to standard Linux.
Google also produces a suite of closed-source applications, including the Android Market and GPS. These are primarily shipped with cell phones.
Can I use Android for my medical device?
To a large degree, selecting an OS for a medical device is like selecting an OS for any other device: we pick the OS that we believe will maximize the value of the device over its life cycle. That includes such considerations as:

• How quickly can we get to market?
• What will be the cost of development?
• How does this selection affect our cost of goods sold?
• What are the licensing costs?
• How much will sustaining engineering cost once we’re on the market?
• How confident are we of our time/cost estimates?

The hallmark of a medical project includes the following additional question:

• Will this selection yield a device that presents an acceptable risk to the patient and users?

As we all recognize, medical devices are different than most other devices in that they can pose a significant risk, particularly to patients. The FDA classifies all medical devices in one of three classes, based on the risk to the patient and the degree of regulatory scrutiny it believes is warranted.
Class I devices present minimal risk and include products like tongue depressors, bandages, and basic surgical instruments. Class II devices present moderate risk and include products like electrocardiographs, x-ray units, blood gas analyzers, and infusion pumps. Class III devices pose the highest risk and include implantable defibrillators, replacement heart valves, and implanted cerebella stimulators.
Heavyweight OSs such as Android are substantially more likely to experience failures than are smaller, more testable OSs designed primarily for reliability. That’s not to say that heavyweight OSs necessarily fail often. Needing to reboot once a year to fix a software lockup may be okay for many devices, and so the inconvenience of an occasional reboot can be weighed against the benefits of a better UI, faster time-to-market, and other benefits of a heavyweight OS. But a yearly reboot for a frozen implantable defibrillator is probably a non-starter.
As a general rule of thumb, Android and similar OSs are appropriate for use in Class I and Class II devices, whereas Class III devices typically require a smaller high-reliability OS. However, every device is different. In any medical device development effort, we must thoroughly consider and understand the risks introduced by OS selection.
One method that’s employed to get “the best of both worlds” is to split processing tasks into two parts: a processor with a high-reliability OS to perform critical functions and a processor with a heavyweight OS to support less-critical tasks. An example could be an infusion pump where one processor with a high-reliability OS controls the motor during infusion, while another processor running Android runs the GUI, communications, and so forth. Note that this two-processor solution is not a straight-forward panacea, and this specific approach may not be appropriate for an infusion pump. A good deal of thought and planning are needed to ensure safety and testability.
The benefits of ubiquity
If you select Android for your embedded device, tens of millions of handsets run essentially the same Android stack that your device will run. There’s a huge pool of users finding bugs, and a large developer community dedicated to fixing them. While Android can’t match the reliability of lighter-weight purpose-built OSs, it is a thoroughly-debugged system as compared to cobbling together a Linux stack from scratch. In addition, more than 100,000 applications are currently available for Android, and many of these applications ease and speed development. That said, Android development is not overly complex and a large pool of developers can support Android.
Android is a strong contender for use in medical devices that don’t require the highest level of software reliability, and whose pricing can support the required hardware. It strikes a good balance between functionality, resource requirements, and productivity, and has the additional advantage of building on the huge and thriving Linux ecosystem.