PROGRAMMING MODELS FOR SENSOR NETWORKS: A SURVEY

Presented By:

Vasvi Kakkad

OUTLINE

Overview Problem Space Requirements Taxonomy of Programming Models Evaluation

OVERVIEW – SENSOR NETWORKS

Challenges Unreliable communication, faulty nodes,

extremely constrained resources

Application logic becoming more complex Failure-resilience, reprogrammability, poor

debugging environment

Requires sophisticated programming models to Make programming easy Full use of available resources

EXAMPLES Habitat Monitoring

Example – ZebraNet Project Very low duty cycle operations – Maximizes battery life

Environmental Monitoring Example – Long term glacial movement, temperature/

humidity in forest

Structural Health Monitoring Example – Analyze structural responses to forced

excitation High data rate and low latency

Tracking applications Example – Surveillance application Collaborative information processing among sensors

PROBLEM SPACE

REQUIREMENTS FOR WSN PROGRAMMING

Energy-efficiency

Scalability

Failure-resilience

Collaboration

TAXONOMY OF PROGRAMMING MODELS

NODE-LEVEL PROGRAMMING MODEL

TinyOS One of the most widely used

OS Written in nesC Component based – allows

modular programming

nesC Flexible Provides unified interface Level of abstraction – very

low Complex programming

OS/Node-Level Programming

nesC/TinyOS

TinyGALSSOSCoMOS

SNACKT2OSM

FiberMantis OSTinyThreadYThread

NODE-LEVEL PROGRAMMING MODEL

Asynchronous Message Passing TinyGALS (Globally Async, Locally

Sync) [2003]

Hybrid of event model and message passing model

Asynchronous FIFO queue

SOS – Synchronous OS [2005]

Uses priority queue

CoMOS – Component Messaging based OS [2006]

Uses message passing Message handling is preemptive

OS/Node-Level Programming

nesC/TinyOS

TinyGALSSOSCoMOS

SNACKT2OSM

FiberMantis OSTinyThreadY-Thread

NODE-LEVEL PROGRAMMING MODEL

Abstraction SNACK [2004]

Provides services same as configuration in nesC

Services – parameterized/ more reusable

T2 [2005] Telescoping abstraction Supports different hardware devices Platform independent

OSM – Object State Model [2005] Extends event-driven model with

states and transitions Support parallel composition Allows refinement of program

OS/Node-Level Programming

nesC/TinyOS

TinyGALSSOSCoMOS

SNACKT2OSM

FiberMantis OSTinyThreadY-Thread

NODE-LEVEL PROGRAMMING MODEL

Thread Abstraction Fiber [2004]

Light-weight concurrency model for TinyOS

Single blocking execution context Mantis OS [2005]

Preemptive, time-sliced multi-threading on MICA2 motes

TinyThread [2006] Multithread library for TinyOS

Y-thread [2006] Similar to Fiber, but preemptive Computation and control

behaviors Shared stack for non-blocking

computation

OS/Node-Level Programming

nesC/TinyOS

TinyGALSSOSCoMOS

SNACKT2OSM

FiberMantis OSTinyThreadY-Thread

NODE-LEVEL PROGRAMMING

Interpreter-based VM Mate/ASVM [2002/2005]

Stack-oriented Reduced size of assembly code Reduced communication

Melete [2006]

Extends Mate Supports multiple concurrent

application

VMStar [2005]

Allows dynamic update of system and application code

Virtual Machine /Middleware

Mate/ASVMMeleteVMStar

ImpalaSensorWare

TMLt-kernel

NODE-LEVEL PROGRAMMING

Re-programmability Impala [2003]

Middleware for ZebraNet project Modular, adaptability to dynamic

environments Easy and efficient on-the-fly

reprogramming

SensorWare [2003]

Tcl-based control scripts Designed for richer hardware

platform Supports multiple concurrent

users

Virtual Machine /Middleware

Mate/ASVMMeleteVMStar

ImpalaSensorWare

TMLt-kernel

NODE-LEVEL PROGRAMMING

Platform Independence TML – Token Machine Language

[2005] Uses DTM model Sends/receives tokens Executes associated token

