Amulet: An Energy-Efficient, Multi-ApplicationWearable Platform

Josiah Hester*, Travis Peters†, Tianlong Yun†, Ronald Peterson†, Joseph Skinner†,Bhargav Golla*, Kevin Storer*, Steven Hearndon*, Kevin Freeman*,

Sarah Lord†, Ryan Halter†, David Kotz†, Jacob Sorber**Clemson University and †Dartmouth College

ABSTRACTWearable technology enables a range of exciting new applica-tions in health, commerce, and beyond. For many importantapplications, wearables must have battery life measured inweeks or months, not hours and days as in most current de-vices. Our vision of wearable platforms aims for long batterylife but with the flexibility and security to support multipleapplications. To achieve long battery life with a workloadcomprising apps from multiple developers, these platformsmust have robust mechanisms for app isolation and developertools for optimizing resource usage.

We introduce the Amulet Platform for constrained wear-able devices, which includes an ultra-low-power hardwarearchitecture and a companion software framework, includinga highly efficient event-driven programming model, low-poweroperating system, and developer tools for profiling ultra-low-power applications at compile time. We present the designand evaluation of our prototype Amulet hardware and soft-ware, and show how the framework enables developers towrite energy-efficient applications. Our prototype has batterylifetime lasting weeks or even months, depending on the ap-plication, and our interactive resource-profiling tool predictsbattery lifetime within 6–10% of the measured lifetime.

CCS Concepts•Computer systems organization → Architectures;•Human-centered computing → Ubiquitous and mobilecomputing systems and tools; Interaction paradigms;

KeywordsWearables, Mobile health, Energy, Low power

1. INTRODUCTIONWearable wristbands are increasingly popular devices for

health and fitness sensing, and the increasing variety ofapplications is driving the market from single-function devices(like the Fitbit Flex) toward multi-application platforms (likethe Apple Watch or Pebble Time).Permission to make digital or hard copies of all or part of this work for personal orclassroom use is granted without fee provided that copies are not made or distributedfor profit or commercial advantage and that copies bear this notice and the full citationon the first page. Copyrights for components of this work owned by others than theauthor(s) must be honored. Abstracting with credit is permitted. To copy otherwise, orrepublish, to post on servers or to redistribute to lists, requires prior specific permissionand/or a fee. Request permissions from permissions@acm.org.

SenSys ’16, November 14 - 16, 2016, Stanford, CA, USA© 2016 Copyright held by the owner/author(s). Publication rights licensed to ACM.ISBN 978-1-4503-4263-6/16/11. . . $15.00

DOI: http://dx.doi.org/10.1145/2994551.2994554

Figure 1: Perspective and interior views of our open-hardware wearable device, part of the open-sourceAmulet Platform. The platform supports develop-ment of energy-efficient, body-area-network sensingapplications on multi-application wearable devices.

These devices enable new sensing paradigms; they are worncontinuously, they can interact through a body-area networkwith computers, smart phones, and other wearables, and theycan provide at-a-glance information to the wearer. Someexisting devices are flexible and full-featured, with supportivedevelopment environments, but have inadequate battery life(about a day). Most others are single-purpose devices withbetter battery life that users cannot easily reprogram orcustomize for different applications and conditions.

Although the line between “smartband” and “smartwatch”products is blurring, we think of the former as having greatbattery life but limited flexibility, and the latter as hav-ing programmability but limited battery life. Battery lifeis a critical feature for mobile and wearable devices – byfar the most-important feature as rated by users of today’ssmartphones and wearable gadgets [9, 42]. We aim to enabledevices that have the week-long or month-long battery life-times of a smartband with the multi-application flexibilityand full-featured development environment of a smartwatch.

To support multiple applications, especially in critical do-mains like health, the platform must also provide strongsecurity properties, including isolation between apps. Torealize these goals, wearables must effectively manage en-ergy, share resources, and isolate applications on low-powermicrocontrollers that cannot support hardware memory man-agement units (MMUs).

In this paper, we present Amulet, a hardware and soft-ware platform for developing energy- and resource-efficientapplications on multi-application wearable devices. Thisplatform, which includes the Amulet Firmware Toolchain,the Amulet-OS Runtime, the ARP-View graphical tool, andopen reference hardware, efficiently protects applicationsfrom each other without MMU support, allows developersto interactively explore how their implementation decisionsimpact battery life without the need for hardware modelingand additional software development, and represents a newapproach to developing long-lived wearable applications.

We also aim to equip the health-behavior science com-munity with a wearable platform researchers can field forlong-duration experiments on human subjects in a wide vari-ety of studies, by providing the entire Amulet Platform as anopen-source, open-hardware alternative to the available com-mercial platforms that have so far been used for wearablesresearch. We envision the Amulet Platform as being broadlyapplicable to those in the sensing communities, as well asdomain scientists and practitioners in human-centered fieldslike health and fitness. With the Amulet Platform, sensorresearchers can prototype new wearable devices and test newsensing technology without building from scratch.

Contributions: The Amulet Platform enables developersto write energy- and memory-efficient sensing applicationsthat achieve long battery life on a secure, open-source, multi-application wearable device. Specifically, this paper makesfour contributions:

1. the Amulet Firmware Toolchain, a firmware-productiontoolchain that guarantees application isolation (protect-ing the system and applications from errant apps),

2. the Amulet-OS Runtime, a multi-application runtimesystem for resource-constrained wearables that is builton a low-power variant of the QP runtime [24],

3. a graphical tool called ARP-View that helps developerspredict Amulet battery lifetimes and understand howtheir decisions affect those lifetimes, and

4. an open-source, open-hardware release of the Amuletplatform and its tools1.

Although the focus of our current implementation is on asmartwatch form factor and on applications related to healthand wellness, these contributions can be generalized to anyembedded platform that needs to support multiple third-party applications with extremely low power consumption.Indeed, Amulet is not a single system – it is a novel approachto developing long-lived wearable platforms that is suitablefor a wide spectrum of multi-application wearable devices.

2. BACKGROUNDAlthough the Amulet Platform has potential to support a

broad range of applications, we focus our design on mobilehealth (mHealth) applications because they are increasingly

1The open-source, open-hardware release of the Amulet plat-form and its tools can be found athttps://github.com/AmuletGroup/amulet-project

prevalent and their need for a robust, secure, long-livedplatform poses important design challenges. The currentgeneration of mHealth wearables, such as the Fitbit Flexand the Withings Pulse, are single-application devices thatfocus on specific health goals like physical activity or sleepquality. These devices run one application, created by thedevice developers; they cannot run multiple applications norbe extended with applications from third-party developers.Meanwhile, “smartwatches” like the Apple Watch and theMicrosoft Band are general-purpose wrist wearables thatsupport multiple applications and third-party developers.Neither class of devices address our goals, for several reasons.

First, we are not convinced that all users want a general-purpose large-screen smartwatch with a battery life measuredin hours. Our architecture aims to enable smaller wristbands(and other constrained wearables) with battery lifetimesmeasured in weeks or months and support for critical andsensitive applications like those related to chronic diseaseand behavioral health.

Second, developer tools for these wearables are in their in-fancy. Battery lifetime (i.e., amount of time between batterycharges) is a critical concern for any wearable; although somedeveloper frameworks provide general guidelines for writingefficient applications, developers are unable to accuratelypredict how their applications will perform when deployed.The Amulet Platform includes tools that forecast battery life-times and an application’s resource usage. More importantly,these tools help developers conceptualize how their designdecisions impact energy consumption and identify specificopportunities for improvement.

Third, current solutions do not provide open-source hard-ware and software; the Amulet Platform is fully open-sourceand open-hardware, enabling new opportunities for innova-tion by health and technology researchers alike.

3. SYSTEM OVERVIEWWe designed Amulet to support a multi-developer, multi-

application vision, aiming at four goals not faced by single-purpose wearables, single-developer wearables, or power-hungry platforms that need to be recharged daily.

Goal 1: Multiple applications. Amulet platforms enablesensing applications written by third-party developers, even onresource-constrained wearable devices. The Amulet Platformmasks the complexity of embedded-system development, andsupports a variety of internal and external sensors, actuators,and user-interface elements. Since users are unlikely to wearmultiple single-function devices, the Amulet Platform aimsto support multiple concurrent applications.

Goal 2: Application isolation. Amulet platforms isolateapplications from each other and from the system. With mul-tiple concurrent applications, sensitive user information mustbe protected and applications must be prevented from inter-fering with the system or other applications. Amulet usescreative compile-time and run-time isolation mechanisms toachieve these properties on ultra-low-power microcontrollersthat do not provide memory virtualization or memory pro-tection. In this paper we focus on memory isolation andresource management; later papers will address encryption,key management, and related security aspects.

Goal 3: Long battery life. Amulet platforms enable wear-able devices with battery life measured in weeks. Today’s

Board Support

Amulet API

CoreServices

Hardware

App1 App2 … AppN

Logging Timer Crypto PowerNetwork Sensors

Serial SD Card Analog BluetoothGPIO ClocksWatchdog Interrupts

Core Interface

Board Interface

UI

Figure 2: The Amulet-OS software stack; applica-tions access core services through the Amulet APIlayer.

