Wireless Sensor Networks (WSN): Open Source Tools

1. Wireless Sensor Networks (WSN): Open Source Tools

2. Outline • Introduction to WSN • TinyOS – An Open Source OS for WSN • nesC – An Open Source Programming Language for WSN • Issues related to Open Source WSN Simulators • Application Tools for WSN • Possible Enhancements

3. Introduction to WSN

4. WSN: What is it ?

5. WSN: “motes”

6. WSN: What is it for ?

7. WSN: What is it for ?

8. Operating Systems TinyOS YATOS Contiki MANTIS SOS Programming Languages Assembly C Giotto Esterel Lustre Signal E-FRP nesC WSN: Open Source Tools • Simulators • NS-2 • TOSSIM • Avrora • NCTUns • OMNET++ • J-Sim • Ptolemy • Application Tools • Localization Tools • TinyDB • Surge • TOSBase

9. WSN: Open Source ToolsMost Popularly Adopted by the Research Communities around the World • Operating System • TinyOS • Programming Language • nesC • Simulators • NS-2 • TOSSIM • Application Tools (Commonly used) • Localization Tools • TinyDB

10. TinyOS

11. Component-2 Component-1 Component-7 Challenges in Designing Architecture • Account for future designs • Hardware diversity • WSN are application specific • Component-Oriented architecture Component-1 Component-2 An Application Component-5 Component-3 Component-6 Component-4 OS Component-7

12. Challenges in Process Management • High concurrency but limited resources • Conventional thread-driven approach is resource intensive • TinyOS event-driven concurrency model • high concurrency with low overhead • events (interrupts) • run-to-completion • tasks • run-to-completion • atomic with respect each other • task queue and scheduler • no blocking • split-phase operations • Synchronization • Relies on the static analysis phase of the compilation

13. Challenges in Storage Management • Memory management • No MMU on sensor hardware !!! • No virtual memory !!! • Physical address binding • program execution on a mote • No memory protection • Safe programming • File Systems • Conventional file systems are resource consuming • TinyOS MatchBox

14. Challenges in Network Management • Conventional network protocols are heavy for tiny sensor nodes • Real-Time requirements • Reliability in radio reception • Networked nodes send events • Active messaging network stack • No end-to-end communication • Ad hoc network formation • Sensor node failures • Multihop Networking

15. Challenges in Upgrading Software on Deployed Sensor Nodes • Generally WSN are of very high node density (some thousands of nodes) • Nodes may be physically inaccessible after being deployed • TinyOS On-Air Programming (Small RAM footprint – 150 bytes) • Multihop support • Store multiple program images • Support for heterogeneous networks • CRC’s • Epidemic propagation • Deluge • NetProg • TOSBoot

16. TinyOS Power Management • Power is valuable resource – Save as much as possible • Role of TinyOS scheduler in power management • Imperative power management interface • HPLPowerManagement component • Low-power power-save mode of the TinyOS timer • Radio power management – specific to underlying MAC/PHY layer standards • Managing the power of sensor devices

17. nesC: Language for WSN

18. Why nesC ? • Why not conventional programming languages ? • Programming for WSN is hard !!! • No support for the demands of Wireless Sensor Networks • No support for Component-Oriented program design • Fails to capture event-driven execution • Provides little help in writing safe code

19. nesC: Component-Oriented Programming Style • Why not Object-Oriented approach ? • nesC is an extension of C • nesC components • Module • Configuration Example

20. nesC: Captures Event-Driven Execution • nesC supports and reflects TinyOS event-driven concurrency model • Primitives to specify event handlers • Bidirectional interfaces • Commands • Events • Simplifies event flow • Supports a flexible hardware/software boundary • Parameterized interfaces • Primitives to handle tasks • task • post • nesC support for Atomicity (Synchronization) • Atomic sections Example

