ANALYZING MOBILE APPLICATION SOFTWARE POWERCONSUMPTION VIA MODEL-DRIVEN ENGINEERING

Chris Thompson, Douglas SchmidtDept. of Computer Science, Vanderbilt University, Nashville, TN, USA

{thomchr,schmidt}@dre.vanderbilt.edu

Hamilton Turner, Jules WhiteDept. of Elec & Computer Engineering, Blacksburg, VA, USA

{hturner,julesw}@vt.edu

Keywords: mobile computing, low-power, model driven engineering

Abstract: Smartphones are mobile devices that travel with their owners and provide increasingly powerful services.The software implementing these services must conserve battery power since smartphones may operate fordays without being recharged. It is hard, however, to designsmartphone software that minimizes powerconsumption. For example, multiple layers of abstractionsand middleware sit between an application and thehardware, which make it hard to predict the power consumption of a potential application design accurately.Application developers must therefore wait until after implementation (when changes are more expensive) todetermine the power consumption characteristics of a design.This paper provides three contributions to the study of applying model-driven engineering to analyze powerconsumption early in the lifecycle of smartphone applications. First, it presents a model-driven methodologyfor accurately emulating the power consumption of smartphone application architectures. Second, it describesthe System Power Optimization Tool (SPOT), which is a model-driven tool that automates power consumptionemulation code generation and simplifies analysis. Third, it empirically demonstrates how SPOT can estimatepower consumption to within∼3-4% of actual power consumption for representative smartphone applications.

1 INTRODUCTION

Emerging trends and challenges. Recent ad-vances in mobile device and smartphone technolo-gies have greatly increased the capabilities of thesedevices. For instance, the Google Nexus One has a1Ghz processor and the Motorola Droid has a 550Mhz processor, compared to the older Palm Treo’s315 Mhz processor. Despite these performance in-creases, these devices still possess limited batterycapacities that application developers must managecarefully.

To optimize power consumption effectively, de-velopers must understand the trade-offs between per-formance and battery life, as well as the implicationsof their software architecture on power consumption.Functional requirements, such as minimum applica-tion response time, can conflict with power consump-tion optimization needs. For example, a traffic acci-dent detection application (White et al., 2010) mustbe able to detect sudden accelerations indicative ofa car accident. To detect acceleration events that in-

dicate accidents, the application must sample devicesensors and perform numerous calculations at a highrate. Conflicts occur between the functional require-ments e.g. the minimum sensor sampling rate neededto accurately detect accidents, and the non-functionalrequirements e.g. sustaining operations on the mobiledevice without frequent battery recharging.

Due to complex middleware, OS, and network-ing layers, it is hard to predict the effects of ap-plication software architecture decisions on powerconsumption without actuallyimplementinga design,which makes it hard to analyze the power consump-tion of design until late in the development cycle,when changes are more expensive (Kang et al., 2008).For example, a developer may elect to use HTTPS in-stead of HTTP to satisfy a security requirement bymaking communication between the application andserver more confidential. It is currently hard, how-ever, to predict how much additional power is con-sumed by the added encryption and decryption of datawithout actually implementing the system.

It is also hard to quantify the trade-off between

power consumption and security, as well as manyother design decisions. Moreover, certain designdecisions, such as data transmission policies (e.g.,should an application transmit immediately or waitfor a specific medium like a Wi-Fi or 3G cellular con-nection) are especially hard to analyze early in the de-sign cycle, due to their variability. For instance, ifan application only sends data intermittently, it maybe beneficial to transmit small amounts of data overcellular connections due to the decreased power con-sumption of 3G cellular connection compared to Wi-Fi (Agarwal et al., 2007). However, if a large amountof data must be sent, the total time required to trans-mit it over 3G may negate the benefit of using the lesspower consumptive connection. The cellular connec-tion will take longer to transmit the data, therefore,which may in turn consume more total power than theWi-Fi radio that can transmit the data faster.

Solution approach→ Power consumption em-ulation of mobile software architectures withmodel-driven testing and auto-generated code.Byusing Model-driven Engineering(MDE) (Schmidt,2006), we allow developers to specify adomain-specific modeling language(DSML) (Ledeczi et al.,2001) to capture key software architecture elementsrelated to power consumption. Developers can thenuse automated code generators to produce emulationcode from this model. Developers can also executethe generated emulation code on target hardware, col-lect power consumption information, and analyze theapplication’s power consumption.

This emulation code allows developers to ana-lyze a proposed software architecture prior to invest-ing significant time and effort in a complete imple-mentation of the design. The auto-generation of em-ulation code also enables developers to compare arange of different designs quantitatively during initialphases of a development process, which allows devel-opers to select designs that satisfy both functional andnon-functional requirements while minimizing powerconsumption. This analysis can also occur early inthe software lifecycle (e.g., at design time), therebyavoiding costly changes being required later in orderto optimize power consumption.

This paper describes theSystem Power Optimiza-tion Tool(SPOT), which uses MDE techniques to an-alyze the power consumption of mobile software ar-chitectures. SPOT allows developers to create high-level models of candidate software architectures usingthe System Power Optimization Modeling Language(SPOML) that capture key software components re-lated to power consumption. SPOT generates emu-lation code from the model that can be executed ontarget devices. As this emulation code is executed,

it is also instrumented to collect power consumptiondata; the power data can later be downloaded andanalyzed offline. This emulation and analysis cy-cle allows developers to understand the power con-sumption implications of their designswithoutexpen-sive and time consuming manual programming usingthird-generation languages, such as C#, C/C++, andJava.

SPOT’s generated emulation code mimics keypower-consuming aspects of a proposed softwarearchitecture. Key power consumptive componentsof mobile application software architectures includeGPS, acceleration, orientation, sensor data con-sumers, and network bandwidth consumers (Peringet al., 2006). Focusing SPOT on these components al-lows developers to model the most significant powerexpenditures of their applications. Moreover, as ap-plications are constructed, the generated emulationcode can be replaced incrementally with actual appli-cation components, allowing developers to refine theaccuracy of the analysis continuously throughout thesoftware lifecycle.

