Many advantages of Android applications in medical electronic devices

Over the past decade, and especially in recent years, there has been a significant increase in developer interest in how to use "heavyweight" mainstream operating systems (OS) such as Windows, Windows CE, and Linux for medical devices. There are many driving factors, today's medical device users expect medical devices to have multiple advanced interfaces, and many developers already have experience using these operating systems and related tools on desktop computers and servers. Not long ago, if you wanted to choose a feature-rich operating system for embedded medical device development, there were two typical options: Microsoft Windows CE (sometimes desktop Windows itself) or Linux (or other Unix variants).

Of the two, Windows CE has the advantage of being a fully integrated development platform, from device drivers all the way to application frameworks. Some developers may not like Windows CE, but few would argue that Windows CE is a quick and easy way to start a project with minimal effort. CE also has disadvantages: royalties are required for use, and its code base is controlled by Microsoft. But it is worth noting that the latter also brings some benefits.

Linux and other Unix variants have the advantage of being free and open source, but there have been significant barriers to their use in embedded devices, especially those with advanced user interfaces. The Linux operating system was originally designed for desktop/server use, and the typical distribution includes many features (taking up several megabytes of space and several CPU cycles) that are not needed or rarely used in embedded systems. Therefore, it has historically required multiple developers to spend weeks creating a lightweight software image with the required subset of functionality and additional resources for embedded use to start a new embedded project in the Linux operating system. Although manually building Linux images can optimize things, the results are still not fully optimized—there is a lot of important code that cannot be cut for desktops, and they do not use memory, CPU, and/or power efficiently.

Therefore, in the past, the choice was either a proprietary system that was easy to get started (Windows CE) or a free and open system that required a lot of work to get started (Linux and Linux family).

Google's Android operating system has been a relatively recent entry into the embedded field. Basically, Android aims to provide a full-featured embedded system framework based on the Linux operating system. In general, Android aims to make Linux/free software as easy to use as Windows CE out of the box.

When Google first released Android in November 2007, it was positioned as an operating system for smartphones. Android has been a clear success: in less than three years, Android has become the most popular smartphone operating system, with half of the world's smartphones using the Android operating system. 100 million Android phones enter the market every year.

Developers quickly realized that Android also has great potential in embedded applications beyond mobile phones. Many of today's embedded devices share many of the same attributes as mobile phones: small LCD/touch screens, rich graphical user interfaces, low-power processors, rich connectivity options (cellular, wireless, Bluetooth, etc.), battery power, etc.

Medical device developers have been a little behind in adopting new technologies because of reliability issues. It is important to wait until new technologies mature before using them in devices regulated by the US FDA. But the Android operating system is a hybrid: although the technology is relatively new, Android is based on Linux technology, which is a proven technology that is well known in the industry. What is Android?

Android is a complete operating system and application framework designed for ARM processors. This is clearly seen in the schematic diagram (Figure 1).

The Android schematic diagram describes its framework.

Android fundamentally uses Linux, but in order to build it into a complete framework for rapid development, Google has upgraded and extended it in the following aspects:

1. The Android kernel supports extensions for more efficient power management and has modified communication between processes.

2. Android replaced the Glibc library with its own Bionic. The Bionic library takes up a small amount of space and is fast, and the Bionic library supports BSD licensing instead of GPL licensing, so that users do not need GPL licensing.

3. Includes multiple libraries that are often used in embedded applications, such as WebKit (web page rendering), media framework, SQLLite and other libraries.

4. There is a hardware abstraction layer that defines the interfaces required by hardware drivers.
[page]

5. The Robot Runtime Environment, which consists of Dalvik, a Java virtual machine optimized for embedded applications, and the core Java API for application development. Although the "dominant mode" of Android is to develop applications in Java, it is also possible to write applications in C and other languages ​​and then compile them into native ARM code using a native development kit.

6. The Android Application Framework, which implements the standard object-oriented structure of Java Android applications.

Android is open source, but is designed to better insulate commercial developers from the GPL. The Linux kernel is under the GPL, but most of the rest of Android is released under the more permissive Apache License, allowing it to be used in both proprietary and open source development. In short, Android makes licensing simpler and clearer than standard Linux.

Google has also developed a set of non-open source applications, including the Android Market and GPS suite. They are mainly used

in mobile phones. Should I use Android in my medical device?

Choosing an operating system for a medical device is largely the same as choosing an operating system for any other device: we choose the operating system that we think will maximize the value of the medical device over its life cycle. Factors to consider include:

• How quickly can the product be available to market?

• How much will it cost to develop?

• How will this choice affect our cost of goods sold?

• How much does the licensing cost?

• How much will it cost to maintain the technology once our product is on the market?

• How confident are we in our time/cost estimates?

If this is a medical project, include an additional question:

• Will this choice result in a device with acceptable risks for patients and users?

As we all know, medical devices are different from most other devices because they carry significant risks, especially for patients. The FDA classifies all medical devices into three categories based on the degree of danger to patients and the level of regulatory review that the FDA deems reasonable.

Class I devices carry the least risk and include devices like tongue depressors, bandages, and basic surgical instruments. Class II devices carry moderate risk and include electrocardiographs, x-ray machines, blood gas analyzers, and infusion pumps. Class III devices carry the highest risk and include implantable defibrillators, prosthetic heart valves, and implantable cerebellar stimulators.

Heavyweight operating systems, such as Android, are inherently more prone to failure than smaller, more easily tested operating systems designed primarily for reliability. That’s not to say that heavyweight operating systems necessarily fail often. For many devices, a reboot once a year to fix a software lockup is sufficient. So, given the better user interface, faster time to market, and other benefits of a heavyweight operating system, the inconvenience of an occasional reboot can be forgiven. But for an implantable defibrillator, an annual reboot may not be an option. As

a general rule of thumb, Android and similar operating systems are suitable for Class I and Class II devices, while Class III devices generally require a smaller operating system with high reliability. Of course, every device is different. When developing any medical device, we must fully consider and understand the risks associated with the operating system.

One way to get the "best of both worlds" is to split the processing tasks into two: have one processor with a high-reliability OS perform the core functions, and one processor with a heavyweight OS handle the less critical tasks. An example is an infusion pump, where one processor with a high-reliability OS controls the motor during the infusion process, while another processor running Android runs the GUI, communications, and so on. Note that a two-processor solution is not a silver bullet. It requires careful consideration and planning. Ensure the security and testability of the medical device.

The advantage of a large number of users

If you choose to use Android for your embedded device design, there are thousands of mobile phones running the same Android stack as your embedded device. There are a large number of users who are looking for vulnerabilities in the Android OS, and there is a large development community dedicated to fixing these vulnerabilities. Although Android is not as reliable as a lightweight proprietary OS, it is a thoroughly debugged system compared to developing a Linux stack from scratch. In addition, there are more than 100,000 applications that support Android, many of which can simplify and speed up the development process. This means that Android development is not very complicated and there is a large developer base supporting Android.

For medical devices that do not require high software reliability and whose price can support the required hardware, Android is highly competitive. It strikes a good balance between functionality, resource requirements, and productivity, and has the additional advantage of being based on a large and prosperous Linux industry chain.