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 allerrors/bugs of anypossible 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_ttryNextSend(){ 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_ttryNextSend(){ 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 Model Checker Violation! Property • e.g, []( sendTaskBusy <>!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@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@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@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 I receive a same version, so I do nothing My code version is 5 A 5 5 I receives an older version, so I send my code. 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@PAT Sensor1: Application: TrickleAppC Sensor2: Application: TrickleAppC Sensor3: Application: TrickleAppC

20. Deploying WSNs • Three topologies

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; #assertSensorNetworkdeadlockfree; //default property #assertSensorNetworknever FalseUpdate; #assertSensorNetwork |= []<> (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 C 0 1 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