Paper organization. The remainder of this pa-per is organized as follows: Section 2 outlines a mo-tivating example we use to showcase and evaluateSPOT’s functionality throughout the paper; Section 3summarizes the challenges associated with predict-ing power consumption of mobile application soft-ware architectures; Section 4 describes the structureand functionality of SPOT and SPOML; Section 5empirically evaluates SPOT’s power prediction capa-bilities and shows how its modeling primitives andemulation infrastructure can accurately predict powerconsumption for representative mobile applicationson the Android smartphone platform; Section 6 com-pares SPOT with related work; and Section 7 presentsconcluding remarks.

2 Motivating Example: theWreckWatch Case Study

This section describesWreckWatch(White et al.,2010), which is an open-source1 mobile applicationwe built on the Android smartphone platform to de-tect automobile accidents. We use WreckWatch as acase study throughout this paper to demonstrate keycomplexities of predicting the power consumptionof mobile software architectures. As shown in Fig-ure 1, WreckWatch operates by (1) monitoring smart-phone sensors (such as GPS receivers and accelerom-

1WreckWatch is available fromvuphone.googlecode.com.

Figure 1: WreckWatch Operation

eters) for sudden acceleration/deceleration events thatare indicative of an accident. Data about the eventare then (2) uploaded to a remote server over HTTPwhere first-responders and/or other motorists can ac-cess the information via a web browser or Androidclient. WreckWatch allows bystanders (3) to uploadimages of the accident to the same web server, therebyincreasing the information first-responders possessbefore arriving at the scene.

To detect traffic accidents accurately, Wreck-Watch runs continuously as a background service andcontinuously consumes a great deal of accelerometerand GPS data. The application must therefore be con-servative in its power consumption. If not designedproperly, WreckWatch can decrease smartphone bat-tery life significantly.

3 Challenges of Designing PowerConscious Mobile Applications

This section describes the challenges associatedwith developing power-aware mobile software, suchas the WreckWatch application described in Sec-tion 2. High-level mobile application developmentSDKs, such as Google Android or Apple iPhone, sim-plify mobile application development, but do not sim-plify power consumption prediction during applica-tion design. In fact, the abstractions present in theseSDKs make it hard for developers to understand thepower implications of software architecture decisionsuntil their designs have been implemented (Parikhet al., 2002), as described in Section 3.1. Interactionwith sensors, such as accelerometers or GPS receiversand network interaction, can also result in a signifi-cant amount of power consumption, as described inSections 3.2 and 3.3.

3.1 Challenge 1: Accurately PredictingPower Consumption of FrameworkAPI Calls

Each line of code executed results in a specificamount of power consumed by the hardware. In thesimplest case, this power consumption results from asmall series of CPU operations, such as reading frommemory or adding numbers. In some cases, however,a single line of code can result in a chain of hardwareinteractions, such as activation of the GPS receiverand increasing the rate at which the screen is redrawn.Moreover, although the higher levels of abstractionprovided by modern smartphone SDKs make it easierfor developers to implement mobile application soft-ware, they also complicate predictions of the effectson the hardware.

For example, WreckWatch heavily utilizes theGoogle Maps API and the “MyLocation” map over-lay, which provides end users with a marker indicat-ing their current GPS location. The use of the “My-Location” is typically accomplished with fewer than10 lines of code, but results in substantial power con-sumption. This is because the overlay is redrawn at ahigh rate to achieve a “flashing” effect, and becausethe overlay enables and heavily utilizes the GPS re-ceiver on the device, which further increases powerexpenditure. It is hard to predict how using arbitraryAPI calls, such as this overlay, will affect applicationpower consumption without implementing a particu-lar design and testing it on a particular target device.

This abstraction in code makes power-consumption analysis on arbitrary segments ofcode hard. Predicting power usage from high-leveldesign abstractions, such as a UML diagram, is evenharder. Section 4 describes the MDE and emulationapproach we use to address this challenge.

3.2 Challenge 2: Accurately PredictingPower Consumption of SensorUsage Architectures

In applications utilizing sensor data, the most accu-rate sensor data is obtained by sampling as often aspossible. Sampling at high rates, however, incurshigh power consumption (Krause et al., 2005) by notallowing sensors to enter low power modes and byincreasing the amount of data processed by applica-tions. Reducing the sample rate can decrease appli-cation power consumption considerably, but also re-duces accuracy. The trade-offs between power con-sumption and accuracy at a given sampling rate arehard to determine without empirical tests on a target

device due to the high-degree of layering in modernsmartphone APIs and system architectures.

For example, WreckWatch was originally de-signed to collect GPS data every 500 millisecondsand consume accelerometer data at Android’s pre-definedNORMAL rate setting. During the devel-opment of WreckWatch, it was clear that reducingWreckWatch’s GPS sampling rate would reduce over-all power consumption, but it was unclear to what de-gree. Moreover, it was hard to predict what samplerate would provide sufficient accuracy and still allowthe phone to operate for days between charges. Sec-tion 4 describes how we use automatic code gener-ation to create emulated applications that accuratelyanalyze the power consumption of a candidate sensorutilization architecture without incurring the substan-tial time and effort to manually implement the archi-tecture.

3.3 Challenge 3: Accurately Assessingthe Effects of DifferentCommunication Protocols on PowerConsumption Prior toImplementation

Each application and network communication proto-col has a specific overhead associated with it and canresult in significant power consumption (Heinzelmanet al., 2000). Certain protocols require more devel-opment overhead to implement, but have low runtimeoverhead (e.g.bandwidth consumption, message pro-cessing time, etc.). It is hard to determine early (e.g.,at design time) in an applications lifecycle, however,how this overhead will affect power consumption andwhether the number of messages transmitted will besubstantial enough to impact power consumption sig-nificantly. This challenge is exacerbated if certainnetwork operations consume more power than others,e.g., receiving data often consumes more power thantransmitting data (Wang et al., 2006).

