1 / 28

Design and Implementation of a Framework for Efficient and Programmable Sensor Networks

This review outlines the design and implementation of SensorWare, a framework for efficient and programmable sensor networks. SensorWare uses lightweight mobile control scripts for dynamic deployment of algorithms on sensor nodes. The framework allows for scripting basic commands and high-level tasks, providing a flexible way to program and deploy algorithms on richer platforms. With a mobile scripting approach, SensorWare enables script migration based on node state and algorithmic instructions. The architecture includes various APIs and modules for sensor interaction, script management, resource metering, and more. SensorWare aims to make sensor networks dynamically programmable with efficient script execution.

gella
Download Presentation

Design and Implementation of 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. Design and Implementation of a Framework for Efficient and Programmable Sensor Networks Reviewed by: Saswati Swami

  2. Wireless Ad hoc Sensor Networks

  3. SensorWare • A framework for programming Sensor Networks using mobile control scripts • SensorWare employs lightweight and mobile control scripts that are autonomously populated in sensor nodes after a triggering user injection • SensorWare tackles --- How to express an algorithm for Sensor Networks --- How to dynamically deploy the algorithm • Overall provides a flexible way to program and deployalgorithms • Limited to richer platforms (1Mbyte of program memory and 128Kbytes of RAM)

  4. SensorWare Approach Make the node environment scriptable Examples : Define: Basic Building Blocks Basic commands Send packet to the radio Get data from sensing device

  5. SensorWare Approach Make the node environment scriptable How to bind many basic commands into an algorithm? A language core (glue commands) is needed. Examples: Flow control Variable support Expression evaluation A Script

  6. SensorWare Approach Make the node environment scriptable Send packet • Access radio • Find route • Check energy • Queue packet Abstracted high-level description of an algorithm Low-level tasks performed by our system

  7. SensorWare Approach Make scripts mobile Script can populate/migrate Scripts move NOT due to explicit user instructions, but due tonode’s state and algorithmic instructions Language + Run-time Environment = SensorWare

  8. An Example: Target Tracking User is notified for presence of target User reacts by injecting a tracking script

  9. An Example: Target Tracking Script migrates and populates into the area of interest User gets periodic updates of target location Scripts exchange information to compute target location

  10. An Example: Target Tracking As target moves, scripts are migrating User still is notified regularly

  11. SensorWare Architecture

  12. SensorWare Language Parts 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  . . . . . .

  13. Initialization Exit code Event handler a Event handler b Event handler c Event handler a SensorWare Programming Model a? Zzz c? wait for event a or b or c b? code Example a? Zzz a? Zzz c? b?

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

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

  16. SensorWare 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 Admission control APIs Device 1 code Code dependency Device 2 code OS specific code • Definition of threads • Definition of msg passing HW access code Changed for porting

  17. SensorWare Script API • replicate < node_list > {variable_name}* • migrate < node_list > {variable_name}* • wait <event_name> <event_data> <msg_sender/msg_body> • < node_list > : destination node addresses • variable_name : a variable name to be passed along with its value to the new script

  18. 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.

  19. 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 SensorWare Implementation Platform

  20. RSC nodes Medusa MK-2 SensorWare Implementation Platform

  21. SensorWare binary breakdown

  22. SensorWare Code size breakdown

  23. Execution Times of SensorWare Commands Commands with less than 0.06 ms delay

  24. Execution Times of SensorWare Commands Most time consuming commands

  25. Execution Times of SensorWare Commands Delays of other special commands

  26. SensorWare vs. Mate Similarities • They share the same goal: make a WSN dynamically programmable in an efficient manner • Both are two-level abstraction • Both support code mobility

  27. SensorWare vs. Mate Differences • 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

  28. Thank You

More Related