Today s Wearable Devices: KEY FACTORS DRIVING THE MARKET · Currently healthcare, fitness, and safety are key segments driving the popularity of wearables. These segments will only

E M B E D D E D S O F T W A R E WH

IT

EP

AP

ER

w w w . m e n t o r . c o m

Developing Effective Design Strategies for Today’s Wearable Devices:

“KEY FACTORS DRIVING THE MARKET”(Paper #1 of a 3-part series)

WARREN KURISU DIRECTOR OF PRODUCT MANAGEMENT

Wearables: Key Factors Driving the Market

w w w. m ento r.co m2

INTRODUCTIONWhile many new fitness bands, smartwatches, and other wearable devices have entered the market, most have under-whelmed prospects and users. It is quite clear the wearable industry is in its infancy and fraught with growing pains. Software developers, embedded systems architects and engineers must take heed in the early miscalculations of these devices (whether it’s functionality, utility, product design and/or aesthetic reasons) if they are to conceive and develop a wearable device that is truly accepted by the masses or even a niche user base. No question, we are in the early stages of a new electronic age, often referred to as the Internet of Things (IoT) where wearables, self-driving cars, smart homes, and devices with a variety of connected sensors and cameras will soon dot our modern landscape in ways never before imagined.

When wearables are finally accepted into our lives (and research says they will) there will be a transformation, a radicalization, in such a way that industries such as healthcare, fitness, sports, apparel, entertainment, retail, and even manufacturing will never be the same again.

With each passing month, new technologies and innovations are introduced which propel embedded software development forward. No doubt, wearables introduce an entirely different design paradigm when compared to conventional embedded systems as they are a worn device thus size, weight, and battery life are critical design considerations. This paper takes a brief look at the wearable market segments showing early promise. It also examines some of the driving factors that are helping software developers and system architects design and develop successful, state-of-the-art wearable devices.

WEARABLE SYSTEMS TODAYSo what is the allure of wearables? For the most part, early indications reveal that users are hopeful a wearable device will yield unique information and insight, which in turn improves the user’s life on some meaningful level. Currently healthcare, fitness, and safety are key segments driving the popularity of wearables. These segments will only broaden the appeal of wearables and help spread new innovations throughout the wearables market. Further, while convenience and/or utility may be the current driving factors behind the purchasing decision of a wearable device, it’s only a matter of time before product aesthetics and ease of use become equally as important. As we become more adept at building wearables, it’s incumbent upon software designers and engineers to design for “simplicity.” The whole idea of having a wearable is to improve one’s way of life. If the device only complicates the typical day, or adds a new layer on involvement, we as software developers, have failed our intended end-users.

Wearable segments showing early promise:

This series of white papers, presented by Mentor Graphics, has been created to assist system architects and software developers who design embedded systems for wearables. This first paper, “Developing Effective Design Strategies for Today’s Wearable Devices: Key Factors Driving the Market,” touches on wearable segments and the contributions made within the industry. The second paper discusses techniques for power management, and the final paper covers security considerations for wearables.



Medical/Healthcare Monitors: Medically-certified wearable devices designed to remotely record specific vital signs or certain medical conditions of individuals who are sick and the elderly. These systems connect wirelessly to local area networks and the Internet (often through smartphones) to send data to doctors, hospitals, emergency responders, and healthcare specialists.

Fitness/Activity Trackers: Consumer devices with multiple sensors and software that track various levels of movement and exercise as well as monitor sleep patterns, heart rates, blood pressure, and other basic body functions. These are usually bracelets, wrist bands, or clip-on devices with a Bluetooth wireless connection to smartphones or computers.

Smartwatches: Wrist-worn personal communications systems that display time and day information, but also combine health/fitness tracking with mobile computing and connectivity to smartphone functionality. Most smartwatches today are peripheral devices for smartphones, which enable access to cellular communications and the Internet through a Bluetooth link.

Headgear/Smart Glasses: Computerized eyewear with optical head-mounted display and wireless connections to the Internet and cellular communications through a smartphone. These head-worn systems have embedded cameras and support “augmented reality” applications. Users are also able to view emails, text messages, and visit the Internet via miniature projection displays.

Body Cameras: Clip-on or embedded stand-alone digital cameras that record and feed images into smartphones for storage on the Internet or in the Cloud. Growing popularity among sports photography enthusiasts and video monitoring used by law enforcement agencies.

Additional Markets: Other wearable markets specialize in addressing certain parts of the human body. In addition to the areas mentioned above, these segments include smart clothing (arms, torso, and legs) for the sports/fitness and healthcare/medical industries; and smart shoes for the fitness and healthcare industries. Other miscellaneous wearable areas include helmets, 3-D trackers, secure wallets, personal security, and even pet trackers.



KEY FACTORS DRIVING THE INDUSTRY FORWARDBroad factors such as ubiquitous connectivity, technology miniaturization, and the business need for innovation and product differentiation have helped fuel the growth of wearables. But it’s also interesting to note that major vendors, suppliers, and semiconductor manufacturers are making commitments and significant contributions to wearables specifically.

System-on-chip (SoC) designs have been developed exclusively for the wearable market. This in turn, has led to consolidation of key functions with improved power management – extending battery life. Major silicon providers such as Texas Instruments, Qualcomm, Freescale, and Atmel have started to direct their research and innovation towards wearables and are starting to introduce wearable-specific silicon into the market. ARM® has been very active on this front with its Cortex®-M series of processors.

Full-featured, scalable, real-time operating systems (RTOSes) are now available and highly recommended for use in wearable embedded systems. The advantage of a using an RTOS is that developers not only gain the performance and small footprint of a deterministic kernel, but they are also able to address key issues such as power management, multicore and multi-OS design, and connectivity options.

And finally, major strides have been made in security. (See white paper #3 in this series.) With many RTOSes security can be implemented within the device (kernel and middleware), the network, and even up to the Cloud. Given the exponentially growing amount of data and valuable information being gathered, processed, transmitted, and stored, the connected device industry is becoming hyper-focused on ensuring all aspects of security are being addressed.

HARDWARE INNOVATIONEmbedded technology for today’s wearable devices require small form size, low power, and high performance. Unfortunately for many wearables up until just a couple of years ago, software developers and engineers were forced to incorporate microprocessor units (MPUs) and microcontroller units (MCUs) into their designs, which were originally intended for plug-in “green” devices or feature-poor, battery-powered devices. To improve performance, semiconductor vendors increased clock rates, which exponentially increased power consumption and heat generation, negatively impacting battery life. To address these problems and continue to meet the growing need for performance and functionality, semiconductor designs moved to homogeneous multicore architectures with integrated, discrete hardware components such as graphical processing units (GPUs). None of these “advancements” have helped the design of wearables (in particular, the smaller form factor, feature-rich, battery-powered devices). In fact, these advancements have had an adverse affect on wearables regarding heat generation and battery life. Today, tiered architecture (or hierarchical computing) is being used within a SoC to help optimize an embedded system for wearables, thus maximizing battery life. By using this approach, software developers are able to make trade-offs

between power usage and features (Figure 1). The trend allows companies to build SoCs exclusively for wearables. An example of hierarchical computing is the Dhanush Wearable Processor Unit (WPU) from Ineda. Freescale has also made available its Wearable Reference Platform (WaRP) on the i.MX 6SoloLite. WaRP is a type of open source reference platform, highly scalable, designed exclusively for wearable OEMs who want to build their embedded system on a single, common platform. MediaTek’s “Astor” SoC is another example. This SoC is used in many smartwatches which are now available to the public, the Omate smartwatch (left) is one such example. Interestingly, MediaTek claims its Astor SoC is the industry’s smallest wearable SoC. The Omate smartwatch.



Bluetooth Low Energy (BLE) Communication standards such as Bluetooth, ZigBee, and Wi-Fi were not specifically designed for low-power wearable devices. As a result, OEMs started to use proprietary communication protocols. While these protocols might’ve addressed low power, they restricted the use of interoperability among wearables.

To address this, the Bluetooth Special Interest Group (SIG) introduced Bluetooth Low Energy (BLE). Much like the original Bluetooth protocol, BLE operates in 2.4GHz with a bandwidth of 1 Mbps. BLE features include:

▪ The low data rate of BLE makes it an ideal fit for SoCs that require only state information be exchanged.

▪ Each layer of the BLE architecture has been optimized to reduce the time needed for connection setup to data exchange.

▪ The protocol has been optimized to burst transmit data in small blocks, at regular intervals.

▪ BLE features a robust architecture supporting Adaptive Frequency Hopping with a 32-bit CRC.

It’s important to note that BLE only supports broadcaster mode so wearable communications do not have to go through a con-nection procedure. Unfortunately, a wearable with BLE is not compatible with a wearable hosting the standard Bluetooth protocol.

The compelling difference between SoCs today and those from a few years ago, besides the reasons already discussed, is the greater availability of wireless connectivity options. Wireless connectivity spans the range from Near Field Communication, mesh networking, Bluetooth/BLE (see sidebar), and Wi-Fi, up to very large mobile cellular networks. This is an area where technology, protocols, and options are changing rapidly. Further, 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.

It’s also quite possible that these connectivity technologies will change over the lifetime of a device, or even during the development cycle. Isolating the application level within the SoC to accommodate change is most effectively handled by the operating system (OS) environment. To be able to move quickly and retain the original characteristics of the SoC, it is often recommended that a real-time operating system (RTOS) be utilized.

WHY A FULL-FEATURED RTOS? To accommodate the physical form factor of a wearable device, the electronics have very little volume available for the components. The physical size limitation typically results in a microcontroller SoC as the core processing engine. While a wearable device can pack an amazing array of peripherals for its size, the issue of memory capacity is the one area where geometry can’t be out maneuvered. If an RTOS is to be considered for both its small footprint and deter-ministic behavior, it must also be able to scale down to the most minimal size in both code and data requirements 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.

Figure 1: The three-tiered hierarchical computing architecture used by Ineda to maximize battery life with desired performance levels.

TECH13370-wMGC 09-15

©2015 Mentor Graphics Corporation, all rights reserved. This document contains information that is proprietary to Mentor Graphics Corporation and may be duplicated in whole or in part by the original recipient for internal business purposes only, provided that this entire notice appears in all copies. In accepting this document, the recipient agrees to make every reasonable effort to prevent unauthorized use of this information. All trademarks mentioned in this document are the trademarks of their respective owners.

F o r t h e l a t e s t p r o d u c t i n f o r m a t i o n , c a l l u s o r v i s i t : w w w . m e n t o r . c o m


Commercial and freely available RTOSes have been around for years, and countless embedded devices have been built with them. The “typical” RTOS consists of some basic capabilities, such as a kernel, file system, con-nectivity, and graphics support for the user interface (UI). While these same capabilities are required for today’s emerging category of wearable devices, developers now find themselves in need of a solution that fully addresses increasingly stringent requirements in the following areas: comprehensive power management (including multicore/multi-OS support), scalability, space partitioning, built-in connectivity options, and security (spanning from the individual device to the Cloud). These topics are discussed in greater detail in the other wearables white papers which are part of this series.

CONCLUSIONThe IoT wearables product category is expanding quickly. Advances in semiconductor technology and design, pervasive connectivity, and the growing consumer appetite for wearables are creating new revenue and business opportunities for manufacturers of connected wearable devices across industry segments.

This paper highlights the key growth segments in wearables. It also describes how commercial RTOS vendors and major silicon providers are now developing products to accommodate the strict requirements of a wearables design.

The wearable market is driving a wave of innovation. The next paper, “Developing Effective Design Strategies for Today’s Wearable Devices: Power Management,” will examine techniques and practises available to conserve battery life in wearable embedded systems which are increasingly becoming more complex.

For details on specific solutions and/or products, please visit the Mentor Embedded Systems website.

Author’s biography: Warren Kurisu is the Director of Product Management in the Mentor Graphics Embedded Systems Division, overseeing the embedded runtime platform business for the Nucleus RTOS, Mentor Embedded Linux, virtualization and multicore technologies, safety certified runtimes, graphics and development tools. Warren has spent nearly 30 years in the embedded industry, both as an embedded developer and as a business executive, working broadly in industries including aerospace, networking, industrial, medical, automotive, and consumer. Warren holds a master’s degree in Electrical Engineering from the University of Southern California and a Master of Business Administration from the University of California at Berkeley.

The registered trademark Linux® is used pursuant to a sublicense from LMI, the exclusive licensee of Linus Torvalds, owner of the mark on a worldwide basis.

http://www.mentor.com/embedded-software/


IT

EP

AP

ER



“POWER MANAGEMENT”(Paper #2 of a 3-part series)


Wearables: Power Management


COMPREHENSIVE POWER MANAGEMENTAs the next wave of wearable devices expands into a new class of revolutionary and innovative products, there will be a growing importance placed on the real-time operating system (RTOS) and corresponding middleware. Wearable System-on-Chip (SoC) processors require an operating system optimized for size and performance with power-efficient wireless connectivity options needed for machine-to-machine (M2M) communication and cloud connectivity. A full-featured RTOS which includes a variety of power management techniques is of the upmost importance. The Mentor Graphics Nucleus® RTOS is one such operating system that of fers a variety of power saving and power management capabilities. Two key power management capabilities supported by Nucleus are the Nucleus native power management framework and the Mentor Embedded Multicore Framework.

This paper examines how a full-featured RTOS can assist developers in the areas of extending battery life, designing within multicore/multi-OS environments, and other areas relating to embedded system power management which include scalability, space partitioning, and connectivity.

EXTENDING BATTERY LIFEBattery life has long been an important feature for connected and wearable devices as the end-user has very little patience for energy-hog gadgets requiring frequent recharging cycles. The current generation of wearables is placing new demands on reducing power consumption at a time when software complexity is rapidly increasing under system resource constraints of the wearable device.

From a business perspective, companies face enormous pressure to reduce development costs and shorten time-to-market with their devices in this increasingly crowded and competitive space. Also, leveraging software investments and minimizing costs in follow-on product versions utilizing updated hardware technologies is key to the success of any wearables product line.

Nucleus RTOS is the first real-time operating system with a built-in native power management framework designed to take advantage of the power management features now present in wearable SoCs. This framework allows developers to immediately address critical power issues without requiring developers to invest enormous amounts of time developing the power management software themselves. The Nucleus power management framework enables software developers to manage the power state for each peripheral, set of peripherals, or system, using simple high-level application programming interface (API) calls.

Just as modern software architectures abstract hardware functions through device drivers, the Nucleus power management framework (Figure 1) provides a structured mechanism for all system devices to be controlled using intuitive API calls. Any alteration of one device that impacts other devices results in a coordinated transition across all involved subsystems.

This series of white papers, presented by Mentor Graphics, has been created to assist system architects and software developers who design embedded systems for wearables. The first paper, “Developing Effective Design Strategies for Today’s Wearable Devices: Key Factors Driving the Market,” touched on the market forces and the growth segments within the wearables industry. This second paper, “Power Management,” discusses techniques for power manage-ment including how a multicore framework can assist software developers. The final paper in this series covers security issues and explains how developers can use technologies and techniques available today to ensure secure device operation.



The power management framework approaches the conservation of power usage from four different directions:

1) System states used to control peripheral power.

2) Dynamic Voltage Frequency Scaling (DVFS) focuses on the entire system.

3) Idle power management prevents expending energy without an ascertainable goal.

