Android has steadily gained momentum in the mobile handset arena, but that’s only one side of the story. While the Android software platform is ideal for handsets, it’s also an extremely good fit for other types of devices that require wireless connectivity, graphical data displays, and intuitive user interactions (see Figure 1).

The emergence of remote patient monitoring devices

One such device category is medical devices, which are becoming more complex by the day. Within this sector, remote patient monitoring is gaining serious traction as a legitimate telemedicine technology. These types of devices are essentially clinical and medical data-gathering systems designed to remotely improve diagnostics, administer health screenings, and deliver therapeutic capabilities. Examples include glucose analyzers, infusion pumps, and cardio monitors. These devices can be used in the home, at the doctor’s office, or in the hospital, and each has its own specialized use case and user experience requirements.

Consider the software requirements for this type of device. A remote patient monitoring device typically comprises two components. The first component is connected to the patient for data collection. The second component is used to display the data and configure the system. It is not uncommon for the device to have requirements that go beyond what Android can offer. This is where the capabilities of an RTOS are needed (Figure 2). When working together, Android and an RTOS deliver a powerful combination of embedded efficiencies that make health care specialists and patients both extremely satisfied users.

A flexible, intuitive UI

A health care professional using a patient monitoring device will need to access data quickly and intuitively. The latest trends in User Interface (UI) technology for mobile phones – gesture, cover flow, and widget-based applications – fit nicely with this type of device, as user interaction is extremely important in medical devices. The available Android software developer kit provides a number of options for how the end device and UI can be used. Will the UI have widgets only? Touch-screen buttons? Perhaps a combination of the two? Will the device require a swipe feature as part of the UI? All this can be achieved with the standard APIs available in the Android application framework.

The lightweight determinism of an RTOS

Exactly what is the role of the RTOS? An RTOS is best used in the most safety-critical aspects of devices where real-time data needs to be gathered from the patient. Think of the RTOS as the part of the device that touches the patient. Often, this is achieved by the patient wearing a wristband or belt, or in some cases, noninvasive sensors that attach directly to the skin.

The RTOS can measure functions such as an EKG, heart rate, respiration, and oxygen saturation. The RTOS is also the part of the device that normally requires a small footprint, deterministic latencies, and low overhead. An RTOS not only fits these requirements, but also tends to have fewer lines of code than Android, which makes meeting specific certification or safety regulations a more straightforward process.

Android’s many APIs

One of the key reasons to use Android is because its application framework is built around connectivity. Most of the software stack and necessary APIs are already developed. This is especially true with connectivity options such as USB, Bluetooth, Wi-Fi, and others.

Many of today’s medical devices demand wireless connectivity, and Android does not disappoint. In fact, Android offers straightforward expansion into new standards such as ZigBee, which is an emerging short-range wireless protocol. The Android software stack can be extended to include a ZigBee driver and stack in the platform layer, all of which gets tied into Android’s connection management utility. This connectivity requirement also applies to the RTOS, which, as part of the device connected directly to the patient, often sends the data back to the display unit over a wireless connection. The applications on the RTOS must manage the connection, gather the data, and transmit the data while meeting deadline requirements for each activity. Integrating the connectivity stack with the RTOS is a key piece of the Android/RTOS multi-OS solution.

The ability to extend the I/O is critically important to the development of embedded systems for medical devices. Developers must be able to freely add other I/O classes to the framework as new classes become available. Android does a good job of including various drivers, platform code, and the specific application frameworks to make this possible. Granted, the Android application framework might need additional classes as its use spreads to other device types. But as an open source project, developers have all the source code, tools, and freedom to extend Android to meet their target requirements.

Combined to succeed

For a medical device to be successful, it must be able to gather sensitive data in real time and meet all of the necessary safety-critical requirements and certifications. This is no small task.

Having an RTOS and Android work together can alleviate much of the pain. As stated earlier, the RTOS must support all of the same connectivity options as Android. This is a critical requirement for the RTOS. If the connectivity is not already built into the RTOS, it is incumbent upon the developer to make sure it can be added easily when the time comes. It’s important to realize that the RTOS not only needs to gather the data quickly, but also support Android in whatever communication/connectivity protocols Android is using.

Matthew Locke is technical director for Mentor Graphics’ Embedded Software Division, with more than 12 years of experience in technology and business leadership roles at Embedded Alley, MontaVista Software, and Lockheed Martin. Prior to Embedded Alley, Matt held CTO positions at several start-ups including NomadGS, which focused on building custom embedded Linux solutions for the consumer device market, and Suunnata, a company developing a system for securely delivering services to networked connected devices. As the product architect for the MontaVista Linux Consumer Electronics Edition, Matt was responsible for the overall product architecture and led the development of key technologies for running Linux on consumer devices. Matthew has a BSEE from the University of Maryland, College Park.

Mentor Graphics Embedded Software Division [email protected] www.mentor.com/embedded