multi-application wearable devices have poor battery life,including research devices like ZOE [23] and commerciallysignificant devices like the Apple Watch [7]. Even the longest-lived commercial devices, like the Pebble [36], have lifetimesmeasured in days. When wearables can run for weeks ormonths, new applications are enabled and users are likelyto benefit from apps that support long-term 24/7 healthmonitoring and interventional behavior change.

Goal 4: Resource-usage prediction. Amulet platformsinclude tools that provide interactive analysis of resourceusage, including energy impact and memory usage for ap-plications and the underlying system. Existing tools forthird-party application developers on wearable platforms arevery limited, focused on documenting best practices andmeasuring resource usage of running applications; they donot provide compile-time, app-developer tools for predictingthe battery impact of an app or combination of applications.

We next describe our initial implementation, focusing onthe above goals in two parts: the Amulet-OS and the AmuletFirmware Toolchain (AFT).

3.1 Amulet-OSThe Amulet-OS software architecture (Figure 2) achieves

all the above goals by providing a low-power, event-drivenprogramming model, a rich API, and efficient app isolationand optimization through compile-time techniques.

Event-driven programming: Many sensing-based apps,including the health-oriented apps that motivate our work,tend to remain idle waiting for user interaction or new sen-sor data. Thus, Amulet uses an event-driven programmingmodel to simplify developer tasks and enable low-power op-eration. Each application is represented as a state machinewith memory, that is, each app consists of a set of statesand transitions between states, and a small set of persis-tent variables. Each transition is triggered by the arrivalof an event, which themselves result from expired timers,user interactions like a button press, or data arriving frominternal and external sensors. Apps can specify optionalevent handlers for each state and each event type. Handlersare non-blocking functions that may consume data arrivingwith the event, update app variables, call Amulet APIs, orsend events, in any combination.

This state-machine approach makes app state explicit, eas-ing analysis and optimization. App code, state, and variables

are kept in persistent storage. Handlers run to completion,so there are no threads with stack-based state information topreserve between events, let alone across processor reboots.The Amulet-OS leverages this simplicity for deep power sav-ings; when there are no events to handle, the processor cango into deep sleep or even shut off. The Amulet FirmwareToolchain leverages this structure to enable the analysis andprofiling tools described in the next section. This approachis also a major advantage over the alternative of running alarger operating system, such as embedded Linux or a real-time OS, in which applications are represented as processesor threads with complex state and limited opportunity fordeep sleep. (For more info, see Section 8.)

Amulet API: Amulet-OS provides an application program-mer interface (API) that allows for sensing, storage, signalprocessing, communication, timing, and user interaction. Aswith any OS, this API provides abstraction and resourcemanagement. Amulet-OS simplifies data gathering by pro-viding applications the ability to subscribe to internal andexternal sensors; multiple applications can share a singledata stream, each receiving an event when new data arrives.Amulet-OS also includes a logging API so apps can log sensorinformation to files on an internal microSD card, and a timerAPI so apps can arrange for an event in the future. Finally,the API provides apps access to interface elements (display,LEDs, buzzer, buttons, and capacitive touch, in our imple-mentation) and multiplexes access across apps. These APIscall into the Amulet-OS core services shown in Figure 2. Allsuch calls are non-blocking because event handlers must runto completion; where needed, a response is delivered to theapp later as an event.

The Amulet-OS is more of a lightweight run-time systemthan an operating system, but nonetheless supports multipleapplications on a low-power microcontroller without memoryprotection or management. These challenges are the focusof the Amulet Firmware Toolchain.

3.2 Amulet Firmware ToolchainThe Amulet Firmware Toolchain (AFT), shown in Figure 3,

manages the analysis, translation, and compilation of firmware.Here, we focus on two critical AFT roles: application isola-tion and resource profiling. First, the AFT ensures that appscan only access Amulet hardware by sending a well-formedrequest to the Amulet-OS core via the Amulet API, andprevents malicious or buggy apps from reading or modifyingthe memory of either the OS or another app. Second, withthe AFT’s profiling tools an app developer can predict herapp’s resource usage.

Analysis and Translation: Our approach leverages compiler-based translation and static analysis: application developerspass their code to the Amulet Firmware Toolchain, whichtranslates and analyzes the source code, rejecting any codethat is either not well formed or violates the isolation princi-ple. App designers implement Amulet state machines usinga simple variant of the C programming language, “Amulet C,”which offers programmers familiar programming constructsand facilitates efficient code generation, while excluding manyof C’s riskier features (Section 5). These modifications, andthe addition of loop invariants and automatic annotations bythe AFT, allow rigorous analysis of an application’s memorysafety. The AFT uses static-analysis tools to examine thecode to identify memory-safety violations and present the

Analyzer & Translator

Compiler

App 1 App N…

Linker

Installer

Analyzer & Translator

ResourceProfiler

ResourceProfiler

AppMerger

custom code

existing tool

QM File withAmulet C

Step 1: Verify compliance withAmulet C. Insert runtime checks(array bounds,access control)C code

C code

Step 2: Analyzeresource usage

Step 3: Visualize usage; Merge apps

Step 4: Compile andlink with the runtimesystem and libraries

Step 5: Install imageon device

C code

binary code

firmware image

AmuletOS

Libraries

ARP-View

Energy model

device profile

Figure 3: Architecture of the Amulet FirmwareToolchain, showing the steps in producing thefirmware image for a given Amulet device.

developer with compile-time errors. The AFT inserts run-time validation code where static analysis is inconclusive; forexample, the AFT inserts code for array-bounds checkingwhen the array index is not computable at compile time.

The Translator also implements authorization policies thatdefine which applications can access which resources. Forexample, these policies may say that a fall-detecting app maysubscribe to data from the accelerometer, that an emergency-response app may write a file to the SD card, or that the EMAapp may use the buttons and the display. By addressingthese policies at the time of app translation and analysis, theAFT can flag illegal access at compile time, and insert run-time checks only when needed. The resulting code is smaller,faster, and safer. We omit description of the authorizationpolicy module in this paper, for lack of space.

Resource Profiler: Although our experiments in Section 6characterize the performance of the Amulet hardware andsoftware under a representative app workload, and thoseresults show it is possible to develop efficient applicationsfor the Amulet hardware, new app developers may not haveaccess to the inner Amulet hardware or to our measurementinfrastructure. With effective compile-time tools that predictan app’s resource usage, developers can effectively managecritical resources and protect the user’s experience even whencombining apps from many developers.

The Amulet Resource Profiler (ARP) tool leverages theother modules in the Amulet Firmware Toolchain to predictan application’s resource usage; here, we focus on memoryand energy. Profiling these resources gives insight into theapp’s impact on battery lifetime, and the app’s impact onconstrained, shared, device computing resources. Lifetimeis the most important consideration for a wearable device;thus, giving developers insight on how their design decisionsaffect lifetime is of great value to the developer and theuser. ARP captures information about each app’s codespace and memory requirements, using a combination of

Figure 4: Screenshot of the ARP-View tool. A se-lected application is rendered on the screen wherethe transitions have been annotated with both theestimated cost of executing that transition and therate at which the transition executes. The slidersalong the right-hand side of the window allow thedeveloper to adjust the rate of specific transitions.The bottom area of the screen displays informationabout an application’s impact on the overall batterylifetime per week and memory usage. To view afull-size interactive demo of ARP-View, please visithttps://arpview.herokuapp.com/.

compiler tools and static analysis. To profile energy, ARPbuilds a parameterized model of the application’s energyconsumption, as described in the next section. The resultsare then exported for use by ARP-View.

ARP-View. This interactive tool presents developers agraphical view of the resource profile and sliders that allowthem to immediately see the battery-life impact when theyadjust application parameters. The tool guides developerstowards a better understanding of their application andenables them to explore trade-offs of different design decisions.See Figure 4 for a snapshot of the ARP-View in action.2

In ARP-View, developers are presented with an annotatedvisualization of their application that resembles their originalfinite-state machine. Annotations on edges (representingstate transitions) provide immediate feedback about the ratein which that event handler executes and the energy usageof that particular event handler. In addition, the ARP-Viewconsists of a set of ‘knobs’ that can be individually scaled tosimulate a particular handler running more/less frequently(Rt); this allows developers to evaluate the impact of specificapplication activities on the overall battery lifetime.

For perspective, ARP-View imports the device profile forinformation about the device (such as battery and memorycapacity) obtained earlier by the Profiler; see the next sectionfor more details.

Merge, Compile, Link: The next step in producing afinal firmware image, referring back to Figure 3, is for theAFT to merge the desired set of applications, then compileand link them with the Amulet-OS code. For Amulet weleverage an event-driven programming framework (QP) thatautomatically generates the C code for state transitions fromeach app’s state diagram. The AFT Merger combines this Ccode with the translated application code (now in C), and the

2We acknowledge that this snapshot may be too small toread without zooming. Readers are encouraged to visit ourinteractive demo.

Table 1: Model notationDevice profileMd storage capacity of data memoryMc storage capacity of code memoryEB energy capacity of full batteryE` average energy consumed by a line `Ef average energy consumed by one call to API function fP0 baseline power drawPs average power draw for subscription to sensor sS the set of all sensors on this deviceF the set of all API functions available in Amulet-OS