4) Hibernate/sleep modes allow the system to go off-line during long periods of inactivity.

Figure 1: At the center of a power management framework is the device manager capability which coordinates the transition of all devices during a change to a low-power state.

Figure 3: The Nucleus power management framework can be used to define and manage system power budgets, as in this medical wearable device example.

Figure 2: Source lines of code: comparison between bare metal, standard RTOS, and Nucleus RTOS with power management features. Oftentimes, developers end up with far more code when working in a bare metal environment.

With a power management framework, software devel-opers can effectively write code to meet power requirements without spending precious development cycles that could result in code bloat (Figure 2) or increasing the size of the memory footprint. A word about bare metal: Bare metal is usually considered more efficient because it is so lightweight. However, the amount of code required to move devices in and out of various power states is complex and can add code bloat without an established framework. For example, taking the Wi-Fi off-line for a transition requires code to ensure the buffers are empty for each TCP/UDP socket, as well as IP management queues. And, the buffer descriptors for each protocol level down to the direct memory access (DMA) state must be verified before the Wi-Fi can be taken off-line. This code is complex and can often be difficult to test.

Just as important, the Nucleus power management framework allows software developers to consider power specifications early in the software design cycle and enables them to define power states which can then be managed through the power management framework (Figure 3). Code can be written to minimize both the footprint and power consumption – and tested throughout the development process to ensure power requirements are achieved.



