Eight Challenges Faced by Wearable Software Designers

Experts from ARM share insights and differing viewpoints on the big issues facing wearable developers of software applications.

Software developers must address many domains to successfully design the latest wearable applications – from signal conditioning to device drivers and RTOSs to end apps. Several industry leaders from ARM offer guidance on these issues, including, kenhavens, System Design Division Marketing Manager; diyasoubra, Product Marketing Manager; willtu, Director Embedded Segment Marketing; and jamesbruce, Director Mobile Solutions. What follows is a portion of their comments. - JB

Blyler: What challenges await wearable software developers, from device drivers (C or embedded) and RTOS selection to signal conditioning and application programming? Will proprietary or open source software win out?

Havens: Here’s a quick check-list of design considerations and constraints:

1. Software driver firmware can be an encompassing topic from the different communication protocol stacks to sensor and signal conditioning libraries. Designing firmware really depends on the wearable device, i.e, what it connects to, what it measures and how secure its data must be.
2. There are already many RTOSs available in the market today that would be a good fit for a wearable design. I think the better question is how integrated is the RTOS with the middleware communication and signal conditioning libraries. The CMSIS RTOS standard is a good fit in that it addresses the integration of the middleware libraries for communication and DSP libraries for signal conditioning.
3. In terms of sensor signal conditioning, one must first determine the data type and how much pre- and post- processing needs to be done. If the data type is more of a structured data set (in the case of a wearable measuring multiple aspects of the user and their environment over time), then the designer may need to collect readings over time and only transmit the differential to save space and transmission time. However, the application may just call for a single piece of data which is then post processed by an upstream application.
4. Application specific software is the defining aspect of most wearable devices. Most wearables are collecting specific pieces of information from various places. A caveat to this is when a wearable provides information back to the user.
5. Since humans are everywhere, the wearable device designers need to focus on the user. There are applications where the wearable needs to be integrated in to the lives of the users to the point that its presence goes unnoticed by the users and those around them.
6. The open source vs. proprietary software issue is really about how captive the manufacture wants to keep the user tied to their products. I would imagine a kickstarter project might gain traction if it was based on open source but, I think the majority volume players will keep the wearable platform closed and exploit the application of the data. Some of the open standards in the security area might be helpful to the developers. Although these are open they can be incorporated into the device while still keeping the platform closed.
7. How much data does the wearable device need to hold before it can upload to the aggregator or host application? How will it handle updates to its own firmware? How will it manage aggregators it connects to for these services? These are just some of the design complexities that need to be thought through.
8. Should there be a full, minimal or even no user interface: Which way is the information going? Is a simple LED enough to tell the users that the wearable has established communication or needs to be charged? Is that all it need to communicate? What about more complex wearable devices that feedback information to the users. Maybe some aspects of this question fall into the Behavioral Science realm of, what will people do with this information and how do we need to adapt designs and firmware to meet their evolving expectations.

Soubra: Open source software will be the most popular alternative. For example, open source software is available at multiple web sites for sensor control – in addition to the sensor vendor sites. Further, most processors will be programmed in C since there is no differentiation in writing assembly code. (The only differentiation is what the gadget will do!) Developers can also use multiple operating systems. All ARM microcontrollers (MCUs) come with a full set of drivers and DSP.

Wearable devices are a commodity on the design side. The market winner will be decided on knowledge of contract manufacturing and then marketing to get people to know about the product. The hardware and software development activities are so easy now that they are no longer a point of discussion. If you look at a few projects at kickstarter, you will see that they invest more on the video to explain the project than the actual gadget.

 [Editor’s Note: To add a bit of controversy to Soubra’s comment, consider the recent CNN story about the lateness of most Kickstarter projects: Why are 84% of Kickstarter's Top Projects Shipped Late - "To say we've learned a lot about engineering, design, manufacturing, marketing and customer service is ... well ... an understatement so extreme as to be laughable," ZPM Espresso's founders wrote in a recent update to their Kickstarter backers." Many readers might recall the “Little Printer” presentation by entrepreneur Matt Webb at last Fall’s ARM TechCon. Webb mentioned many of the technical learning curve challenges covered by ARM’s Soubra and the recent CCN story.]

Tu: There are plenty of available software IDEs, although one might consider a professional tool such as ARM MDK or IAR Embedded Workbench by IAR Systems. Device drivers for sensors just got simpler with the recent announcement by ARM and Sensor Platform of an Open Sensor Platform. This open source framework allows sensor companies to contribute to and provide their own drivers. This will help companies leverage the framework so that they can incorporate various sensor hub fusion algorithms.

The key challenge is for software developers to leverage what is out there instead of reinventing the wheel. For processor-based sensor algorithms, a number of companies provide solutions with easy interfaces, e.g., Hillcrest Labs, Movea (see figure), Sensor Platforms, and even silicon partner like Freescale. Wearable software developers don’t have to reinvent the wheel. Instead, they can can “build, borrow and buy” in their software development. They can buy commercial tools and sensor fusion algorithms. They can borrow open source frameworks and other open source software from the Open Sensor Platform. Finally, they can build, integrate and focus on interface to bring everything together.

Bruce: One of the big challenges on both the hardware and software side will be battery life. Users want to charge their wearable devices as little as possible. Designers must understand where power is being consumed, i.e., in the connectivity via Wi-FI, Bluetooth, GPS or something else. Power may also be consumed by the sensors and the devices screen – if it has one. Power can be consumed in many areas. Power profiling software tools, such as within Development Studio 5, will help developers with trade-off analysis. Typically, though, a combination of monitoring tools are used to where the power is being consumed, for example, within the processing system and on the outside peripherals.

The other challenge is very much related to software development. One needs to have the right ecosystem for developing applications. “Android Wear” is a good example of such an environment. Many wearable designs include a microcontroller which benefits from ARM’s mbed environment for development of the overall system software.