Programming Sensor Networks Using Event-based Groups

Programming Sensor Networks Using Event-based Groups

James Horey

UNC Systems SeminarMarch 20 2009

Roadmap

● Introduction to sensor networks

– Overview of technology and applications

● Simplifying programming

– Programming using event-based groups

– Tables: A user-friendly programming interface

● Future work

– Pervasive systems

– Smart grids

The Technology

● Sensor networks

– Wireless networks of small, programmable computers equipped with environmental sensors

● Thermistor, photometer, humidity, pressure, location, radiation ...

– Purpose: sense the environment, perform some communication and computation, derive some information

– Constraints● Form factor (10 kb memory, 1 MB flash, 8 mhz)● Poor communication (802.15.4, << 20 meters)● Power (double AA should last weeks months)→● Scale (tens hundreds thousands)→ →

TelosB Mote

Application Scenarios

● Data monitoring applications:

– “What is the temperature gradient in this space?”

● Event analysis applications:

– “Is there traffic congestion at this intersection?”

● Personal applications:

– “Is it raining at John's house?”















Research Problems

● Defined by constraints and applications

– Form factor (10 kb memory, 1 MB flash, 8 mhz)

– Poor communication (802.15.4, << 20 meters)

– Power (double AA should last weeks months)→

– Scale (tens hundreds thousands)→ →

● Research examples

– Designing systems (OS, VM, runtime) that fit in hardware constraints

– Network protocols (MAC, routing, transport) that provide low-overhead communication

– Programming environments (models, interfaces, languages) that help users create applications

– Efficient algorithms (Privacy, aggregation, classification) to solve application specific problems

Research Problems

● Defined by constraints and applications

– Form factor (10 kb memory, 1 MB flash, 8 mhz)

– Poor communication (802.15.4, << 20 meters)

– Power (double AA should last weeks months)→

– Scale (tens hundreds thousands)→ →

● Research examples

– Designing systems (OS, VM, runtime) that fit in hardware constraints

– Network protocols (MAC, routing, transport) that provide low-overhead communication

– Programming environments (models, interfaces, languages) that help users create applications

– Efficient algorithms (Privacy, aggregation, classification) to solve application specific problems

Programming Models● Current models are insufficient

● Programming-centric

– Difficult to scale

Magic

– Computation tightly coupled to physical implementation

– Too little focus on data

● Data-centric

– Query-based solutions (TinyDB, Cougar)

– Computation is inflexible (not Turing-Complete)

– Debugging opaque

– Too little focus on computation

Hierarchical Group Model

● Main idea: Computational tasks are assigned to distributed events

– As opposed to a node-centric model

– Events can be dynamic (nodes come and go)

● Separation of concerns: defining events versus assigning tasks

● Implement a wide range of applications

● Flexible implementation strategy

Tasks

Results

Hierarchical Group Model

● Main idea: Computational tasks are assigned to distributed events

– As opposed to a node-centric model

– Events can be dynamic (nodes come and go)

● Separation of concerns: defining events versus assigning tasks

● Implement a wide range of applications

● Flexible implementation strategy

Tasks

Results

How to define events?How to define and associate computation with events?What are the consequences of this model on communication?

Kensho● Provides API for communication and group

operations

● Defining Event-Groups

– “all nodes in the shadow”

– Each sensor node periodically evaluates admission function and determines group membership

– new_logical_group(adm_fn, sampling_schedule)


operations


● Defining Tasks

– Logical groups consist of multiple sensor nodes

– Local: act on data from each node

● Sampling and data filtering

– Collective: act on data from all group members

● Data fusion● Event notification

– map_{local, collective}(grp, init, body, destructor)


operations


● Defining Tasks

● Defining Communication

– Simplify by discouraging peer-to-peer communication

– Local tasks publish to collective tasks

– Collective tasks push to local tasks

– Messages go through processing steps

Pre-processing Functions

compression

Local Computation

data filteringdata sampling

Publ

ish

Collective Computation

event notificationdata analysis

Push

Post-processing Functions

aggregation

Push

Publ

ish


operations


● Defining Tasks

● Defining Communication

– Simplify by discouraging peer-to-peer communication

– Local tasks publish to collective tasks

– Collective tasks push to local tasks

– Messages go through processing steps

– Messages can also be synchronized at local and collective tasks

Pre-processing Functions

compression

Local Computation

data filteringdata sampling

Publ

ish

Collective Computation

event notificationdata analysis

Push

Post-processing Functions

aggregation

Barr

ier

Publ

ish

Sync

hron

izat

ion

Simple Photometer Application