DESIGNING AND WORKING WITHIN MULTICORE/MULTI-OS ARCHITECTURES

Wearable SoC architectures are evolving rapidly to integrate more application-class and microcontroller-class cores on a single piece of silicon. System architects see a tremendous opportunity to consolidate and extend functions on these heterogeneous multicore processors, but are finding that consolidation of heterogeneous operating environments on a single SoC presents some unique architectural and development challenges. With this type of dynamic, it’s also more difficult for developers to utilize the power-saving capabilities available in the underlying hardware.

While symmetric multiprocessing (SMP) operating architectures allow load balancing of the application workload across homogeneous processors within the multicore infrastructure, they do not scale to heterogeneous cores. Further, while asymmetric multiprocessing (AMP) system architectures are increasingly required, there is a lack of accepted standards and software design paradigms to take full advantage of AMP architectures. Having certain mechanisms in place enables AMP applications to efficiently leverage parallelism offered by the heterogeneous processors present in a multicore configuration. Mentor’s multicore framework was designed specifically for these challenges and offers architects a light-weight methodology to quickly begin AMP architectural development.

THE MENTOR EMBEDDED MULTICORE FRAMEWORK To address AMP complexities, the Mentor®Embedded Multicore Framework (enabling AMP with the Nucleus RTOS, Mentor® Embedded Linux®, bare metal environments, and the Mentor® Embedded Hypervisor) allows developers to configure and deploy multiple operating systems and applications across heterogeneous processor cores. This comprehensive framework enables developers to manage the many challenges associated with inter-process communication (IPC), resource management and sharing, booting, process control, debugging, and application optimization within a heterogeneous multicore environment by supporting native, virtualized, and trusted configurations of multiple operating systems. Components of the multicore framework include:

INTER-PROCESS COMMUNICATION (IPC)

Once the master processor OS and application stack are running, many use cases require communication with other parts of the system. The multicore framework provides a cleanroom, proprietary implementation of an open

source remote processor messaging feature (referred to as rpmsg) to establish a commun-ications channel between the master operating system and the remote operating systems. In this way, data can be passed back and forth between the two in an interprocessor communication channel (Figure 4).

The transport layer that enables both remote processor lifecycle management and interprocess communication is made possible by VirtIO. VirtIO is a virtualization standard for high performance input/output device drivers widely adopted in virtualized Linux® environments. This same technology has now been imported and tested and is fully operational in an RTOS environment, allowing a seamless system IPC mechanism that interoperates between proprietary and open source environments.

Figure 4: The interprocessor communication (IPC) channel allows data to passed between the master OS (core 0) and the remote OS (core 1) allowing for buffer allocation, payload prioritization, and configuration from device trees.



PROCESSOR LIFECYCLE CONTROL AND MANAGEMENT Assuming control over a remote processor, and then starting or stopping an OS and/or app-lication stack within that remote processor, is referred to as remote processor lifecycle manage-ment. The Linux community has adopted a remote processor framework (remoteproc) for managing this scenario in an open source environ-ment and now this technology is part of the Mentor multicore framework. Remoteproc allows a master operating system to bring up other operating systems on other processor cores in the same SoC.

