Sensor Network Programming Ryo Sugihara [email protected] 2009/11/05 for CSE237B.

Sensor Network Programming

Ryo Sugihara

[email protected]

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 [email protected]

Research Exam:

2006/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


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


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

　


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





• Evaluation


• Conclusion


“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


“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


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





• Evaluation


• Conclusion


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


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”



Programming models






“Program a node” “Program a group” “Program the whole”

Different viewpoint


Programming models


OS / Node-level Programming Language





TML



RegimentKairos


Semantic Streams


TinyOS/nesCSNACKTinyGALST2OSM

Programming models







TML



RegimentKairos


Semantic Streams



Tools

SimulatorSoftware

environment

TOSSIMAvrora

EmStarMarionetteSympathy

Tools

SimulatorSoftware

environment

TOSSIMAvrora


1. Node-level Programming

• Node-level programming– Program each node’s behavior

• Assumption: Node efficiency is the top priority– Low overhead

Node-level


Virtual Machine

Maté/ASVMVMStarImpalaSensorWareSOS

TML



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


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


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


SNACK (1/4)[Greenstein, Kohler, & Estrin, 2004]

• Sensor Network Application Construction Kit– Configuration language– Reusable service library– Compiler


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


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”


SNACK (4/4)

• “Service weaving”– Merge compatible components

• Automatically by SNACK compiler

– Reduce the size of code


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]


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]


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.


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


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







TML



RegimentKairos


Semantic Streams



Programming models







TML



RegimentKairos


Semantic Streams



Tools

SimulatorSoftware

environment

TOSSIMAvrora


Tools

SimulatorSoftware

environment

TOSSIMAvrora


Group-level

Neighborhood-basedgroup

Logical group


EnviroTrack

Liu et al. (State-centric)


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


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]


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


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


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


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







TML



RegimentKairos


Semantic Streams



Programming models







TML



RegimentKairos


Semantic Streams



Tools

SimulatorSoftware

environment

TOSSIMAvrora


Tools

SimulatorSoftware

environment

TOSSIMAvrora


Macroprogramming

DatabaseMacroprogramming

Language

RegimentKairos



Semantic Streams


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


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


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


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))


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


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




• Programming Models for Sensor Networks– Taxonomy– Approach 1: Node-level programming – Approach 2: Group-level programming– Approach 3: Macroprogramming

• Evaluation


• Conclusion


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


Exposed

with no support

Group-level

Mostly hidden

Exposed

with support

Exposed

with supportMacro-programming DB Hidden Hidden


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



• Data Collection appl.+ Database approach is most suitable and simple

• Provides easy-to-use interface

+ Others are OK, too• Sufficient for simple data collection







Macro-programming






• 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







Macro-programming




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





• Evaluation


• Conclusion


Future directions

• Heterogeneity

• Strict QoS support

• Support for multiple applications / users


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


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


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


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]


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





• Evaluation


• Conclusion


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


BACKUP


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]


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


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







TML



RegimentKairos


Semantic Streams



Programming models







TML



RegimentKairos


Semantic Streams



Tools

SimulatorSoftware

environment

TOSSIMAvrora


Tools

SimulatorSoftware

environment

TOSSIMAvrora


Tools

Simulators Software Environment

TOSSIMAvrora



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]


OLD SLIDES


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


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



Programming models







TML



RegimentKairos


Semantic Streams


TinyOS/nesCSNACKTinyGALST2OSM Liu et al. (State-centric)

Tools

SimulatorSoftware

environment

TOSSIMAvrora


• Three major approaches– Node-level programming model– Group-level abstraction– Macroprogramming


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


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


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


Summary of Group-level abstraction

• Neighborhood-based group+ Suitable for implementing “localized algorithms”+ Good balance of efficiency & usefulness

• Logical group+ Closer to application logic


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


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


Node-levelExposed


Exposed


Exposed

with no support

Group-level

Mostly hidden

Exposed

with support

Exposed



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


Node-levelExposed


Exposed


Exposed

with no support

Group-level

Mostly hidden

Exposed

with support

Exposed



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


Node-levelExposed


Exposed


Exposed

with no support

Group-level

Mostly hidden

Exposed

with support

Exposed



Future directions

• Applications’ viewpoint– Heterogeneity– Interactiveness– Strict QoS support

• Systems’ viewpoint– Support for multiple applications / users– Ubiquitous deployment

• Software engineering viewpoint– “Refinement”


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


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


“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

Sensor Network Programming Ryo Sugihara [email protected] 2009/11/05 for CSE237B.

Documents

Transcript of Sensor Network Programming Ryo Sugihara [email protected] 2009/11/05 for CSE237B.