21. nesC: Support for Writing Safe Code • nesC is a static language • No dynamic memory allocation ( malloc( ) ) • No function pointers • nesC static analysis (Whole-program analysis) • Compile-Time data race detection module SurgeM { … } implementation { bool busy; async event void ADC.dataReady(uint16_t sample) { // From interrupt if (!busy) { //  Concurrent state access busy = TRUE; //  Concurrent state access } } … } Mail

22. Mail from Philip Levis (Designer of nesC)pal@cs.stanford.edu There's a difference between malloc() and dynamic allocation. nesC does not forbid dynamic memory allocation: there's nothing stopping you from writing a component that allocates a pool of memory and has dynamic allocation interfaces. Take a look at TinyAlloc, for example. nesC does, however, frown on malloc, for the reasons described in the above mail. Modern coding styles generally assume unbounded memory, in as much that you have swap space so will see tremendous performance degradation before the system crashes. General application behavior on allocation failure is to exit(2) and therefore deallocate everything. With a processes, multitasking, and automatic page reclamation, this works fine. But on an embedded system with no memory protection, well, it's not so clean. Part of the issue is that while dynamic allocation among a set of cooperating components can work fine (e.g., TinyDB, Ben Greenstein UCLA's work on signal processing), dynamic allocation between arbitrary components (a single shared pool) is a recipe for disaster. One bad component can bring the entire system down, as the shared resource breaks inter-component isolation. The reason why nesC frowns on function pointers is because they are dangerous and except for a few edge cases (e.g., dynamically linking new binary modules), unnecessary. You know the call graph at compile-time. Instead of storing a function pointer in memory, which could be corrupted and lead you to jump to certain doom, you can just use a parameterized interface and call based on a function ID. This also gives you type checking for the functions It is more robust, just as easy (once you get used to it), and generally uses less RAM (no need to store the pointer). Function pointers are a basic result of C's linking model. nesC's linking model does not have the same complications (interfaces are bidirectional), so you can avoid them.

23. nesC/TinyOS: Example Program BlinkM.nc module BlinkM {  provides {    interface StdControl;  }  uses {    interface Timer;    interface Leds;  }}implementation {command result_t StdControl.init() {    call Leds.init();    return SUCCESS;  }command result_t StdControl.start() {    return call Timer.start(TIMER_REPEAT, 1000) ;  }command result_t StdControl.stop() {    return call Timer.stop();  }event result_t Timer.fired()  {    call Leds.redToggle();    return SUCCESS;  }} Blink.nc configuration Blink {}implementation {components Main, BlinkM, SingleTimer, LedsC;  Main.StdControl -> BlinkM.StdControl;  Main.StdControl -> SingleTimer.StdControl;  BlinkM.Timer -> SingleTimer.Timer;  BlinkM.Leds -> LedsC;} Back

24. Open Source Simulators for WSN

25. Issues related to Open Source WSN Simulators • Importance of simulation in WSN • Concerns about methodology and assumptions • Idealized hardware • Simplified protocols • Non-realistic radio models • Limits of scalability • Worse scale problems • Propagation computations • Computations of interference • Location updates caused by node mobility • PADS (Parallel and Distributed Simulation) “accuracy and detail versus performance and scalability”

26. Issues related to Open Source WSN Simulators • Environment modeling • Better represented in continuous-time domain • Which data are fed to the nodes ? • Which nodes receive these data ? • How do nodes interact with these data ? • Energy modeling • Far from describing the real hardware behavior • CPU power consumption is often neglected • Protocol stack and Application layer issues • Cross-layer interdependencies must be handled efficiently • Mathematical abstractions for simulated layers • Reduces processing power and simulation run time.

27. Issues related to Open Source WSN Simulators • Simulation Frameworks • Classical network simulation frameworks • Specific WSN simulation frameworks • Classical network simulation frameworks • NS-2, NCTUns, OMNET++, J-Sim, Ptolemy fall into this category • Advantages • Availability of ready-to-use models • Powerful scripting support • Clear and extensible interfaces and graphical support • Disadvantages • Protocol implementation is quite different from a real one • No support for new communication paradigms (data or location centric)

28. Issues related to Open Source WSN Simulators • Specific WSN simulation frameworks • TOSSIM and Avrora fall into this category • Advantages • Targets overall system test • Goal is to achieve high level of fidelity • Simulates at bit level • The use of native source code • Disadvantages • High fidelity reduces scalability • Bit level simulation degrades performance

29. Open Source Application Tools for WSN

30. WSN: Application Tools • Localization Tools • VU Acoustic Ranging • TOF based • Minimal hardware requirements • Average error of distance estimation is below 10cm • Relatively limited range (About 10m) • The effects of echoes and obstructions are not adequately handled • IISc In-Ranging • An iterative approach • Relies only on the basic communication capability of sensor nodes • Not very accurate but reliable

31. WSN: Application Tools • TinyDB • Reflects traditional query processing systems • Distributed AQP (Acquisitional Query Processor) • Acquisitional techniques to reduce power consumption • Ability to select, join, project, and aggregate • Interleaving query processing with local computations • Acquisitional techniques to reduce power consumption • Quantitative analysis for aggregation

32. Possible Enhancements • Implementation of IEEE 802.15.4 in nesC/TinyOS • Environment Modeling in TOSSIM and NS-2 • Enhancement of nesC to flexibly support Multi-client services • Think of threaded model in nesC/TinyOS • Memory management in TinyOS • Use of accurate mathematical abstractions in WSN simulators • Think of new Synchronization approach in nesC/TinyOS • Modeling of CPU power consumption in NS-2

33. Questions ?