Application parametersA the set of all applications on this devicea an application in the set of all applications; a ∈ Af a function in the set of all Amulet API functions; f ∈ FFa the set of all API functions used by application a; Fa ⊆ Fs a sensor in the set of all sensors; s ∈ SSa the set of sensors used by application a; Sa ⊆ St transition t in the set of all application transitions, TTa the set of all transitions in application a; Ta ⊆ TL the set of all lines of code outside Amulet-OS` line of code in the set of all lines of code; ` ∈ L

N`,t number of times line ` is executed by transition tNf,t number of times function f is called in transition tRt rate transition t executes (transitions per second)

Energy estimatesEt estimated energy of each occurrence of transition tEa estimated energy consumed by application aEA estimated energy consumed by set of applications A

underlying event-driven application framework, into a singleC file. This file is compiled and linked with the Amulet-OScode, incorporating only the system components needed forthis particular set of applications. (We anticipate users willselect apps for their personal Amulet device from a storehosting apps from many developers and which compiles acustom firmware image comprising their selected apps.)

4. RESOURCE MODELAs noted above, the Amulet Resource Profiler (ARP) con-

structs a predictive energy and memory model for each appli-cation. In doing so, the ARP proceeds in four phases, withreference to the notation in Table 1.

Phase I: Import device profile. The ARP imports adevice profile, specific to the target Amulet model but in-dependent of any particular application. The device profilelists the amount of energy consumed for each API call andfor other fundamental operations, based on empirical mea-surements collected earlier on a given hardware and systemsoftware configuration; a device profile would be preparedand provided by the Amulet manufacturer with each newhardware and Amulet-OS release. (The AFT can assist byautomatically producing the code to create this profile bygenerating a specially instrumented Amulet Device Profilerapp that exhaustively tests each of the Amulet API func-tions that draw significant amounts of energy, for example,sampling the Gyro, writing to the SD card, or turning onthe radio. Using simple monitoring hardware, Amulet man-ufacturers can gather these statistics once and distributethe profile to application developers for their own testing.Similar to current Android manufacturer practice [4].)

The device profile includes information about the devicecapacity (memory, battery) as well as empirically derivedmeasures of average energy consumed Ef for each AmuletAPI function f ; the average energy consumed E` for exe-cuting a specific line of C code `; and the average powerdraw Ps for a subscription to sensor s (see Table 1). En-

ergy is measured in joules (J); power draw is measured inwatts (J/s).

Phase II: Analyze code. The ARP examines the appli-cation’s state diagram – a graph in which nodes representstates and directed edges represent transitions from one stateto another. The result is a set of transitions Ta for appli-cation a. For each transition t ∈ Ta the ARP identifies allnon-system code executed when transition t occurs (usingstatic analysis to count the number of executions N`,t of eachline of code `, summing across loop iterations and recursivelyexamining code in helper and library functions). That is, N`,t

counts the number of times line ` will be executed during thehandling of transition t, accounting for loops and functioncalls.3 Similarly, for each transition t the ARP determinesthe number of times the code for transition t will invoke eachAmulet API function f , which we denote Nf,t. Finally, theARP examines the sensor-related API calls to identify theset of sensors Sa to which application a subscribes. The con-straints of Amulet C (no recursion, no pointers, no dynamicmemory allocation) make this static analysis feasible.

Phase III: Construct model. The ARP constructs aparameterized model of the total energy cost for the app. Foreach transition t, it estimates the average energy consumedEt for an occurrence of that state transition, incorporatingthe cost of executing the code and API calls in that transition:

Et =∑`∈L

N`,tE` +∑f∈F

Nf,tEf (1)

If the app subscribes to any sensors to feed it sensor data, wemust also account for their average power draw:

∑s∈Sa

Ps.Finally, the Amulet hardware incurs a baseline power

draw when it is inactive; we use P0 to represent the averagepower draw of the baseline system (the microcontrollers, thedisplay, and the input devices). Because Amulet-OS has nobackground activity, this baseline power draw represents allof the Amulet-OS power draw not captured in the aboveequations.

To estimate the total energy consumption for applicationa, the ARP needs to know how often each transition t willoccur. While some of these rates may be discerned fromstatic analysis on the code, for others the ARP needs advicefrom the developer – which the developer provides throughannotations on the app’s state machine. These rates Rt arethe ‘knobs’ for the energy model – knobs the developer cantweak to explore the power draw for various design options(for example, the period of a timer that duty-cycles a keypart of the application behavior). The total energy consumedfor application a, over a time period τ , is thus predicted fromthe baseline power and the above equations, factoring in therate of every transition t:

Ea(τ) = τP0 +∑s∈Sa

τPs +∑t∈Ta

τRtEt (2)

Over a week, then, application a consumes a fraction of thetotal battery capacity, Ea(ω)/EB, where ω = 1 week; weleverage this calculation in our evaluation below.

Phase IV: Count memory usage. Every application

3We count lines of code as a proxy for code complexity;to improve accuracy we could use the code generator tocount instructions of assembly. Since instruction executionhas a relatively small impact on power consumption, ourimplementation assumes E` to be the same for all lines ofcode; we focus on modeling the API calls and sensor usage.

requires memory for storage of its code and its data; likeany embedded system, low-power wearable platforms haveseverely limited memory space. After parsing the applica-tion’s code and generating its firmware image, ARP reportsthe amount of memory to store the application’s code anddetermines an upper bound on the amount of data memoryconsumed by the application. These numbers are presentedas fractions of Mc and Md. An application’s data memorycomprises global variables and local variables (on the stack).Amulet C does not allow dynamic memory allocation, soARP easily counts the size of all global variables; Amulet Cdoes not allow recursion, so ARP can compute the maximumstack depth (including local variables).

Multiple applications. The ARP is also capable of esti-mating the energy consumption for some mix of applicationsA. (The view shows one app’s state diagram along withtotal energy consumption for all apps.) To estimate thetotal energy consumed by A, we cannot simply sum theenergy consumed by all of the individual applications. Thatis, the total is not simply

∑aEa, because we need to avoid

double-counting the baseline power draw as well as the sensorsubscriptions (which are shared across all apps). Instead,we need to account for the union of all sensors used by themix of apps: SA =

⋃a∈A Sa. The total energy consumed for

the application mix A is therefore estimated by a variant ofEquation 2:

EA(τ) = τP0 +∑s∈SA

τPs +∑a∈A

∑t∈Ta

τRtEt (3)

5. IMPLEMENTATIONWe developed a Amulet reference device and implemented

the Amulet-OS and Amulet Firmware Toolchain softwaredescribed above. In this section we describe the details ofeach, as well as nine applications we wrote to demonstrateand evaluate our Framework.

Amulet device prototype. The Amulet wearable proto-type shown in Figure 1 is mostly a single-board system. Themain board, battery, haptic buzzer, and secondary storageboard are all housed in a custom-designed 3D-printed casethat fits a standard 22mm off-the-shelf watchband. Thehardware architecture of the prototype is shown in Figure 5.

A Texas Instruments (TI) MSP430FR5989 microcontrollerwith 2 KB of SRAM and 128 KB of integrated FRAM servesas the main computational device. The wearable is equippedwith internal sensors for use by developers: an Analog Devices(AD) ADMP510 microphone, an Avago Tech APDS-9008light sensor, a TI TMP20 temperature sensor, an STMi-croelectronics L3GD20H gyroscope and an AD ADXL362accelerometer. The board includes a Nordic nRF51822 usedas a modem for communicating with peripheral BLE devices(such as a heart-rate monitor); the MSP430 communicateswith this radio chip over a SPI bus. The board’s GPIO andADC ports connect the microcontroller to two buttons, threecapacitive touch sensors, a haptic buzzer, and two LEDsembedded in the case. The small secondary storage boardholds a microSD card reader. The board also includes a USBbattery charger (MCP73831) that can recharge the 110 mA hbattery.4 A Sharp LS013B7DH03 display with 128x128 reso-lution is mounted on the backside of the PCB opposite the

4A survey of popular smartwatches [39] shows an averagebattery capacity in today’s smartwatches of about 350 mA h

AmuletPrototype

Light

Temp

Sound

USB

BLE MCU(nRF51822)

Antenna

Accel.

Buttons/Display/Touch

GyroµSD

Power/Data

FRAM MCU(MSP430)

LED

Battery

Haptic

Figure 5: The hardware architecture of our two-processor Amulet prototype: the MSP430 runs ap-plications, and the nRF51822 manages communica-tion.

components. In batches of 1000, including all components(except the enclosure and wristband), PCB fabrication, andassembly, we estimate the cost of a Amulet wearableto be only $54.85.

Ultra Low Power Operation: We use a variety of tech-niques to achieve low power operation. The MSP430 runsAmulet-OS and is responsible for running applications. TheMSP430 spends most of its duty cycle in a low-power deepsleep (3 µA); it wakes from sleep when action is triggeredby the user interface, a timer, or inbound message from theBLE radio chip. The MSP430 gates power to high-poweredcomponents (like the microSD card, and BLE radio) usingon-board MOSFETs. Thus, when these components are notin use by applications, they can be completely “turned off”to reduce power consumption. Always-on components likethe display draw only 6 µW.

