Towards a Model Checker for NesC and Wireless Sensor Networks Manchun Zheng 1, Jun Sun 2, Yang Liu...

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 Singapore2 Singapore University of Technology and Design

NUS Presentation Title 2006Towards a Model Checker for NesC and Wireless Sensor Networks

BackgroundBackground Wireless Sensor Network (WSN)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.


BackgroundBackground TinyOS [1]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

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


BackgroundBackground TinyOSTinyOS

Interrupt-driven Execution Model


BackgroundBackground NesC (Nested C) [2]NesC (Nested C) [2]

An extension of C Component-based programming model Concepts of command, event, tasks, etc Operations are split-phase

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

Are NesC implementations

reliable?


MotivationMotivation Traditional approachesTraditional approaches

Simulation: TOSSIM [3]

Good to analyze the execution but unable to find an error/bug automaticallyautomatically.

Testing/Debugging:

Able to find bugs but highly restricted by test cases Limitations:

Unable to find allall errors/bugs of anyany 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 ofEntire TinyOS Applications. In SenSys. ACM, 2003.


A motivating exampleA motivating example Tricky codeTricky 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; …}



result_t tryNextSend(){ atomic{ if(!sendTaskBusy){ post sendTask(); sendTaskBusy = TRUE;sendTaskBusy = TRUE; } }...}

If post sendTask() fails, the task will never be executed, and thus sendTaskBusy remains TRUE forever.

YES!

task void sendTask(){ … sendTaskBusy = FALSE; …}



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())if(SUCCESS != post sendTask()) sendTaskBusy = FALSE; else sendTaskBusy = TRUE; }...}

result_t tryNextSend(){ atomic{ if(!sendTaskBusy){ post sendTask(); sendTaskBusy = TRUE; } }...}


MotivationMotivation Model CheckingModel Checking

Determining whether a model satisfies a property by exhaustive searching.

Model Checker

Model

PropertyViolation!

e.g, []( sendTaskBusy <>!sendTaskBusy)Whenever sendTaskBusy is true, it will eventually be reset as false.


Our ApproachOur 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.


PAT Architecture Design

NesC@PAT


ChallengesChallenges 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


NesC@PATNesC@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 automatedautomated, dealing with NesC code directlydirectly Verification of properties of a large range


NesC@PATNesC@PAT Overview


Formalization of WSNsFormalization of WSNs Semantic Model of WSN

Sensor Model WSN Model

Operational Semantics NesC/C language Constructs Interrupt-driven Feature Networked Feature

ConcurrencyCommunication


Case study: Trickle [5]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 receives an older version, so I

send my code.

I receive a same version, so I do nothing

5

5

7

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

A

BC


TrickleTrickle Desirable Property

If a node is reachable in the network, then it should always always eventually eventually be updated with the latest code.

Code Structure of NesC Implementation Top-level configuration: TrickleAppC.nc Implementation of Trickle: TrickleC.nc


Verifying Trickle with NesC@PATVerifying Trickle with NesC@PAT

Sensor1:Application: TrickleAppC




Three topologies

Single-track Ring Ring Star

Deploying WSNsDeploying WSNs


Verification GoalsVerification Goals Definition of States

Properties Safety Properties

Temporal Properties (Liveness)#assert SensorNetwork |= []<> (UpdateA && UpdateB && UpdateC);Always eventually all three nodes get updated.

#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;


Experimental ResultsExperimental Results


Experimental ResultsExperimental Results

The liveness property is violated by SRing WSN!


Buggy Scenario – Single-tracked RingBuggy Scenario – Single-tracked Ring

0

1

01

Version channel

Code channel

Data link

Never updated

A

B

C


Real execution on Iris motesReal 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


Discussion & Future WorkDiscussion & Future Work Scalability

Reasons: Two-level concurrency, complex behaviors Reduction Techniques: partial order reduction, symmetry

reduction, etc. Symbolic Model checking: BDD encoding

Timed FeatureCurrently, 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)


Thank youThank you

Towards a Model Checker for NesC and Wireless Sensor Networks Manchun Zheng 1, Jun Sun 2, Yang Liu...

Documents

Transcript of Towards a Model Checker for NesC and Wireless Sensor Networks Manchun Zheng 1, Jun Sun 2, Yang Liu...