For example, to provide the most accurate situa-tional awareness to first responders—and provide themost accurate congestion information to motorists—the WreckWatch application must periodically re-quest wreck information from the central web server.These updates must be done periodically and wereoriginally intended to run over HTTP. Using HTTPresults in a significantly less developer effort butresults in a considerable amount of communicationoverhead from the underlying TCP and HTTP proto-cols, which ultimately transmits substantial amountsof data that have no relevance to the application. It ishard to determine at design time if/how this additional

data transmission will significantly impact power con-sumption. Section 4 shows how we used MDE codegeneration to implement and analyze potential com-munication protocols rapidly.

4 The System Power OptimizationTool (SPOT)

This section describes the structure and function-ality of theSystem Power Optimization Tool(SPOT),which is an MDE tool that allows developers to modelpotential mobile application software architectures topredict their power consumption, generate code toemulate that architecture, and then systematically an-alyze its power consumption properties. SPOT ad-dresses the challenges described in Section 3 by al-lowing developers to understand the implications oftheir software architecture decisions at design time.

SPOT’s development process enables develop-ers to generate visual, high-level models rapidly, asshown in Figure 2. These models can then be used toanalyze the power consumption of mobile applicationsoftware architectures (step 1 of Figure 2). SPOT thushelps overcome key challenges of predicting powerconsumption by generating device logic that can beused to gather power consumption information onphysical hardware during early phases of an applica-tion’s software lifecycle, which helps minimize ex-pensive redesign/refactoring costs in later phases.

SPOT uses models shown in Figure 2 to generateinstrumented emulation code for the given platformor device (step 2 of Figure 2). When executed onactual hardware (step 3 of Figure 2), this generatedcode collects power consumption and system state in-formation. This power consumption data can then bedownloaded and analyzed offline to provide develop-ers with application power utilization at key pointsthroughout the lifecycle and execution path (step 4 ofFigure 2).

SPOT also supports the use of custom code mod-ules. These models allow developers to replace auto-matically generated code with actual application logicwhile still providing the same analytical capabilitiesavailable when using generated code. SPOT thereforenot only allows developers to perform analysis earlyin the development cycle, but also to perform contin-uous integration testing throughout development.

SPOT is implemented as a plugin for the EclipseIDE. Its runtime power consumption emulation andcapture infrastructure is built using predefined, user-configurable classes that emulate specific power con-suming components, such as GPS data consumers.This infrastructure captures power consumption in-

(Optional)

Developer replaces

model elements

with specific code

Figure 2: SPOT Modeling and Analysis Process

formation during executing by using the device’spower API. For example, power data collection onthe Android platform is performed by interfacingwith the OS application power API,i.e., the Androidpower consumption API as implemented by the “Fu-elGauge” application.

The remainder of this section describes howSPOT’s DSML, emulation code generation, and per-formance measurement infrastructure help applica-tion developers address the challenges presented inSection 3. Section 4.1 describes SPOT’s modelinglanguage, SPOML, Section 4.2 describes how SPOTgenerates emulation code, and Section 4.3 describeshow SPOT analyzes and evaluates emulation codeduring execution.

4.1 Mobile Application ArchitectureModeling and Power ConsumptionEstimation

SPOT describes key power-consuming aspects of amobile application via a DSML with specific lan-guage elements. This DSML allows developers tospecify their software architecture visually with re-spect to power consuming components, as shown inFigure 2. Prior work (Thompson et al., 2009; Whiteet al., 2010; Turner et al., ) showed how the followingcomponents are often significant power consumers inmobile applications:

• CPU consumersare used to represent CPU-intensive code segments such as calculations on sen-sor data. Developers can specify the amount of CPUtime that should be consumed by specifying the num-ber of loop iterations of a square root calculation thatshould be run. For example, WreckWatch developerscan model the mathematical calculation time to deter-mine the current G-forces on the phone.

• Memory consumersgenerate dynamically allo-cated memory. These consumers allow developers toanalyze not only the power consumed by actual opera-tions, but also their impact (such as the frequency and

duration of garbage collector sweeps) on garbage col-lection. Developers can specify the amount of mem-ory to consume as bytes. For example, WreckWatchdevelopers can model the effects of caching accidentimages of varying sizes.

• Accelerometer consumers, which interact withsystem accelerometers and consume accelerometerdata. These consumers can be configured to utilize thefull range of system-supported sample rates. For ex-ample, WreckWatch developers can model the sensorinteraction needed to accurately detect car accidents.

• GPS consumersinteract with the device’s GPSreceiver. These consumers can be configured withcustom sample rates as well as a minimum distancebetween points,i.e., the sensor will only return a datapoint if the distance between the current point andthe last point is greater than a specified value. GPSconsumers allow developers to analyze the impact ofusing a location service configuration on power con-sumption. For example, WreckWatch developers usethis capability to model how polling for a vehicle’s lo-cation at different rates impacts power consumption.

• Network consumersemulate application net-work interaction by periodically transmitting and re-ceiving data. Network consumers allow users to sup-ply SPOT with sample data that is then transmittedat the interval specified. For example, WreckWatchdevelopers can provide a URI along with server andport information to configure SPOT to make a specificrequest. These consumers can also be configured toexecute at varying times to emulate periodic updates.

• Screen drawing agentsutilize graphics li-braries, such as OpenGL, to emulate a graphics-intensive application, such as a game or streamingvideo to a first responder’s WreckWatch client. Userscan configure these consumers by specifying the typesand size of objects to draw on the screen, along withany transformations that should be performed on theobject. For example, WreckWatch developers can usethe drawing agents to show how the use of images andvideo for situational awareness impacts battery life.

• Custom code modulesallow developers to

specify their own code to run against the profilingpackage. This capability allows developers to extendSPOT’s functionality to meet their needs, as well asincrementally replace the emulation code with actualapplication logic as it becomes available. Replacingthe emulation logic allows developers to perform test-ing as development progresses and increase the ac-curacy of the evaluation and analysis. For example,WreckWatch developers can use these consumers toinclude a service for uploading multimedia contentabout an accident to a central web server.

