Programming Sensor Networks Using Event-based Groups

336 views
274 views

Published on

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
336
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
12
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Programming Sensor Networks Using Event-based Groups

  1. 1. Programming Sensor Networks Using Event-based Groups James Horey UNC Systems Seminar March 20 2009
  2. 2. 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
  3. 3. 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) TelosB Mote ● Scale (tens → hundreds → thousands)
  4. 4. 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?”
  5. 5. 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?”
  6. 6. 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?”
  7. 7. 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
  8. 8. 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
  9. 9. Programming Models ● Current models are insufficient ● Programming-centric – Difficult to scale – 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 Magic – Too little focus on computation
  10. 10. Hierarchical Group Model ● Main idea: Computational tasks are assigned to distributed events – As opposed to a node-centric model – Events can be dynamic (nodes Results Tasks come and go) ● Separation of concerns: defining events versus assigning tasks ● Implement a wide range of applications ● Flexible implementation strategy
  11. 11. Hierarchical Group Model ● Main idea: Computational tasks are assigned to distributed events As opposed to a node-centric – model How to define events? How–to define and dynamic (nodes Events can be associate computation with events? Results Tasks What are the consequences of this model on communication? come and go) ● Separation of concerns: defining events versus assigning tasks ● Implement a wide range of applications ● Flexible implementation strategy
  12. 12. 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)
  13. 13. 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)
  14. 14. Kensho ● Provides API for communication and group Collective Computation operations event notification ● Defining Event-Groups data analysis Publish ● Defining Tasks Push ● Defining Communication Pre-processing Post-processing Functions Functions – Simplify by discouraging peer-to-peer compression aggregation communication – Local tasks publish to collective tasks Publish Push – Collective tasks push to local tasks – Messages go through processing steps Local Computation data filtering data sampling
  15. 15. Kensho ● Provides API for communication and group Collective Computation operations event notification Synchronization ● Defining Event-Groups data analysis Publish ● Defining Tasks Push ● Defining Communication Pre-processing Post-processing Functions Functions – Simplify by discouraging peer-to-peer compression aggregation communication – Local tasks publish to collective tasks Publish Collective tasks push to local tasks Barrier – – Messages go through processing steps Local Computation – Messages can also be synchronized at local data filtering and collective tasks data sampling
  16. 16. Simple Photometer Application ● Define local tasks init { local_barrier(barrier, timeout, options); // Synchronize all local tasks } body { for(;;) { dev_read(DEV_MSP_TSR, &photo, sizeof(uint16_t) ); // Read the photometer publish_data(group, “photo”, sizeof(uint16_t) ); // Send it to the collective task mos_thread_sleep(SAMPLING_PERIOD); // Sleep for a little while } } destructor { // Free up any allocated memory and send any last messages }
  17. 17. Simple Photometer Application ● Define local tasks ● Define collective tasks init { ... } body { for(;;) { // Get data published from local tasks collect_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 { ... }
  18. 18. 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 test return TRUE; // Join the group return FALSE; // Leave the group }
  19. 19. 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 group map_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 group printf(“Group size %dn”, group->members”); } }
  20. 20. 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
  21. 21. 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
  22. 22. 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
  23. 23. Pivot Tables ● 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
  24. 24. 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
  25. 25. 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
  26. 26. Specifying Functions ● Initially each sheet represents data from a single node ● Local functions – Use node sheet
  27. 27. 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
  28. 28. Defining Applications ● Example: centroid calculation ● Define set of local functions – Check proximity value of magnetometer ● Assign weighted position
  29. 29. 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
  30. 30. 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
  31. 31. 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
  32. 32. 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
  33. 33. 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?
  34. 34. 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?
  35. 35. Acknowledgments ● 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

×