1. Xiong Junjie Node-level debugging based on finite state machine in wireless sensor networks

2. Debugging in WSN 2 Outline Current debugging research TinyOS and nesC overview Motivation Methods & Challenges

3. Debugging in WSN 3 Outline Current debugging research TinyOS and nesC overview Motivation Methods & Challenges

4. Debugging in WSN 4 Passive Diagnosis for Wireless Sensor Networks (Sensys2008) Propose PAD, a passive diagnosis approach for inferring the root causes of abnormal phenomena. PAD includes diagnosis information in the regular application data packet by employing a marking algorithm. Therefore, it does not incur additional traffic overhead for collecting desired information. Disadvantages: this networking diagnosis method can only piggyback selected and limited networking logs back to the base station, and it takes further effort to detect and find bugs from the logs.

5. Debugging in WSN 5 Passive Distributed Assertions (PDA) for Sensor Networks (IPSN2009) PDA allows a programmer to formulate assertions over distributed node states using a simple declarative language, causing the sensor network to emit information that can be passively collected and evaluated to verify that assertions hold.

6. Debugging in WSN 6 Passive Distributed Assertions (PDA) for Sensor Networks (IPSN2009) Disadvantages: no principle for where to insert assertions, no automation for inserting assertions

7. Debugging in WSN 7 Outline Current debugging research TinyOS and nesC overview Motivation Methods Challenges

8. Debugging in WSN 8 TinyOS and nesC TinyOS is an operating system designed to target limited-resource sensor network nodes TinyOS 0.4, 0.6 (2000-2001) TinyOS 1.0 (2002): first nesC version TinyOS 1.1 (2003): reliability improvements, many new services TinyOS 2.0 (2006): complete rewrite, improved design, portability, reliability and documentation TinyOS and its application are implemented in nesC, a C dialect: nesC 1.0 (2002): Component-based programming nesC 1.1 (2003): Concurrency support nesC 1.2 (2005): Generic components, “external” types

9. Debugging in WSN 9 TinyOS in a nutshell System runs a single application OS services can be tailored to the application’s needs These OS services include timers, radio, serial port, A/D conversion, sensing, storage, multihop collection and dissemination, … Application and services are built as a set of interacting components using a strictly non-blocking execution model –event-driven execution, most service requests are split-phase Implementation based on a set of OS abstractions tasks, atomic with respect to each other; interrupt handlers resource sharing and virtualisation, power management hardware abstraction architecture

10. Debugging in WSN 10 nesC in a seashell C dialect Component based all interaction via interfaces connections (“wiring”) specified at compile-time generic components, interfaces for code reuse, simpler programming Reduced expressivity no dynamic allocation no function pointers Supports TinyOS’s concurrency model must declare code that can run in interrupts atomic statements to deal with data accessed by interrupts data race detection to detect (some) concurrency bugs

11. Debugging in WSN 11 Outline Current debugging research TinyOS and nesC overview Motivation Methods & Challenges

12. Debugging in WSN 12 Motivation Components and Interfaces Programs built by writing and wiring components –Modules: we write some components in C –Configurations: we wire the above components Components interact via interfaces only –Each component contains only two kinds of functions: command & event –event-driven execution The execution mode is event-driven Therefore, I can use finite state machine to check the workflow of a single node. However, it is difficult to implement the FSM mechanism in programs written in other languages.

13. Debugging in WSN 13 Outline Current debugging research TinyOS and nesC overview Motivation Methods & Challenges

14. Debugging in WSN 14 Methods & Challenges To debug the workflow of a single node program For each component –Draw state transition diagram. –Write state transition and check function for the component. –Insert the state check function at the beginning of each event function. –Insert the state transition function at the end of each event function. –How to automate the process? For a program that contains multiple components –Combine the state transition diagram of the components (how?).

15. Debugging in WSN 15 Methods & Challenges Example: for a static multi-hop routing component with firing period 30ms Base station Watch data of node 2 Finite state diagram of the program downloaded into a sensor node

16. Debugging in WSN 16 Methods & Challenges To debug the workflow of a single node program The developer should be the one writing such checking code based on the specification, the advantages are: –The effort is not high, and the component can be reused. –Can detect bugs in time without sending too much information. –Help locate bugs by watching the workflow. Sometimes, not passing certain path in the state transition diagram is a bug. –How to detect such bug? By statistics?

17. Debugging in WSN 17 Some Typical Devices mica2 (2002) 8MHz ATmega128 4kB RAM, 128kB flash 512kB external flash 20kb/s custom radio many different sensor boards 2 AA batteries: –radio+cpu: 75mW –sleep mode: 140μW telosb (2004) 1MHz TI MSP430 10kB RAM, 48kB flash 512kB external flash 250kb/s 802.15.4 radio built-in sensors 2 AA batteries: –radio+cpu mode: 63mW –sleep mode: 30 μW lifetime: a few days to several years

18. Debugging in WSN 18 Diagnosing Node-Level Faults in Remote Wireless Sensor Systems (Mobisys2007) Aim to find faults: stack overflow, deadlock and livelock Methods: insert checkpoints and assertions Disadvantages: no principle for where to insert checkpoints and assertions, no automation for insertion, implemented on Mantis OS (not TinyOS)