The metamodel for SPOT’s DSML, called theSystem Power Optimization Modeling Language(SPOML), allows application developers to buildsoftware architectural specifications that determinepower consumption from key power consuming com-ponents. SPOML was created using the metamod-eling features of the Generic Eclipse Modeling Sys-tem (GEMS) (White et al., 2009), which is a toolfor rapidly generating visual modeling tools atop theEclipse Modeling Framework (EMF). GEMS is builtatop Ecore, which provides metamodeling and mod-eling facilities for Eclipse (Budinsky et al., 2003).

The primary application serves as the root elementof the model. Power consumption modules can ex-ist within eitheractivities (which are basic buildingblock components for Android applications and rep-resent a “screen” or “view” that provides a single, fo-cused thing a user can do) orservices(which are back-ground processes that run without user interventionand do not terminate when an application is closed).

Each activity or service can contain one or morepower consumer modeling elements described above.Developers can therefore emulate potential decisionsthat they make when designing a mobile device ap-plication, which allows them to emulate a wide rangeof application software architectures. For example,Figure 3 shows a SPOML model of the WreckWatchapplication’s sensor usage design.

Figure 3: WreckWatch Model

Acceleration and GPS consumers run in indepen-dent services, while the network consumer runs in theapplication’s activity. This model results in an appli-cation that monitors GPS and accelerometer values atall times regardless of what the user is doing. It onlyutilizes the network connection, however, when theuser has the WreckWatch application open and run-ning.

4.2 Generating Software ArchitectureEmulation Code

Predicting the power consumption of an arbitrary de-sign decision is hard, as described in Section 3.1.SPOT addresses this challenge by generating appli-cation emulation code automatically to execute on theunderlying device hardware. SPOT’s automatic gen-eration of emulation code allows application develop-ers to reduce the time required to write enough code toanalyze system power consumption accurately. Thisemulation code is instrumented so the architecture’spower expenditures can be examined after a test run.

In addition to instrumenting the code, SPOT hasthe potential to apply the same model for multipletarget platforms, such as Android and iPhone, aslong as configurable code is available for the power-consuming elements. This emulation and analysiscycle allows developers to observe the power con-sumption of their design very early in the develop-ment cycle, as well as evaluate their software designsacross multiple hardware configurations to assess howchanges in hardware affect application power con-sumption. For example, even though the MotorolaDroid and Google Nexus One both run the Androidplatform, each possesses key hardware differences,such as the type and size of the display, that impactpower consumption.

The generated emulation code allows developersto address the remaining challenges of selecting anoptimal communication protocol and optimizing sen-sor polling rates, as described in Section 3. Gen-erated emulation code allows developers to evaluatethe power consumption of a potential design empiri-cally, rather than simply guessing its power consump-tion or waiting until an application implementation iscomplete before running tests. Moreover, develop-ers can quantitatively compare the power consump-tion effects of choosing different networking proto-cols and can evaluate the power consumption of dif-ferent sensor sampling rates.

To accomplish this mobile software architecturalemulation, SPOT uses a set of predefined code blocksthat can be configured at runtime to perform powerconsuming operations. SPOT uses an XML config-uration file to perform any necessary configurationand create an application that emulates the power con-sumption of the desired software architecture. To gen-erate this XML configuration file, SPOT interprets themodel outlined in Section 4.1. Users of SPOT de-fine the model and tweak configuration parameters,and SPOT can then compile the model and parame-ters into an intermediate XML format which is uti-lized to configure prebuilt implementations of each

power consuming element described in Section 4.1.Figure 4 shows a sample of the XML configura-

tion file generated for the WreckWatch model shownin Figure 3. The XML shown in Figure 4 represents

Figure 4: Sample WreckWatch Emulation XML

a configuration with two background services runningan accelerometer consumer and a GPS consumer. TheGPS consumer samples every 500 milliseconds, witha minimum radius between sample points set to 0.The accelerometer consumer is set to sample at theNORMAL rate, which is a constant defined by An-droid. There is also a network consumer transmittingsample data every 30 seconds and repeating infinitely.The network consumer is configured to connect to aspecific host on a specific port and utilize the HTTPprotocol.

The predefined power consumers have config-urable options (such as the sample rate of the GPSand data to transmit over the network) provided by theXML configuration file. These power consumptionelements are generic and applicable to a wide rangeof platforms, such as Android, iPhone, or BlackBerry.The predefined power consumers are implemented onthe Android platform as follows:

• CPU consumersare implemented as a set ofnested loops that perform basic mathematical opera-tions, such as square root calculations, on randomlygenerated data. This module utilizes the CPU whileminimizing utilization of other system resources,such as memory that could skew power consumptioninformation. For example, this consumer uses primi-tive types to avoid allocating dynamic memory. Userscan adjust the length of the loops via a configurableparameter. Various end device processors result insame-length loops performing differently on divfer-ent devices, in a manner similar to CPU-intensive al-

gorithmic performance on end-user devices.

• Memory consumersare implemented by dy-namically allocating custom objects that wrap bytearrays. To analyze the frequency of garbage collec-tion, a JavaWeakReference object is used to informthe garbage collector that they can be reclaimed, de-spite having active references within running code.The object’sfinalize() method (which is called im-mediately before the object is reclaimed by the An-droid Dalvik virtual machine) is overridden to recordthe time of garbage collection, thereby allowing de-velopers to analyze the frequency of garbage collec-tion runs. TheWeakReference object will thus bereclaimed during every garbage collection run.

Due to the limitations of the Android instrumen-tation API, garbage collection and memory usagemust be inferred through analysis of the frequencyand duration of garbage collection runs, rather thanthrough direct power consumption measurement. Al-though this limitation prevents developers from in-cluding memory statistics in the data along with CPU,sensor, and network utilization, they can still exam-ine how their design uses memory. Users can alsoconfigure the amount of memory and frequency of al-location, as well as supply custom objects (such asWreckWatch’s image caches) to use rather than thebyte arrays used by default.

• GPS consumersare implemented by code thatregisters to receive location updates from the GPS re-ceiver at specific intervals.

