Speed the development of wearable devices with a solid, targeted platform
The IoT world is expanding on all fronts, including the demand for wearable devices for a range of consumer needs and also for medical devices that can free wearers from home confinement. A targeted MCU/RTOS combination with the proper features can speed development for successful designs.
The world of wearable devices is becoming one of the most challenging and dynamic areas of the Internet of Things. A recent issue of Consumer Reports featured 27 wearable fitness devices—only one aspect of the wearable world. The combination of fitness monitoring on the consumer side and medical applications on a more specialized and serious side are leading to innovations that present the developer with an array of opportunities and challenges. On the one hand, advances in low-power, high-performance microcontrollers along with innovative and miniature sensors are presenting developers with a rich set of tools to approach the challenges.
On the other hand, a range of demands and constraints face the developer approaching the design of wearable devices, one of the more prominent being low power consumption and power management. Power consumption and management will involve the connected sensor(s), the local processor and its load and the external wireless link. Other constraints for wearable devices are, of course, that they be attached to the body, but also not obvious to view. They can be worn hidden under or concealed in clothing or disguised as fashion items like rings or bracelets. Many aspects of a design will depend on whether a device is primarily aimed at fitness monitoring, or has more specific medical application like glucose and blood oxygen monitoring, blood pressure, pulse and more. In many cases the latter classes will also require FDA certification. In such cases, security will also be a primary concern (Figure 1).
Then there is the matter of wireless connectivity. Perhaps the most familiar is Bluetooth LE connected to a smartphone that is also carried on the body. This has the advantage of providing a platform for apps that can process or pre-process data from the sensor(s) prior to sending it on to a gateway or ultimately to the cloud. However, this solution is not applicable to all situations, for example sporting events like football or a marathon race. Thus the selection and integration of a wireless solution will also entail design decisions involving size, weight and power.
A platform for development
Microcontrollers and processors, sensors and wireless connectivity solutions are available in rich and ever-growing variety. For example, in considering the hardware, one attractive choice would be a very low-power MCU with sleep modes that could be invoked to further save power. Parts of the design, such as A/D conversion or other frequent and relatively simple functions could be assigned to programmable logic, which inherently uses less power than a processor. A processor consumes power by needing powered memory, fetching and executing instructions, waking and going back to sleep, etc. On the other hand, putting too much function into logic takes longer to develop and once implemented, is difficult to update, which affects flexibility and adaptability. Functions implemented in software are easier to develop, and easier to adapt to meet changing demands, so some trade-offs between programmable logic and memory are required.
Fortunately, there is a growing selection of processors that have the performance to not only support trade-offs between programmable logic and powered memory. They also have the capacity to work with a fully functional RTOS. That then lets a you start with a solid platform—a matched pair of processor and RTOS—one that has all the capabilities you may need but from which you can select only those you do need. Building on the right RTOS/processor platform gets you started faster adding unique, innovative value and speeding time to market. It also assists in porting systems and applications to new hardware environments when that becomes necessary. The key is to find the right RTOS that can offer modularity, a familiar API such as POSIX and support for a lean development model.
Having an adaptable platform, such as one based on a family or families of processors sharing the same basic RTOS, lets you easily change modules and provide new functionality to quickly address changing markets. It lets you preserve, reuse and enhance the existing software offering to meet those challenges. For example, you could move the entire functionality to a compatible, more powerful processor and smoothly modify or add features including new sensors. That platform also needs to be complete in the sense that it supports such things as memory, mechanical, display, camera and other sensor systems. The availability of driver source code for a wide variety of sensors will make it straightforward to integrate them into a wearable design. For any devices you select, that code can be quickly compiled and the drivers ported for the specific MCU.
Such an inherently modular and configurable RTOS model can greatly streamline the development process by adopting a platform based on a lean or agile development model as that invented by Toyota for modular design and technology inclusion in automobiles. This model also works very well with other products. Combined with a platform consisting of the selected MCU or MPU with the RTOS already adapted and supplied, it can significantly reduce time to market and cost. A targeted RTOS like the WearableOS from RoweBots, Ltd. brings all these characteristics together in a targeted platform for wearable development.
Decisions about the user interface
A small device that is to be worn on a part of the body not normally in view or easily accessible limits the possibilities for an HMI—at least locally. It certainly can’t include a large display or keyboard. In some cases where, for example, a smart watch is part of the system, its touch display and buttons can be used for limited user interaction. This still does not add up to a very rich user interface. A true HMI depends on device connectivity to the wider infrastructure.
Wearable devices, even the most unobtrusive ones, are connected, either to other devices carried by the wearer and/or ultimately to the Internet. Thus the needs for a richer HMI become bound up with the connectivity architecture of the device and this can even result in different layers or versions of user interface (Figure 2).
Imagine a health monitoring device that measures heart rate and blood pressure. Normally it might simply sense that data and send it via Bluetooth to the wearer’s smart phone, which would then transmit it periodically to an Internet gateway and from there to a doctor’s computer. Such a device would not be set up directly but probably from the physician’s workstation using a rich graphical display. That same workstation and its HMI would be used to display and analyze the data. But there might also be a somewhat more limited interface on the smart phone or smart watch that could have a vibrating panel on the back to alert the wearer to contact the doctor or take some other action. In other words, there could be different levels of user interface depending on the connected devices and their role in the overall function of the application. This is in turn involved with the wireless connectivity model associated with the device—often in cases where the smartphone model is not appropriate.
Choosing connectivity and security
As we have noted, different forms of lifestyle, activity, application demands and situational circumstances will require different approaches to wireless connectivity and different radio types. The one thing, of course, that they will all have in common is the need for low power. While the Bluetooth connection to a smartphone may have many convenient aspects, it is not appropriate on a football or soccer playing field. In such situations, traditional Wi-Fi might look attractive but it consumes too much power. A good substitute would be the 6LowPAN protocol running on top of an 802.15.4 radio, which also allows group communication among teammates. For more spread-out events like marathons and road races, there is the emerging LoRaWAN radio with a range of some 15 kilometers. It depends on the presence of gateways, but these are becoming increasingly popular with city administrations for a range of management tasks from street lighting to waste management and more. Alternatively, a set of gateways could easily be set up along the course of a race. On the horizon are other technologies such as LTE CAT-M1, which uses a slice of the cellular network.
For wearables—especially the medically sensitive ones—security is essential. This is important not only for access, but also for communications in the form of transport layer security (TLS) along with secure SFTP and SSH for file transfer. Depending on the hardware, the RTOS should be able to work with secure processor features such as ARM trust zones and silicon supported encryption. Over the air updates also require secure boot. In addition, the RTOS must provide the ability to roll back to a previous release if an update is interrupted or doesn’t succeed.
A development platform made up of a selection of processor families supported by a portable RTOS will serve as a solid basis for building wearable devices. The RTOS should offer a well-understood API like POSIX or embedded Linux and rich features that can be selected and quickly integrated to form the image that best fits the target design. This means supporting a rich selection of sensors, peripherals and wireless communication alternatives along with security. Such a platform will also be accessible by a wide choice of development tool suites that will quickly fit into the existing environment of most development teams and speed the creation of unique value while shortening time to market, which are the keys to success.