1 / 75

Sensor Network Programming

2009/11/05. for CSE237B. Sensor Network Programming. Ryo Sugihara ryo@ucsd.edu. About today’s talk. I’ll talk about programming models for sensor networks High-level overview NOT about hands-on experience or development tips Based on the presentation for my research exam in 2006

anais
Download Presentation

Sensor Network Programming

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 2009/11/05 for CSE237B Sensor Network Programming Ryo Sugihara ryo@ucsd.edu

  2. About today’s talk • I’ll talk about programming models for sensor networks • 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 Research Exam: Ryo Sugihara

  3. 2006/06/22 Research Exam: Programming Models for Sensor Networks Ryo Sugihara Computer Science and Engineering UC San Diego ryo@ucsd.edu

  4. Wireless Sensor Networks (WSNs) • 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 Tmote Sky MSP430 microcontroller (16bit RISC, 8MHz, 10kB RAM, 48kB Flash) 250kbps radio, 1Mb ext storage Humidity, Temperature, and Light sensors Research Exam: Ryo Sugihara

  5. Programming Models • “Programming models” • An abstraction of the target machine that a programmer uses 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 needs, 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 Research Exam: Ryo Sugihara

  6. 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 Research Exam: Ryo Sugihara

  7. 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 Research Exam: Ryo Sugihara

  8. 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 Research Exam: Ryo Sugihara

  9. “Data Collection” Applications • “Data collection” type • Collect data to the center • Users are interested in sensor data itself Great Duck Island (2002-) Habitat monitoring GlacsWeb (2003-) Glacial movement ZebraNet (2002-) Habitat monitoring Wisden (2004-) Structural Health Monitoring Research Exam: Ryo Sugihara

  10. proximity sensor IDSQ (2001) Information-driven sensor querying VigilNet (2004-) Surveillance target Trilateration Vehicle monitoring (2006) “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 “Tracking” appl Research Exam: Ryo Sugihara

  11. Requirements from WSN applications and their implications to programming models • Energy-efficiency • Nodes must run for months only with battery • Failure-resilience • Appls should be functional even after failures (node, sensors, communication, ..) • Collaboration • Appls often need collaborative info. processing • Also applicable to data collection applications • In-network aggregation / summarization / ... • 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 Research Exam: Ryo Sugihara

  12. 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 Research Exam: Ryo Sugihara

  13. 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 level 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 Research Exam: Ryo Sugihara

  14. Taxonomy of PMs for WSNs • Three major approaches • Node-level programming • Group-level programming • “Macroprogramming” Research Exam: Ryo Sugihara

  15. Taxonomy of PMs for WSNs “Program a node” “Program a group” “Program the whole” Different viewpoint Research Exam: Ryo Sugihara

  16. 1. Node-level Programming • Node-level programming • Program each node’s behavior • Assumption: Node efficiency is the top priority • Low overhead Research Exam: Ryo Sugihara

  17. 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 Research Exam: Ryo Sugihara

  18. C-based language Component-based programming Event-based execution model Two types of components “module” functional unit “configuration” set of modules wired together StdControl Timer StdControl Timer TimerM Clock Clock HWClock TimerC StdControl Timer TimerM Clock nesC (1/2) [Gay, Levis, von Behren, Welsh, Brewer & Culler, 2003] module TimerM { provides { interface StdControl; interface Timer; } uses interface Clock; } ... implementation { ... command result_t StdControl.init() { ... } ... } configuration TimerC { provides { interface StdControl; interface Timer; } } implementation { components TimerM, HWClock; StdControl = TimerM.StdControl; Timer = TimerM.Timer; TimerM.Clock -> HWClock.Clock; } 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 definition Module definition Research Exam: Ryo Sugihara

  19. 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 Research Exam: Ryo Sugihara

  20. SNACK (1/4) [Greenstein, Kohler, & Estrin, 2004] • Sensor Network Application Construction Kit • Configuration language • Reusable service library • Compiler Research Exam: Ryo Sugihara

  21. SNACK (2/4) • Combine parameterized “services” • Similar to nesC configuration • Ranged parameter to facilitate “service weaving” (later) tree1, tree2 :: my RoutingTree(period < 20000); SenseLight(period < 10000) -> [collect] tree1; SenseTemp(period < 10000) -> [collect] tree2; “services” Application programming in SNACK Research Exam: Ryo Sugihara

  22. SNACK (3/4) • Generic services are provided by SNACK library • Separation of “application programmers” and “service programmers” 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 into Components Research Exam: Ryo Sugihara

  23. SNACK (4/4) • “Service weaving” • Merge compatible components • Automatically by SNACK compiler • Reduce the size of code Research Exam: Ryo Sugihara

  24. 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] Research Exam: Ryo Sugihara

  25. Maté / ASVM [Levis & Culler, 2002], [Levis, Gay & Culler, 2005] • Application specific virtual machine • Expose new programming primitives by using application-specific 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) Research Exam: Ryo Sugihara

  26. Maté Build Process Appl-specific VM Compile code to custom instruction set Appl program in “tscript” etc. Users select these three things From Philip Levis, "Rapid and Safe Programming of In-situ Sensor Networks“, Qualifying examination proposal, Jan 2004. Research Exam: Ryo Sugihara

  27. 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 programmers • Reusable service libraries (SNACK, T2) can be helpful • VM-approach has a different goal • Reprogrammability Research Exam: Ryo Sugihara

  28. 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 Research Exam: Ryo Sugihara

  29. d topological geographical 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 Research Exam: Ryo Sugihara

  30. Abstract Regions [Welsh & Mainland, 2004] • 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, ...) Research Exam: Ryo Sugihara

  31. Choose leader node Create a region Read proximity sensor Compute centroid as an estimate of target location Put data as shared variables ex.) Tracking appl. in Abstract Regions • No need for explicitly describing communication among sensor nodes within a region 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); } 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); Research Exam: Ryo Sugihara

  32. “Group” cf.) Abstract Regions target target 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 Research Exam: Ryo Sugihara

  33. 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 Research Exam: Ryo Sugihara

  34. 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 Research Exam: Ryo Sugihara

  35. 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 Research Exam: Ryo Sugihara

  36. TinyDB [Madden, Franklin, Hellerstein, & Hong, 2003] • 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 • 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 SELECTAVG(volume), room FROM sensors WHERE floor = 6 GROUP BY room HAVINGAVG(volume) > threshold SAMPLE PERIOD 30s Research Exam: Ryo Sugihara

  37. 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 Research Exam: Ryo Sugihara

  38. Regiment [Newton & Welsh, 2004][Newton, Morrisett, Welsh, 2007] • 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 • 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)) Research Exam: Ryo Sugihara

  39. Rectangle CampusB = new Rectangle(...); public interface Camera { public Picture getPicture(); ... } Location definition Service definition Space granularity SpatialViews [Ni, Kremer, Stere, & Iftode, 2005] • 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 visiteach x : sv1 { Picture p=x.getPicture(); ... } spatialview sv1 = Camera @ CampusB % 100; SpatialView definition Spatial View Iterator Research Exam: Ryo Sugihara

  40. 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 Research Exam: Ryo Sugihara

  41. 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 Research Exam: Ryo Sugihara

  42. Evaluation (Summary) • In terms of the applications’ requirements • Efficiency • Failure-resilience • Collaboration Research Exam: Ryo Sugihara

  43. Evaluation (per Application) • Per each type of programming models • Evaluate aptitude for each type of applications Research Exam: Ryo Sugihara

  44. Evaluation (per Application) • Data Collection appl. • Database approach is most suitable and simple • Provides easy-to-use interface • Others are OK, too • Sufficient for simple data collection Research Exam: Ryo Sugihara

  45. 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 Simpler ex.) Tracking appl. (based on centroid) • Node-level • 369 lines in nesC[*] • Group-level • 134 lines in Abstract Regions[*] • Macroprogramming • 6 lines in Regiment[**] Simpler, but with efficiency concern [*] [Welsh & Mainland, 2004] [**] [Newton & Welsh, 2004] Evaluation (per Application) Research Exam: Ryo Sugihara

  46. 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 Research Exam: Ryo Sugihara

  47. Future directions • Heterogeneity • Strict QoS support • Support for multiple applications / users Research Exam: Ryo Sugihara

  48. 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 Hierarchical architecture HW SW Sensor-actuator networks Logical heterogeneity Research Exam: Ryo Sugihara

  49. agg sink src gw ch slave on off Coverage Aggregation Clustering Generic Role Assignment [Frank & Römer, 2005] • 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 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 • No other clusterhead within 1-hop from clusterhead • Two clusterheads within 1-hop from gateway Role specifications (Figures courtesy of C. Frank) Research Exam: Ryo Sugihara

  50. 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 Research Exam: Ryo Sugihara

More Related