Amulet-OS. We implemented the Amulet-OS run-time sys-tem on top of the QP event-driven framework [24]. Asshown in Figure 2 the Amulet architecture (and our imple-mentation) has three major layers: 1) a board-support layer,running directly on the hardware and abstracting some ofthe hardware-dependent nuances; 2) a set of core servicesthat provide core functionality like networking, time, logging,and power management; and 3) a set of application servicesaccessible through a thin set of functions in the AmuletAPI. The AFT static-analysis tools recognize Amulet APIfunctions and verify an app’s authorization to use specificapplication services (much as Android uses the Manifest fileto determine app permissions).

Recalling Section 3.1, the event-driven Amulet-OS has noprocesses or threads, and no context-switching overhead.Quick interrupt and event handlers allow the system to stayin low-power sleep mode most of the time. For the purposesof our experiments below, and to support the Amulet De-vice Profiler app, Amulet-OS can to toggle GPIO pins whenexecuting app event handlers, Amulet API functions, or inter-rupt handlers; our external measurement chassis (Section 6)monitors these pins to derive detailed energy and temporalmeasurements about application and system modules.

with a low of 250 mA h and a high of 570 mA h. Our 110 mA hbattery is much smaller.

Figure 6: Screenshots of six of the nine applicationspresented in this paper.

Amulet apps. We implemented nine applications to demon-strate and evaluate the Amulet Platform. Amulet applicationdevelopers construct their applications using the QP event-based programming framework. Following QP, each app isdefined as a finite-state machine; for each possible state, theapp can respond to a set of events by providing a handlerfunction for each type of event. We used vanilla QP withthe non-preemptive kernel (version 5.3), and required ap-plications to use the Amulet API to request services fromAmulet-OS. Screenshots of six apps are shown in Figure 6.

The QP framework exports the application in the XML-based QM format, which embeds all of the programmer-supplied C code along with information about the applica-tion’s finite state machine.

Amulet C. As mentioned earlier, app isolation is an impor-tant goal of the Amulet Platform. To achieve app isolationwithout the support of memory-management hardware, andwithout incurring excessive run-time overhead, the AFT con-ducts most app isolation at compile time. Applications (thatis, their handler functions) are written in a custom variantof C that removes many of C’s riskier features: access to ar-bitrary memory locations (pointers), arbitrary control flows(goto statements), recursive function calls, and in-line assem-bly. Since array access in C is implemented using equivalentpointer operations, we modified the array syntax so that ar-rays can be passed to functions explicitly ‘by reference’ (notas pointers). In Amulet C, arrays also have an associatedlength that allows for run-time bounds checking wheneveraccess behaviors cannot be adequately checked statically. Al-though this approach imposes some effort on the developer(to adapt their code for Amulet C) it allows us to estimatethe runtime of code executed in the state machine, givingtighter bounds on energy predictions made by the AmuletResource Profiler.

Amulet Firmware Toolchain. We implemented the AFTas a series of programs that translate, analyze, validate, andprofile apps. Each app includes 1) a state machine, 2) eventhandlers (written in Amulet C), and 3) attributes specifyingthe app’s global variables. The QP framework combinesapplication information into XML-formatted QM files. AFTtools are written in Java and use its built-in XML libraries toparse the submitted apps. Our tools translate the Amulet Ccode to safe C code using a modified C grammar and theANTLR parser generator [6]. Violations against Amulet C

coding rules and non-authorized requests to the core APItrigger AFT compile-time errors.

After all these steps, applications are merged togetherin a single QM file, which is then converted to C usingQP. Immediately before the merge, all app resources (e.g.,variables, handlers, helper functions) are isolated by mappingthem to a unique namespace based on the application’sname (no two apps installed on the system can have thesame name). This code is then compiled and linked usingTexas Instrument’s open-source GCC for MSP430. Thisfirmware image can then be installed onto the applicationchip (MSP430) of our Amulet device prototype.