The remoteproc feature within Mentor’s multicore framework (Figure 5) allows remoteproc interoperability between numerous, disparate operating systems, such as Mentor® Embedded Linux®, Nucleus RTOS, and bare metal environments. A key benefit to remote processor lifecycle management is reduced power consumption. The remote processor stays in a low power state when not in use, which is a critical design require-ment for wearables. When the use case of the wearable device requires more powerful processing tasks, remoteproc is used to bring up the remote processor, which increases the power consumption only for the duration of that activity.

SIMPLIFIED BOOTING

Booting a heterogeneous system is also not as simple as booting an OS on a unicore or homogeneous multicore processor. One needs a way to manage the booting of operating systems across the various cores, and to manage the applications that run on those processors. For example, performance requirements may dictate a certain boot order of the components. The multicore framework feature provides the capabilities to manage the booting of operating systems and applications across heterogeneous cores through the support for the remoteproc which can be used for open source, RTOS, and even bare metal implementations.

VISUALIZATION INTO A MULTICORE SYSTEM

In order to optimize performance and power consumption, developers can benefit by having a way in which to visualize how the heterogeneous components interact in the consolidated heterogeneous system. Because the systems are consolidated on shared hardware, chances of running into resource contention and bottlenecks are increased, which can hinder performance, and create unnecessary processing cycles and power consumption. Developers need tools that can help them identify those contentions and bottlenecks, and then quickly find solutions to the problems. Sourcery™ CodeBench with built-in Sourcery™ Analyzer has been integrated into the multicore framework. This means various runtime systems and graphics components, along with virtualized guest runtimes and corresponding applications can be visualized on a single common timeline.

SCALABILITYSmall, battery-powered wearables require highly efficient methods that consume minimal resources and are amicable to minimizing power modes. Nucleus RTOS allows common applications to span not only a wide variety of peripheral combinations, but also allows 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 MPU platform.

Figure 5: Remote processor lifecycle management allows the master OS (core 0) to bring up other OSes on other cores.



SPACE PARTITIONINGAlthough there are plenty of commercial RTOSes to choose from, many of these RTOSes do not provide a mechanism for embedded developers to design software that can take advantage of spatial (memory) partitioning. With spatial

partitioning built into the operating system, the MPU can be easily configured at runtime to establish memory regions in both kernel and user space. Intuitive APIs can be used to load processes at runtime or dynamically based on the use-case during execution. Nucleus employs a light-weight approach to a process model (Figure 6).

The MPU in the ARM® Cortex®-M3/M4-based SoCs can be used for spatial domain partition-ing without the need (or overhead) to virtualize memory. Processes can be loaded directly into memory from ROM or Flash. And with prelinked embedding, processes can execute in Flash, which is a feature commonly required in MCUs with very limited RAM. Utilization of the MPU for process separation in Cortex-M-based SoCs, provides embedded developers with a powerful feature to design embedded systems for wear-ables that gives the perception of a system being much larger on the outside than what is actually available on the inside, since applications can be dynamically loaded

depending on the current demands on the wearable by the user. The ability to dynamically load processes in this manner allows the wearables designer to select hardware with minimum processing power and memory, which not only saves on cost, but also minimizes power consumption.

CONNECTIVTYFor wearable embedded systems, eliminating the design challenges associated with wireless connectivity to support M2M communication and cloud integration can be a critical factor on whether a product makes it to market on time, or if the product launches at all. This is especially true for wearable systems with complex applications that use multiple wireless connections or multiple profiles on a single device. The networking features in Nucleus incorporate a wide range of standards-compliant networking and communication protocols designed exclusively for wearables supporting Wi-Fi, Bluetooth, USB 2.0/3.0, and low-power options such as Bluetooth Low Energy (BLE) and 6LoWPAN over 802.15.4. Nucleus RTOS supports an array of chipsets and SoCs and its modular and highly structured organization provides for the ability to install additional software protocols as SoC requirements change.

WIRELESS

It’s quite common for wireless connectivity technologies to change over the lifetime of a wearable device. The introduction of Bluetooth Low Energy (BLE) is just one example. It’s even possible that a new wireless technology will be introduced during the development cycle of a wearable design. Some wireless technologies and their distinct advantages and requirements are outlined in (Figure 7).

