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 for days without being recharged. It is hard, however, to design smartphone software that minimizes power consumption.
For example, multiple layers of abstractions and middleware sit between an application and the hardware, 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) to determine the power consumption characteristics of a design.
This paper provides three contributions to the study of applying model-driven engineering to analyze power consumption early in the lifecycle of smartphone applications. First, it presents a model-driven methodology for accurately emulating the power consumption of smartphone application architectures. Second, it describes the System Power Optimization Tool (SPOT), which is a model-driven tool that automates power consumption emulation code generation and simplifies analysis. Third, it empirically demonstrates how SPOT can estimate power consumption to within ∼3-4% of actual power consumption for representative smartphone applications.
SNIPPETS:
Motivating Example: The Wreckwatch Case Study:
This section describes WreckWatch, which is an open-source 1 mobile application we built on the Android smartphone platform to detect auto mobile accidents. We use WreckWatch as a case study throughout this paper to demonstrate key complexities of predicting the power consumption of mobile software architectures.
WreckWatch Operation.
Challenges of Designing Power Conscious Mobile Applications:
This section describes the challenges associated with developing power-aware mobile software, such as the WreckWatch application described. High-level mobile application development SDKs, such as Google Android or Apple iPhone, simplify mobile application development, but do not simplify power consumption prediction during application design.
The System Power Optimization Tool (SPOT):
This section describes the structure and functionality of the System Power Optimization Tool (SPOT), which is an MDE tool that allows developers to model potential mobile application software architectures to predict their power consumption, generate code to emulate that architecture, and then systematically analyze its power consumption properties. SPOT addresses the challenges described by allowing developers to understand the implications of their software architecture decisions at design time.
SPOT Modeling and Analysis Process.
Mobile Application Architecture Modeling and Power Consumption Estimation:
SPOT describes key power-consuming aspects of a mobile application via a DSML with specific language elements. This DSML allows developers to specify their software architecture visually with respect to power consuming components.
Generating Software Architecture Emulation Code:
Predicting the power consumption of an arbitrary design decision is hard, as described. SPOT addresses this challenge by generating application emulation code automatically to execute on the underlying device hardware.
Sample WreckWatch Emulation XML.
RESULTS:
This section analyzes the results of experiments that empirically evaluate SPOT’s MDE based capabilities presented. These experiments measure SPOT’s ability to collect power consumption information on a given model, as well as accurately model the power consumption of a proposed application software architecture. These results show how SPOT can assess and analyze power consumption information gathered through the Android’s power consumption API and evaluate SPOT’s accuracy in predicting power consumption information about a software architecture at design time.
Comparison of Open GPS Tracker Application Logic and Emulation Code.
Relative Power of Hardware Components.
CONCLUSION:
The System Power Optimization Tool (SPOT) is an MDE tool that allows developers to evaluate the power consumption of potential mobile application architectures early in the software lifecycle, e.g.at design time. Our experiments indicate that SPOT provides a high degree of accuracy, e.g. it predicted the power consumption of the WreckWatch and OpenGPSTracker applications to within 3-4%. We learned the following lessons developing and evaluating SPOT:
- Sensor sample rates play an important role in long-term power consumption.
The power consumed by the device sensors is largely uniform over the first several minutes of activation regardless of sample rate. It is only when these sensors are used for an extended period that the benefit of lower sample rates is realized. Developers must therefore consider the amount of time to activate the sensor in addition to the overall sample rate.
-
Certain hardware components draw significantly more power than others.
In the case of utilizing the GPS receiver, the power consumed by the location (GPS) service is so substantial that it becomes difficult to identify the effects of enabling or disabling other hardware components. Due to this “masking” effect, developers may overlook a significant consumer of power in an application. In general, small changes in GPS sample rate can have significant impacts on overall application power consumption.
-
Power consumption of an application can be accurately modeled by a few keycomponents.
The power consumed by certain components, such as the GPS receiver and accelerometers is so significantly greater than the power consumed by running the CPU, displaying images on the screen, etc. that SPOT can effectively model the power consumption of an application simply by modeling those components. The most effective power consumption optimization can be realized, there fore, with changes to only a small number of components.
- Certain system-related operations such as garbage collection are not reflected in data gathered by SPOT.
Through the current method of data collection SPOT is only able to gather power consumption information about operations that it performs such as CPU, memory or sensor operations that it specifically requests. Our future work will therefore develop mechanisms for capturing the impact of these services on power consumption.
- Power consumption of networking hardware is dependent on data transmitted which is often dependent on user interaction.
The power consumption of hardware, such as the Bluetooth or Wi-Fi interfaces, is dependent on the data transmitted and received on the device. This data is often generated at run-time by user interaction with the program. While it is effective for the developer to generate some sample data and provide it to SPOT, it would be more effective if developers could simply describe the data, e.g. via a schema file. Our future work is extending SPOT so it can process a data schema file and generate data that is random, yet still valid to the application.
- Although GPS is a major consumer of power, not all applications rely on GPS.
Although GPS is a major consumer of power on today’s smartphone devices, it is still important to understand the power consumption of applications that do not use the GPS, even if their power consumption is less drastic. Our future work is therefore analyzing SPOT’s accuracy with mobile applications (such as 3D games with acceleration-based controls, streaming video players, and audio recording/processing applications) that do not use GPS, such as 3D games, feed readers, and multimedia applications.SPOT is available in open-source form at syspower.googlecode.com.
Source: Vanderbilt University
Authors: Chris Thompson | Jules White | Douglas C.Schmidt