Techniques for Leveraging Future Capabilities of Wearable Medical Devices

By: Andrew Caples, Mentor Graphics
http://www.mentorkr.com/

The day will come when the wearing of portable medical devices becomes perfectly integrated into our daily lives. In fact, we will come to perceive these devices not as "equipment" but as services by the type they provide. With continuous advances in wireless connectivity and cost pressures to shift to ambulatory care models where possible, excellent opportunities await developers who stay ahead of anticipated demand.

Of course, developers must meet very stringent manufacturing requirements. Wearable medical devices must be small in size, always connected to the internet, and possess long battery life. The features provided will constantly push the computing resources available within the confined device to their limits. Developers must survive in an increasingly complex and fiercely competitive market. To do so, they must rely on platforms that are fast, flexible, lightweight, and cost-effective (Figure 1).


Figure 1: Software platforms must encompass all non-application-specific code.

Device Profiles

Wearable medical devices fall broadly into two categories: disposable and reusable. Disposable devices represent a relatively new market segment with relatively short product lifespans, allowing for rapid evolution. Conversely, reusable devices require much longer lifecycles, security, and high reliability coefficients.

Devices in the disposable sector operate under the economics of high-volume, low-margin business models. To achieve this, disposable devices must extract maximum functionality from highly resource-constrained processors. To maximize profits, it is common to offer a series of products targeting diverse end users, balancing price and features.

Writing separate applications for each step in the product feature range is entirely uneconomical. Therefore, a common software environment must be maintained that supports a single application base yet transitions seamlessly across a range of computing resources. This environment must be scalable to the most minimalist systems with only minimal memory resources while capable of expanding to support broader features.

The reusable product market faces a different set of challenges. The critical added value provided by device manufacturers to end customers is the ability to protect them from early processor obsolescence. Semiconductor vendors undergo significant changes during the lifecycle of devices they support. In contrast, medical sector customers often expect replacement services to be supported over more than a decade. To endure this conflicting situation while maintaining profitability and preserving the long lifespan of necessary application code, stable programming APIs rather than specific processor devices must be developed.

Connectivity Options