Networking GUI FileSystems

PeripheralBus Drives

Nucleus® RTOS

Ethernet /Wireless LCD Storage Connectivity

Protected Memory

Process

ProtectedMemory

Process

ProtectedMemory

Library

ProtectedMemory

Library

ProtectedMemory

Figure 6: The Nucleus process model offers increased device reliability by providing hardware-enforced fault isolation.



6LoWPAN

IPv6 over Low Power Wireless Personal Area Networks (or 6LoWPAN) is a networking connectivity technology connecting wearables to each other and to the cloud. 6LoWPAN’s low-power, IP-driven nodes, and large mesh network support make it an ideal connectivity technology for not only wearables, but for a variety of IoT applications. It supports Layer 2 packet forwarding over multiple radio hops and is compatible with Ethernet, Wi-Fi, 3G, and satellite.

CoAP

Constrained Application Protocol (CoAP) is an application-layer protocol for simple, low-power connected devices allowing a device to communicate interactively over the Internet. CoAP is especially suited for devices such as wearables. CoAP is ideal for limited Flash or RAM requirements and supports DTLS for communications security.

Figure 7: The more common wireless links used in today’s wearables. Ethernet included as a comparison.





CONCLUSIONThe wearables market is driving a wave of innovation. OEMs, device manufacturers, and development teams are eager to find new design methods and methodologies that not only address how to create and optimize an embedded system (as complexity continues to increase), but how to keep development costs down.

This paper described numerous methodologies for power management of embedded wearable systems. To meet the stringent battery life requirements of a wearable device, architects and developers can benefit from the following:

■ A comprehensive and scalable system-wide power management framework

■ A framework for heterogeneous OSes and multicore where the cores can be powered up as needed by the user

■ A lightweight process model, which can dynamically load applications as needed

■ Low-power connectivity features

■ A system tool that helps developers visualize system issues and optimize performance and power consumption

The next paper, “Developing Effective Design Strategies for Today’s Wearable Devices: Security,” will examine techniques and technologies currently available to help software developers address the critical issue of building security into wearable devices.

For details on specific solutions and/or products, please visit the Mentor Embedded Systems website.

Author’s biography Warren Kurisu is the Director of Product Management in the Mentor Graphics Embedded Systems Division, overseeing the embedded runtime platform business for the Nucleus RTOS, Mentor Embedded Linux, virtualization and multicore technologies, safety certified runtimes, graphics and development tools. Warren has spent nearly 30 years in the embedded industry, both as an embedded developer and as a business executive, working broadly in industries including aerospace, networking, industrial, medical, automotive, and consumer. Warren holds a master’s degree in Electrical Engineering from the University of Southern California and a Master of Business Administration from the University of California at Berkeley.




IT

EP

AP

ER