Resource Profiler. We implemented the Amulet ResourceProfiler (ARP) in Java and integrated it with the other toolsof the Amulet Firmware Toolchain (AFT). After validationand translation, the ARP uses an ANTLR-generated parserto extract model parameters from the application’s code andQM file. Specifically, from the application code it extractsestimates of lines executed per transition (N`,t), sensor sub-scriptions (Sa), and Amulet API calls (Fa and Nf,t). Fromthe QM file it extracts the state machine and its transitions(Ta), and the developer’s annotations about transition rates(Rt). From the firmware’s symbol table it extracts the codesize for both the application and the core, and the amountof FRAM memory used by the application and the core.

Separately, the ARP uses the Amulet Device Profiler app,and the measurement chassis described in the next section,to extract the parameters for the device profile (Table 1).The Device Profiler app also informs ARP about the scalingfactors for certain operations, allowing for fine-grained esti-mates of function cost (for example, assigning lower energycosts to drawing a 2x2 rectangle as opposed to drawing a128x128 rectangle). The Resource Profiler combines thesemeasurements to build a parameterized model of the energycost for each application, following Equation 2. Our proto-type hardware has two kinds of internal memory: SRAMused for the execution stack and local data, and FRAM usedfor code and global data; thus our ARP implementationreports on SRAM and FRAM usage (rather than code anddata usage as in Section 4).

Resource Profiler Developer View. Our developer-facing tool, ARP-View, leverages the ARP’s fine-graineddata about the structure and behavior of applications to1) give developers insight into how certain user actions, sam-pling rates, and blocks of code consume energy, enablingdevelopers to make concrete the links between certain partsof code and energy draw; and 2) provide meaningful battery-lifetime estimates for an application or suite of applications.The ARP-View currently presents a wealth of informationincluding system and OS level details (e.g., FRAM avail-able and its usage), sliders to adjust event frequency andview results in real-time, and the battery impact (percent-age of battery consumed per week) and lifetime in days fora selected application as well as an entire suite of applica-tions. Our implementation provides real-time feedback tothe developer regarding application impact on the battery byrunning a daemon process that monitors application files andre-profiles applications upon detecting changes to those files;note that application translation, analysis, validation, andprofiling all happens prior to actually compiling the sourcecode and, thus, runs fast even on common laptop and desktopmachines. Providing memory stats to the developer via the

Table 2: Amulet applications used for evaluation

Name Description

Clock Display time of day and temperatureFall Detection Detect falls using the accelerometerPedometer Record number of steps walkedSun Exposure Monitor exposure to light over timeTemperature Monitor ambient temperature over timeHeart-rate Monitor and display HR from BLE sensorBattery Logger Monitor, display, and log battery statisticsHeart-rate Logger Monitor, display, and log HR statisticsEMA Deliver surveys to users with touch input

ARP-View requires compiling all of the application/systemcode and parsing the resulting binary, which incurs a no-ticeable – but small – amount of time (approximately 1-2seconds) on common laptop and desktop machines.

6. EVALUATIONIn this section we evaluate the performance of Amulet-OS

and the Amulet Firmware Toolchain against the goals fromSection 3. Goal 1 (Multiple applications) and Goal 2 (Ap-plication isolation) are met by design of Amulet-OS and theAmulet Firmware Toolchain. We thus focus on an experi-mental evaluation of Goal 3 (Long battery life) and Goal 4(Resource-usage prediction). First, though, we describe theexperimental infrastructure that allowed us to collect precisecontrolled measurements of the Amulet system (and its apps)without incurring measurement artifacts or overhead on theAmulet itself.

Measurement chassis: For detailed measurements undercontrolled conditions, we built a chassis comprising multi-ple ARM breakout boards equipped with 12-bit DACs and16-bit ADCs (to control and monitor signals on the proto-type Amulet), MOSFETs to gate power to the prototypes(allowing repeatable testing by power cycling), and INA225auto-ranging current-sense circuits to gather power readings.This programmable chassis allowed us to stimulate the userinterface and trigger state changes in the applications undertest. Thus, we could automatically and repeatably test theAmulet prototype under controlled and consistent conditions.

Applications: We developed nine apps for use in the evalu-ation of Amulet (Table 2), selected to represent a range ofcompelling applications and exercise many of the featuresavailable in the current prototype. Three of the apps wereused in the pilot study described in Section 7.

Event automation: We used the measurement chassisalong with minor modifications to the core code to partiallyautomate the state transitions of the applications running onour prototype Amulet devices. User sessions can be simulatedby providing an interaction script that defines the interaction(specifically the named state transitions), and the delay be-tween these transitions. This method was minimally invasiveto the Amulet software and hardware (one dedicated I/Opin and a small portion of RAM). By executing interactionscripts multiple times, the full functionality of an applicationcan be tested repeatably and without human involvement.We refer to this program as the “Event Automator”.

6.1 Battery lifetimeIn this section we quantify the average power draw of our

Amulet prototype for multiple loads. We represent this power

233days

209days

140days

214days

192days

54days

17days

14days

67days

39days

0.0

0.5

1.0

1.5

Clo

ckFal

l Det

ect

Ped

omet

erSun

Exp

osur

eTem

pera

ture

Hea

rtra

teBat

tery

Log

HR

Log

EM

AC

lock

+HR

+Fal

l

Po

we

r (m

W)

Figure 7: Average power draw for each app on thecurrent prototype. The expected lifetime with the110mAh battery is shown above each bar.

draw in terms of battery lifetime using the 110 mA h batterycurrently encased in the prototype. (Larger batteries up to570 mA h are used in current smartwatch products [39].) Weacknowledge that the accuracy of battery lifetime estimatesdepends heavily on battery wear, quality, leakage, and otherfactors. These estimates serve to place the actual measuredpower draw in an understandable form.

For our first experiment, we installed a firmware imagecontaining a single application and measured the averagepower draw using the measurement chassis. We used theEvent Automator to emulate user sessions, where a ‘session’lasted as long as it took to exercise states in the criticalpath of an application. We repeated this experiment for eachof the nine applications, for a single session, determiningaverage power by summing the energy of the session anddividing by the time. The results of this experiment areshown in Figure 7. This figure shows the power draw of anapp was highly dependent on the hardware components used,and the frequency of their use, further motivating the use ofARP-View. Lifetimes for all of the apps exceeded two weeks.

On our current prototype, an application load compris-ing Clock, Fall Detection, Pedometer, Sun Exposure andTemperature would allow an Amulet battery to last overfour months. With constant BLE communication to theheart-rate sensor (we used commercial Zephyr and Mio heart-rate sensors) our Amulet’s power draw allows for nearly atwo-month battery life. Two energy-hungry applications(Battery Log and HR Log) used significant amounts of en-ergy logging data to the microSD card, drastically reducingbattery life.

To determine the effect multiple applications have on thedevice lifetime, we assembled a firmware image that includedthree applications (Clock, Heartrate, and Fall Detection),and measured the steady-state power draw as above. Withthis configuration, using the accelerometer, Bluetooth com-munication, and updating the display, the expected lifetimewas 39 days. In summary, an Amulet with applicationsusing on-board sensors will last for many months, an Amuletusing an external BLE sensor feeding regular heart-rate datawill last for 1-2 months, and applications making heavy useof the logging operations or capacitive touch features will

Table 3: ARP battery-%impact predictor.

App Name Obs. Pred. Error Error( µW) ( µW) ( µW) (%)

Clock 72.73 77.45 4.72 6.1Fall Detect 81.20 89.21 8.01 9.0Pedometer 120.47 129.98 9.51 6.3Sun Exposure 79.19 85.13 5.94 7.0Temperature 88.37 92.89 4.52 4.9Heart rate 316.16 320.34 4.18 1.3Battery Log 984.10 1089.63 105.53 9.7HR Log 1223.11 1318.68 95.57 7.2EMA 253.07 265.05 11.98 4.5Multi 430.01 438.86 8.85 2.0

last for a few weeks. This lifetime enables long-term usagefor many application domains.

6.2 Resource ProfilerRecall that the ARP tool predicts the effect of an app

on the battery lifetime of an Amulet device. Specifically,ARP predicts the app’s total energy cost per week, whichcan be used to determine the impact an application hason the battery lifetime. To evaluate the accuracy of thesepredictions, we compared the ARP battery-impact prediction,for each app, with the actual battery impact computed fromthe measured average power draw presented in Figure 7.

Each app’s event frequencies were set to match the eventfrequencies used by the Event Automator in collecting themeasurements that resulted in in Figure 7. For some apps,specifically Clock, Temperature, and Sun Exposure, theseevent frequencies were gathered from the developer’s code.These apps sense intermittently, on a timer whose value is setby the developer inside the code for a transition. These appsonly respond to the timer, not to user or environmental input,so their energy impact depends completely on the timer value.Event frequencies were set carefully for Apps like Pedometerand Fall Detection, but their energy impact was dominatedby the Amulet’s baseline energy, paired with the numberof times they compute over a series of acceleration values.Table 3 presents the predicted (and observed) percent impacton battery life, for each application, along with the percenterror in the ARP prediction. (We quantify the error asthe difference between expected average power draw andobserved average power draw.) The results indicate that ourResource Profiler was reasonably accurate at estimating thebattery life for these applications.

Applications can have different battery lifetimes dependingon the amount of user interaction, the data rates or sens-ing schedules, the environment, and of course, the choicesthe developer makes in implementation. We capture fourtypes of events in ARP: 1) User interaction, 2) Data deliv-ery, 3) Timers, and 4) Programmer defined. While datadelivery events are static (sensor subscription schedules aredetermined beforehand in our current system), each of theother three can be modified by the developer to explore theeffect on battery lifetime. The ARP predictions are heavilydependent on the accuracy of the underlying device profile.Small measurement errors in generating the device profile cancompound as event frequency increases. ARP has troublequantifying certain types of operations. For instance, theenergy required for microSD card writes is heavily dependenton the size of the write. ARP does not currently account forparameter length in SD writes, contributing to the higher

error for applications that use SD functions (Battery Log,HR Log). Nonetheless, in our experiments, the highest errorrate was only 9.7%, and we expect it will improve.

However, most developers will not care if their applicationis predicted to last 90 days and instead lasts 80 or 100 days;they care about how the code they write, and the frequency ofevents, proportionally affect the lifetime. Of course, furthertests ‘in the wild’, with a wider variety of apps, will benecessary to generalize this conclusion.

6.3 ARP-View User StudyWe claim that ARP-View helps developers reason about

how different parts of their code, and their decisions, mapto energy costs of the application. To test this claim, weconducted a preliminary study of 10 computing students(Sophomore to Graduate) who all had some experience withlow-power embedded systems.Each subject was asked toconsider developing an embedded application that requiredsensing temperature at an undefined frequency. Subjectswere asked to decide how frequently to take temperaturereadings, and to calculate the fictional application’s energyusage given their chosen frequency. To assist in this process,subjects were first provided the QM IDE and a data sheetcontaining relevant information about the temperature sensorbeing used. Subsequently, each subject was provided ARP-View, and asked to repeat the same tasks as above. Eachsubject went through a structured interview at the end ofthe study.

We found that ARP-View helps developers better under-stand the relationship between event frequency and energyuse. Prior to using ARP-View, only 2 subjects reportedconsidering energy consumption as a determining factor indeciding how many events to use, while 9 in 10 subjectsreported accounting for energy in their decision-making pro-cess when using ARP-View. Additionally, ARP-View madeevent-frequency decisions easier for developers: 7 of 10 sub-jects reported their decision-making process was less difficultwhen using ARP-View. Further, after using both tools, 8 in10 subjects indicated they would not consider using the QMIDE and a data sheet to aid in their future application devel-opment, if able to use ARP-View instead. We believe thesefindings indicate there is room for further exploration into de-veloper understanding of resource use on constrained devices,and tools like ARP-View can assist in their reasoning.

6.4 OverheadRuntime: Energy consumption is significantly impacted bythe fraction of time the application microcontroller (MSP430)is active; the rest of the time it can be in a low-power deepsleep mode. The MSP430 is active whenever it is runningapplication code (handler) or system code (Amulet-OS andQP system code). The latter time is overhead, from theapplication’s point of view. To measure this overhead, weinstrumented the Amulet-OS to trigger I/O pins wheneverit 1) puts the system to sleep, 2) was active and executingAmulet-OS code, and 3) was active and executing applicationcode. We then used our measurement chassis to obtainprecise measurements of the time spent in each mode, foreach of our applications, as shown in Table 4. For eachapplication listed, we ran three short sessions while theapplication was conducting its normal duty cycle, but notbeing triggered by user-interface events. For all apps thismeant polling sensors, and waking up for timer events. The

Table 4: Temporal overhead.

Application %Sleep %OS %App

Clock 98.1 0.9 1.0EMA 98.2 1.0 0.8Heart rate 91.1 0.9 8.0Pedometer 93.8 2.2 4.0Pedometer+HR 87.5 1.9 10.6Pedometer+HR+Clock 85.4 2.8 11.8

low temporal overhead of 0.9-2.8% confirms the efficiency ofour approach.

Memory: Amulet-OS uses a portion of the limited memoryspace available to applications, limiting the quantity andsize of apps that can be installed in a single firmware image.In our prototype, applications and the OS must share thelimited FRAM memory space (128 KB). For a firmwareimage comprising five applications that used most of thefunctionality available, Amulet-OS consumed 55.91 KB ofthe 128 KB available FRAM code space, while applicationsconsumed 14.48 KB; the OS consumes nearly half of thecurrent FRAM. Meanwhile, Amulet-OS claims 1.078 KB ofSRAM, leaving 0.922 KB of SRAM for applications; recallthat apps use SRAM only for their execution stack, and onlywhen actively executing an event handler; only one app isactive at a time. Moreover, FRAM and SRAM are continuouson the MSP430; we anticipate making larger blocks of FRAMavailable (to be treated as RAM) to the application.

The memory and runtime overhead of our Amulet imple-mentation – while sufficient to develop multiple interestingapps on constrained hardware – could be improved. Memorylimitations could be sidestepped by adding 256KB of externalFRAM on a secondary storage board to “swap” applications.We expect runtime overhead to further improve as we tunethe display driver, which dominates the system overhead.

7. PILOT STUDY: MHEALTHWe conducted a preliminary pilot study with the Ecological

Momentary Assessment (EMA) application in collaborationwith our School of Medicine.EMA tools are often used inbehavioral medicine research. These tools allow participantsto report on symptoms, affect, behavior, and experiences atthe time of action, and in the participants’ natural environ-ment. This preliminary study was intended to evaluate useracceptance of the Amulet wearable, and technical feasibilityof multi-source data collection with an mHealth EMA appli-cation. This type of application can be used in both clinicaland research settings for tracking stress, cravings, sleepingand eating habits, and other events in a non-intrusive way.

An EMA tool needs to be non-invasive to the users’ dailyroutine. A wrist-worn EMA device is better positioned thana mobile phone to facilitate a quick, unobtrusive response toan EMA prompt. Moreover, a wearable with long batterylife allows for continuous, un-interrupted monitoring, doesnot burden the user with the need to recharge the device,and is less likely to be left behind or misplaced.

For this preliminary study, we recruited six participants(medical students) to simulate the behavior and user inter-actions of the target population (habitual cigarette smokersover the age of 18). Each participant wore the Amulet pro-totype and an external heart-rate sensor (a Mio LINK) for5–10 hours of a normal workday. We loaded their Amulet

Table 5: Data gathered during pilot deployment.

Packets Battery drain Duration Mio BLEreceived per hour worn disconnect

P1 13,381 3.2% 9.3 hr 62.0 minP2 15,526 2.1% 9.6 hr 0.2 minP3 10,267 2.0% 6.6 hr 0.3 minP4 10,893 1.9% 7.3 hr 0.2 minP5 12,709 2.4% 8.7 hr 42.5 minP6 8,645 1.7% 5.4 hr 0.0 min

with the Clock, Heart-rate Logger, and EMA applications.The EMA application asked participants about their tobaccouse at random intervals during the day, prompting them toanswer a few multiple-choice questions using the buttons andcapacitive-touch slider. A screen shot of the EMA app start-ing one of these surveys is shown in Figure 6. Participantsreturned both devices at the end of the day, and then filledout a short usability survey.

Data Gathered: we logged EMA responses, heart-ratedata from the Mio LINK HRM sensor, and battery-statusanalytics to the microSD card throughout the study. Amuletprototypes were worn for a total of 47.8 hours, and gatheredover 71,421 heart-rate readings. Table 5 shows statisticsfor each participant. The amount of time the Mio wasdisconnected correlates strongly with the amount of energyused; whenever a connection was lost, the Amulet prototypegoes into a high-power discovery mode attempting to re-establish connection. The battery drain was higher thanexpected; we identified after the study that the capacitivetouch sensors were drawing a continuous 1400 µW during thedeployment, reducing the battery much faster than expected.These sensors were not exposed to the developer API or ARPat the time of development. After the pilot, we added APIfunctions to allow developers to enable and disable the touchsensors. As these user-input elements are only needed whenthe user is presented with EMA questions, this duty cyclingwill significantly increase lifetime. (We used this newer EMAapplication for Figure 7.)

Usability Results: Each participant filled out the SystemUsability Survey after their session [12]. The participantsall thought the Amulet prototype was a bit bulky and un-comfortable, but a majority did not consider it a nuisanceand thought it was easy to use, while a plurality noted thatthey learned something about themselves by using the sen-sor. The biggest problem identified was the small size anddifficult placement of the buttons. All of the participantsenjoyed the real-time feedback about their heart rate. Wehave since addressed these usability issues with a smaller,more comfortable case (and larger buttons).

This preliminary deployment demonstrated the feasibilityof the Amulet prototype for EMA, and for continuous moni-toring applications on human subjects. Indeed, we now planfurther studies with more subjects and for longer durations.

8. RELATED WORKThe collection of software and hardware techniques in

Amulet draw extensively from the wireless sensor networkliterature. In this section we address related work in softwarearchitectures for sensor-focused devices and other constraineddevices (including wearables); approaches for isolating the

execution of application code; and techniques for modelingan application’s energy and resource usage.

Open wearable platforms. Current commercial plat-forms such as Pebble, Android Wear, and Apple watchOSonly document best practices and measure resource usage ofrunning applications [3, 8, 35], and are closed source, closedhardware, or both. However, many open platforms havebeen developed concurrently with Amulet as the wearablehardware ecosystem has evolved; many are not yet availableto users or developers, or do not address one or more of theAmulet goals. BLOCKS [43], ZWear [48], Angel Sensor [5]and Sony’s Open SmartWatch Project [40] are all in devel-opment. Little information about their developer tools areavailable; none of them appear to provide compile-time, app-developer tools for predicting battery life for a given app orcombination of apps, and none are engineered to give batterylifetime measured in months. Hexiwear [19] is completelyopen source and open hardware built for the mbed plat-form. However, it lacks comprehensive developer tools thatallow application isolation and evaluation of energy costs.Hexiwear was not built specifically for low power operationlike Amulet. The choice of high powered components likea color OLED screen and ARM Cortex-M4 make lifetimessignificantly less than the Amulet.

Wearable platform such as ZOE [23] Mercury [27] andOpo [20] have been designed by the research communityto address specific sensing problems, or to explore specificresearch areas (like BodyScan [16]).

In contrast, Amulet provides open-source hardware andsoftware in a general platform allowing wearable systemdesigners to innovate at both the operating system and ap-plication level – importantly, Amulet provides a tool thatgives application developers insight into the tradeoffs be-tween energy and utility. The Amulet Firmware Toolchainand Resource Profiler provide novel capabilities essential toapp development for long-running multi-application multi-developer wearables.

Software architectures. Software architectures and op-erating systems exist for sensor networks and the Internet ofThings, including TinyOS [25], Contiki [15], RIOT OS [10],and mbed OS [29]. SafeTinyOS [14] allows for the static anal-ysis of code to improve reliability and programmer confidencein a solution for single TinyOS applications. Amulet usessimilar static analysis techniques to provide application isola-tion and energy prediction for multiple applications. All butRIOT OS are event-driven (like Amulet), and only one (mbedOS) provides application isolation and access control. Thembed OS provides app isolation using the target processor’sMemory Protection Unit (MPU) – a capability not availableon the ultra-low-power microcontrollers targeted by Amulet.

Amulet’s architecture combines high- and low-power com-ponents to achieve our lifetime, performance, and availabilitygoals. This design is similar to other hierarchical power-management systems [1,11,41] that seek to provide resource-rich computing platforms with wide dynamic power ranges,by combining a hierarchy of functional “tiers” into a sin-gle integrated platform. None of the other IoT frameworksin development appear to offer the multi-application andapp-isolation features of Amulet.

Application isolation. Traditionally, hardware memorymanagement units (MMUs) prevent applications from in-terfering with each other and with core system functions.Software fault-isolation techniques extend the MMU by isolat-

ing malicious code and been implemented for x86 and ARMarchitectures [37,46,47] or require hardware (MMU) support.These approaches require hardware (MMU) support not avail-able on low power processors, and incur significant runtimeoverhead. They are not tenable on the constrained hardwareplatforms that enabled long-lived wearable deployment.

Language-based techniques provide a more efficient al-ternative, by changing the programming model [18, 21] tomake dangerous actions impossible or easy to detect, andusing a combination of compile-time static analysis and in-serted run-time checks to detect the dangerous actions thatremain [13, 14]. The Amulet architecture builds on thesetechniques, with a new focus on safely combining multipleapplications without hardware memory-protection supportand providing insight into each apps’ share of system re-sources.

Energy and resource modeling. Previous research onenergy modeling for constrained devices has focused on tech-niques for smartphones and wireless sensors. Tools like San-dra [31], eDoctor [28], Eprof [34], Carat [33] and PowerFore-caster [30] help users make decisions about energy efficiencyat install time, observe the effect of use from day to day, ordiagnose abnormal battery drain. Other research has triedto identify how users and batteries interact—investigatingthe battery mental model of users [17]. These works focus onmeeting user needs while ARP-View is focused on enablingthe developer. Further, these systems are all in-situ; gather-ing information about usage and then presenting informationto the user. However, integrating these tools with ARP-viewcould provide interesting avenues for future work.

Developer-focused tools have also emerged for smartphones.Tools have focused on identifying energy bugs at compiletime [44], in-situ energy metering using kernel additions forenergy model building [45], and then using those models topredict smartphone lifetime [22]. These tools, if carefullyapplied to constrained wearable platforms, could complementthe developer insights gleaned from the Amulet ResourceProfiler and ARP-view.

Other tools profile changes in the frequency and amountof system calls as a proxy for hardware profiling, to esti-mate changes in application energy efficiency [2]. Some toolsestimate energy cost per line of source code [26]. Thesetools provide insight for the developer into energy usage andefficiency, but are not tuned to the specific needs of wear-able development. Wearable applications are more energyconstrained than cell phones, and rely on periodic sensingactivities for their function. The developer must be ableto easily identify energy expensive code segments that areperiodically executed. This is why ARP-view exposes timersto the developer, allowing them to manipulate code, andfrequency of sensing actions in a GUI, without additionalprofiling or emulation steps.

Simulation and emulation techniques have attempted toprovide forecasts of energy usage, starting with tools from thewireless sensor network literature like Power TOSSIM [38].WattsOn [32] extends the idea of emulation to provide in-sights and what-if analysis for Android applications, afterrunning the application in an emulator. WattsOn specificallyfocuses on empowering developers to understand energy effi-ciency, and is most closely aligned with the goals of ARP-view.However, WattsOn is phone-focused, and does not accountfor periodic sensing tasks that are crucial to wearable oper-ation. Nor does it provide real time feedback on code and

duty cycling changes. Wearables require special attention tobe paid to periodic sensing tasks, timing and duty cycling,and costs of each API function. The Amulet Resource Pro-filer seeks to empower wearable developers without requiringspecialized hardware knowledge, or costly profiling and emu-lation, all while accounting for sensing and user-interactioncosts.

9. DISCUSSION AND FUTURE WORKThe Amulet project (see http://Amulet-project.org) is

a large, ongoing research effort, and this paper is focused onjust one aspect of the Amulet vision and its novel approachto enabling secure co-existence of multiple applications onan ultra-low-power wearable device. There remain somelimitations and areas for future work.

Profiler limitations: Predicting software energy costs isdifficult in any context, and the Amulet Resource Profiler hassome limitations. First, it currently assumes that every lineof code has the same energy cost E`, regardless of complexity(though it does account separately for any function the linecalls; each of the system API calls are explicitly measuredsuch that we know the amount of energy consumed by makingsuch a call and thus, do not have to estimate their energycost). We could improve our analysis tools (and benchmarkmeasurements) to reflect a more nuanced view.

Second, it cannot handle data-dependent loop conditions(all loops are expected to execute a statically-determinedmaximum number of times) or conditional statements (ARPconservatively assumes both branches are always taken).

Third, it assumes that each sensor has an average powerdraw Ps, although some sensors may have different rates ormodes of operation that affect power consumption. Indeed, itassumes that the set of sensor subscriptions does not changeover time, whereas some apps may start (or end) sensorsubscriptions (triggered by new data or by user input).

Fourth, as applications become more complex, the ARP-view interface becomes much larger, and the amount ofparameters increases, which could lead to usability prob-lems, We plan to address these limitations by refining ourenergy model and analysis tools. Further improvements toARP-View are planned that take advantage of the wealthof information provided by ARP. By integrating ARP-Viewwith a code editor, developers will be able to get real timeupdates as they code, and view energy costs per line of code.

App combinations: We anticipate that Amulet users willbe able to select a set of apps for their personal Amuletdevice, perhaps from a sort of app store. The app storewould compile a custom firmware image comprising theirselected apps. When a developer submits her app to the appstore, the results of the Resource Profiler are included, whichlater allows the app store to evaluate a given combinationof apps for their impact on Amulet resources and advise theuser in battery lifetime impact.

Applications: To fully explore the capability of Amulet andits tools, we need to explore a wider variety of applications.Researchers at Worcester Polytechnic Institute (WPI) havedeveloped an app that correlates data from multiple phys-iological signals in an effort to mathematically determinewhether one sensor is faulty (or perhaps tampered). Weencourage the community to download our code, fabricatean Amulet device, and write apps.

Security and privacy: Wearable devices, especially thosefocused on mHealth applications, raise important securityand privacy questions. Together, Amulet-OS and AFT pro-vide the foundation for securing the system and applicationsfrom misbehaving applications, but more effort is needed onissues related to access control, encrypted storage, securecommunication, and key management.

10. SUMMARY AND CONCLUSIONSWearable platforms must give developers insight into how

their application (and specifically its usage of system re-sources) will affect the device’s battery lifetime. Currently,developers can not easily determine how an application’ssensing regimen will impact battery lifetime, or easily tweaksensing and interaction rates to explore their effect on batterylife. Furthermore, today’s multi-application wearable plat-forms have battery life measured in hours and days, whereasmany compelling applications (particularly in mHealth) ben-efit from battery life on the order of weeks. In this paper wepresent the Amulet Platform, which comprises a toolchain(the Amulet Firmware Toolchain) and runtime (the Amulet-OS) for development of energy- and resource-efficient ap-plications on low-power multi-application wearable devices.Using this framework, and the interactive ARP-View tool,developers are given guarantees on app isolation, insight intothe tradeoff between resource usage and app performance,and bounded predictions of the application’s effect on batterylifetime.

This paper’s contributions include 1) a firmware-productiontoolchain that guarantees application isolation (protectingthe system and applications from errant applications), 2) amulti-application runtime system for resource-constrainedwearables, and 3) the ARP-View tool to help developers pre-dict battery lifetimes and understand how their decisions af-fect those lifetimes, 4) an open-source, open-hardware releaseof the Amulet platform and its tools;5 From our evaluation,we found that our Amulet prototype could sustain multipleapplications for weeks on a single, small battery, that ourresource profiler was accurate to within 6-10% of the actualpower draw on our prototype hardware, and that Amulethas great potential as an mHealth research device.