• Accelerometer consumersare implemented us-ing the configuration specified in the XML file, alongwith generic setup code to establish a connection tothe appropriate hardware.

• Network consumersare implemented as emu-lation code containing a timer that executes a givennetworking operation, such as an HTTP operation ata user defined interval.

• Screen drawing agentsallow users to specify3D and 2D graphics to draw on the screen. Develop-ers will specify object contents along with any poten-tial motion or actions.

• Custom code modulesallow developers to sup-ply their own code blocks to extend the functionalityof SPOT and enhance emulation accuracy as the de-velopment cycle progresses by substituting thefauxemulation code with actual application logic. SPOTallows developers to supply class files to load into theemulation application dynamically, as well as method“hooks” to allow the emulation code to interact withthe custom code properly.

4.3 Power ConsumptionInstrumentation

SPOT uses an instrumentation system to capturepower consumption statistics as the emulation codeis executed, as shown in Figure 5. Components in

Figure 5: SPOT Instrumentation System

the instrumentation system are eitherCollectors,Recorders, or Event Handlers. Collectors inter-face directly with the specific power API on the sys-tem and pass collected data toRecorders, which per-sist the data collected byCollectors by writing it toa file or other storage medium.Event Handlers re-spond to the events fired by entering or leaving emu-lation code blocks.

These components are dynamically loaded viaJava reflection to ensure extensibility and flexibil-ity. For instance, developers can implement a cus-tom Collector to monitor which components are inmemory at any given time. Alternatively, developerscould defineRecorders to log power consumptioninformation to another data storage medium, such asa local or network database rather than a flat file.

To analyze an architecture effectively, SPOTrecords battery state information over time to al-low developers to pinpoint specific locations in theirapplication’s execution path that demand the mostpower. To collect power consumption informationaccurately, SPOT uses an event-driven architecturethat precisely identifies the occurrence of each majorapplication-state change, such as registering or unreg-istering a GPS listener and SPOT takes a “snapshot”of the power consumption when the application per-forms these operations. This event-driven architectureallows developers to understand the power consump-tion of the application before, during, and after keypower-intensive components.

In addition to event-triggered power snapshots,SPOT also periodically collects power consumptioninformation. This information allows developers to

trace overall power consumption or power consump-tion within a given block. The power informationCollector that collects snapshots and periodic sam-ples can be configured to run in a separate process toprevent contamination of the data.

To accomplish event-driven power profiling,SPOT fires events immediately before an applicationenters a component that was defined in the model andimmediately after it leaves a model-defined compo-nent. These events work in conjunction with the peri-odic power consumption updates to provide develop-ers with a complete description of how their softwarearchitecture elements consume power. SPOT’s event-driven model of collecting power consumption dataalso allows developers to identify precisely what theapplication was doing when key power consumptionspikes occur, further helping them optimize their de-signs.

SPOT’s emulation infrastructure currently runs onthe Android mobile platform and uses the power con-sumption API utilized by the “FuelGauge” applica-tion in the core Android installation. The power con-sumption API provides application developers withaccess to the amount of time the application utilizesthe CPU, sensors, wake-locks, and other system re-sources, in addition to the overall power consumption.

Android’s power consumption API providespower-consumption information on a per-package ba-sis. By implementing SPOT in a different package,developers can analyze power consumption withoutinfluencing it. Collecting power consumption infor-mation in this manner increases accuracy. Moreover,SPOT can be implemented simply as a collector toanalyze existing applications without modifying theirsource code.

5 Results

This section analyzes the results of experimentsthat empirically evaluate SPOT’s MDE-based capa-bilities presented in Section 4. These experimentsmeasure SPOT’s ability to collect power consumptioninformation on a given model, as well as accuratelymodel the power consumption of a proposed applica-tion software architecture. These results show howSPOT can assess and analyze power consumption in-formation gathered through the Android’s power con-sumption API and evaluate SPOT’s accuracy in pre-dicting power consumption information about a soft-ware architecture at design time.

5.1 Hardware/Software Testbed

All tests were performed on a Google Nexus One witha 1Ghz CPU, 512MB of RAM, 512MB of ROM anda 4 GB SD card running the default installation ofAndroid 2.1 (Eclair). The SPOT application was theonly third-party application running at the time of ex-perimentation. The same power consumption infor-mation gathering logic was used to collect informa-tion on emulation code, as well as the sample appli-cations. The information was analyzed in Excel basedon power consumption data written to the device’s SDcard in the form of a CSV file.

To assess the consumption characteristics of dif-ferent designs, the current SPOT version generatesan Android application package. It then periodicallysamples the battery usage statistics from the OS writ-ing these values to a CSV file on the SD card. SPOTalso fires events when the application’s state changes,e.g., when the GPS is started or a sensor is discon-nected. These events allow SPOT users to examinethe power consumption of active hardware, in addi-tion to the overall consumption of the application.

SPOT uses an XML-based configuration file thatis generated from the SPOML model described inSection 4.1. This XML file is loaded on to the de-vice’s SD card and parsed at startup. Due to the waythat the power consumption API collects information,the data gathered reflects only power consumed bythe SPOT application and does not include any powerconsumed by system processes, such as the GUI dis-play or garbage collector.

5.2 Experiment 1: EmpiricalEvaluation of SPOT’s EmulationCode Accuracy

Overview. This experiment quantitatively comparesthe power consumption of two Android applicationsand the power consumption of the emulation code de-rived from their respective SPOT models. EnsuringSPOT’s accuracy is important since it allows develop-ers to compare the power consumption of key powerconsuming components in their mobile architecture.

The applications used in this experiment arethe WreckWatch application presented in Sec-tion 2 and OpenGPSTracker (open-gpstracker.googlecode.com), which is an open-source Androidapplication that uses GPS to track the coordinates ofthe phone and display it on a Google Map on the de-vice. The GPS points, and other information aboutthe route, are stored on the device to allow the userto replay the route later. OpenGPSTracker also deter-mines device speed as GPS points are collected.

Figure 6: Comparison of WreckWatch Application Logicand Emulation Code