handler Easier to implement higher level

programming construct

t-kernel [2006] OS kernel focuses on reliability Provides OS protection and

virtual memory at load time

Virtual Machine /Middleware

Mate/ASVMMeleteVMStar

ImpalaSensorWare

TMLt-kernel

HIGH-LEVEL PROGRAMMING – GROUP-LEVEL

Hides detail of communication Abstract Region [2004]

Groups are defined topologically, geographically or combinations

Provides way to tune trade-off between resource consumption and accuracy

Hood [2004] Uses one-hop neighbor for

group definition

Neighborhood-based Group

Abstract RegionHood

HIGH-LEVEL PROGRAMMING – GROUP-LEVEL

Defines group based on logical properties Type of nodes, dynamic input

from environment EnviroTrack [2004]

Programming abstraction Group – set of sensors that

detect same event Provides data sharing and

aggregation

SPIDEY [2006] Node is represented as logical

node with attributes Static – node type Dynamic – sensor readings

Logical Group

EnviroTrackSPIDEY

HIGH-LEVEL PROGRAMMING – NETWORK-LEVEL

Database

CougarTinyDBSINAMiLANDSWare

Cougar [2000]

Declarative SQL like language Pushes operation to sensor

TinyDB [2003]

Focuses on acquisition issues Optimizes routing tree

SINA [2000]

Allows more explicit tasking User can embed scripts written

in imperative language MiLAN [2004]

Provides QoS feature DSWare [2003]

Notion of compound event and supports real-time semantics

HIGH-LEVEL PROGRAMMING – NETWORK-LEVEL

Microprogramming Language

RegimentKairos

Spatial ProgrammingSpatialViewsDRN

Semantic StreamsSoftware Sensors

Global behavior Regiment [2007]

Functional language – syntax similar to Haskell

Hides direct data manipulation Can express group of nodes Programs compiled to TML

intermediate language then nesC

Kairos [2005]

Language independent Can be implemented as an

extension to existing programming language

Reduces communication overhead by eventual consistency

HIGH-LEVEL PROGRAMMING – NETWORK-LEVEL

Microprogramming Language

RegimentKairos

Spatial ProgrammingSpatialViewsDRN

Semantic StreamsSoftware Sensors

Resource Naming Spatial Programming [2004]

Resources referenced by physical location

Uses static binding

SpatialViews [2005]

Network of nodes named by services and locations

Dynamic binding

DRN – Declarative Resource Naming [2005]

More flexible

HIGH-LEVEL PROGRAMMING – NETWORK-LEVEL

Microprogramming Language

RegimentKairos

Spatial ProgrammingSpatialViewsDRN

Semantic StreamsSoftware Sensors

Other Abstractions Semantic Streams [2006]

Framework that allows declarative queries over semantic interpretation

Prolog-based implementation Automatic composition of

sensors and inference units

Software Sensor [2004]

Originates from SW engineering Supported by Sensor-Jini

middleware Provides lookup service to find

and bind application SW Sensor

EVALUATION

Energy-efficiency – 3 mechanism Caching, routing, in-network summarization

Abstract Region, Hood, EnviroTrack, and Kairos SPIDEY – efficient routing Database approaches

Control tradeoff with “quality” Abstract Region, TinyDB extension Semantic Stream

Efficient code update VM based approaches

EVALUATION

Scalability Cougar – pushes selection to sensors TinyDB Some macroprogramming languages

EVALUATION

Failure-resilience – 4 measures Redundancy; addressing by roles

Group-level abstraction

Caching Same as for energy-efficiency

Dynamic binding SpatialViews, DRN

Failure as “quality/confidence” assessment MiLAN, DSWare – failure treated as quality

degradation or added uncertainty

EVALUATION

Collaboration – 3 mechanisms Group definition

Group-level abstraction – Spatial programming, SpatialViews, DRN

Declarative Query Database approach

Resources as variable Some macroprogramming languages

FUTURE DIRECTION

Heterogeneity Support to multiple different type of sensors

Strict QoS Support Often too inefficient to collect high-quality data

Accuracy, latency, error rates Control tradeoff between energy and quality

THANK YOU!!!