11. ACKNOWLEDGMENTSWe thank the anonymous reviewers and our shepherd,

Omprakash Gnawali, for their comments. We are gratefulto George Boateng for developing the EMA and Heart-rateLogger apps, to Taylor Hardin for the final preparation ofthe open-source release, and to the whole Amulet team fortheir advice and input. We are especially grateful to AndresMolina-Markham for his early guidance of the Amulet designand development.

This research results from a research program at the In-stitute for Security, Technology, and Society, supported bythe National Science Foundation under award numbers CNS-1314281, CNS-1314342, and TC-0910842, and by the De-partment of Health and Human Services (SHARP program)under award number 90TR0003-01. The views and conclu-sions contained in this document are those of the authorsand should not be interpreted as necessarily representing theofficial policies, either expressed or implied, of the sponsors.

5The Amulet Platform can be found athttps://github.com/AmuletGroup/amulet-project

12. REFERENCES[1] Y. Agarwal, S. Hodges, R. Chandra, J. Scott, P. Bahl,

and R. Gupta. Somniloquy: Augmenting networkinterfaces to reduce PC energy usage. In Proceedings ofthe USENIX Symposium on Networked Systems Designand Implementation (NSDI), pages 365–380. USENIXAssociation, 2009.

[2] K. Aggarwal, C. Zhang, J. C. Campbell, A. Hindle, andE. Stroulia. The power of system call traces: Predictingthe software energy consumption impact of changes. InProceedings of Annual International Conference onComputer Science and Software Engineering,(CASCON), pages 219–233. IBM Corp., 2014. Online athttp://portal.acm.org/citation.cfm?id=2735546.

