Download Slides - Universität Stuttgart

Universität Stuttgart
Institute of Parallel and
Distributed Systems (IPVS)
Universitätsstraße 38
D-70569 Stuttgart
Meeting Lifetime Goals with Energy Levels
Andreas Lachenmann*, Pedro José Marrón**,
Daniel Minder**, and Kurt Rothermel*
* Universität Stuttgart, Germany
** Universität Bonn, Germany
ACM SenSys 2007
Motivating Application Scenarios
• Applications
◦ Structural health monitoring
◦ Volcano monitoring
◦ Environmental monitoring
• Common characteristics
◦ Required lifetime known beforehand
© BeautifulFreak / PIXELIO
 Maximize application quality
◦ High-energy tasks
◦ Every node should meet lifetime
▪ Reduces spatial resolution of sensor
data
▪ Or single node failure can render large
parts of network useless
If required lifetime cannot be
met, reduce functionality
Research Group
“Distributed Systems”
Universität Stuttgart
2
IPVS
Meeting Lifetime Goals
• Have to define
Programming abstraction
◦ For wide range of applications
◦ Independent development of
◦ Required lifetime
◦ Optional functionality in code
• Have to know at runtime
◦ Still needed lifetime
◦ Remaining energy
◦ Current energy consumption
◦ Energy consumption of other
modules
Runtime system
◦ Meet lifetime goal without low-
modes
• Have to compute time with full
level energy issues
functionality
◦ Deal with variations in energy
◦ Provide best quality possible
◦ Low overhead at runtime
consumption
 Appropriate abstractions and system support could make this task
