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

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



Motivation


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



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



Motivation


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



Motivation


Debugging in WSN14


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


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


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)

Documents

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