1. 1 Software Reliability in Wireless Sensor Networks (WSN) -Xiong Junjie -2010.4.26

2. 2 Outline Motivation Recent Research Feasible Techniques and Challenges

3. 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. 4 Motivation The software architecture is implied in the hardware abstraction architecture (EWSN2005). Software Hardware

5. 5 Outline Motivation Recent Research Feasible Techniques and Challenges

6. 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. 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 =...; ”. ONEA pointer that always refers to a single object. ONE_NOKSame 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. 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. 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. 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. 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. 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. 13 Outline Motivation Recent Research Feasible Techniques and Challenges

14. 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. 15 Feasible Techniques RF is radio frequency

16. 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 Routing request to PC Routing Reply from node 8 with hop 4 Routing Reply from node 7 with hop 3 Routing Reply from node 6 with hop 2 Ask T to send to IUT

17. 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. 18 Thank you!