The ability to make devices small enough to be wearable has been realized long ago. The interesting difference between past and present lies in the capability to provide worldwide connectivity. This is achieved either through direct connection to the internet (or cloud) or ultimately through the internet via an intermediary local device (a medical wearable device paired with the user's smartphone). Such connectivity can be intermittent, using wireless or temporary wired connections, or continuously provided using one of many available wireless options.

Wired options are the most economical but most restrictive in flexibility. However, for low-cost devices, they remain a competitive solution. When connecting to other devices provided by wearable system vendors through wired links, extremely simple methods such as SPI or I2C can be used.

Conversely, connection to generally available computing devices requires more open standards such as USB. Engineers who have used these different methods know that protocol complexity differs significantly between USB and simpler methods. Such choices can change during the device's lifetime or even during development cycles. Protecting the application level from underlying connectivity method changes is most effectively handled through the operating environment.

However, the true future of wearable medical devices lies in wireless connectivity. While USB is more complex than SPI, various wireless connectivity options are considerably more complex than USB, especially when security features are involved. The range of wireless connection methods extends from Near Field Radio to Bluetooth/BLE, Wi-Fi, and mobile cellular networks. This is an area showing rapid changes in technology, protocols, and options. More importantly, the cost dynamics of these systems mean that solutions currently considered prohibitively expensive can quickly become economical standards tomorrow. Meanwhile, application-level code maintains a longer lifespan and utility ahead of these changes.


Figure 2: Wireless connectivity options are diverse and constantly evolving.

If an RTOS environment can be deployed within minimalist devices with SPI-level interfaces while transitioning to full cellular connectivity (whether across a series of products or across product lifecycles), wearable medical equipment OEMs will undoubtedly be able to adapt to any future situation.

Power Requirements

Battery life is undoubtedly a critical factor in wearable medical devices. Weight becomes unavoidable when users carry or wear items, and batteries represent the heaviest and bulkiest component of all portable devices. If users must carry items throughout the day until evening, simply extending battery life by minimizing power consumption is insufficient.

Power demands must be dramatically reduced to the point where battery size is minimized. Items like smartphones can accommodate batteries of specific sizes providing specific power amounts. Using these parameters as fixed benchmarks results in satisfactory products meeting customer expectations simply by achieving specific battery charge durations. However, wearable medical devices are different. Even after battery charge duration is determined, pressure to reduce power consumption continues endlessly. The smaller power consumption becomes, the smaller and lighter the battery can be.

Modern processors today incorporate an impressively diverse array of effective power-saving features. Unfortunately, these features are complex and often highly interdependent with each other and with system portions unrelated to specific power-saving modes being implemented. For example, changing device clock frequency affects communication clock speeds, even when no change occurs in power states of communication peripherals.

All these situations impose enormous burdens on application developers already heavily burdened with simply completing target applications. The ability to squeeze battery power to the last drop determines the device's market competitiveness. Developers are pressured between application-level complexity and the reality of needing to perform peripheral aspects of projects to survive, often as complex as the applications themselves.


Figure 3: Power consumption optimization impacts all components of wearable devices.

The solution to this problem is developing applications on a software platform that includes power management functions as an essential part of that environment (Figure 3). Most large-scale general-purpose operating systems incorporate highly sophisticated power management features. However, these operating systems prove completely ineffective in the processing device field targeting portable medical devices.

Most real-time operating systems provide some form of power management, with tick suppression being the most common. This suspends the kernel's periodic timer tick interrupts until the next timer event when no tasks are available for execution. Wearable devices require more sophisticated methods, though these remain rare in the RTOS field. Currently, only Mentor Graphics' Nucleus RTOS incorporates built-in support for all aspects of device power-saving features. This includes dynamic voltage/frequency scaling (DVFS) capabilities and complete control of all peripheral power levels through all interactions between peripheral and core operation clock periods (Figure 4).


Figure 4: Structured power frameworks optimize development effort.

Size Constraints

To accommodate the physical form factors of wearable medical devices, electronics have minimal space not only for component mounting but also for waste heat dissipation. Heat issues resemble power consumption problems already addressed. Physical size constraints typically lead to selection of MCU System-on-Chip (SoC) as the core processing engine. While these devices support an remarkably diverse range of peripherals relative to their size, memory capacity represents an area inseparable from space constraints. All applications require more memory. For small devices, memory—whether volatile or non-volatile—must be an extremely scarce resource.

Developers absolutely want to avoid having their applications compete with the RTOS for limited resources. The reason general-purpose operating systems cannot enter the wearable medical device field is precisely this point. When considering RTOS, both code and data requirements must be reduced to minimum sizes, with approximately 2K of text space preferred for the most basic kernel (to survive in the lowest-cost device category). Furthermore, such RTOS must be capable of scaling to provide full-featured services, including, for example, cellular mobile communications. Otherwise, developers must struggle to support applications spanning multiple operating system environments.

The Gap Between Technology Implementation and Actual Products

You may recall the early days of the PC revolution when advertisers, marketers, and technology magazines obsessed over clock speeds, bus sizes, and other technical details. However, today's devices are judged solely by end-user experience. Achieving the engineering feat of fitting a device with excellent instruction processing speed into a wristband may provide bragging rights among colleagues but contributes nothing to revenue.

Consequently, developers find themselves in situations where they must implement the most features with minimal hardware. Whether it is the smallest memory, slowest clock (device limit or practical use), or smallest battery, what is typically expected of engineers is implementing magic in disposable devices.

Conclusion

To survive in a market demanding extensive complexity, tremendous cost pressure, and continuously evolving underlying hardware, applications must be deployed on robust and flexible platforms. Such platforms must be abstract while simultaneously capable of optimizing specific hardware features.

Today, platforms are defined not by processing architecture or peripheral sets, but by the programming environment available to developers. Standard platforms such as Windows, Android, iOS, and Linux aimed at achieving this have reached their limits in terms of minimum hardware requirements.

These limitations cannot be reconciled with the price, power, and physical constraints of medical wearable devices. Currently, the only option meeting these requirements is an RTOS environment with high adaptability and scalability, as RTOS can replace bare metal and overlap with the lower-end segment of fully-featured operating systems.

Author Biography
Andrew Caples is a Product Marketing Manager for the Embedded Systems Division (ESD) at Mentor Graphics. He brings more than 20 years of experience working with startups and Fortune 500 high-tech companies, having held various positions ranging from technical marketing to sales management. He holds a Bachelor's degree in Electrical and Computer Engineering from California Polytechnic University and currently serves in product management for the Nucleus Real-Time Operating System.