[3] Android. Optimizing performance and battery life.Online at http://developer.android.com/training/wearables/watch-faces/performance.html, visited Dec.2015.

[4] Android. Power profiles for Android. Online at https://source.android.com/devices/tech/power/index.html,visited Nov. 2015.

[5] Angel. Angel Sensor. Online athttp://www.angelsensor.com, visited Dec. 2015.

[6] ANTLR (ANother Tool for Language Recognition).Online at http://www.antlr.org/, visited Mar. 2014.

[7] Apple. Apple Watch. Online athttp://www.apple.com/watch/, visited Dec. 2015.

[8] Apple. Energy efficiency and the user experience.Online at https://developer.apple.com/library/prerelease/watchos/documentation/Performance/Conceptual/EnergyGuide-iOS/, visited Dec. 2015.

[9] C. Arthur. Your smartphone’s best app? battery life,say 89% of Britons. The Guardian, May 2014. Onlineat http://www.theguardian.com/technology/2014/may/21/your-smartphones-best-app-battery-life-say-89-of-britons.

[10] E. Baccelli, O. Hahm, M. Gunes, M. Wahlisch,T. Schmidt, et al. RIOT OS: Towards an OS for theInternet of Things (poster). In Proceedings of the IEEEInternational Conference on ComputerCommunications (INFOCOM), 2013. DOI10.1109/INFCOMW.2013.6970748.

[11] N. Banerjee, J. Sorber, M. D. Corner, S. Rollins, andD. Ganesan. Triage: balancing energy and quality ofservice in a microserver. In Proceedings of theInternational Conference on Mobile Systems,Applications and Services (MobiSys), pages 152–164.ACM, 2007. DOI 10.1145/1247660.1247680.

[12] J. Brooke et al. SUS – a quick and dirty usability scale.Usability evaluation in industry, 189(194):4–7, 1996.

[13] Y. Chen, O. Gnawali, M. Kazandjieva, P. Levis, andJ. Regehr. Surviving sensor network software faults. InProceedings of the ACM SIGOPS Symposium onOperating Systems Principles, (SOSP), pages 235–246.ACM, 2009. DOI 10.1145/1629575.1629598.

[14] N. Cooprider, W. Archer, E. Eide, D. Gay, andJ. Regehr. Efficient memory safety for tinyos. InProceedings of the International Conference onEmbedded Networked Sensor Systems, (SenSys), pages205–218. ACM, 2007. DOI 10.1145/1322263.1322283.

[15] A. Dunkels, O. Schmidt, T. Voigt, and M. Ali.

