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:
- 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.