This file type includes high-resolution graphics and schematics when applicable.
The world of wearables may well be the newest—and the most challenging—area of the Internet of Things (IoT). To be acceptable, a wearable device must either be familiar in look and feel, like a watch, a pair of glasses, a belt or a normal piece of clothing, or it must be almost completely unobtrusive so that the wearer isn’t always conscious of its presence. It wouldn’t hurt if it was also fashionable, but that may be asking too much.
Of course, the applications for wearable devices vary widely and we’re no doubt just beginning to explore the possibilities. Perhaps one common purpose, regardless of the specific application, is that they must sense, store, interpret, and communicate information about the wearer’s body or surroundings.
The implications of such requirements on design (i.e., the internal functions) as well as size, weight, and power (SWaP) can seem daunting. In addition, the need to be flexible in order to adapt to changing demands also puts a burden on the designer. Ideally, wearable devices would be completely invisible, weigh nothing, and consume no power. Since that’s not possible, engineers are left to do what they do best—devise complex tradeoffs between these demands to come up with an optimal design.
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 analog-to-digital 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., all of which consume power and time.
On the other hand, putting too much function into logic takes longer to develop. And once implemented, it’s difficult to update, which affects flexibility and adaptability. Functions implemented in software are easier to develop, and easier to adapt to meet changing demands.
These considerations alone will dictate that a wearable device can’t be a multipurpose “utility knife” type of system, but must focus on doing one or two things very well and very efficiently. This rule seems to be challenged by recent smart watches from Android and Pebble. Both boast a large number of apps, some of which are standalone while others interact with apps on the wearer’s smartphone.
A watch, however, is a device that can get away with that since it’s so familiar on all our wrists and can therefore be accepted with as many applications as can be crammed into it without making it too bulky. The same can’t be said of other devices like heart monitors, glucose meters, fall detectors, or concussion sensors, to which few if any wearers are accustomed.
What Kind of HMI?
Given the fact that a small device may be worn on a part of the body not normally in view or easily accessible, the possibilities for a human-machine interface (HMI) are rather limited—and certainly don’t include a large display or keyboard. For the actual device, these limitations may come down to some lights and a couple of small buttons, or in the case of a smart watch, perhaps a touch display along with some buttons. In many instances, physical buttons on the side of a watch can be set to different options with button combinations and the current function displayed on the screen. This still doesn’t add up to a very rich user interface.
Ah, but the goal of a richer user interface gets a boost due to the fact that wearable devices, even the most unobtrusive ones, are connected—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 (Fig. 1).
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 smartphone, 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.
However, a somewhat more limited interface also might be on the smartphone or smartwatch that could vibrate 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.
The connectivity architecture in which wearable devices function offers many possibilities for different levels of user interface, but it also can be used to adapt to the functional needs of the wearable device. For example, a Bluetooth connection to a phone, which then connects to a network gateway, is becoming a very popular mode. However, it’s not applicable in all cases. For example, RoweBots is developing concussion monitors for use by football, rugby, soccer, and lacrosse players to give early warnings of impacts that could be dangerous (Fig. 2).
While players can easily carry a sensor connected to a small attached device, they can’t each very well carry a phone in the game. Still, the data must be instantly available to coaches and medical staff. This requires connection to a wireless gateway that’s connected to the cloud so it can be observed on the sidelines. That means not only a different design for the connectivity and the user interfaces; it may also require more power to span the playing field. Other designs may require yet a different approach involving special radios (i.e., LoRa) and satellite phones. These considerations will then dictate the choice of hardware and battery supply.
Safety, Security, and Privacy
In addition to the intertwined decisions on SWaP, specialized features, connectivity, and interface, there’s another set of equally important and interconnected considerations: safety, security, and privacy. Security is the prerequisite for both safety and privacy. And today, as with so many IoT devices, many security experts believe that wearable devices are mostly not secure.
For small wearable devices, security has to be built in from the ground up. This means selecting an RTOS like the Unison WearableOS platform that incorporates secure protocols such as transport layer security (TLS) and the secure network management protocol version 3 (SNMPv3). Support for encryption, password protection, and a secure-boot mechanism for remote firmware upgrades are essential, too.
Privacy naturally depends on security, but it’s defined by establishing clear rules for sharing information in the device. Today, this is at best ad hoc or simply not currently a consideration, because most vendors consider the user’s data to be their data.
However, an emerging set of guidelines called Privacy by Design (PbD) offers an approach to protecting privacy by embedding it into the design specifications of technologies, business practices, and physical infrastructures. That means building in privacy up front—right into the design specifications and architecture of new systems and processes. PbD has identified seven principles, including keeping it user-centric and ensuring that it’s preventative and not remedial. While these have yet to be fully defined, they can still be used as general principles to guide design from the device to the application, and the use of the data all the way to the cloud.
The need for safety should go without saying, but the issue of safety can get quite subtle when it involves details of the application. Security will prevent attacks from outside, but safety must be built into the device so that it works reliably and provides timely and meaningful information. For example, the design of a gait or fall detector for an elderly person should avoid a scenario from those, “I’ve fallen and can’t get up” commercials. We want to get information that could signal instability in gait in time to get attention, help, and/or treatment and avoid a broken hip that might result from an actual fall.
That will require careful selection of sensors, such as accelerometers, levels, and motion sensors, combined with functions like GPS and careful software design to provide data that can be accurately analyzed—partly in real time on the device as well as on a remote site in the cloud. Each type of wearable device will have a different set of such considerations. Therefore, it’s important for a line of products to be able to share a common processor architecture and RTOS platform that offer both the performance and flexibility to address specialized needs. It’s also likely that a wearer may have more than one device, and the data they supply should be compatible for quick analysis at the gateway and cloud levels.
The Wearable Design Process for Success
Getting all of the above factors correct is essential for success, but it’s also necessary to accomplish the design smoothly using a defined process in order to minimize spending too much time and money. This starts with the concept of a product that carries the impression of robustness and quality and has the right feature set aimed at its core purpose. Trying to include too many features that aren’t supportive of each other and aimed at some core concept (e.g., cardiovascular health, fitness, or baby monitoring) will detract from its air of quality.
To address that focused set of features, it’s important to have a selection of proven and readily usable wireless-connectivity options. Bluetooth Low Energy (BLE) is used most often because it provides a direct phone connection with fast connections and low power. Other options such as Bluetooth Classic are required for full audio communications while video requires Wi-Fi, and low-data-rate sensors can use 6LoWPAN/802.15.4. Even 2G/3G/4G are available. Ideally, these are included with the operating system, and are known to work without having to be adapted (Fig. 3).
The development process itself can be greatly streamlined by adopting a platform based on a lean or agile development model. One example is the model invented by Toyota for modular design and technology inclusion in automobiles, which also works very well with other products. This combined with a platform consisting of the selected MCU or MPU with the RTOS already adapted and supplied can significantly reduce time to market and cost.
Having an adaptable platform, such as one based on a family of processors sharing the same basic RTOS, lets you easily change modules and provide new functionality to quickly address changing markets. It allows you to preserve, reuse, and enhance the existing software offering to meet those challenges. For instance, 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 memory, mechanical, display, camera, and other sensor systems. For example, mechanical devices are connected using a variety of technologies, including PWM, analog-to-digital and digital-to-analog conversion, and encoders for such things as stepper motors and more. Storage devices use a variety of SPI flash, NOR and NAND flash, RAM, and MMC interfaces. Then there’s USB, which is gaining almost universal popularity.
Wearable devices must naturally interact with the cloud, where their data is gathered and evaluated, and where high-level decisions are made. The cloud is the source of program changes and updates to the connected devices, where everything is pulled together. Integrating with the cloud involves selecting the cloud platforms that are used along with their operating systems and applications, which should be compatible with those employed on connected devices. In the Unison RTOS world, this means the ability to work with other leading-edge applications like Microsoft Azure. It also means the use of tools for setting up cloud user interfaces and data displays as well as monitoring and remote update capabilities.
Wearable devices represent the newest frontier on the Internet of Things, so they portray “cutting edge” from the get-go. To effectively design and deploy them, you need the latest technology platforms and tools as well as a process that’s agile and adaptable, since the products must exist in a rapidly changing world. When you focus the cutting-edge tools, technology, and process on a focused set of needed features, you have a product that’s effective, economically produced, compelling for the customer, and cutting edge.
