Upload
peterbuck
View
241
Download
0
Tags:
Embed Size (px)
Citation preview
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?”
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?”
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)
Kensho● Provides API for communication and group
operations
● Defining Event-Groups
● 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)
Kensho● Provides API for communication and group
operations
● Defining Event-Groups
● 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
Kensho● Provides API for communication and group
operations
● Defining Event-Groups
● 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
}
Simple Photometer Application
● 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 { ... }
Simple Photometer Application
● Define local tasks
● Define collective tasks
● 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}
Simple Photometer Application
● Define local tasks
● Define collective tasks
● 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
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
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
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
● 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