1

Software Reliability in Wireless Sensor Networks (WSN)

-Xiong Junjie-2010.4.26

2

Outline

Motivation Recent Research Feasible Techniques and Challenges

3

Motivation

Software Reliability is very important in WSNs. E.g., a bug in the flash driver of Deluge caused a three-day network-outage during a deployment on an active volcano.

Try to find as many bugs as possible before deployment. By simulation. By testbad.

4

Motivation The software architecture is implied in the hardware

abstraction architecture (EWSN2005).

Software

Hardware

5

Outline

Motivation Recent Research Feasible Techniques and Challenges

6

Recent Research (1) TOSSIM: Accurate and scalable simulation of entire

TinyOS applications (SenSys2003)

It is a well-known simulation environment for TinyOS. It works by replacing components with simulation

implementations. It supports simulation configuration file written with two

programming interfaces: Python and C++. To compile TOSSIM, execute command: make micaz sim

7

Recent Research (2) Safe TinyOS: Efficient memory safety for TinyOS

(SenSys2007) It catches all pointer and array bounds errors with the Deputy compiler. Deputy compiler enforces type and memory safety with several

annotations:

To compile a program in safe TinyOS, execute command: make micaz safe. E.g., after executing such command, line “message_t* msg = ...; ” in the compiled program will be changed to “message_t* ONE msg = ...; ”.

ONE A pointer that always refers to a single object .

ONE_NOK Same as ONE but may be NULL.

COUNT(n)  A pointer that always refers to a block of at least n objects.

COUNT_NOK(n)  Same as COUNT but may be NULL.

BND(n,m)  A pointer p such that n≤p<m, and that is aligned with respect to n and m.

… …

8

Recent Research (3) T-Check: Bug Finding for Sensor Networks (IPSN2010)

T-Check is developed to find bugs by simulation before deployment. It uses TOSSIM and Safe TinyOS, and adds non-deterministic events to

trigger corner case bugs. It is built on the model checker from paper “Detecting liveness bugs in

systems code” (NSDI2008): Depth-bounded explicit state model checking. Random walk exploration. Partial order reduction. Critical Transition Isolation.

It finds 10 safety bugs and 2 lives bugs in TinyOS 2.1.

9

Recent Research (4) KleeNet: Discovering Insidious Interaction Bugs in Wireless

Sensor Networks Before Deployment (IPSN2010)

KleeNet is a debugging environment that effectively discovers interaction bugs before deployment by injecting non-deterministic events. It is suitable for WSNs by extending Klee (a symbolic virtual machine built on top of the LLVM, OSDI2008): It uses symbolic execution to generate execution paths of

participating nodes at high-coverage. It injects symbolic, nondeterministic events (such as loss, duplication

and corruption of packets and node failures), and thus drive the sensor network execution into corner-case situations.

It detects four insidious bugs in the TCP/IP protocol stack of the Contiki OS.

10

Recent Research (5) Neutron: Surviving sensor network software faults

(SOSP2009)

Neutron is a version of the TinyOS operating system that efficiently recovers from memory safety bugs.

It divides programs into recovery units and reboot only the faulting unit. It is built on Safe TinyOS and TOSThreads (multi-threaded TinyOS in

SenSys2009).

11

Recent Research (6) FSMGen: Deriving State Machines from TinyOS Programs

using Symbolic Execution (IPSN2008)

TinyOS programs are low-level and thus difficult to understand, maintain, and debug. Deriving Finite State Machine (FSM) aids program understanding, error detection, and program validation.

FSMGen adopts symbolic execution. FSMGen employs a form of predicate abstraction on the resulting

information from symbolic execution, and generate a FSM.

12

Recent Research (7) PTFW: A Protocol Testing Framework for Wireless Sensor

Networks (IWCMC2009: AR47.5%)

It is a protocol testing framework for WSNs. It based on the layered architecture of WSNs. It uses FSM.

13

Outline

Motivation Recent Research Feasible Techniques and Challenges

14

Feasible Techniques

Simulation and testbed cannot find some bugs that appear in real deployment.

Testing with large amount of real sensor nodes is not efficient and practical.

It is efficient and feasible to develop a virtual testing environment with a few real sensor nodes and a few PCs, and make the testing closer to real deployment than simulation.

15

Feasible Techniques

RF is radio frequency

16

Feasible Techniques An example to test a shortest path routing.

Test case 1: PC wait for IUT’s routing request.

Test case 2: PC notices T to transmit several routing replies to IUT.

Routing request

Forward Routingrequest to PC

Routing Reply from node 8 with hop 4

Routing Reply from node 7 with hop 3

Routing Reply fromnode 6 with hop 2

Ask T to send to IUT

17

Challenges

Manipulate the Radio Frequency address. The transmitting module at the PC should be able to

communicate with the counterpart at the controlled transmitting node via serial port.

The receiving module at the PC should be able to communicate with the counterpart at the controlled receiving node via serial port.

API design for test case at any software level of sensor nodes.

Test case generation by FSM or other formalized models.

18

Thank you!