Today’s modern medical devices are evolving at a record pace. From small wearable watches and bands worn by health enthusiasts, to portable wireless units for patients to use at home, to the larger more complex handheld devices used by healthcare professionals—there’s no question we are at the forefront of developing new ways in which to empower patients and medical professionals alike.
While all of this is very exciting, there are some critical manufacturing and design requirements developers must keep in mind. Wearable medical devices need to be small, constantly connected, secure, and have extended battery life. Developers must survive a highly competitive market of increasing complexity as well. To accomplish this, developers must build upon a platform that is fast, flexible, lightweight, and cost effective.
In this article we will touch on a few design considerations developers need to keep in mind before they embark on developing their next wearable or portable medical device.
How Will the Device Be Used?
One way to best guarantee the success of your medical device is to first consider its use cases, not just by the end-user, but how your device will be designed, developed, and tested.
Will your new device have communication modes or is it purely a stand-alone? Depending on its communication needs, you may have to move from bare metal to some type of operating system (OS). Are there any deterministic, real-time needs? For some portable medical devices, there is no requirement for real-time behavior. If an interrupt is serviced 100ms late, the results may be delayed by 100ms, but that’s not going to cause a failure.
Perhaps your device will be a critical piece of equipment so there is minimal sensitivity to cost. On the contrary, a device that is sold in the thousands has a high sensitivity to costs. The type of decisions you make will directly affect the need to minimize the bill of materials, which, in turn, might potentially minimize the memory you will need to effectively build the complete application with some margin.
It’s All about the Hardware
Once the use cases have been defined, it’s time to find the appropriate hardware. Wearable, and to some extent portable medical systems can be extremely small with an 8-bit microcontroller clocked at less than 25 MHz, and use only 8K of memory. Low power ARM devices such as the ARM Cortex-M and Cortex-A families are ideal for the smaller, wearable devices because of their small form factor and minimal power requirements. The Pebble watch is a good example of a wearable device running on the ARM Cortex M-3 processor. (See Figure 1)
More complex designs often include feature-rich systems on chips (SoCs) clocked in the hundreds of MHz and megabytes of memory. There are hybrid systems that have special purpose processors or digital signal processors (DSPs) to systems that include numerous multicore chips. The more complex portable devices often require the operation of a graphical user interface (GUI) and wireless connectivity to the Internet or cloud.
The Heart of the Matter: The Operating System
Wearable devices, and to a greater degree portable medical devices, are usually managed by some sort of operating system (OS). An OS can vary from a simple, in-house creation, to a more complex OS purchased from an established vendor. The general purpose operating system (GPOS), such as Linux or Android, provides a feature-rich platform for application development, but it can be overkill at times consuming more memory than necessary. A real-time operating system (RTOS) is also a good choice for modern medical devices. An RTOS is ideal when specific requirements within the system require the capabilities of a deterministic preemptive kernel and a small memory footprint.
The compelling difference between medical devices today compared to a few years ago is the ability to offer global connectivity—either directly to the Internet (the “Internet of Things”), or to a local intermediary device, such as a medical device paired to the user’s smartphone, which eventually provides a path to the Internet. This connectivity can be intermittent, using either wireless or a temporary wired connection, or it can be constant, using one of the many of wireless options available.
Wired options are the least expensive route, but offer the most limited flexibility. However, they are still a viable solution for low-cost devices. When connecting through a wired link to another device provided by the vendor of the wearable system, it’s possible to resort to extremely simple methods such as Serial Peripheral Interface (SPI) and an inter-integrated circuit (I2C). It’s quite feasible that the choice will change over the lifetime of the device, or even during the development cycle. Insulating the application level from the underlying connection method is most effectively handled by the operating environment.
The true future of wearable medical devices is, however, in the realm of wireless connectivity. While universal serial bus (USB) is a more complex protocol than SPI, varying wireless connectivity options are far more complex than USB, especially when security is involved. Wireless connection methods span the range of Near Field Radio, Bluetooth/BLE, Wi-Fi, up through mobile cellular networks. This is an area where technology, protocols, and options are changing rapidly. More important, the dynamics of the costs of these systems is such that solutions currently deemed to be too expensive today can easily become the economical standard tomorrow.
The Importance of Scalability
The market for wearable and portable medical devices, like most electronic device markets, is a continuum ranging from small and inexpensive, to large and sophisticated. Even within a specific device category, such as IV pumps, the range of devices and features is extensive. Within the development environment, maintaining commonality of software over as wide a range of devices as possible is important to the economics of product creation.
One of the tremendous advantages of an RTOS environment is the ability to consider the RTOS application interface as the target machine and develop applications to that specification. Beneath the RTOS layer, the incorporated middleware suite and device driver collection provide the adaptation to the physical hardware. An appropriately designed application can adapt to the particular details of the underlying instantiation of a specific product version. This adaptation can be achieved through dynamic evaluation of the included features at runtime, or selective build options during compilation and linking.
Sophisticated and high-speed communication methods may require extensive memory and processing resources that are not economical on reduced feature versions of a product. Small battery powered devices require highly efficient methods that consume minimal resources and are amicable to minimizing power modes. Some allow common applications to span not only a wide variety of peripheral combinations, but also allow applications to be transportable across different processor variations, families, and architectures. A reduced feature version of an application can share the same environment on an MCU device as a full-featured version would experience on a high-performance MCU platform.
Low Power Requirements
Battery life is obviously a critical factor for wearable and portable medical devices. Today’s modern processors contain an impressive array of effective power saving capabilities. Unfortunately, these capabilities are complex and often highly interdependent on each other as well as on parts of the system that are not related to the specific power-saving mode being implemented. All of this adds up to an excessive burden to application developers who have enough responsibility simply getting the target application completed. The ability to squeeze every last nA-Hr from a battery will determine the competitiveness of a device in the marketplace. Developers are caught in a vise between a software task that rivals or exceeds the application in complexity and the reality that this peripheral aspect of the project must be performed in order to survive.
The solution to this problem is to develop the application on a software platform that incorporates power management as an integral part of the environment. (See Figure 2) Most large general purpose operating systems incorporate a fairly sophisticated array of power management features. These operating systems simply don’t function in the world of processing devices that target portable medical devices.
Most real-time operating systems provide some form of power management, the most common being tick suppression, which suspends the kernel periodic timer tick interrupt until the next timer event when no tasks are scheduled to run. Other more sophisticated methods are needed for wearable devices, but these are rare in the RTOS world. Currently only Nucleus has built-in support for all aspects of device power savings including dynamic voltage frequency scaling (DVFS) as well as full control of all peripheral power levels with all interactions between peripherals and the core operating clock period. (See Figure 3)
When Size Matters
To accommodate the physical form factor of wearable medical devices, the electronics will have very little volume available for the components as well as the ability to dissipate waste heat. The issue of waste heat parallels that of power consumption and has already been addressed. The physical size limitation will typically result in an MCU system-on-chip (SoC) being chosen as the core processing engine.
While these devices can pack an amazing array of peripherals for their size, the issue of memory capacity is the one area where geometry can’t be out maneuvered. Every application needs more memory. And memory in small devices, both volatile and non-volatile is at a premium. This, more than anything else, is what precludes a general purpose operating system from entering the wearable medical device arena. If an RTOS is to be considered, it must scale down to the most minimal size in both code and data requirements preferable into the range of 2K of text for a stripped down kernel (in order to survive at the lowest end of the device spectrum). This same RTOS must also be able to scale up to the most full-featured range of services.
Power-aware hardware, an adaptable operating system, extensive connectivity, and long-term software usage are critical components of modern medical device design. A platform must have the ability connect to the rest of the world using any methodology currently available, and those not yet envisioned. Standard platforms that achieve this, such as Windows, Android, iOS, Linux, et al., hit a hard lower limit when it comes to their minimum hardware requirements. The only fit at this time is a highly adaptable and extensible RTOS environment that can span the range of replacing bare metal to overlapping the lower end of full-featured operating systems.
The article was written by Rich Rejmaniak, a Technical Marketing Engineer for the Embedded Systems Division (ESD) of Mentor Graphics, Warren, NJ. For more information, Click Here .