Figure 7: Comparison of OpenGPSTracker ApplicationLogic and Emulation Code

Hypothesis. SPOT is intended to provide devel-opers with an estimate of how a proposed applicationsoftware architecture will consume power. We there-fore hypothesized that SPOT could provide powerconsumption information to within 25% of the ac-tual power consumption of WreckWatch and OpenG-PSTracker. Based on prior work (Thompson et al.,2009; White et al., 2010; Turner et al., ), we also hy-pothesized that the components we chose representedthe key factors in mobile application power consump-tion and would be adequate to provide this level ofaccuracy.

WreckWatch results. Figure 6 shows the graphof the actual power consumption of the WreckWatchapplication compared with the power consumption ofthe WreckWatch emulation code generated by SPOT.The emulation code’s power consumption follows thesame trend as that of the application and provided afinal power consumption value that was within 3%

of the actual power consumed by WreckWatch. TheSPOT model consisted solely of GPS and accelerom-eter consumers and did not attempt to model any ad-ditional aspects of the WreckWatch application. Themodel was accurate due to the substantial amountof power required by the GPS receiver. This resultconfirms that the GPS, sensor, and network modulesthat SPOT provides are key determinants of mobilepower consumption. Although WreckWatch performsa number of CPU-intensive calculations on sensordata to determine if an accident occurred, these calcu-lations are minor power consumers compared to sen-sor users.

OpenGPSTracker results. Figure 7 shows thegraph of the actual power consumption of the OpenG-PSTracker application compared with the power con-sumption of the emulation code generated by SPOT.As with the WreckWatch emulation code, the OpenG-PSTracker emulation code consumes power at a ratesimilar to the actual application. Over the same timeperiod, the emulation code for the OpenGPSTrackerapplication was accurate at predicting power con-sumption to within 4%. The SPOT model for theOpenGPSTracker application only used a GPS con-sumer and did not attempt to model any Google Mapsfunctionality (or requisite network functionality) orany processing required to determine speed or storethe location information. In this instance, the GPSpower consumption was sufficient to model the powerconsumption of the entire application.

With both applications, SPOT modeled and pre-dicted the power consumption of the actual applica-tion to within 4% of the actual power consumption.This result confirms our hypothesis that SPOT canprovide an accurate prediction of power consumptionby modeling key components of a mobile application.

5.3 Experiment 2: QualitativeComparison of Sensor Sample Rates

Overview. This experiment evaluates the effects ofsensor sample rates on an application’s overall powerconsumption. The rate at which sensor data is con-sumed can have a significant impact on applicationpower consumption, as described in Section 3.2. Forexample, Android’s accelerometer provides four enu-merations for sample rate:NORMAL, UI, GAME, andFASTEST. Although these sample rates provide vary-ing levels of QoS, the trade-off between a given levelof QoS and power consumption is not readily ap-parent at design time. The enumeration names givedevelopers a clue to potential uses, as well as rankthese sample rates according to rate and consequentlypower consumption. Alternatively, the GPS receiver

allows developers to specify a value as the delay, inmilliseconds, between samples.

SPOT allows developers to evaluate the powerconsumption of potential sensor sample rates. Forexperiment 2, we compared the power consumptionof the GPS receiver while sampling at once every 2seconds, once every 30 seconds, and once every 500milliseconds.

Hypothesis. We hypothesized that SPOT couldcapture the power consumption effects of sensorsampling rate changes. In particular, we believedsampling rate changes of a few hundred millisec-onds would produce power consumption changes thatSPOT could detect.

Results. Figure 8 show SPOT’s output for threedifferent sample rates for the GPS sensor. The dashed

TimeuA

uA

uA

uA

uA

uA

5 Minutes

Time

30s Sample Rate

2s Sample Rate

500ms Sample Rate

Figure 8: GPS Sample Rate Comparison

line represents the power consumption of the applica-tion when the sensor was sampled every 500 millisec-onds, the solid line represents a sample taken every2 seconds, and the dotted line represents the powerconsumption of the application sampling the sensortwice per minute. The samples in this graph were col-lected over 5 minutes and support the following ob-servations:

• Power consumption during the first severalseconds is uniform regardless of sample rate.Eachgraph is approximately equivalent for the first severalseconds of data gathered during the GPS sampling,which implies that if developers need access to GPSfor a short period of time, the greatest benefit wouldcome from using a higher sample rate.

• The greatest improvement in power con-sumption due to a lower sample rate will occurover time. Although the graphs demonstrate a no-ticeable difference in power consumption over the5-minute sample period, the improvement in batterylife from a change in sample rate will only be real-ized when sampling occurs over an extended periodof time.

Ultimately, the amount of power consumed by theGPS receiver is directly proportional to the samplingrate of the application. Reducing the sampling rateof the GPS receiver is an effective means to reducethe overall power consumption of an application if thereceiver is active for longer than∼2 minutes.

5.4 Summary and Analysis of Results

The results of the two experiments presented aboveshow how SPOT can accurately analyze and predictan application’s power consumption based on a modelof the application software architecture. This capabil-ity allows developers to understand the implicationsof their design decisions early in the software lifecy-cle, i.e., without implementing the complete applica-tion. The emulation code SPOT generates is accurate,e.g., for our WreckWatch application it could predictpower consumption within 3% of the actual applica-tion’s power consumption. SPOT’s accuracy stems inpart from the significant power consumption of hard-ware components, such as the GPS receiver, that con-sume significantly more power than other hardwarecomponents on the device, such as the CPU or evenaccelerometers.

6 Related Work

This section describes previous work in five cat-egories: (1) system execution modeling tools, (2)hardware-based power consumption optimization, (3)network protocol and interface optimization, (4) post-implementation power consumption analysis, and (5)our previous work on design-time power consumptionanalysis.

