Xiong Junjie
Node-level debugging based on finite state machine in wireless
sensor networks
Debugging in WSN2
Outline
Current debugging research
TinyOS and nesC overview
Motivation
Methods & Challenges
Debugging in WSN3
Outline
Current debugging research
TinyOS and nesC overview
Motivation
Methods & Challenges
Debugging in WSN4
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.
Debugging in WSN5
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.
Debugging in WSN6
Passive Distributed Assertions (PDA) for Sensor Networks (IPSN2009)
Disadvantages: no principle for where to insert assertions, no automation for inserting assertions
Debugging in WSN7
Outline
Current debugging research
TinyOS and nesC overview
Motivation
Methods
Challenges
Debugging in WSN8
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
Debugging in WSN9
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
Debugging in WSN10
nesC in a seashellC 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
Debugging in WSN11
Outline
Current debugging research
TinyOS and nesC overview
Motivation
Methods & Challenges
Debugging in WSN12
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.
Debugging in WSN13
Outline
Current debugging research
TinyOS and nesC overview
Motivation
Methods & Challenges
Debugging in WSN14
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?).
Debugging in WSN15
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
Debugging in WSN16
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?
Debugging in WSN17
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
Debugging in WSN18
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)