“SECURITY”(Paper #3 of a 3-part series)


Wearables: Security


SECURITY FOR WEARABLESIt seems with each passing day we hear of a new data breach somewhere in the world. The malicious attacks can come from individuals, groups, or even from some type of clandestine government operation. As end users rely more on their connected devices, and businesses throughout the world transition to online activity, these nefarious actions of cyber-attack must be stopped. And while a 100 percent secure wearable on a network is nearly impossible, software developers and architects can still do their part to minimize the chances of a cyber data breach. Many of the precautions required are readily available today. In some cases, it’s the mindset around designing for security that needs to be addressed. Essentially, security can no longer be thought of as an “after thought” to embedded system design. Security needs to be considered from the first day a concept begins. Also, building security into a design must be thought of as protection against a design, an investment, rather than a “cost” nobody cares to cover.

Because so many wearable devices connect to dispersed public networks and support bi-directional data flow, most devices are highly susceptible to attack. Just look at the diverse set of network connectivity options available today compared to 20 years ago; Wi-Fi, ZigBee, Bluetooth, and 4G cellular simply did not exist. Each connectivity option has very clear advantages – as well as disadvantages when it comes to secure communications.

Without designing in security methods to address the full of range of threats, wearables are vulnerable to attacks from even the most unsophisticated malcontent . Without question, active and passive threats have to be detected, neutralized, and corrected before any harm to the individual device occurs. To ensure security, development teams should adopt a security development lifecycle approach that meets their requirements. For example, Microsoft has developed a comprehensive Security Development Lifecycle process that companies can use as a starting point (www.microsoft.com/en-us/sdl/).

Clearly, security is a very broad topic that begins with device conception and spans planning, process, activities, and technology. The remainder of this paper focuses on a handful of key technology topics that are useful, if not critical, to building secure wearable devices. These topics include:

■ The use of Public Key Infrastructure (PKI) for boot-time authentication and code authentication

■ Establishing a “chain of trust” to ensure downloaded code and data are authenticated and validated

■ Process separation using MMU-based memory protection to partition critical code and memory spaces

■ Leveraging safety-certified code

■ Hardware enforced system partitioning with ARM®TrustZone®

Let’s take a closer look at some of the techniques and technologies software developers are using to build security into their wearable devices.

This series of white papers, presented by Mentor Graphics, has been created to assist system architects and software developers who design embedded systems for wearables. The first paper, “Developing Effective Design Strategies for Today’s Wearable Devices: Key Factors Driving the Market,” touched on the market forces and the growth segments within the wearables industry. This second paper, “Power Management,” discussed techniques for power management including how a multicore framework can assist software developers. This final paper in this series, “Security” covers security issues and explains how developers can use technologies and techniques available today to ensure secure wearable device operation.

Wearables: Security


CODE AUTHENTICATION/BOOT-TIME AUTHENTICATIONCode authentication is essentially binary OS image authentication. Developers can set up their system to check to see if data coming in originated from the original equipment manufacturer (OEM). Further, as the developer, you need to investigate whether any of the code has been modified. Code authentication (Figure 1) and secure-boot authentication (Figure 2) are some of the most basic steps developers can take to secure their embedded wearable system.

Figure 1: Code authentication requires the use of both a Public Key and a Private Key. The Public Key is made available to everyone on the network via a publicly accessible repository or directory. On the other hand, the Private Key must remain confidential to its respective owner. Because the key pair is mathematically related, whatever is encrypted with a Public Key may only be decrypted by its corresponding Private Key and vice versa. This type of authentication achieves a high level of confidentiality.

Figure 2: Secure-boot authentication starts by executing a first stage boot loader stored within secure flash memory provided by the Trusted Platform Module (TPM) hardware. This boot loader is stored within protected memory so it cannot be replaced by hackers. Also stored in protected memory is the signature and crypto key for the second stage boot loader. The first stage boot loader calculates the signature of the second stage boot loader using the hardware crypto support and crypto key. If the calculated signature for the second stage boot loader matches the stored signature, we know the second stage boot loader is valid and allowed to run. The second stage boot loader repeats this verification process before loading the operating system.

Wearables: Security


ESTABLISHING A CHAIN OF TRUSTOnce the initial boot stage has been confirmed, the process can continue to create a chain of trust. By using the same Public/Private key approach, subsequent executable modules can be downloaded, verified, loaded, and run (Figure 3). This approach becomes particularly interesting in the case of a complex wearable device, that might be loading different operating environments and applications depending on the functional requirements required at any given time.

PROCESS SEPARATIONThe introduction of new SoCs designed for wearables provides enhanced system performance capable of running robust applications. However, the need to reduce size, power consumption, and cost will challenge software developers to run complex applications with limited memory resources. And this is where process separation can best be used. And while process separation leveraging a system MMU or MPU does not guarantee security, it does help to contain misbehaving applications from affecting other process applications or the kernel itself. Nucleus® Process Model (Figure 4) is a light-weight approach for space partitioning that creates protected memory regions offering full isolation of kernel and middleware resources. In this manner, scribblers, stack overflows, accessing rogue pointers, etc., in application code can no longer corrupt or interfere with system software operation. Utilizing the MMU or MPU, Nucleus Process Model partitions memory to create protected memory regions without virtualizing memory – which is extremely important with wearables. Space partitioning provides the framework to load new applications using cloud services, or the ability to partition large algorithms into smaller components that are loaded slightly ahead of execution time. With Nucleus Process Model, manu-facturers of wearables have the ability to provide compelling applications on devices with limited system resources with a level of security built in. Nucleus can also take advantage of advanced hardware-based security separation mechanisms to enable a Secure Execution Environment (SEE) which ensures data and code loaded within that secure partition can be completely isolated from the rest of the system. SEE is discussed later in the paper.

Figure 3: Chain of Trust – When we build our wearable device, we want it to be trustworthy and we want the software that runs on it to be authentic. To accomplish this, we establish a software “chain of trust” which starts from the root, the hardware. The process begins at the authentication step to make sure the hardware authenticates the boot ROM, the boot ROM authenticates operating systems, and then, of course, the operating systems authenticate the application layer. The goal of this strategy is to prevent applications from executing that haven’t been signed and authenticated. When we have the system up and running, we can prevent attacks and uploading of malicious code by looking at every file that is being downloaded, making sure that it’s signed and authenticated.

Wearables: Security


NUCLEUS SAFETYCERTMentor Embedded Nucleus® SafetyCert™ (Figure 5) is a safety-certified real-time operating system (RTOS) and middleware package targeting high-performance, next-generation applications. Nucleus SafetyCert is designed to meet the stringent safety and regulatory requirements for embedded devices, including system architectures that leverage the hardware MMU/MPU for process separation. As with using a process model, running a safety-certified operating system by itself does not guarantee security. However, by building on a safety-certified foundation, developers have an additional level of confidence that the code will behave as intended, which improves system reliability. Safety-certified environments also help avoid situations that might result from software faults that could cascade across the system and result in security vulner-abilities in unrelated sections of code.

Nucleus SafetyCert allows developers to shorten the path to regulatory certification with a complete certified solution that includes all the necessary documentation and artifacts required for users to develop mission critical

Figure 4: Nucleus Process Model adds task and library isolation – as well as memory protection – to a real-time embedded platform either on an MMU or MPU.

Figure 5: Nucleus SafetyCert com-mercial solution addresses a broad range of IoT sectors and includes a full spectrum of development tools (quality processes with test and documentation) available to Nucleus embedded software developers.

Wearables: Security


applications. Nucleus SafetyCert has been documented to meet the certification requirements for wearables or medical devices requiring International Electrotechnical Commission (IEC) standard 62304 certification.

SECURITY THROUGH ARM TRUSTZONE ARM® TrustZone® architecture (Figures 6 & 7) provides a solution that carves out or segregates a hardware subset of the SoC. It does this by defining processors, peripherals, memory addresses, and even areas of L2 cache to run as “secure” or “non-secure” hardware. A SoC that utilizes ARM® TrustZone® technology has the ability to dynamically, with only a few clock cycles delay, transition a system into “secure world” processing, where a subset of the hardware is partitioned, and data and processing is completely invisible to the rest of the system.

The normal world (or non-secure world) created and enforced by the ARM® TrustZone® can be used to define a hardware subset of the SoC. ARM® TrustZone® ensures that non-secure processing can access only non-secure resources and receive only non-secure interrupts. For example, a normal world hardware subset might include the

UART and USB interface, but exclude Ethernet access. The Ethernet might instead be dedicated to the secure world where a separate RTOS or application runs for the sole purpose of managing all Ethernet traffic, independent of the normal world software stack.

Software that runs in the normal world is assumed to be flawed from a safety and security perspective. That is, normal world software is expected to contain bugs, exploits, hacks, faults, or irregular-ities that could expose sensitive information or functions. It is these assumptions that drive the value of ARM® TrustZone’s® ability to isolate the adjacent processing area (secure world) where sensitive data storage or functions are managed from the perceived flawed normal world software.

Unlike the hardware subset in which normal world software runs, software running within the secure world has complete access to all of the SoC hard-ware. Thus, from the perspective of the secure software’s execution, the system looks and acts nearly identical to what would be seen on a processor that does not have ARM® TrustZone®. This means that secure software has access to all resources associated with both the secure and normal worlds.

ARM® TrustZone® architecture contributes to the overall system security by preventing normal world software from accessing the

Figure 6: The ARM® TrustZone® is well-suited for single-core configurations. Mentor Embedded Multicore Framework (MEMF) plays a key role in such a scenario.

Figure 7: The ARM TrustZone is also well-suited for multicore architectures. Again, Mentor Embedded Multicore Framework plays a central role here.




Wearables: Security

secure world resources. It is important to understand that ARM® TrustZone® does little to improve the safety or security of the software that runs in the secure world except to prevent unwanted secure world access by normal world software. It goes without saying that for the secure world to be completely trusted, the system must initially boot in a trusted state (see the earlier discussion about trusted boot). Beyond that, it is the developer who determines which software is “trusted” typically through rigorous development processes, testing, certification, and supporting a “chain of trust” strategy in the secure world.

CONCLUSIONSecurity for wearables is a complex subject. While designing an embedded system from the ground up provides many of the proven security capabilities other electronic system designs have been using for years – secure boot, code authentication, and chain of trust to name a few – these are basic fundamental security capabilities that every wearable needs to include today (when applicable). This paper described how Mentor Graphics is dedicated to assisting developers when building security into their embedded wearable systems. Mentor’s involvement in building for certification using Nucleus RTOS and involvement in secure execution environments with Mentor’s multicore framework capability are opening new doors for developers.

To view white paper #1 (“Factors Driving the Market”) and #2 (“Power Management”) in this 3-part series, please visit the Mentor Embedded Systems website.

Author’s biography Warren Kurisu is the Director of Product Management in the Mentor Graphics Embedded Systems Division, overseeing the embedded runtime platform business for the Nucleus RTOS, Mentor Embedded Linux, virtualization and multicore technologies, safety certified runtimes, graphics and development tools. Warren has spent nearly 30 years in the embedded industry, both as an embedded developer and as a business executive, working broadly in industries including aerospace, networking, industrial, medical, automotive, and consumer. Warren holds a master’s degree in Electrical Engineering from the University of Southern California and a Master of Business Administration from the University of California at Berkeley.



Documents

Today s Wearable Devices: KEY FACTORS DRIVING THE MARKET · Currently healthcare, fitness, and safety are key segments driving the popularity of wearables. These segments will only