Presentation is loading. Please wait.

Presentation is loading. Please wait.

Towards a Model Checker for NesC and Wireless Sensor Networks Manchun Zheng 1, Jun Sun 2, Yang Liu 1, Jin Song Dong 1, and Yu Gu 2 1 National University.

Similar presentations


Presentation on theme: "Towards a Model Checker for NesC and Wireless Sensor Networks Manchun Zheng 1, Jun Sun 2, Yang Liu 1, Jin Song Dong 1, and Yu Gu 2 1 National University."— Presentation transcript:

1 Towards a Model Checker for NesC and Wireless Sensor Networks Manchun Zheng 1, Jun Sun 2, Yang Liu 1, Jin Song Dong 1, and Yu Gu 2 1 National University of Singapore 2 Singapore University of Technology and Design

2 NUS Presentation Title 2006 Towards a Model Checker for NesC and Wireless Sensor NetworksBackground  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 NUS Presentation Title 2006 Towards a Model Checker for NesC and Wireless Sensor NetworksBackground  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.

4 NUS Presentation Title 2006 Towards a Model Checker for NesC and Wireless Sensor NetworksBackground  TinyOS Interrupt-driven Execution Model

5 NUS Presentation Title 2006 Towards a Model Checker for NesC and Wireless Sensor NetworksBackground  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?

6 NUS Presentation Title 2006 Towards a Model Checker for NesC and Wireless Sensor NetworksMotivation  Traditional approaches Simulation: TOSSIM [3] automatically 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: all any  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 NUS Presentation Title 2006 Towards a Model Checker for NesC and Wireless Sensor Networks 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 NUS Presentation Title 2006 Towards a Model Checker for NesC and Wireless Sensor Networks 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. YES! task void sendTask(){ … sendTaskBusy = FALSE; … }

9 NUS Presentation Title 2006 Towards a Model Checker for NesC and Wireless Sensor Networks 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()) if(SUCCESS != post sendTask()) sendTaskBusy = FALSE; else sendTaskBusy = TRUE; }... } result_t tryNextSend(){ atomic{ if(!sendTaskBusy){ post sendTask(); sendTaskBusy = TRUE; } }... }

10 NUS Presentation Title 2006 Towards a Model Checker for NesC and Wireless Sensor NetworksMotivation  Model Checking Determining whether a model satisfies a property by exhaustive searching. Model Checker Model Property Violation! e.g, []( sendTaskBusy  <>!sendTaskBusy) Whenever sendTaskBusy is true, it will eventually be reset as false.

11 NUS Presentation Title 2006 Towards a Model Checker for NesC and Wireless Sensor Networks 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]www.patroot.com 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 NUS Presentation Title 2006 Towards a Model Checker for NesC and Wireless Sensor Networks PAT Architecture Design NesC@PAT

13 NUS Presentation Title 2006 Towards a Model Checker for NesC and Wireless Sensor NetworksChallenges  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 NUS Presentation Title 2006 Towards a Model Checker for NesC and Wireless Sensor NetworksNesC@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 automateddirectly Fully automated, dealing with NesC code directly Verification of properties of a large range

15 NUS Presentation Title 2006 Towards a Model Checker for NesC and Wireless Sensor NetworksNesC@PAT  Overview

16 NUS Presentation Title 2006 Towards a Model Checker for NesC and Wireless Sensor Networks 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 NUS Presentation Title 2006 Towards a Model Checker for NesC and Wireless Sensor Networks 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 B C

18 NUS Presentation Title 2006 Towards a Model Checker for NesC and Wireless Sensor NetworksTrickle  Desirable Property always eventually 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 NUS Presentation Title 2006 Towards a Model Checker for NesC and Wireless Sensor Networks Verifying Trickle with NesC@PAT Sensor1: Application: TrickleAppC Sensor2: Application: TrickleAppC Sensor3: Application: TrickleAppC

20 NUS Presentation Title 2006 Towards a Model Checker for NesC and Wireless Sensor Networks  Three topologies Single-track RingRingStar Deploying WSNs

21 NUS Presentation Title 2006 Towards a Model Checker for NesC and Wireless Sensor Networks Verification 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;

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

23 NUS Presentation Title 2006 Towards a Model Checker for NesC and Wireless Sensor Networks Experimental Results The liveness property is violated by SRing WSN!

24 NUS Presentation Title 2006 Towards a Model Checker for NesC and Wireless Sensor Networks Buggy Scenario – Single-tracked Ring 0 1 01 Version channel Code channel Data link Never updated A B C

25 NUS Presentation Title 2006 Towards a Model Checker for NesC and Wireless Sensor Networks 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 NUS Presentation Title 2006 Towards a Model Checker for NesC and Wireless Sensor Networks 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 NUS Presentation Title 2006 Towards a Model Checker for NesC and Wireless Sensor Networks Thank you


Download ppt "Towards a Model Checker for NesC and Wireless Sensor Networks Manchun Zheng 1, Jun Sun 2, Yang Liu 1, Jin Song Dong 1, and Yu Gu 2 1 National University."

Similar presentations


Ads by Google