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.
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:
- The Android kernel supports extensions for more aggressive power management and modified inter-process communications.
- 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.
- Several libraries commonly needed for embedded use are included, 
such as WebKit (web page rendering), Media Framework, SQLLite, and 
others.
- There’s a hardware abstraction layer that defines the interface needed by hardware drivers.
- 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.
- 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.