System execution modeling tools. The Com-ponent Utilization Test Suite (CUTS) (Hill et al.,2008) is a system execution modeling tool (Smithand Williams, 2001) that allows developers to modelkey architectural elements of distributed systems thatdetermine performance. CUTS allows developers tomodel a distributed software architecture and thengenerate emulation code to predict performance. Al-though CUTS and SPOT share common domain-specific modeling patterns, CUTS’s modeling ab-stractions focus on performance-related aspects ofdistributed systems, whereas SPOT’s modeling ab-stractions focus on important power consumers inmobile applications, such as GPS usage. Moreover,it is not possible to capture power consumption in-formation from CUTS emulation code or to generatemobile emulation applications for Android or iPhone.

Hardware-based power optimizations.Conven-tional techniques for reducing mobile device powerconsumption have focused on hardware- or firmware-level modifications to achieve the target consump-tion (Pering et al., 2006). These techniques are highlyeffective, but are limited to environments in which thehardware can be modified by the end user or devel-oper. Further, these modifications tend to result in atightly coupled architecture which makes them diffi-cult to use outside of the context in which they weredeveloped. In other words, a solution might reducepower consumption for one application or in one en-vironment, but may not have the same effect if any ofthose assumptions change. Moreover, such modifica-tions are typically beyond the scope of software engi-neering projects and require substantial understandingof low-level systems. In some instances, hardware-level modifications can actually hurt power consump-tion by increasing overhead. These techniques arealso useful for reducing overall power consumptionbut do not help in power consumption analysis that isnecessary when developing power-conscious applica-tions. SPOT is complimentary to these approaches inthat developers can use SPOT to identify the most ef-fective method to minimize power consumption with-out requiring extensive hardware knowledge or re-stricting the optimizations a single hardware platform.

Network protocol and interface optimization.Due to the limited battery power available to mo-bile and embedded systems, a great deal of workhas been done on the notion of optimizing systempower consumption. Network interfaces consume alarge portion of overall device power (Krashinskyand Balakrishnan, 2005) and consequently, a greatdeal of work has focused on reducing the power con-sumption of networking components. Ultimately, theamount of power consumed is directly proportionalto the amount of data transmitted (Feeney and Nils-son, 2001) and in some instances require 100 timesthe power consumed by one CPU instruction to trans-mit one byte of data (Liu et al., 2004). Therefore,the power consumption of the network interface canbe reduced by reducing the amount of data transmit-ted. Moreover, utilizing MAC protocols that reducecontention can significantly reduce power consump-tion (Chen et al., 1998). While MAC-layer modifi-cation is effective, it is typically beyond the scope ofsoftware-engineering projects, which is common withmobile application development.

SPOT seeks to accomplish similar goals by mod-ifying the data transmitted by the application layer,rather than attempting to modify the underlying net-work stack. SPOT helps developers analyze the datathey transmit to maximize throughput of relevant data

(e.g.actual data versus markup or framing overhead)thereby reducing power consumption. In addition,SPOT can function in a complimentary role allowingdevelopers to analyze the power consumption of net-work protocol optimizations to identify the most ef-fective configuration.

Post-implementation power consumption anal-ysis. Previous work (Creus and Kuulusa, 2007) notonly identified software as a key player in mobiledevice power consumption, specifically Symbian de-vices, but also sought to allow developers to analyzethe power consumption of applications during execu-tion. Moreover, other work (Landsiedel et al., 2005)utilized a similar approach to analyze the power con-sumption of sensor nodes in a wireless sensor net-work. This power consumption analysis providedhighly accurate results but suffers from the pitfalls ofpost-implementation testing, including increased costof refactoring if problems are discovered. To pre-vent costly post-implementation surprises, SPOT al-lows developers to analyze designs before any code iswritten and allows them to perform continuous inte-gration testing through the use of custom code com-ponents to further refine the accuracy of the model asdevelopment progresses.

This paper also extends our earlier work on MDEpower consumption described in (Thompson et al.,2009) by providing the following new significant con-tributions: (1) it quantitatively examines SPOT’s ac-curacy in evaluating power consumption of softwarearchitectures, (2) it examines the impact of differentsoftware architecture components, such as GPS uti-lization, on overall application power consumption,(3) it empirically evaluates the effects of software ar-chitecture design decisions, such as sensor samplerate, on overall application power consumption, and(4) it describes how data produced by SPOT can beutilized to refine and optimize the power consumptionof a sample application.

7 Concluding Remarks

The System Power Optimization Tool(SPOT) isan MDE tool that allows developers to evaluate thepower consumption of potential mobile applicationarchitectures early in the software lifecycle,e.g., atdesign time. Our experiments indicate that SPOTprovides a high degree of accuracy,e.g., it pre-dicted the power consumption of the WreckWatch andOpenGPSTracker applications to within∼3-4%. Welearned the following lessons developing and evaluat-ing SPOT:

• Sensor sample rates play an important rolein long-term power consumption. The power con-

sumed by the device sensors is largely uniform overthe first several minutes of activation regardless ofsample rate. It is only when these sensors are used foran extended period that the benefit of lower samplerates is realized. Developers must therefore considerthe amount of time to activate the sensor in additionto the overall sample rate.

• Certain hardware components draw signifi-cantly more power than others. In the case of uti-lizing the GPS receiver, the power consumed by thelocation (GPS) service is so substantial that it be-comes difficult to identify the effects of enabling ordisabling other hardware components. Due to this“masking” effect, developers may overlook a signifi-cant consumer of power in an application. In general,small changes in GPS sample rate can have significantimpacts on overall application power consumption.

• Certain system-related operations such asgarbage collection are not reflected in data gath-ered by SPOT.Through the current method of datacollection SPOT is only able to gather power con-sumption information about operations that it per-forms such as CPU, memory or sensor operations thatit specifically requests. Our future work will thereforedevelop mechanisms for capturing the impact of theseservices on power consumption.

• Power consumption of networking hardwareis dependent on data transmitted which is often de-pendent on user interaction. The power consump-tion of hardware, such as the Bluetooth or Wi-Fi in-terfaces, is dependent on the data transmitted and re-ceived on the device. This data is often generated atrun-time by user interaction with the program. Whileit is effective for the developer to generate some sam-ple data and provide it to SPOT, it would be more ef-fective if developers could simply describe the data,e.g., via a schema file. Our future work is extendingSPOT so it can process a data schema file and gener-ate data that is random, yet still valid to the applica-tion.