much easier: Levels
Research Group
“Distributed Systems”
Universität Stuttgart
3
IPVS
Levels Overview
• Specify optional functionality in “energy levels”
◦ System decides which level is active
◦ Only code in active levels is executed
• Similar to model-predictive control schemes
◦
◦
◦
◦
Profiling energy consumption of optional code
Battery model that maps voltage to remaining energy
Monitor consumed energy at runtime
Periodically optimize level assignment for remaining energy
Research Group
“Distributed Systems”
Universität Stuttgart
4
IPVS
Energy Levels Abstraction
• Energy level contains all statements
Component1
ComputeLevel
that can be deactivated together
ui
SenseLevel
l3 Complex analysis
7
BasicLevel
l2 Energy-intensive storage
5
l1 Expensive sensing
4
l0 Cheap forwarding
0
◦ Optional code, not needed for
basic functionality
◦ Placed in conditional statement
• Levels form a stack where levels
can be deactivate from top
◦ Level l0 always active
◦ If level li is active, all levels below
Application
Component2
StoreLevel
BasicLevel
are active
• Each level associated with utility
value
• Wiring of levels fits modular
development
Research Group
“Distributed Systems”
Component3
Component4
StoreLevel
FlashLevel
BasicLevel
BasicLevel
Universität Stuttgart
5
IPVS
Code Example
• Energy levels provided and
wired like interfaces
• Declaration specifies order of
levels
• “if” statement to place code
into energy level
• Activate/deactivate commands
• Summary
◦ Only small changes to nesC
◦ Low overhead for developer
module Component1 {
provides energylevel SenseLevel<1>;
provides energylevel ComputeLevel<2>;
...
}
implementation {
...
event TOS_MsgPtr ReceiveMsg.receive(...) {
if (ComputeLevel.active) {
post computeTask();
}
return msg;
}
event result_t Timer.fired() {
if (SenseLevel.active) {
call SensorADC.getData();
}
return SUCCESS;
}
command void SenseLevel.activate() {
call SensorControl.start();
}
command void SenseLevel.deactivate() {
call SensorControl.stop();
}
...
Research Group
“Distributed Systems”
Universität Stuttgart
6
IPVS
Profiling Energy Consumption
• Simulators like Avrora already
◦ Not just consumed by CPU but
also by radio, flash, sensors, …
◦ Energy of asynchronously
executed code
◦ Reuse unit testing code
Consumed energy
include energy models
Level 2
Level 2 – Level 1
Continuous energy
consumption
• Compute difference to next
lower level
Level 1
One-time energy
consumption
◦ One-time energy for code
◦ Change in continuously
t1
consumed energy
Execute code
Research Group
“Distributed Systems”
t2 Time
Universität Stuttgart
7
IPVS
Battery Model
• Maps voltage to remaining energy
◦ Not main focus
• Very simple and efficient model
◦ Does not consider many effects
◦ But sufficient for given type of
batteries (“Duracell Plus”, alkaline)
• Model creation
◦ Used application to drain batteries
and record voltage readings
◦ Computed available capacity from
total execution time
• Store for each voltage reading average
energy left and expected accuracy
◦ Not actual energy, but energy
consumed for constant voltage
Research Group
“Distributed Systems”
Universität Stuttgart
8
IPVS
Monitoring Energy Consumption in Energy Levels
• In each optional code block
consumption for level
◦ Change in continuous energy
consumption for level
• Periodically, every few seconds
Consumed energy
◦ Add one-time energy
Total
◦ Compute continuously
consumed energy in interval
• Periodically, every few hours
Continuous
◦ Compute optimal level
assignment to reach lifetime
Time
Execute code block
Research Group
“Distributed Systems”
Add continuous
consumption
Level adjustment
Universität Stuttgart
9
IPVS
Adjusting Levels at Runtime
• Maximize average utility of
maximize
energy levels
◦ Linear programming problem
◦ Uses fixed-point implementation of
subject to
Simplex algorithm
• Result: Durations in levels
• Periodically executed every
few hours
Result: time in levels
◦ React to changes in energy
◦
◦
consumption
Small inaccuracies will be balanced
in later periods
Delay computation if not enough
energy consumed for accuracy of
battery model
Utility of levels
Power consumption
of energy levels
Current lifetime
Required lifetime
Remaining energy
Research Group
“Distributed Systems”
Universität Stuttgart
10
IPVS
Energy Level Assignment over Time
• Problem: All nodes might switch to
lower level near end of lifetime
 Network not of much use then
• Solution: Do not always select
highest level from local optimization
first
◦ Useful distribution often
application-specific:
 Input from the application
◦ Uniform distribution:
Network-wide
average:
 Random level from local result
Research Group
“Distributed Systems”
Universität Stuttgart
11
IPVS
Evaluation: Lifetime Achieved
• Applications
◦ FFT: Periodically Compute Fast
Fourier Transform
◦ Volcano: Harvard’s volcano
monitoring application
Actual lifetime [days]
▪ Depends on external events
▪ Modified 20 lines of code
• No node failed early
◦ FFT
▪ Application quality almost optimal
▪ Variations in lifetime small
◦ Volcano
▪ Lived somewhat longer than
required
▪ Cannot consume safety buffer
completely
Required lifetime [days]
Research Group
“Distributed Systems”
Universität Stuttgart
12
IPVS
Evaluation: Experiment Lifetime
• Energy-expensive “Voltage”
application
◦ Lifetime: Time while neighbor can
receive periodic messages
◦ Used for experiments with real Mica2
nodes
◦ Calibrated energy model to nodes
• Met lifetime goal in almost all
cases
◦ Between 1.1 % and 6.5 % longer than
required
• Exception: Last experiments
◦ Some nodes failed early
◦ Due to differences in batteries
◦ After adjusting battery model:
Met lifetime again
Research Group
“Distributed Systems”
Universität Stuttgart
13
IPVS
Evaluation: Runtime Overhead
• Purely local optimization:
No communication overhead
• Computational overhead
◦ Level adjustment: 10-20 ms
Application
• Actual effect on application
lifetime
◦ Do all computation without
adjusting level
 Overhead negligible, even for
low-power applications
Research Group
“Distributed Systems”
Lifetime with
Levels
Reduction
Voltage l0
7.687 days
0.0 %
Voltage l1
6.648 days
0.0 %
Voltage l2
5.932 days
0.0 %
FFT l0
944.4 days
1.8 %
FFT l1
372.7 days
0.7 %
Universität Stuttgart
14
IPVS
Related Work
• Most existing work tries to maximize lifetime
• Mobile computing: Odyssey
◦ Meet lifetime goals by adapting application fidelity
◦ Does not leverage simulation data
• TinyDB
◦ Adapt sampling rate to achieve lifetime
◦ Limited to queries
• Online energy metering (hardware or software )
◦ Could be used instead of battery model to get overall energy consumed
◦ But cannot attribute energy to asynchronously executed code
Research Group
“Distributed Systems”
Universität Stuttgart
15
IPVS
Conclusions
• Levels: Abstraction and system support for energy-aware sensor
network applications
◦ Makes it possible to meet lifetime goals
◦ System takes care of low-level energy estimations
◦ Requires only small modifications of source code
• Evaluation shows
◦ Properly meets lifetime goals if accurate model available
◦ Quality close to optimum
◦ Runtime overhead negligible
Research Group
“Distributed Systems”
Universität Stuttgart
16
IPVS
Questions
Thank you for your attention!
Andreas Lachenmann
[email protected]
http://www.ipvs.uni-stuttgart.de?id=andreas.lachenmann
Universität Stuttgart
Institute of Parallel and Distributed Systems (IPVS)
Universitätsstr. 38
70569 Stuttgart, Germany
Research Group
“Distributed Systems”
Universität Stuttgart
17
IPVS
Backup Slides
Research Group
“Distributed Systems”
Universität Stuttgart
18
IPVS
Relevant Sensor Network Properties
• Single application on each node
◦ Lifetime estimation easier than in multitasking systems
• Applications often exhibit repeating behavior
◦ Estimate future energy usage based on past data
• Simulation integral part of development process
◦ Use simulation to get information about energy consumption
• Software developers more concerned about energy than in other
domains
◦ Willing to invest some additional effort
Research Group
“Distributed Systems”
Universität Stuttgart
19
IPVS
Wiring Example
• Completely analogous to
wiring of interfaces
configuration Application {
}
implementation {
components Main, Component1, Component2;
• Utility values defined by
Main.EnergyLevel[7] -> Component1.ComputLevel;
Main.EnergyLevel[5] -> Component2.StoreLevel;
Main.EnergyLevel[4] -> Component1.SenseLevel;
wiring to
Main.EnergyLevel
• Several energy levels can
be combined
...
}
configuration Component2 {
provides energylevel StoreLevel<1>;
}
implementation {
components Component3, Component4;
StoreLevel = Component3.StoreLevel;
StoreLevel = Component4.StoreLevel;
}
Research Group
“Distributed Systems”
Universität Stuttgart
20
IPVS
Energy Profiling Example
• Example to profile energy
module ProfilingM {
provides interface ReceiveMsg;
provides interface Timer;
...
}
implementation {
...
void measureReceive()
@energy("ReceiveMsg", "receive") {
TOS_Msg msg;
msg.addr = TOS_LOCAL_ADDRESS;
...
signal ReceiveMsg.receive(&msg);
}
void measureTimer()
@energy("Timer", "fired") {
signal Timer.fired();
}
...
consumption of previous code
example
• @energy attribute: Name of
function under measurement
• Wired to original module instead
of GenericComm and TimerC
• Writing this code is only effort for
developer
◦ Can build upon similar functions
from unit testing
Research Group
“Distributed Systems”
Universität Stuttgart
21
IPVS
Unit Testing with nCUnit
• Similar to JUnit
• Builds upon the Avrora simulator
• @test attribute to mark test
module TestAssertM {
uses interface Assert;
uses interface StdControl as TestControl;
}
implementation {
void testFunction1() @test() {
uint8_t* varPtr;
// create Java class to check
// simulator assertion
call Assert.assertJavaClass(
"example.TestJavaAssert", 1000);
// check if function under test
// toggles the red LED
call Assert.assertCalls(
"ToTestM.Leds.redToggle", NULL,
NULL, COMP_NONE);
// call function under test
call TestControl.start();
}
functions
• nCUnit starts separate
simulation run for each test
function
• Automates check of success
◦ Usual assertions
◦ Check arbitrary state in simulator
with custom Java class
◦ Assertion if function in other
void testFunction2() @test() {
...
}
component called
Research Group
“Distributed Systems”
Universität Stuttgart
22
IPVS
Energy Values for Constant Voltage
• No voltage boost converter on
From
sensor nodes
and
◦ Current draw depends on
:
Energy:
voltage
◦ Effect on power and energy
quadratic
For constant voltage:
• Battery model
◦ Assumed constant voltage of
Uconst = 3.0 V
◦ Not actual energy values
◦ Simplifies computations at
runtime
Research Group
“Distributed Systems”
Universität Stuttgart
23
IPVS
Evaluation
• Used Avrora for simulation
• Battery model
◦ Nodes compute with trace from real battery
◦ Battery model in simulator average of several traces
• Evaluation criteria
◦ Meeting lifetime goals
▪ Lifetime achieved
▪ Average energy level
◦ Level assignment over time
◦ Runtime overhead
Research Group
“Distributed Systems”
Universität Stuttgart
24
IPVS
Evaluation: Sample Applications Lifetime for Fixed
Energy Levels
Application
Periodic Task in l1 and l2
Level l0
Level l1
Level l2
FFT
Compute Fast Fourier
Transform
961
days
375
days
Not used
Flash
Store data to flash memory
961
days
296
days
Not used
SendLPL
Use low-power listening, send
messages with long
preambles
34.6
days
22.5
days
16.7
days
SendLPLRandom Not periodically but randomly
send
34.6
days
27.1
days
22.2
days
SendRadioOff
Turn radio only on for sending
short message
948
days
692
days
Not used
Voltage
Send message with current
voltage, toggle LEDs
7.69
days
6.65
days
5.93
days
Research Group
“Distributed Systems”
Universität Stuttgart
25
IPVS
Evaluation: Lifetime Achieved
• Varied lifetime goals for all
applications
• Simulations with different
simulated batteries
◦ Used voltage traces from
real sensor node
◦ Same inaccuracies as in
practice
• Always achieved lifetime
goal accurately
• Small variations in lifetime
Research Group
“Distributed Systems”
Universität Stuttgart
26
IPVS
Evaluation: Average Utility
• Computed optimum average utility
value offline
◦ Using exact data about energy
◦ Solved optimization problem once
for complete lifetime
• SendLPL
◦ Achieved utility close to optimum
• SendRadioOff
◦ Extremely long-lived application
◦ In l1 0.14 mW more than in l0
 Very few level adjustments
 Cannot make use of safety
overhead early enough
Research Group
“Distributed Systems”
Universität Stuttgart
27
IPVS
Evaluation: Level Assignment over Time
• Perfect case
◦ Stay in highest level for as long
as possible
◦ Switch only later to lower levels
◦ Minimize number of level
changes
• Not possible because of
inaccuracies on sensor nodes
◦ Switch to higher level when
safety overhead no longer
needed
◦ Still very few level changes
Research Group
“Distributed Systems”
Universität Stuttgart
28
IPVS
Evaluation: Real-World Application
• Harvard’s volcano monitoring
application
◦ Sparse topology
◦ Behavior depends on external events
◦ Sensor board main energy consumer:
40 mA
• Added energy level that makes
sampling optional
◦ Nodes continue forwarding
◦ Modified 20 lines
◦ Energy profiling code: 200 lines
• No sensor node failed early
• Application quality close to optimum
Research Group
“Distributed Systems”
Universität Stuttgart
29
IPVS
Evaluation: Runtime Overhead
• Purely local optimization:
No communication overhead
• Computational overhead
◦ For each optional block: 91 µs
◦ Updating continuous energy: 30235 µs
◦ Level adjustment: 10-20 ms
• Actual effect on application lifetime
◦ Do all computation without
adjusting level
Application
◦ Compared to application in fixed
level without runtime system
 Overhead negligible, even for lowpower applications
Research Group
“Distributed Systems”
Lifetime with Levels
Reduction
Voltage l0
7.687 days
0.0 %
Voltage l1
6.648 days
0.0 %
Voltage l2
5.932 days
0.0 %
FFT l0
944.4 days
1.8 %
FFT l1
372.7 days
0.7 %
Universität Stuttgart
30
IPVS
Evaluation: Effect of Temperature on Battery Voltage
Inside
• Temperature effect on battery
voltage not explicitly
considered
• All lifetime experiments done
inside
◦ Variations about 4 °C
◦ Temperature effect does not
Outside
influence Levels
• Outside
◦ Differences up to 15 °C
◦ Visible effect of temperature on
voltage curve
Research Group
“Distributed Systems”
Universität Stuttgart
31
IPVS