● Define local tasksinit {

local_barrier(barrier, timeout, options); // Synchronize all local tasks}

body {for(;;) {

dev_read(DEV_MSP_TSR, &photo, sizeof(uint16_t) ); // Read the photometerpublish_data(group, “photo”, sizeof(uint16_t) ); // Send it to the collective taskmos_thread_sleep(SAMPLING_PERIOD); // Sleep for a little while

}}

destructor {// Free up any allocated memory and send any last messages

}


● Define local tasks

● Define collective tasks

init { ... }body {for(;;) {

// Get data published from local taskscollect_data(store, “photo”, min, synch_strategy, options);

. . .

// Send results of analysis back to local tasks.push_data(group, “analysis”, analysis, sizeof(analysis) );mos_thread_sleep(SAMPLING_PERIOD);

}}

destructor { ... }




● Define event-group

uint8_t in_the_light(admission_fn_args* arg){

dev_read(DEV_MSP_TSR, &photo, sizeof(uint16_t) ); // Read the photometer sensor

if(photo < THRESHOLD) // Simple shadow testreturn TRUE; // Join the group

return FALSE; // Leave the group}




● Define event-group

● Stitch everything together

int main(int argc, char** argv){

group = new_logical_group(&adm_fn, schedule); // Create a new groupmap_local(group, &local_task); // Assign the local task to the group map_collective(group, &collective_task); // Assign the collective task to the group

for(;;) {// Periodically print out the status of the groupprintf(“Group size %d\n”, group->members”);

}}

Multiple Implementations

● Host implementation

– Sensor nodes periodically transmits all sensor data

– All computation executes on basestation

– Ideal for dumb / legacy devices (aRFID, etc.)

● Tiered implementation

– Execute admission function and local tasks on sensor nodes

– Execute collective function on basestation

– Fewer message transmissions (active members vs. all nodes)

● In-network implementation

– Execute all computation on sensor nodes

– Work in progress: which nodes execute the collective tasks?

– Potentially fewest messages

Simpler Programming Interface

● Most sensor network users are not developers

– Domain specialists

– Casual users

● Tables: A spreadsheet-inspired programming environment for sensor networks

– Allow domain specialists to create their own applications in a friendly development environment

– Combine simplicity of Hierarchical Group model with spreadsheet actions

● Reduce number of actions to implement a program

– Organize data from the sensor network using interactive tools

– Specify local and collective functions

Tables Workflow● All sensor data continually

collected and stored

– On nodes for tiered implementation

● Users specify what data to view at any time

– Pivot tables

● Spreadsheet populated with data from the sensor network

● User specifies functions to operate on data

– Local and collective

● User requests updated data

● Miniature representation of the spreadsheet

– Query and organize data from sensor network

– Users click-and-drag items to the data and metadata panes

– Specify recurrence

● Data: data the user wants to view

● Row, Column: spatially organize the data

● Sheet: organize the data into logical sensor groups

● Sensor list is updated automatically as new data are assigned

Pivot Tables

Pivot Tables● Pivot table is compiled

and propagated to the sensor network

● Each sensor node responds to pivot table requests

– Transmits requested data along with metadata (time, node ID, etc.)

● Tables organizes data according to pivot table

Specifying Functions● Users need a way to do more than

simply viewing the data

● Users type in spreadsheet-like functions in empty cells

– Functions are data-driven

– Arithmetic, sum, average, conditional, assignment

– Assignment places new data in the relevant queue (accessed by pivot tables)

– No loops (functions are recursive)

● Two types of functions

– Local and collective

Specifying Functions● Initially each sheet represents

data from a single node

● Local functions

– Use node sheet

Specifying Functions● Initially each sheet represents

data from a single node

● Local functions

– Use node sheet

● Collective functions

– Drag items on Sheet axis

● Example: DETECTION produces two sheets: → DETECTION 0 and DETECTION 1

– Nodes in a sheet form a logical group

– Function collectively tasked for that group

● Collective functions execute on basestation

– Dependant data automatically published

Defining Applications● Example: centroid calculation

● Define set of local functions

– Check proximity value of magnetometer

● Assign weighted position





● Create pivot table to view ID of nodes with DETECTION = 1

– Creates two DETECTION sheets







● Define functions to average weighted positions







● Define functions to average weighted positions

● Construct a pivot table view the centroid locations

Multiple Implementations

● Both Host and Tiered (like Kensho)

– Opinion: users should prefer Host unless there is a compelling reason not to

● Automatically archives data in database, etc.● Online and Offline modes

– Online: all interaction performed in real time (good for testing)

– Offline: all interaction recorded and played back on devices later (transfer to other networks after testing)

● Work-in-Progress: constraints and aggregation in pivot tables

– Reduce message transmissions

Pervasive Systems

● Lots of cool hardware: iPhone, Android, Netbooks

– Better hardware, intermittent (but high-bandwidth) connections, better I/O

● What is an appropriate programming model for pervasive computing?

– Much more interaction with users

– Two dominant types of applications:● Context-centric: Users assign actions to contexts (eating lunch)● Data-centric: Users want to view and integrate data from many sources

– MVC is going in the right direction

– How to include web-based tools?

Smart Grids● Power sources + sensor networks + actuation

– Smart homes● Closing-the-loop: observed data == requested data + power input

– Sensor networks provide detailed observational data (heat throughout home) and detailed power consumption

● Optimization-and-control: Automatically control appliances to meet external constraints (power availability, total cost, etc.)

– Large-scale infrastructure● Limited power availability at any given time● Set of users that request power (over a period of time)● Schedule power over users so that users leave happy

– How much user interaction will there be?

● Special thanks: Mary Whitton

● Collaborators (RENCI)

– Rob Fowler

– Rick Skarbez

● Collaborators (NC State)

– Frank Mueller (FREEDM Center)● Collaborators (UNM)

– Arthur B. Maccabe

– Stephanie Forrest

– Wenbo He

Acknowledgments

Documents

Programming Sensor Networks Using Event-based Groups