sensor network programming ryo sugihara ryo@ucsd.edu 2009/11/05 for cse237b
Post on 19-Dec-2015
221 Views
Preview:
TRANSCRIPT
Sensor Network Programming
Ryo Sugihara
ryo@ucsd.edu
2009/11/05
for CSE237B
Research Exam: Ryo Sugihara 22006/06/22
About today’s talk• I’ll talk about programming models for sensor network
s– High-level overview– NOT about hands-on experience or development tips
• Based on the presentation for my research exam– in 2006
• For more details, see– Ryo Sugihara and Rajesh K. Gupta,
"Programming Models for Sensor Networks: A Survey" in ACM Transactions on Sensor Networks, vol.4, issue 2, Mar. 2008
Programming Models for Sensor Networks
Ryo SugiharaComputer Science and Engineering
UC San Diegoryo@ucsd.edu
Research Exam:
2006/06/22
Research Exam: Ryo Sugihara 42006/06/22
• Network of tiny sensors with processing capabilities
• Emerging field with huge application area– Environmental monitoring– Structural monitoring– Target localization– ... and more
• ... but difficult to program– Embedded & distributed system– and moreover,
• Unreliable communication• Faulty nodes• Scarce energy• Insufficient development environment• ... and more
Wireless Sensor Networks (WSNs)
Tmote SkyMSP430 microcontroller
(16bit RISC, 8MHz, 10kB RAM, 48kB Flash)250kbps radio, 1Mb ext storage
Humidity, Temperature, and Light sensors
Research Exam: Ryo Sugihara 52006/06/22
Programming Models
• “Programming models”– An abstraction of the target machine that a programmer use
s to write applications• Represented in programming languages / language extension
• Why are programming models important for WSNs?– Programmers need software support
• Too many things to care about: efficiency, unreliableness..• Appropriate PM can let programmers focus on application need
s, rather than mechanisms to specify and implement them
– New algorithms for sensor network applications• Due to unique assumptions and requirements• Appropriate PM can facilitate implementing them
Research Exam: Ryo Sugihara 62006/06/22
In this talk, we ...
• Analyze WSN applications– to figure out their requirements and implications to PMs
• Give a taxonomy of programming models for WSNs– No clear taxonomy before– Categorize them into three major types
• Evaluate each type of programming models – in terms of applications’ requirements
• Discuss future research directions
Research Exam: Ryo Sugihara 72006/06/22
Outline• Background
• Requirements from Applications
• Programming Models for Sensor Networks– Taxonomy– Approach 1: Node-level programming– Approach 2: Group-level programming– Approach 3: Macroprogramming
• Evaluation
• Future Research Directions
• Conclusion
Research Exam: Ryo Sugihara 82006/06/22
Outline• Background
• Requirements from Applications
• Programming Models for Sensor Networks– Taxonomy– Approach 1: Node-level programming– Approach 2: Group-level programming– Approach 3: Macroprogramming
• Evaluation
• Future Research Directions
• Conclusion
Research Exam: Ryo Sugihara 92006/06/22
“Data Collection” Applications
• “Data collection” type– Collect data to the center– Users are interested in sensor data itself
Great Duck Island (2002-)Habitat monitoring
ZebraNet (2002-)Habitat monitoring
GlacsWeb (2003-)Glacial movement
Wisden (2004-)Structural Health Monitoring
Research Exam: Ryo Sugihara 102006/06/22
“Collaborative Info. Processing” Applications
• “Collaborative information processing” type– Extract high-level info by processing data from multiple sensors
• i.e. “sensor fusion”– Users are more interested in processed data
• Data processing often happens inside the network
PinPtr (2004-)Countersniper system
Vehicle monitoring (2006)
IDSQ (2001)Information-driven sensor querying
VigilNet (2004-)Surveillance
Trilateration
proximity sensor
target
“Tracking” appl
Research Exam: Ryo Sugihara 112006/06/22
Requirements from WSN applications
• Energy-efficiency– Nodes must run for months only with battery
• Failure-resilience– Appls should be functional even after failures (n
ode, sensors, communication, ..)
• Collaboration– Appls often need collaborative info. processing– Also applicable to data collection applications
• In-network aggregation / summarization / ...
and their implications to programming models
• PMs should be accompanied with compilers/tools that generate efficient code
• PMs should provide ways to control energy-performance trade-off
• PMs should provide ways to handle failures gracefully
• PMs should provide ways to describe collaboration easily
Research Exam: Ryo Sugihara 122006/06/22
Outline• Background
• Requirements from Applications
• Programming Models for Sensor Networks– Taxonomy– Approach 1: Node-level programming– Approach 2: Group-level programming– Approach 3: Macroprogramming
• Evaluation
• Future Research Directions
• Conclusion
Research Exam: Ryo Sugihara 132006/06/22
Towards a taxonomy of PM for WSNs
• Motivation– A number of PMs have been proposed– Lack of comprehensive taxonomy
• Strategy: Classify PMs by “level of abstraction”– Three levels: “Node”, “Group”, and “Whole network”
– Consider the highest level of abstraction• Higher level abstractions are usually accompanied with lower le
vel tools / runtime environments– Every program needs to be compiled into node-level code, after all
• Highest level of abstraction is the programming interface– that a PM exposes to programmers– thus it’s what matters for programmers
Research Exam: Ryo Sugihara 142006/06/22
Taxonomy of PMs for WSNs
Programming models
Node-level Group-level Macroprogramming
Node-level Programming Language
Virtual MachineNeighborhood-based
groupLogical group Database
Macroprogramminglanguage
Mate/ASVMVMStarImpalaSensorWareSOS
TML
Abstract RegionsHood
Directed DiffusionEnviroTrack
RegimentKairos
Spatial ProgrammingSpatialViewsDRN
Semantic Streams
CougarTinyDBSINAMiLANDSWare
TinyOS/nesCSNACKTinyGALST2OSM Liu et al. (State-centric)
• Three major approaches– Node-level programming– Group-level programming– “Macroprogramming”
Research Exam: Ryo Sugihara 152006/06/22
Taxonomy of PMs for WSNs
Programming models
Node-level Group-level Macroprogramming
Node-level Programming Language
Virtual MachineNeighborhood-based
groupLogical group Database
Macroprogramminglanguage
“Program a node” “Program a group” “Program the whole”
Different viewpoint
Research Exam: Ryo Sugihara 162006/06/22
Programming models
Node-level Group-level Macroprogramming
OS / Node-level Programming Language
Virtual MachineNeighborhood-based
groupLogical group Database
Macroprogramminglanguage
Mate/ASVMVMStarImpalaSensorWareSOS
TML
Abstract RegionsHood
Directed DiffusionEnviroTrack
RegimentKairos
Spatial ProgrammingSpatialViewsDRN
Semantic Streams
CougarTinyDBSINAMiLANDSWare
TinyOS/nesCSNACKTinyGALST2OSM
Programming models
Node-level Group-level Macroprogramming
OS / Node-level Programming Language
Virtual MachineNeighborhood-based
groupLogical group Database
Macroprogramminglanguage
Mate/ASVMVMStarImpalaSensorWareSOS
TML
Abstract RegionsHood
Directed DiffusionEnviroTrack
RegimentKairos
Spatial ProgrammingSpatialViewsDRN
Semantic Streams
CougarTinyDBSINAMiLANDSWare
TinyOS/nesCSNACKTinyGALST2OSM
Tools
SimulatorSoftware
environment
TOSSIMAvrora
EmStarMarionetteSympathy
Tools
SimulatorSoftware
environment
TOSSIMAvrora
EmStarMarionetteSympathy
1. Node-level Programming
• Node-level programming– Program each node’s behavior
• Assumption: Node efficiency is the top priority– Low overhead
Node-level
Node-level Programming Language
Virtual Machine
Maté/ASVMVMStarImpalaSensorWareSOS
TML
TinyOS/nesCSNACKTinyGALST2OSM
Research Exam: Ryo Sugihara 172006/06/22
1-1. Node-level Language• Earliest and still prevalent approach
• Examples– Event-driven component-based programming
• nesC [Gay et al., 2003] / TinyOS [Hill et al., 2000]
– Some enhancements on nesC / TinyOS• Easier concurrency management
– TinyGALS [Cheong et al., 2003]
• Reusable service library – SNACK [Greenstein et al., 2004], T2 [Levis et al., 2005] (TinyOS ver.2)
• Features+ Flexible+ Efficient– Complex
• Little support from programming models• You can do anything as long as you are an excellent programmer
Research Exam: Ryo Sugihara 182006/06/22
nesC (1/2)
• C-based language– Component-based programming– Event-based execution model
• Two types of components– “module”
• functional unit
– “configuration”• set of modules wired together
[Gay, Levis, von Behren, Welsh, Brewer & Culler, 2003]
StdControl Timer
TimerM
Clock
module TimerM { provides { interface StdControl; interface Timer; } uses interface Clock;} ...implementation { ... command result_t StdControl.init() { ... } ...}
Module definition
interface StdControl { command result_t init();}interface Timer { command result_t start(char type, uint32_t interval); command result_t stop(); event result_t fired();}interface Clock {...
configuration TimerC { provides { interface StdControl; interface Timer; }}implementation { components TimerM, HWClock;
StdControl = TimerM.StdControl; Timer = TimerM.Timer;
TimerM.Clock -> HWClock.Clock;}
StdControl Timer
TimerM
Clock
HWClock
Clock
StdControl Timer
TimerC
Configuration definition
Research Exam: Ryo Sugihara 192006/06/22
nesC (2/2)
• Advantages– Modular programming– Flexible boundary of HW/SW
• Same functionality can be implemented either on HW or SW
– Compile-time analysis of concurrency• Compiler can detect most potential race conditions
• Disadvantages– Complex
• Rigorously event-driven programming style• “Split-phase operations”
– No blocking operations: Request / Completion– e.g.) getData() → requestGetData(), eventDataAvailable(),
– Lack of reusability• Configurations are not parameterizable• Module has parameters specific to application
Research Exam: Ryo Sugihara 202006/06/22
SNACK (1/4)[Greenstein, Kohler, & Estrin, 2004]
• Sensor Network Application Construction Kit– Configuration language– Reusable service library– Compiler
Research Exam: Ryo Sugihara 212006/06/22
SNACK (2/4)
tree1, tree2 :: my RoutingTree(period < 20000);SenseLight(period < 10000) -> [collect] tree1;SenseTemp(period < 10000) -> [collect] tree2;
“services” • Combine parameterized “services”– Similar to nesC configuration– Ranged parameter to facilitate “ser
vice weaving” (later)
Application programming in SNACK
Research Exam: Ryo Sugihara 222006/06/22
SNACK (3/4)
tree1, tree2 :: my RoutingTree(period < 20000);SenseLight(period < 10000) -> [collect] tree1;SenseTemp(period < 10000) -> [collect] tree2;
service RoutingTree (period: max uint32_t $p = 5000) { dispatch :: my TreeDispatch16; nf :: my NullForwarder16; in [collect] -> dispatch -> [collect] out; dispatch [fromChild] -> nf; nf [toRoot] -> dispatch; dispatch [subtreeReady] -> nf; dispatch [lookup] -> TreeBuilder(period = $p);};
service TreeDispatch16(qsize: min uint8_t $q = 8){ ...};...
Expansion intoComponents
• Generic services are provided by SNACK library
• Separation of “application programmers” and “service programmers”
Research Exam: Ryo Sugihara 232006/06/22
SNACK (4/4)
• “Service weaving”– Merge compatible components
• Automatically by SNACK compiler
– Reduce the size of code
Research Exam: Ryo Sugihara 242006/06/22
1-2. Virtual Machines• Idea: Run a virtual machine on each sensor node
– Programs are described as intermediate code for VM
• Mainly for reprogrammability– Dissemminate and install code on-the-fly– Not possible in TinyOS only
• Examples– Application-specific VM
• Maté / ASVM [Levis et al., 2002, 2005], VMStar [Koshy & Pandey, 2005]
– For richer platforms• SensorWare [Boulis et al., 2003]
– Update native code• SOS [Han et al., 2005]
Research Exam: Ryo Sugihara 252006/06/22
Maté / ASVM
• Application specific virtual machine– Expose new programming primitives by using application-spe
cific opcodes• Each VM supports only limited instruction set
– Complete generality is not necessary for a given network• Assumption: each sensor deployment is for a specific application
• Mainly for – Efficient dynamic reprogramming
• Smaller code size by reducing the size of instruction set
– Safety– (Not for portability as in JVM)
[Levis & Culler, 2002], [Levis, Gay & Culler, 2005]
Research Exam: Ryo Sugihara 262006/06/22
Maté Build Process
Appl-specific VM
Compile code to custom instruction set
Users select these three thingsFrom Philip Levis, "Rapid and Safe Programming of In-situ Sensor Networks“, Qualifying examination proposal, Jan 2004.
Appl programin “tscript” etc.
Research Exam: Ryo Sugihara 272006/06/22
Evaluation of Node-level PM
• Energy-efficiency• Failure-resilience• Collaboration
– Exposed to programmers, with little support• Everything is possible, but needs to be implemented by p
rogrammers • Reusable service libraries (SNACK, T2) can be helpful
• VM-approach has a different goal– Reprogrammability
Research Exam: Ryo Sugihara 282006/06/22
2. Group-level Programming
• Group-level programming– Define a group of nodes and program it
• Assumption: Need support for collaboration– Building block for applications / higher level abstractions
Programming models
Node-level Group-level Macroprogramming
OS / Node-level Programming Language
Virtual MachineNeighborhood-based
groupLogical group Database
Macroprogramminglanguage
Mate/ASVMVMStarImpalaSensorWareSOS
TML
Abstract RegionsHood
Directed DiffusionEnviroTrack
RegimentKairos
Spatial ProgrammingSpatialViewsDRN
Semantic Streams
CougarTinyDBSINAMiLANDSWare
TinyOS/nesCSNACKTinyGALST2OSM
Programming models
Node-level Group-level Macroprogramming
OS / Node-level Programming Language
Virtual MachineNeighborhood-based
groupLogical group Database
Macroprogramminglanguage
Mate/ASVMVMStarImpalaSensorWareSOS
TML
Abstract RegionsHood
Directed DiffusionEnviroTrack
RegimentKairos
Spatial ProgrammingSpatialViewsDRN
Semantic Streams
CougarTinyDBSINAMiLANDSWare
TinyOS/nesCSNACKTinyGALST2OSM
Tools
SimulatorSoftware
environment
TOSSIMAvrora
EmStarMarionetteSympathy
Tools
SimulatorSoftware
environment
TOSSIMAvrora
EmStarMarionetteSympathy
Group-level
Neighborhood-basedgroup
Logical group
Abstract RegionsHood
EnviroTrack
Liu et al. (State-centric)
Research Exam: Ryo Sugihara 292006/06/22
2-1. Neighborhood-based group
• Locally-defined group– Consists of a node and its neighboring nodes
• Examples– Abstract Regions [Welsh & Mainland, 2004]
• Topological (N-hop neighbor)• Geographical
– Hood [Whitehouse et al., 2004]
• One-hop neighbor
• Good balance of efficiency and usefulness– Captures broadcasting nature of wireless communication– Intuitive definition, easy to use for programmers– Suitable for describing collaboration
d
topological geographical
Research Exam: Ryo Sugihara 302006/06/22
Abstract Regions
• Efficient communication primitives within group (= “region”)
• Region definition– Topological: N-hop– Geographical: within radius d, k-nearest neighbor– Others: planar mesh, spanning tree
• Provide interface for– Neighborhood discovery
• Create a region– Enumeration
• Get a set of nodes in the region– Data sharing
• Linda-like tuplespace interface: “Get” and “Put”– (key, value) tuple is put into shared tuplespace– Anyone who specifies the same key obtains the associated value
– Reduction• MPI-like reduction operations
– Collect data to one node while applying some operations (avg, sum, ...)
[Welsh & Mainland, 2004]
Research Exam: Ryo Sugihara 312006/06/22
ex.) Tracking appl. in Abstract Regions
location = get_location();
/* Get 8 nearest neighbors */
region = k_nearest_region.create(8);
while (true) {
reading = get_sensor_reading();
/* Store local data as shared variables */
region.putvar(reading_key, reading);
region.putvar(reg_x_key, reading * location.x);
region.putvar(reg_y_key, reading * location.y);
if (reading > threshold) {
/* ID of the node with the max value */
max_id = region.reduce(OP_MAXID, reading_key);
/* If I am the leader node ... */
if (max_id == my_id) {
/* Perform reductions and compute centroid */
sum = region.reduce(OP_SUM, reading_key);
sum_x = region.reduce(OP_SUM, reg_x_key);
sum_y = region.reduce(OP_SUM, reg_y_key);
centroid.x = sum_x / sum;
centroid.y = sum_y / sum;
send_to_basestation(centroid);
}
}
sleep(periodic_delay);
}
• No need for explicitly describing communication among sensor nodes within a region
Create a region
Put data as shared variables
Choose leader node
Compute centroid as an estimate oftarget location
Read proximity sensor
Research Exam: Ryo Sugihara 322006/06/22
2-2. Logical Group
• Defined according to high-level logical properties– Not only topological/geographical proximity– e.g.) sensor input
• Example– EnviroTrack [Abdelzaher et al., 2004]
• Data-centric group definition for tracking application– cf.) Node-centric group definition in Abstract Region / Hood
• Group of sensors that detected the same event
• Closer to application’s logic than system’s logic– Data-centric approach
target
“Group”
target
cf.) Abstract Regions
Research Exam: Ryo Sugihara 332006/06/22
Evaluation of Group-level Programming
• Energy-efficiency– Mostly hidden
• Easy to achieve: broadcasting nature of wireless comm.• Abstract Regions also exposes low-level control knobs
• Failure-resilience– Exposed, with support
• Node enumeration
• Collaboration– Exposed, with support
• Predefined mechanisms: data sharing, reduction• Users can implement collaborative algorithms using
them
Research Exam: Ryo Sugihara 342006/06/22
3. Macroprogramming
• “Macroprogramming”– Program sensor network as a whole, regarding it as a single abstract
machine• Assumption: Focus on application-side requirements
– DB: Ease-of-use– Macroprogramming Lang.: Expressiveness
Programming models
Node-level Group-level Macroprogramming
OS / Node-level Programming Language
Virtual MachineNeighborhood-based
groupLogical group Database
Macroprogramminglanguage
Mate/ASVMVMStarImpalaSensorWareSOS
TML
Abstract RegionsHood
Directed DiffusionEnviroTrack
RegimentKairos
Spatial ProgrammingSpatialViewsDRN
Semantic Streams
CougarTinyDBSINAMiLANDSWare
TinyOS/nesCSNACKTinyGALST2OSM
Programming models
Node-level Group-level Macroprogramming
OS / Node-level Programming Language
Virtual MachineNeighborhood-based
groupLogical group Database
Macroprogramminglanguage
Mate/ASVMVMStarImpalaSensorWareSOS
TML
Abstract RegionsHood
Directed DiffusionEnviroTrack
RegimentKairos
Spatial ProgrammingSpatialViewsDRN
Semantic Streams
CougarTinyDBSINAMiLANDSWare
TinyOS/nesCSNACKTinyGALST2OSM
Tools
SimulatorSoftware
environment
TOSSIMAvrora
EmStarMarionetteSympathy
Tools
SimulatorSoftware
environment
TOSSIMAvrora
EmStarMarionetteSympathy
Macroprogramming
DatabaseMacroprogramming
Language
RegimentKairos
Spatial ProgrammingSpatialViewsDRN
CougarTinyDBSINAMiLANDSWare
Semantic Streams
Research Exam: Ryo Sugihara 352006/06/22
3-1. Database• Intuitive metaphor, earliest work in high-level PM
• Examples– SQL-based interface
• COUGAR [Bonnet et al., 2000]
• TinyDB [Madden et al., 2003, 2005]
– plus imperative language for tasking• SINA [Srisathapornphat et al., 2000]
– Specialized in event detection• DSWare [Li et al., 2003]
– QoS feature• MiLAN [Heinzelman et al., 2004]
• Features+ Easy-to-use
+ Easy for the end-users (nontechnical people, non-CS researchers)– Narrow coverage of application
• Only for applications that query
Research Exam: Ryo Sugihara 362006/06/22
TinyDB
• SQL-based interface– Supports selection, join, projection
• Supports in-network aggregation– SUM, AVG, MAX, ...
• Supports continuous sampling– “SAMPLE PERIOD” clause– “LIFETIME” clause
• Specify the lifetime• Estimate the lifetime and adjust sampling rate accordingly
[Madden, Franklin, Hellerstein, & Hong, 2003]
SELECT AVG(volume), room FROM sensors WHERE floor = 6 GROUP BY room HAVING AVG(volume) > threshold SAMPLE PERIOD 30s
• Monitor the occupancy of the conference rooms – on the 6-th floor of a building – by using microphone sensors
• Report all rooms where the average volume is over the threshold
• Deliver updates every 30 seconds
Research Exam: Ryo Sugihara 372006/06/22
3-2. Macroprogramming Language
• Expressiveness in application’s context– Just like manipulating spatially distributed data points
• Focus & examples– Description of global behavior
• Regiment [Newton & Welsh, 2004]
• Kairos [Gummadi et al., 2005]
– Resource naming• Focus on space-awareness
– Spatial Programming [Borcea et al., 2004]
– SpatialViews [Ni et al., 2005]
• plus declarative predicates– DRN [Intanagonwiwat et al., 2005]
• Features+ Broader coverage of applications than DB-approach– Require effort on compilers
• To produce efficient code
Research Exam: Ryo Sugihara 382006/06/22
Regiment
• Purely functional macroprogramming language– No direct manipulation of program state– Benefit: Easier to extract parallelism
• Idea– Individual nodes are represented as data “streams”
• Change continuously over time– “Regions” are groupings of these streams
• Correspond to “continuous data from group of nodes”– Program operates over these streams and regions
• Translated into node-level actions
• Example: Tracking Object
[Newton & Welsh, 2004][Newton, Morrisett, Welsh, 2007]
• A region is created that represents the value of the proximity sensor on every node in the network
• Each value is also annotated with the location of the corresponding sensor.
• Data items that fall below the threshold are filtered out from the region.
• The spatial centroid of the remaining collection of sensor values is computed to determine the approximate location of the object that generated the readings
let aboveThresh (p,x) = p > threshold read node = (read_sensor PROXIMITY node, get_location node)in centroid (afilter aboveThresh (amap read world))
Research Exam: Ryo Sugihara 392006/06/22
SpatialViews
• Space-aware programming language– Extension to Java– Programming = defining “SpatialViews” and “Spatial View Iterators”
• “SpatialView” – = Collection of “virtual nodes” indicated by services and locations– “Virtual nodes” = programming abstraction for a physical node
• Bound to a physical node within a “space x time” region• Single physical node can be multiple virtual nodes in different space/time
• “Spatial View Iterator”– To discover/access virtual nodes in the SpatialView– Program is migrated to each node and executed
[Ni, Kremer, Stere, & Iftode, 2005]
spatialview sv1 = Camera @ CampusB % 100;
visiteach x : sv1 { Picture p=x.getPicture(); ... }
Spatial View IteratorSpatialView definition
Rectangle CampusB = new Rectangle(...);
public interface Camera { public Picture getPicture(); ...} Service definition
Location definition
Space granularity
Research Exam: Ryo Sugihara 402006/06/22
Evaluation of Macroprogramming• Energy-efficiency
– DB: Hidden• Achieved by query processor
– Lang: Hidden• Not easy to realize (by compilers)
– Programmers can describe arbitrary collaborations (diff. from Group-level)
• Failure-resilience– DB: Hidden
• Query processor handles failure silently• Users don’t have ways to add failure-resilience mechanism
– Lang: Exposed, with support• Iterator access, dynamic binding• Programmers can describe how to handle failures
• Collaboration– DB: Hidden
• Query processor uses collaboration in execution plans– Lang: Exposed, with support
• Naming schemes provided• Programmers can describe arbitrary collaborations
Research Exam: Ryo Sugihara 412006/06/22
Outline• Background
• Requirements from Applications
• Programming Models for Sensor Networks– Taxonomy– Approach 1: Node-level programming – Approach 2: Group-level programming– Approach 3: Macroprogramming
• Evaluation
• Future Research Directions
• Conclusion
Research Exam: Ryo Sugihara 422006/06/22
Evaluation (Summary)
• In terms of the applications’ requirements– Efficiency– Failure-resilience– Collaboration
Level of abstraction Efficiency Failure-resilience Collaboration
Node-levelExposed
with limited support
Exposed
with limited support
Exposed
with no support
Group-level
Mostly hidden
Exposed
with support
Exposed
with supportMacro-programming DB Hidden Hidden
Research Exam: Ryo Sugihara 432006/06/22
Evaluation (per Application)
• Per each type of programming models
• Evaluate aptitude for each type of applications
Level of abstraction
Type of Applications
Pro ConData Collection
Collaborative Info. Proc.
Node-level + - Most flexible Complex
Group-level + ++ Better handling of collaboration
Macro-programming
+ +Suitable for general applications
Hard to realize efficiency
DB ++ - Ease of useNarrow coverage of applications
Research Exam: Ryo Sugihara 442006/06/22
Evaluation (per Application)
• Data Collection appl.+ Database approach is most suitable and simple
• Provides easy-to-use interface
+ Others are OK, too• Sufficient for simple data collection
Level of abstraction
Type of Applications
Pro ConData Collection
Collaborative Info. Proc.
Node-level + - Most flexible Complex
Group-level + ++ Better handling of collaboration
Macro-programming
+ +Suitable for general applications
Hard to realize efficiency
DB ++ - Ease of useNarrow coverage of applications
Research Exam: Ryo Sugihara 452006/06/22
Evaluation (per Application)
• Collaborative Information Processing appl.+ Group-level abstraction is good
• Good balance of usefulness and efficiency
+ Macroprogramming lang is OK• Can be problematic when
efficiency requirement is tight
– Node-level PM leads to complexity• No support for communication
– DB lacks flexibility to implement arbitrary collaboration algorithms
• Limited kinds of collaboration– e.g.) Aggregation
Level of abstraction
Type of Applications
Pro ConData Collection
Collaborative Info. Proc.
Node-level + - Most flexible Complex
Group-level + ++ Better handling of collaboration
Macro-programming
+ +Suitable for general applications
Hard to realize efficiency
DB ++ - Ease of useNarrow coverage of applications
ex.) Tracking appl. (based on centroid)– Node-level
• 369 lines in nesC[*]
– Group-level• 134 lines in Abstract Regions[*]
– Macroprogramming• 6 lines in Regiment[**]
[*] [Welsh & Mainland, 2004][**] [Newton & Welsh, 2004]
Simpler
Simpler, butwith efficiencyconcern
Research Exam: Ryo Sugihara 462006/06/22
Outline• Background
• Requirements from Applications
• Programming Models for Sensor Networks– Taxonomy– Approach 1: Node-level programming– Approach 2: Group-level programming– Approach 3: Macroprogramming
• Evaluation
• Future Research Directions
• Conclusion
Research Exam: Ryo Sugihara 472006/06/22
Future directions
• Heterogeneity
• Strict QoS support
• Support for multiple applications / users
Research Exam: Ryo Sugihara 482006/06/22
Heterogeneity• More and more heterogeneity
• Need PMs to exploit heterogeneity– Macroprogramming languages
• Resource naming scheme – cf.) Generic role assignment [Frank & Römer, 2005]
• Using declarative role specification language• Separate role assignment and programming
Multiple types of sensors
Sensor-actuator networks
Hierarchical architecture
Logical heterogeneity
HW
SW
Research Exam: Ryo Sugihara 492006/06/22
Generic Role Assignment
• Enables automatic assignment of– Special functions/roles to nodes in the network– Using programmer-specified rules for assignment
• In declarative specification language
• Partly address logical heterogeneity– No support for “programming” stage, currently
[Frank & Römer, 2005]
Clustering
ch slave gw
(Figures courtesy of C. Frank)
CLUSTERHEAD :: {battery >= 60% &&count(1 hop) {
role == CLUSTERHEAD} == 0 }
GATEWAY :: {chs == retrieve(1 hop, 2) {
role == CLUSTERHEAD} &&count(2 hops) {
role == GATEWAY &&chs == super.chs
} == 0 }SLAVE :: else
Role specifications
•No other clusterhead within 1-hop from clusterhead
•Two clusterheads within 1-hop from gateway
Research Exam: Ryo Sugihara 502006/06/22
Strict QoS Support• QoS is prevalent
– Trade-off between energy-efficiency and various qualities such as
• Accuracy, Latency, Error rate etc.– ... and energy is precious
• QoS is an integral element in WSN appls– Poor QoS can ruin the appls
• e.g.) Detect an earthquake and warn for Tsunami.......latency?
• PMs should support QoS– Abstract Regions: low-level control knobs
• Indirect, not in applications’ context: e.g.) #retransmission
– MiLAN, DSWare: explicit QoS support• Subjective and/or qualitative definition of QoS
– Need for more objective, quantitative QoS support• Controllable in each application’s context
Research Exam: Ryo Sugihara 512006/06/22
cf.) Accuracy-aware Data Gathering
• Approximate data gathering with user-specified accuracy
– Using planes and “explicit points”• Fit planes to approximate the data• “Explicit points” = Data points not
approximated by planes
• Efficient– Distributed algorithm to construct
the representation
• Exploits energy-efficiency trade-off– Smaller data size when accuracy re
quirement is loose
• Works as a general mechanism for strict QoS support
– Not requiring any assumptions on statistical property of data
270
272
274
276
278
280
282
284
38.839.039.239.439.639.840.040.240.4
-92.2-92.0-91.8-91.6-91.4
-91.2
-91.0
270
272
274
276
278
280
282
284
38.839.039.239.439.639.840.040.240.4
-92.2-92.0-91.8-91.6-91.4
-91.2
-91.0
Accuracy requirementLoose requirement
12 Planes49 Explicit pointsData size: 392.57 byte
4 Planes13 Explicit pointsData size: 119.82 byte
(Sensor #: 155)
Tight requirementAccuracy requirement
Te
mp
era
ture
(K
)
Te
mp
era
ture
(K
)
5.0 5.1
[Sugihara & Chien, 2005, 2006]
Research Exam: Ryo Sugihara 522006/06/22
Multiple Applications / Users• Increasing need for accommodating multiple applications / users simult
aneously– Single sensor can provide multiple info
• e.g.) Breakbeam: detect vehicle, measure speed, ...– Users’ interests can be diverse
• e.g.) Traffic count, control speeding, ...• by using same/overlapping set of sensors
• Implication to PM: Isolation vs. integration– Isolation for security– Integration for efficiency
• SNACK: “Service weaving”– SNACK compiler merges duplicate nesC components to reduce the size of compiled cod
e• But more dynamically
• cf.) Sensor-actuator networks– Multiple appls may issue contradicting requests to (shared) actuators
• e.g.) room temperature control: heat or cool– Appls may need to compromise to each other
• by relaxing the requirements– CAhoot [Lin, Gupta, 2009], Hotline [Lin et al., 2009]
• Programming support • Appls can specify the actions in case there is a conflict with other appls
Research Exam: Ryo Sugihara 532006/06/22
Outline• Background
• Requirements from Applications
• Programming Models for Sensor Networks– Taxonomy– Approach 1: Node-level programming– Approach 2: Group-level programming– Approach 3: Macroprogramming
• Evaluation
• Future Research Directions
• Conclusion
Research Exam: Ryo Sugihara 542006/06/22
Conclusion• Analyzed WSN applications to figure out their requirem
ents and implications to PMs– Energy-efficiency– Failure-resilience– Collaboration
• Built a taxonomy of PMs according to the level of abstraction– Node-level – Group-level– Macroprogramming
• Evaluated each type of PMs– in terms of the applications’ requirements
• Discussed future direction of research in PMs for WSNs
Research Exam: Ryo Sugihara 552006/06/22
BACKUP
Research Exam: Ryo Sugihara 562006/06/22
Directed Diffusion
• Communication among group of nodes that share interest– i.e. “Data-centric dissemination”– Sink (base-station) publishes “interests”– Source (sensor) publishes “event”– Propagation is facilitated when gradient is large
• Gradient is assigned to each edge
• Reinforcement-based adaptation– Successful paths are reinforced
• Realizes energy-efficient & robust dissemination
[Intanagonwiwat, Govindan & Estrin, 2000]
Research Exam: Ryo Sugihara 572006/06/22
Group-level PM vs. Macroprogramming
Group-level PM Macroprogramming
Local group View Whole network
Bottom-up“Me and my neighbor”
Def. of group
Top-down(“Node A and its neighbor”)
• Macroprogramming may contain Group-level PM– e.g.) Kairos provides “get_neighbor()” operation
Research Exam: Ryo Sugihara 582006/06/22
4. Tools• Related to PM
– Help development– Complementary to
programming models
• Tools– Simulators
• TOSSIM [Levis et al., 2003]
– Runs TinyOS code• Avrora [Titzer et al., 2005]
– Software environment• Suite of library, tool, services
– EmStar [Girod et al., 2004]
• Runtime debugging support– Sympathy [Ramanathan et al., 2005]
» Diagnosis tool to localize the failure source at runtime– Marionette [Whitehouse et al., 2006]
» Allow debugger access to node at runtime» Seamlessly span a program between PC and sensor node
Programming models
Node-level Group-level Macroprogramming
OS / Node-level Programming Language
Virtual MachineNeighborhood-based
groupLogical group Database
Macroprogramminglanguage
Mate/ASVMVMStarImpalaSensorWareSOS
TML
Abstract RegionsHood
Directed DiffusionEnviroTrack
RegimentKairos
Spatial ProgrammingSpatialViewsDRN
Semantic Streams
CougarTinyDBSINAMiLANDSWare
TinyOS/nesCSNACKTinyGALST2OSM
Programming models
Node-level Group-level Macroprogramming
OS / Node-level Programming Language
Virtual MachineNeighborhood-based
groupLogical group Database
Macroprogramminglanguage
Mate/ASVMVMStarImpalaSensorWareSOS
TML
Abstract RegionsHood
Directed DiffusionEnviroTrack
RegimentKairos
Spatial ProgrammingSpatialViewsDRN
Semantic Streams
CougarTinyDBSINAMiLANDSWare
TinyOS/nesCSNACKTinyGALST2OSM
Tools
SimulatorSoftware
environment
TOSSIMAvrora
EmStarMarionetteSympathy
Tools
SimulatorSoftware
environment
TOSSIMAvrora
EmStarMarionetteSympathy
Tools
Simulators Software Environment
TOSSIMAvrora
EmStarMarionetteSympathy
Research Exam: Ryo Sugihara 592006/06/22
TinyOS
• Implemented by nesC• Event-based programming model• Set of components
– Rather than monolithic OS– Abstract hardware– Layering of components: “Command” and “Event”
• Services provided such as:– RF messaging– Periodic timer events– Asynchronous access to UART data transfers– Mechanism for static, persistent storage
[Hill, Szewczyk, Woo, Hollar, Culler & Pister, 2000]
Research Exam: Ryo Sugihara 602006/06/22
OLD SLIDES
Research Exam: Ryo Sugihara 612006/06/22
Programming Models• “Programming models”
– “An abstract conceptual view of the structure and operation of a computing system” (from “Getting Up To Speed: The Future Of Supercomputing”, National Academic Press, 2005)
– Our interpretation: • “Sophisticated view/method/framework that facilitates design and pro
gram WSN applications and underlying software”
– Programming constructs, abstractions• Represented in programming languages / language extension
• Why are programming models important for WSNs?– Programmers need software support
• Too many things to care about: efficiency, unreliableness..• Appropriate PM can let programmers focus on application logic
– Many new algorithms for sensor network applications• Due to unique assumptions and requirements• Appropriate PM can facilitate implementing them
Research Exam: Ryo Sugihara 622006/06/22
Requirements from WSN applications
• Energy-efficiency– Nodes must run for months only with battery
• Failure-resilience– Appls should be functional even after failures (n
ode, sensors, communication, ..)
• Collaboration– Appls often need collaborative info. processing– “Localized algorithms” [Estrin et al., 1999] preferred
• = Info. processing inside the network • Also applicable to data collection applications
– In-network aggregation / summarization / ...
and their implications to programming models
• PMs should be accompanied with compilers/tools that generate efficient code
• PMs should provide ways to control energy-efficiency
• PMs should provide ways to handle failures gracefully
• PMs should provide ways to describe localized algorithms easily
Research Exam: Ryo Sugihara 632006/06/22
Taxonomy of PMs for WSNs
Programming models
Node-level Group-level Macroprogramming
OS / Node-level Programming Language
Virtual MachineNeighborhood-based
groupLogical group Database
Macroprogramminglanguage
Mate/ASVMVMStarImpalaSensorWareSOS
TML
Abstract RegionsHood
Directed DiffusionEnviroTrack
RegimentKairos
Spatial ProgrammingSpatialViewsDRN
Semantic Streams
CougarTinyDBSINAMiLANDSWare
TinyOS/nesCSNACKTinyGALST2OSM Liu et al. (State-centric)
Tools
SimulatorSoftware
environment
TOSSIMAvrora
EmStarMarionetteSympathy
• Three major approaches– Node-level programming model– Group-level abstraction– Macroprogramming
Research Exam: Ryo Sugihara 642006/06/22
1-1. OS / Node-level Language
• Earliest and still prevalent approach
• Event-driven component-based programming– nesC [Gay et al., 2003] / TinyOS [Hill et al., 2000]
• de facto standard
– Some enhancements on nesC / TinyOS• Easier concurrency management
– TinyGALS [Cheong et al., 2003]
• Reusable service library – SNACK [Greenstein et al., 2004], T2 [Levis et al., 2005] (TinyOS ver.2)
• State machine– OSM (Object State Model) [Kasten & Römer, 2005]
• Different action for a single event according to the current state
Research Exam: Ryo Sugihara 652006/06/22
Summary of Node-level PM
• OS / Node-level programming languages+ Flexible+ Low overhead– Complex
• Not for end-users– nontechnical people
– non-CS researchers
• Virtual Machines+ Reprogrammable on runtime– Performance issue
• interpreter-based
Research Exam: Ryo Sugihara 662006/06/22
2-2. Logical Group• Defined according to high-level logical properties
– Not only topological/geographical proximity– e.g.) interests of node, sensor input
• Examples– Directed Diffusion [Intanagonwiwat et al., 2000]
• Data-centric dissemination mechanism• Communication within a group of nodes that share interests
– EnviroTrack [Abdelzaher et al., 2004]
• Data-centric group definition for tracking application– cf.) Node-centric group definition in Abstract Region / Hood
• Group of sensors that detected the same event
• Closer to application’s logic than system’s logic– Data-centric approach
target
“Group”
target
cf.) Abstract Regions
Research Exam: Ryo Sugihara 672006/06/22
Summary of Group-level abstraction
• Neighborhood-based group+ Suitable for implementing “localized algorithms”+ Good balance of efficiency & usefulness
• Logical group+ Closer to application logic
Research Exam: Ryo Sugihara 682006/06/22
Summary of Macroprogramming
• Database+ Intuitive, easy-to-use– Limited coverage of applications
• Applicable to the appls that query• Not expressive enough to describe collaboration
• Macroprogramming language+ Broader coverage of applications– More burden on compiler
• Especially problematic when efficiency requirement is tight
Research Exam: Ryo Sugihara 692006/06/22
Energy-efficiency
• Node-level– Mostly exposed, with limited support
• Implementation totally left to programmers– Some support efficient code generation
• SNACK: service weaving• VMStar: incremental linking
• Group-level, macroprogramming– Mostly hidden
• Achieved by runtime environments– Some explicitly allow fine-grained tunings
• Abstract Regions: low-level control knobs (e.g. #retransmission, timeout, etc.)• BBQ [Deshpande et al., 2004]: tolerable errors and confidence in SQL query
Level of abstraction Efficiency Failure-resilience Collaboration
Node-levelExposed
with limited support
Exposed
with limited support
Exposed
with no support
Group-level
Mostly hidden
Exposed
with support
Exposed
with supportMacro-programming DB Hidden Hidden
Research Exam: Ryo Sugihara 702006/06/22
Failure-resilience
• Node-level– Exposed, with limited support
• Implementation totally left to programmers– Node failures are difficult to handle
• Group-level, macroprogramming (except DB)– Exposed, with support
• Abstract Regions, Hood: caching other nodes’ data• SpatialViews, DRN: iterator access to nodes
• Database– Hidden
• MiLAN, DSWare: incorporate failures into quality calculation
Level of abstraction Efficiency Failure-resilience Collaboration
Node-levelExposed
with limited support
Exposed
with limited support
Exposed
with no support
Group-level
Mostly hidden
Exposed
with support
Exposed
with supportMacro-programming DB Hidden Hidden
Research Exam: Ryo Sugihara 712006/06/22
Collaboration
• Node-level– Exposed, with no support
• Usually difficult to implement
• Group-level, macroprogramming (except DB)– Exposed, with support
• Abstract Regions: data sharing, reduction
• Database– Hidden
• Declarative queries only• Query processors devise collaborative execution plans
Level of abstraction Efficiency Failure-resilience Collaboration
Node-levelExposed
with limited support
Exposed
with limited support
Exposed
with no support
Group-level
Mostly hidden
Exposed
with support
Exposed
with supportMacro-programming DB Hidden Hidden
Research Exam: Ryo Sugihara 722006/06/22
Future directions
• Applications’ viewpoint– Heterogeneity– Interactiveness– Strict QoS support
• Systems’ viewpoint– Support for multiple applications / users– Ubiquitous deployment
• Software engineering viewpoint– “Refinement”
Research Exam: Ryo Sugihara 732006/06/22
Interactiveness
• More dynamic interaction needed– Collect preliminary data and later modify sensor behavior– Closer look of interesting phenomena– Unexpected events requiring human decision
• Need two things for interactiveness– Low-latency communication– Reprogrammability
• VM-based approach
• PMs should provide a way to specify the requirements for latency and other constraints
Research Exam: Ryo Sugihara 742006/06/22
Ubiquitous deployment• Sensors are installed in advance
– For more general use on-demand• Shared infrastructure
– Not for specific application
• Need– Resource allocation scheme
• Resource request– Resource specification
• Naming scheme
• Implications to PMs– Reprogrammability– Declarative approach
• Automatically figure out necessary set of resources according to the application’s objective
Research Exam: Ryo Sugihara 752006/06/22
“Refinement”
• For iterative development
• Repeat– Prototyping– Refine the logic and parameters
• Need PMs to allow refinement– OSM
• Hierarchical composing of state machine– SNACK, T2
• Reusable services for rapid prototyping– VM-based approach
• Reprogrammability• VMStar: incremental linking
top related