• Although GPS is a major consumer of power,not all applications rely on GPS.Although GPS isa major consumer of power on today’s smartphonedevices, it is still important to understand the powerconsumption of applications that do not use the GPS,even if their power consumption is less drastic. Ourfuture work is therefore analyzing SPOT’s accuracywith mobile applications (such as 3D games withacceleration-based controls, streaming video players,and audio recording/processing applications) that donot use GPS, such as 3D games, feed readers, andmultimedia applications.

SPOT is available in open-source form atsyspower.googlecode.com.

REFERENCES

Agarwal, Y., Chandra, R., Wolman, A., Bahl, P., Chin, K.,and Gupta, R. (2007). Wireless wakeups revisited: en-ergy management for voip over wi-fi smartphones. InACM MobiSys, volume 7.

Budinsky, F., Steinberg, D., Merks, E., Ellersick, R., andGrose, T. J. (2003).Eclipse Modeling Framework.Addison-Wesley, Reading, MA.

Chen, J., Sivalingam, K., Agrawal, P., and Kishore, S.(1998). A comparison of MAC protocols for wirelesslocal networks based on battery power consumption.In IEEE INFOCOM, volume 1, pages 150–157. Cite-seer.

Creus, G. and Kuulusa, M. (2007). Optimizing Mobile Soft-ware with Built-in Power Profiling. Mobile PhoneProgramming and its Application to Wireless Net-working, F. Fitzek and F. Reichert, Eds. Springer.

Feeney, L. and Nilsson, M. (2001). Investigating the energyconsumption of a wireless network interface in an adhoc networking environment. InIEEE INFOCOM,volume 3, pages 1548–1557. Citeseer.

Heinzelman, W., Chandrakasan, A., and Balakrishnan, H.(2000). Energy-efficient communication protocol forwireless microsensor networks. InProceedings of the33rd Hawaii International Conference on System Sci-ences, volume 8, page 8020. Citeseer.

Hill, J., Schmidt, D. C., Slaby, J., and Porter, A. (2008). Ci-CUTS: Combining System Execution Modeling Toolswith Continuous Integration Environments. InPro-ceeedings of 15th Annual IEEE International Confer-ence and Workshops on the Engineering of ComputerBased Systems (ECBS), Belfast, Northern Ireland.

Kang, J., Park, C., Seo, S., Choi, M., and Hong, J. (2008).User-centric prediction for battery lifetime of mo-bile devices. InProceedings of the 11th Asia-PacificSymposium on Network Operations and Management:Challenges for Next Generation Network Operationsand Service Management, pages 531–534. Springer.

Krashinsky, R. and Balakrishnan, H. (2005). Minimizingenergy for wireless web access with bounded slow-down. Wireless Networks, 11(1):135–148.

Krause, A., Ihmig, M., Rankin, E., Leong, D., Gupta, S.,Siewiorek, D., Smailagic, A., Deisher, M., and Sen-gupta, U. (2005). Trading off prediction accuracy andpower consumption for context-aware wearable com-puting. In Proceedings of the Ninth IEEE Interna-tional Symposium on Wearable Computers, pages 20–26. IEEE Computer Society.

Landsiedel, O., Wehrle, K., and Gotz, S. (2005). Accurateprediction of power consumption in sensor networks.In Proceedings of The Second IEEE Workshop on Em-bedded Networked Sensors (EmNetS-II). Citeseer.

Ledeczi,A., Bakay, A., Maroti, M., V”olgyesi, P., Nordstrom, G., Sprinkle, J., and Karsai,G. (2001). Composing domain-specific design envi-ronments.Computer, pages 44–51.

Liu, T., Sadler, C., Zhang, P., and Martonosi, M. (2004).Implementing software on resource-constrained mo-bile sensors: experiences with impala and zebranet.In Proceedings of the 2nd international conferenceon Mobile systems, applications, and services, pages256–269. ACM New York, NY, USA.

Parikh, D., Skadron, K., Zhang, Y., Barcella, M., and Stan,M. (2002). Power issues related to branch prediction.In Proceedings of the Eighth International Symposiumon High-Performance Computer Architecture, pages233–44. Citeseer.

Pering, T., Agarwal, Y., Gupta, R., and Want, R. (2006).Coolspots: Reducing the power consumption of wire-less mobile devices with multiple radio interfaces. InProceedings of the 4th International Conference onMobile systems, Applications and Services, page 232.ACM.

Schmidt, D. C. (2006). Model-Driven Engineering.IEEEComputer, 39(2):25–31.

Smith, C. and Williams, L. (2001).Performance Solutions:A Practical Guide to Creating Responsive, ScalableSoftware. Addison-Wesley Professional, Boston, MA,USA.

Thompson, C., White, J., Dougherty, B., and Schmidt, D.(2009). Optimizing Mobile Application Performancewith Model-Driven Engineering. InProceedings ofthe 7th IFIP Workshop on Software Technologies forFuture Embedded and Ubiquitous Systems.

Turner, H., White, J., Thompson, C., Zienkiewicz, K.,Campbell, S., and Schmidt, D. Building Mobile Sen-sor Networks Using Smartphones and Web Services:Ramifications and Development Challenges.

Wang, Q., Hempstead, M., and Yang, W. (2006). A re-alistic power consumption model for wireless sensornetwork devices. InProceedings of the Third AnnualIEEE Communications Society Conference on Sen-sor, Mesh and Ad Hoc Communications and Networks(SECON).

White, J., Clarke, S., Dougherty, B., Thompson, C., andSchmidt, D. (2010). R&D Challenges and Solutionsfor Mobile Cyber-Physical Applications and Support-ing Internet Services.Springer Journal of InternetServices and Applications (to appear).

White, J., Hill, J., Tambe, S., Gray, J., Gokhale, A., andSchmidt, D. C. (2009). Improving Domain-specificLanguage Reuse through Software Product-line Con-figuration Techniques.IEEE Software Special Issue:Domain-Specific Languages and Modeling.