Towards a Model Checker for NesC and Wireless Sensor Networks

1
Towards a Model Checker for NesC and Wireless
Sensor Networks
Manchun Zheng1, Jun Sun2, Yang Liu1, Jin Song
Dong1, and Yu Gu2
1 National University of Singapore 2 Singapore
University of Technology and Design
2
Background

• Wireless Sensor Network (WSN)
• Sensor code TinyOS applications (NesC programs).
• Wireless communication unicast,
• broadcast, dissemination, etc.
• Sensor device light, temperature,
• movement, etc.
• Applications
• Real-time transportation,
• medical device,
• military and security supervision,
• fire detection, etc.

3
Background

• TinyOS 1
• Widely used in WSN community
• Designed to run on small, wireless sensors.
• Lightweight operating system
• Concurrent, interrupt-driven execution model
• Component libraries for device-related operations

• D. Gay, P. Levis, D. E. Culler Software design
  patterns for TinyOS. ACM Trans.
• Embedded Comput. Syst. 6(4) 2007.

4
Background

• TinyOS
• Interrupt-driven Execution Model

5
Background

• NesC (Nested C) 2
• An extension of C
• Component-based programming model
• Concepts of command, event, tasks, etc
• Operations are split-phase

Are NesC implementations reliable?
2. D. Gay, P. Levis, J. R. von Behren, M. Welsh,
E. A. Brewer, D. E. Culler The nesC
language A holistic approach to networked
embedded systems. PLDI 2003 1-11
6
Motivation

• Traditional approaches
• Simulation TOSSIM 3
• Good to analyze the execution but unable to find
  an error/bug automatically.
• Testing/Debugging
• Able to find bugs but highly restricted by test
  cases
• Limitations
• Unable to find all errors/bugs of any possible
  scenarios
• e.g, the code shown in previous slides

3. P. Levis, N. Lee, M. Welsh, and D. E. Culler.
TOSSIM Accurate and Scalable Simulation
of Entire TinyOS Applications. In SenSys. ACM,
2003.
7
A motivating example

• Tricky code

result_t tryNextSend() atomic
if(!sendTaskBusy) post sendTask()
sendTaskBusy TRUE
...
1. The task sendTask() will be scheduled to
execute at a later time. 2. sendTaskBusy is reset
as FALSE in the task sendTask().
Is there any bug in this method?
task void sendTask() sendTaskBusy
FALSE
8
A motivating example

• Tricky code

result_t tryNextSend() atomic
if(!sendTaskBusy) post sendTask()
sendTaskBusy TRUE
...
If post sendTask() fails, the task will never be
executed, and thus sendTaskBusy remains TRUE
forever.
task void sendTask() sendTaskBusy
FALSE
YES!
9
A motivating example

• Tricky code
• Testing, simulating, debugging is difficult to
  reach the scenario when post sendTask() fails.
• Requires a technique that automatically explores
  all possible system states.

result_t tryNextSend() atomic
if(!sendTaskBusy) if(SUCCESS ! post
sendTask()) sendTaskBusy
FALSE else sendTaskBusy TRUE
...
result_t tryNextSend() atomic
if(!sendTaskBusy) post sendTask()
sendTaskBusy TRUE
...
10
Motivation

• Model Checking
• Determining whether a model satisfies a property
  by exhaustive searching.

Model Checker
e.g, ( sendTaskBusy ? ltgt!sendTaskBusy) Whenever
sendTaskBusy is true, it will eventually be reset
as false.
11
Our Approach

• A systematic self-contained model checker for WSN
• Generating LTS from NesC source code directly
• Supporting both safety properties liveness
  properties
• Conducting complete searching
• Buit as a the NesC module in PAT
• PAT (www.patroot.com) 4
• A self-contained framework for developing model
  checkers
• Supporting concurrent, real-time and
  probabilistic systems
• Simulation, Verification

4. Y. Liu, J. Sun, and J. S. Dong. Developing
Model Checkers Using PAT. In ATVA, pages 371-377,
Singapore, 2010. Springer.
12
PAT Architecture Design
NesC_at_PAT
13
Challenges

• Complex syntax and semantics of NesC
• No existent formal semantics of the NesC language
• Hardware services of TinyOS
• E.g., messaging, sensing, etc.
• The interrupt-driven execution model of TinyOS
• Introduces local concurrency between tasks and
  interrupts

14
NesC_at_PAT

• Features
• Fully automatic and domain-specific for NesC and
  WSNs
• Two levels of concurrency network and sensor
  levels
• Safety Liveness (temporal) properties
• E.g, A buffer is released infinitely often
• Low-level safety properties
• E.g, Access to a null pointer, array index
  overflow, etc.
• Contributions
• Define formal operational semantics for WSNs and
  NesC
• Fully automated, dealing with NesC code directly
• Verification of properties of a large range

15
NesC_at_PAT

• Overview

16
Formalization of WSNs

• Semantic Model of WSN
• Sensor Model
• WSN Model
• Operational Semantics
• NesC/C language Constructs
• Interrupt-driven Feature
• Networked Feature
• Concurrency
• Communication

17
Case study Trickle 5

• An algorithm
• Propagating and maintaining code updates in WSN
• Each node
• Periodically broadcasts its version to neighbors
• Stays quiet if it has received an identical
  version
• Broadcasts code if it has heard an older version

My code version is 5
I receive a same version, so I do nothing
A
5
I receives an older version, so I send my code.
5
B
7
C
5. P. Levis, N. Patel, D. E. Culler, S. Shenker
Trickle A Self-Regulating Algorithm for Code
Propagation and Maintenance in Wireless Sensor
Networks. NSDI 2004 15-28
18
Trickle

• Desirable Property
• If a node is reachable in the network, then it
  should always eventually be updated with the
  latest code.
• Code Structure of NesC Implementation
• Top-level configuration TrickleAppC.nc
• Implementation of Trickle TrickleC.nc

19
Verifying Trickle with NesC_at_PAT
Sensor1 Application TrickleAppC
Sensor2 Application TrickleAppC
Sensor3 Application TrickleAppC
20
Deploying WSNs

• Three topologies

Single-track Ring Ring Star

21
Verification Goals

• Definition of States
• Properties
• Safety Properties
• Temporal Properties (Liveness)

define FalseUpdate Sensor1.App.data 0 //0 is
the newest data. define UpdateA Sensor1.App.data
1 //1 is the newest data. define
UpdateB Sensor2.App.data 1 define UpdateC
Sensor3.App.data 1 define AllUpdate UpdateA
UpdateB UpdateC
assert SensorNetwork deadlockfree //default
property assert SensorNetwork never FalseUpdate
assert SensorNetwork ltgt (UpdateA UpdateB
UpdateC) Always eventually all three nodes
get updated.
22
Experimental Results
23
Experimental Results
The liveness property is violated by SRing WSN!
24
Buggy Scenario Single-tracked Ring
A
0
Never updated
0
1
C
1
Version channel
B
Code channel
Data link
25
Real execution on Iris motes

• Comparison with Real execution on Motes
• Trickle has been executed on Iris motes
• Three nodes, with the three topologies
• Single tracked ring, Ring, Star
• Videos

26
Discussion Future Work

• Scalability
• Reasons Two-level concurrency, complex behaviors
• Reduction Techniques partial order reduction,
  symmetry reduction, etc.
• Symbolic Model checking BDD encoding
• Timed Feature
• Currently, timed information is abstract
• Introduce a system timer without increasing the
  state space too much
• Large Case Study
• Collection Tree Protocol implementation (hundreds
  of components)

27
Thank you