1 / 50

SensorWare: A Framework for Efficient and Programmable Sensor Networks

SensorWare: A Framework for Efficient and Programmable Sensor Networks. Athanassios Boulis, Chih-Chieh Han, Mani B. Srivastava EE Dept. UCLA. Presented by Jia Xu CS Dept. UVa Nov 11, 2003. Outline. Contributions Introduction Problem SensorWare’s approach to address this problem

gray-pena
Télécharger la présentation

SensorWare: A Framework for Efficient and Programmable Sensor Networks

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. SensorWare:A Framework for Efficient and Programmable Sensor Networks Athanassios Boulis, Chih-Chieh Han, Mani B. Srivastava EE Dept. UCLA Presented by Jia Xu CS Dept. UVa Nov 11, 2003

  2. Outline • Contributions • Introduction • Problem • SensorWare’s approach to address this problem • SensorWare Details • Language • Run-time Environment • Portability & Expandability • Addressing & Routing • Code Examples • Implementation & Evaluation • Comparison & Related work • Conclusion

  3. Roadmap • Contributions • Introduction • SensorWare Details • Code Examples • Implementation & Evaluation • Comparison & Related work • Conclusion

  4. Contributions • A script environment for dynamic programming WSNs in a proactive and efficient way • Code mobility through script replication & migration • Good support for portability and extensibility • Admission Control & Policing of Resource Usage to make scripts stay under their resource contract

  5. Roadmap • Contributions • Introduction • SensorWare Details • Code Examples • Implementation & Evaluation • Comparison & Related work • Conclusion

  6. Wireless Ad-hoc Sensor Network

  7. Programming Paradigms for WSNs • How to write/debug/test/reuse programs on WSNs? • Challenges: • Constraints (energy, computation, storage, bandwidth) • Individuals are trivial, programming as an aggregate • The aggregate is often a changing set • Dynamically deploy algorithms • Meet real-time, security, reliability requirements How does one dynamically deploy different algorithms into the network?

  8. Workarounds • Hard-coded algorithms tunable through the transmission of parameters • Not applicable to the wide variety of possible apps. • Download executable images into the nodes • Nodes could be physically unreachable or reachable at a very high cost. • Transfer the executable images into nodes • Energy inefficient (communication cost) • Cannot allow the sharing of the WSN by multiple users.

  9. Basic questions • How to express the algorithms? • How to dynamically deploy them? SensorWare employs lightweight and mobile control scripts that are autonomously populated in sensor nodes after a triggering user injection.

  10. Scriptable Environment Define: Basic Building Blocks Basic commands Examples : Send packet to the radio Get data from sensing device

  11. Examples: Flow control Variable support Expression evaluation Scriptable Environment How do you bind many basic commands into an algorithm? You need a language core! (glue commands)

  12. Scriptable Environment Send packet • Access radio • Find route • Check energy • Queue packet Abstracted high-level description of an algorithm Low-level tasks performed by our system

  13. Make Scripts Mobile Script can populate/migrate Scripts move NOT due to explicit user instructions, but due to node’s state and algorithmic instructions Language + Run-time Environment = SensorWare

  14. User can inject script Architecture Message exchanging Apps, Services Apps, Services Scripts Scripts Code migration SensorWare SensorWare OS OS HW abstraction layer HW abstraction layer Hardware Hardware Sensor node 1 Sensor node 2

  15. SensorWare vs Mate • They share the same goal: make a WSN dynamically programmable in an efficient manner • Both are two-level abstraction • Both support code mobility Question: what are the similarities so far?

  16. SensorWare vs Mate • Mate is for motes, e.g., 128KB PM, 4KB RAM; while SensorWare targets richer platforms like 1MB PM, 128K RAM • Mate is on TinyOS; SensorWare is on Linux • Mate is a stack-based architecture with ultra-compact instruction set; SensorWare builds scripts based on basic blocks • No concurrent apps in one mote; SensorWare supports multi-tasking • SensorWare’s scripts are more powerful than Mate’s capsules Question: what are the differences so far?

  17. Roadmap • Contributions • Introduction • SensorWare Details • Code Examples • Implementation & Evaluation • Comparison & Related work • Conclusion

  18. Language Extensions to the core The glue core The basic script interpreter (stripped-down Tcl) Radio API Timer API Sensor 1 API Mobility API waitcommand idcommand Sensor 2 API GPS API Optional modules  . . . . . .

  19. Script Mobility API • spawn <node_list> <script> {variable_name}* • replicate < node_list > {variable_name}* • migrate < node_list > {variable_name}* < node_list > : destination node addresses variable_name : a variable name to be passed along with its value to the new script. An advantage over Mate: it supports both replicateand migrate There is a question Mate doesn’t answer: how the nodes cooperate in code population and how does this process end?

  20. Replicate • First, the parent is assumed to already have the code for the script • Second, send out “intention to replicate” • Third, if the same script already exists, choose: • Not to transfer the code • Initiate a second script of the same type • “add-user” for this script if supporting multi-user • In addition, you need to explicitly specify the replication node list If you leave node list empty, what happens? Flooding? When does it ends?

  21. Initialization Exit code Event handler a Event handler b Event handler a Event handler c Event-based Programming a? Zzz c? wait for event a or b or c code b? Example a? Zzz a? Zzz c? b?

  22. Event-based Programming • Achieved through the wait command • Examples of events: • Reception of a message of a given format • Traversal of a threshold for a given sensing device reading • Filling of a buffer with sensing data of a given sampling rate • Expiration of several timers More events supported than Mate • Is it implemented by the OS or by SensorWare? • When an event handler is running, can the system respond to another event? • Should the system idle or can go on with the event handler running aside as another thread?

  23. Run-time Environment: Tasks Resource Abstraction & Resource Metering Tasks Fixed tasks Platform specific Radio/Networking Timer service Script Manager (script state keeping, spawns new scripts) Sensor 1 Sensor 2 Admission Control & Policing of Resource Usage Paging radio . . .

  24. Special Tasks • Script Manager • Accepts spawning requests • Forwards the request to the Admission Control • If pass, initiates a new thread/task running a script interpreter for the new script • Keeps script-related state info • Admission Control & Policing • Make sure that the scripts stay under their resource contract, and checks the overall energy consumption How the Admission Control is implemented is in another paper [4].

  25. Resource Abstraction & Metering Tasks • Every platform is assumed to have at least one radio and a timer service • Radio • Accepts requests from the scripts about the format of network messages • Dispatches messages to appropriate scripts • Measure the radio utilization for each script • Timer • Provides many virtual timers relying on one timer provided by the system

  26. Queue Run-Time Environment Resource metering info Device related permanent Script related Admission control Script Manager event interest in event Radio thread system msg. Radio Script 1 OS thread . . . Sensing Sensor HW access code Script n Timer Service

  27. Portability and Expandability • Capabilities variability, i.e., having different modules, such as sensing devices, GPS • HW/SW variability, i.e., having different OS and/or specifics of hardware devices

  28. Dealing with Capabilities Variability Define and support virtual devices • Almost everything in SensorWare is a device • Radio, Sensing(magnetometer, accelerometer) • Battery, Timer service • Localization procedure, neighborhood discovery • Devices are registered • Unified interface presented to the scripts • 4 commands: act,query, createEventID, disposeEventID

  29. Dealing with HW/SW variability • Abstract Wrapper Functions • Find OS dependencies and abstract them • Definition and creation of threads • Support for non-polling message passing • Find hardware dependencies and abstract them • send/receive packets/bits • set a real timer • set the sampling rate of a sensor

  30. Code Structure Changed with platform capabilities Never changed Platform independent code Device Definition code • Register all devices • Define functions for options parsing Script manager Tcl APIs Admission control Device 1 code Code dependency Device 2 code OS specific code • Definition of threads • Definition of msg passing HW access code Changed for porting

  31. Addressing • Generic format: • [nodes_specification.script_name.userID.appID] • For now, nodes_specification = node ID • Script_name: • Level_0_name.Level_1_name….Level_n_name • UserID • AppID • Denote the application that the particular instance of a script belongs to

  32. Routing • Need to support multiple and new routing protocols at SensorWare compile time • To achieve this • Define routing protocols as devices • Define a special device that gives scripts the ability to handle system-kept routing table to support application-level routing

  33. Roadmap • Contributions • Introduction • SensorWare Details • Code Examples • Implementation & Evaluation • Comparison & Related work • Conclusion

  34. Code Example: multi-user aggregation The first command tries to replicatethe script to all the neighbors, declaring that this is a multi-userscript. The nodes that the script wasspawned or an “add user” messagewas sent are returned and addedto the need_reply_from variable. For more details: http://www.ee.ucla.edu/~boulis/phd/Illustrations.html

  35. Code Example: multi-user aggregation The second command reads thecurrent value from the sensingdevice and sets the maxvaluevariable with it. For more details: http://www.ee.ucla.edu/~boulis/phd/Illustrations.html

  36. Code Example: multi-user aggregation If there are no nodes to return areply the script sends the maxvalueto the parent and exits. Otherwise the parent node is addedto the list return_reply_to and the loop begins. For more details: http://www.ee.ucla.edu/~boulis/phd/Illustrations.html

  37. Code Example: multi-user aggregation Each time a packet is received wecheck if it is a data reply or an “adduser” message and modify our listsand maxvalue accordingly. For more details: http://www.ee.ucla.edu/~boulis/phd/Illustrations.html

  38. Code Example: Porting to a platform • First, create a virtual device for the sensing device • Create_device(char* name, int (*query)(), int (*act)(), void* (*createEventID)(), int (*disposeEventID)(), void* (*task)()) • Second, define the OS-specific code to create threads and use mailboxes/queues

  39. Roadmap • Contributions • Introduction • SensorWare Details • Code Examples • Implementation & Evaluation • Comparison & Related work • Conclusion

  40. Implementation: Platform • iPAQ 3670 • Intel StrongARM 1110 rev 8 32bit at 206Mhz • 16Mbytes flash mem • 64Mbytes RAM mem • OS: v0.5 Linux StrongARM, kernel 2.4.18-rmk3 • Compiler: gcc • Radio: wavelan card • Sensing: Honeywell HMR-2300 Magnetometer

  41. Implementation: Memory Size Linux + TinyTcl = 80%

  42. Implementation: Delay measurement spawn(one hop) < spawn(local) + send (one hop) Lefttop: commands with less than 0.06 ms delay Righttop:most time consuming commands Leftbottom: delays of other special commands Overhead of real-time measurements: 0.25ms

  43. Roadmap • Contributions • Introduction • SensorWare Details • Code Examples • Implementation & Evaluation • Comparison & Related work • Conclusion

  44. Tradeoffs: native code vs. scripts Why not native code? What do we get with scripts? • Portability • Code safety + Capabilities-related • Slower execution • 8% slowdown for a typical app. • Compactness of code: • 209 bytes for a typical app • 764 bytes the equivalent native code • Transmitting and Executing native code is not beneficial overall - Energy-related + How about the Linux and Tcl code?

  45. Comparison (1)

  46. Comparison (2)

  47. Other Related Work • Active networking (e.g. PLAN at UPenn) • Similarities: scripting abstraction, weak mobility • packet-driven vs. event-driven • resource management through language design vs. through run-time mechanism • Reactive Sensor Networks (at PSU) • no scripting abstraction • code mobility is download oriented, no proactive • Sensor Querying and Tasking Language (Delaware) • no provisions for efficient algorithms • no diverse mobility rules • no code modularity • support for multi-user scripts • no resource management

  48. Roadmap • Contributions • Introduction • SensorWare Details • Code Examples • Implementation & Evaluation • Comparison & Related work • Conclusion

  49. Conclusion • Is it truly a programming paradigm? Not really in terms of programming abstraction, just a scriptable environment. • Does it meet all the WSN constraints? It can’t support mote-like equipments • Does it implement programming an aggregate which is a changing set? Yes. It supports proactive programming and code population • Can it meet real-time, security, reliability requirements? Code safety is supported. Real-time can be supported in a roughly way. Reliability is an open issue.

  50. Open Questions • How to define the scope of basic building blocks? (Efficiency vs Abstraction) • Is SensorWare appropriate for real-time applications? Security applications? • Is “general-purpose” programming paradigm really desirable?

More Related