Protothreads: Simplifying event-driven programming ofmemory-constrained embedded systems. In Proceedingsof the International Conference on EmbeddedNetworked Sensor Systems (SenSys), pages 29–42.ACM, 2006. DOI 10.1145/1182807.1182811.

[16] B. Fang, N. D. Lane, M. Zhang, A. Boran, andF. Kawsar. Bodyscan: Enabling radio-based sensing onwearable devices for contactless activity and vital signmonitoring. In Proceedings of the Annual InternationalConference on Mobile Systems, Applications, andServices, (MobiSys ), pages 97–110. ACM, 2016. DOI10.1145/2906388.2906411.

[17] D. Ferreira, E. Ferreira, J. Goncalves, V. Kostakos, andA. K. Dey. Revisiting human-battery interaction withan interactive battery interface. In Proceedings of theACM International Joint Conference on Pervasive andUbiquitous Computing, (UbiComp), pages 563–572.ACM, 2013. DOI 10.1145/2493432.2493465.

[18] D. Gay, P. Levis, R. von Behren, M. Welsh, E. Brewer,and D. Culler. The nesC language: A holistic approachto networked embedded systems. In Proceedings of theACM SIGPLAN Conference on Programming LanguageDesign and Implementation (PLDI), pages 1–11, 2003.DOI 10.1145/781131.781133.

[19] Hexiwear. Hexiwear open iot development solution.Online at http://www.hexiwear.com/, visited Aug.2016.

[20] W. Huang, Y. S. Kuo, P. Pannuto, and P. Dutta. Opo:A wearable sensor for capturing high-fidelityface-to-face interactions. In Proceedings of the ACMConference on Embedded Network Sensor Systems,(SenSys), pages 61–75. ACM, 2014. DOI10.1145/2668332.2668338.

[21] T. Jim, J. G. Morrisett, D. Grossman, M. W. Hicks,J. Cheney, and Y. Wang. Cyclone: A safe dialect of C.In Proceedings of the Annual Conference on USENIXAnnual Technical Conference (ATEC), pages 275–288.USENIX Association, 2002.

[22] D. Kim, Y. Chon, W. Jung, Y. Kim, and H. Cha.Accurate prediction of available battery time for mobileapplications. ACM Transactions on EmbeddedComputing Systems, 15(3), May 2016. DOI10.1145/2875423.

[23] N. D. Lane, P. Georgiev, C. Mascolo, and Y. Gao.ZOE: A cloud-less dialog-enabled continuous sensingwearable exploiting heterogeneous computation. InProceedings of the Annual International Conference onMobile Systems, Applications, and Services (MobiSys),pages 273–286. ACM, May 2015. DOI10.1145/2742647.2742672.

[24] Q. Leaps. QP/C Framework. Online athttp://www.state-machine.com/qpc/index.html, visitedDec. 2015.

[25] P. Levis, S. Madden, J. Polastre, R. Szewczyk,K. Whitehouse, A. Woo, D. Gay, J. Hill, M. Welsh,E. Brewer, et al. TinyOS: An operating system forsensor networks. In Ambient Intelligence, pages115–148. Springer, 2005.

[26] D. Li, S. Hao, W. G. J. Halfond, and R. Govindan.Calculating source line level energy information forAndroid applications. In Proceedings of theInternational Symposium on Software Testing and

Analysis, (ISSTA), pages 78–89. ACM, 2013. DOI10.1145/2483760.2483780.

[27] K. Lorincz, B.-r. Chen, G. W. Challen, A. R.Chowdhury, S. Patel, P. Bonato, and M. Welsh.Mercury: A wearable sensor network platform forhigh-fidelity motion analysis. In Proceedings of theInternational Conference on Embedded NetworkedSensor Systems (SenSys), pages 183–196, Nov. 2009.DOI 10.1145/1644038.1644057.

[28] X. Ma, P. Huang, X. Jin, P. Wang, S. Park, D. Shen,Y. Zhou, L. K. Saul, and G. M. Voelker. eDoctor:Automatically diagnosing abnormal battery drainissues on smartphones. In Proceedings of the USENIXConference on Networked Systems Design andImplementation, (NSDI), pages 57–70. USENIXAssociation, 2013. Online at https://www.usenix.org/conference/nsdi13/technical-sessions/presentation/ma.

[29] ARM. Technology / mbed OS. ARM mbed IoT DevicePlatform, 2014. Online athttp://mbed.org/technology/os/.

[30] C. Min, Y. Lee, C. Yoo, S. Kang, S. Choi, P. Park,I. Hwang, Y. Ju, S. Choi, and J. Song. PowerForecaster:Predicting smartphone power impact of continuoussensing applications at pre-installation time. InProceedings of the ACM Conference on EmbeddedNetworked Sensor Systems (SenSys), pages 31–44.ACM, 2015. DOI 10.1145/2809695.2809728.

[31] C. Min, C. Yoo, I. Hwang, S. Kang, Y. Lee, S. Lee,P. Park, C. Lee, S. Choi, and J. Song. Sandra helps youlearn: The more you walk, the more battery yourphone drains. In Proceedings of the ACM InternationalJoint Conference on Pervasive and UbiquitousComputing, (UbiComp), pages 421–432. ACM, 2015.DOI 10.1145/2750858.2807553.

[32] R. Mittal, A. Kansal, and R. Chandra. Empoweringdevelopers to estimate app energy consumption. InProceedings of the Annual International Conference onMobile Computing and Networking, (Mobicom), pages317–328. ACM, 2012. DOI 10.1145/2348543.2348583.

[33] A. J. Oliner, A. P. Iyer, I. Stoica, E. Lagerspetz, andS. Tarkoma. Carat: Collaborative energy diagnosis formobile devices. In Proceedings of the ACM Conferenceon Embedded Networked Sensor Systems, (SenSys).ACM, 2013. DOI 10.1145/2517351.2517354.

[34] A. Pathak, Y. C. Hu, and M. Zhang. Where is theenergy spent inside my app?: Fine grained energyaccounting on smartphones with Eprof. In Proceedingsof the ACM European Conference on ComputerSystems, (EuroSys), pages 29–42. ACM, 2012. DOI10.1145/2168836.2168841.

[35] Pebble. Battery performance guide. Online athttps://developer.getpebble.com/guides/best-practices/battery-perform-guide/, visited Nov.2015.

[36] Pebble. Pebble. Online at https://www.pebble.com/,visited Nov. 2015.

[37] D. Sehr, R. Muth, C. Biffle, V. Khimenko, E. Pasko,K. Schimpf, B. Yee, and B. Chen. Adapting softwarefault isolation to contemporary CPU architectures. InUSENIX Security Symposium, pages 1–12, 2010.

[38] V. Shnayder, M. Hempstead, B. R. Chen, G. W. Allen,and M. Welsh. Simulating the power consumption oflarge-scale sensor network applications. In Proceedingsof the International Conference on EmbeddedNetworked Sensor Systems, (SenSys), pages 188–200.ACM, 2004. DOI 10.1145/1031495.1031518.

[39] SocialCompare. Comparison of popular smartwatches.Online at http://socialcompare.com/en/comparison/comparison-of-popular-smartwatches, visited Dec. 2015.

[40] Sony. Open SmartWatch Project. Online athttp://developer.sonymobile.com/services/open-smartwatch-project/, visited Dec. 2015.

[41] J. Sorber, N. Banerjee, M. D. Corner, and S. Rollins.Turducken: Hierarchical power management for mobiledevices. In Proceedings of the International Conferenceon Mobile Systems, Applications, and Services(MobiSys), pages 261–274. ACM, 2005. DOI10.1145/1067170.1067198.

[42] TE Connectivity. New survey from TE Connectivityuncovers America’s desire for wearables. PR Newswire,May 2015, Online at https://perma.cc/Y55G-5RRF.

[43] The Creators Project. Choose BLOCKS. Online athttp://www.chooseblocks.com, visited Dec. 2015.

[44] H. Wu, S. Yang, and A. Rountev. Static detection ofenergy defect patterns in android applications. InProceedings of the International Conference onCompiler Construction, (CC), pages 185–195. ACM,2016. DOI 10.1145/2892208.2892218.

[45] C. Yoon, D. Kim, W. Jung, C. Kang, and H. Cha.AppScope: Application energy metering framework forAndroid smartphones using kernel activity monitoring.In Proceedings of the USENIX Conference on AnnualTechnical Conference, (USENIX ATC), page 36.USENIX Association, 2012. Online athttps://www.usenix.org/conference/atc12/technical-sessions/presentation/yoon.

[46] L. Zhao, G. Li, B. De Sutter, and J. Regehr. ARMor:Fully verified software fault isolation. In Proceedings ofthe International Conference on Embedded Software(EMSOFT), pages 289–298. ACM, 2011. DOI10.1145/2038642.2038687.

[47] Y. Zhou, X. Wang, Y. Chen, and Z. Wang. ARMlock:Hardware-based fault isolation for ARM. In Proceedingsof the ACM SIGSAC Conference on Computer andCommunications Security (CCS), pages 558–569. ACM,2014. DOI 10.1145/2660267.2660344.

[48] ZWear. ZWear – a wearable platform for makers.Online at http://zwear.org, visited Dec. 2015.