An Automatic Approach To Verify Sensor Network Systems

Man Chun ZhengSchool of Computing

National University of SingaporeSingapore

zmanchun@comp.nus.edu.sg

Abstract—The programming language nesC for TinyOS ap-plications supports special features of sensor network systemsby providing a component-oriented programming model whichis flexibly concurrent/reactive and event-driven. Sensor net-work systems are correctness critical since they are expectedto work autonomously. Formal verification techniques such asmodel checking have been successfully applied to assure thereliability and correctness of concurrent systems and real-timesystems. However, manually constructing a formal model isalways a non-trivial task. We develop a lightweight frameworkfor sensor network systems which automatically extracts real-time models from nesC implementations and verifies themagainst goals using model checking techniques. We believethat our approach contributes to systematically improving thequality of sensor network systems, with little overhead or costcaused by applying verification techniques.

Keywords-Sensor Network System; Model Checking; RTS;

I. INTRODUCTION

A sensor network consists of a large number of tiny,low-power sensor nodes, each of which executes concurrent,reactive programs that must operate with severe memory andpower constraints. To deal with such constraints, TinyOS [1]is proposed as an operating system for sensor networksystems. Moreover, nesC was proposed by Gay et al. [2] as aprogramming language for developing TinyOS applications.

The well-designed mechanisms of TinyOS and the ex-pressiveness of nesC have attracted a lot of research users.Although nesC has provided advanced program analysissuch as compile-time data race detection, it cannot assurecomplete correctness of a given nesC application. Since theexecution model of TinyOS is concurrent and based on tasksand interrupt handler, the correctness of concurrency (suchas absence of race conditions) is critical. Furthermore, thecorrectness of real-time constraints, power managements,sensing and communicating behaviors of sensor networksystems have motivated researchers to explore formal veri-fication techniques for sensor network systems.

In this paper, we propose to automatically generate real-time system (RTS) models [3] from sensor network systemsimplemented in nesC. Model checking techniques are alsoapplied to the RTS models for verifying properties suchas deadlock freeness, divergence freeness, state reachabil-ity, temporal properties and non-timed/timed refinement.Currently, we have built a lightweight framework for this

approach. We believe that our approach will contribute toboth eliminating the extra efforts for formally verifying nesCapplications and increasing the correctness and reliability ofnesC applications.

II. RELATED WORK

Rosa and Cunha propose an approach for formalizingTinyOS applications with a formal specification languageLOTOS [4] based on process algebra. Main concepts ofnesC, namely interfaces, modules and configurations, arespecified as synchronization ports, processes with choicesand compositional processes. This approach emphasizesmostly on modeling the interaction between components andintroduces no verification techniques. McInnes presents atechnique for modeling the concurrency of TinyOS appli-cations using another process based specification language,i.e. CSP, and the model checker FDR is introduced toanalyze the applications [5]. Both approaches contributeto applying formal methods to sensor network systemsfor enhanced analysis and early error detection. However,these approaches cannot yet avoid the trouble caused byconstructing formal models manually.

The framework SLEDE [6], [7] is proposed for automaticverification of sensor network security protocols imple-mented in nesC. SLEDE extracts Promela models from pro-tocol implementations in nesC, generates intrusion modelsand uses the model checker SPIN [8] to verify securityproperties of the models. The contribution of SLEDE is thatit decreases the cost of verification and improves the qualityof nesC security protocol implementations. However, thisframework focuses on security protocol implementations andis not suitable for other nesC applications. Our approachdiffers from SLEDE in that we consider real-time behaviorsduring model generations and our approach is feasible forvarious applications besides protocol implementations.

Reference [9] introduces a model construction methodol-ogy for TinyOS-based networks using Behavior-Interaction-Priority (BIP) component framework. This methodologyincludes a model generation method for nesC. The net-worked system is specified as a global model, which is thecomposition of models of nodes. This framework allowsbehavioral verification and simulation of sensor networksystems. This work differs from ours in that it uses BIP

2010 Fourth IEEE International Conference on Secure Software Integration and Reliability Improvement Companion

978-0-7695-4087-0/10 $26.00 © 2010 IEEE

DOI 10.1109/SSIRI-C.2010.12

7

Executea Task

Finish the Task

Idle Task QueueNot Empty

QueueNot Empty

Init

QueueEmpty

Figure 1. The Execution Model of Task Scheduler

ExecuteInterruptHandler

Finishinterrupt

interrupt

Preemptioin

interrupt

No Preempted Handlers

IdleInit

Figure 2. The Execution Model of Interrupt Manager

(i.e. hierarchical real-time components) while we uses RTS(i.e. process algebra with real-time extensions).

III. METHODOLOGY

Our approach is to automatically extract RTS models fromTinyOS applications (implemented in nesC), and then toapply verification techniques to the generated RTS models.The verification results of the RTS models reflect the cor-rectness of the original TinyOS applications. The TinyOSexecution model and related RTS semantics are describedin Section III-A. Section III-B explains in detail how ourapproach is designed and implemented in a framework. InSection III-C, an assertion annotation language is presentedand examples are provided to demonstrate verification goals.

A. The Execution Model of TinyOS

TinyOS’s execution model is based on split-phase opera-tions, run-to-completion tasks and interrupt handlers.

In effect, a task is a deferred procedure call. Tasks canbe posted at anytime and are executed later one by one,managing by the TinyOS scheduler. A task runs atomicallywith respect to others. At runtime, TinyOS maintains ascheduler for managing the executions of tasks, using aqueue for running tasks in FIFO order. The task schedulercan be represented as the state machine shown in Fig. 1.

In contrast to tasks, an interrupt handler can preempttasks or other interrupt handlers. The interrupt manageris introduced to manage the executions and interactionsbetween interrupt handlers. In the interrupt manager, a newinterrupt preempts the execution of the current one. The statemachine of the interrupt manager is shown in Fig. 2.

Since interrupts can preempt the execution of tasks, theglobal state machine of the execution model of TinyOSshould capture such features, as presented in Fig. 3. Initially,the state machine is idle. When a new task is posted, it

idleinit

Push taskTo Task QueueTask Posted

interrupt

InterruptHandler

TaskScheduler

interrupt interrupt

Task Queue not Empty

Figure 3. The Execution Model of TinyOS

will be pushed into the task queue, and the task schedulerbegins to execute. Similarly, initially an interrupt will beginthe execution of the interrupt handler. Since interruptspreempt tasks, an interrupt can be accepted during theexecution of the task scheduler, and the execution of theinterrupt handler will begin, blocking the execution of thetask scheduler. After the execution of the interrupt handler,the task scheduler will be resumed if the task queue isnot empty otherwise the execution model will become idleagain. The executions of the task scheduler and the interrupthandler in Fig. 3 follow the state machines in Fig. 1 andFig. 2, respectively.The formal definition of RTS models have been previouslypresented in [3], where an RTS model is defined as a3-tuple R = (Var, init, P). Var is a set of global variables,init is the initial valuation of the variables and P is aprocess. Based on this definition, the RTS semantics of thetask scheduler and of the interrupt manager are defined asthe following.

Definition 1 (Task Scheduler): The task scheduler sdl ofTinyOS is modeled as an RTS model Rsdl, where Var ={Qt, Ch(sdl, 0), Cont(EOT,−1)1, tskid} (Qt is a queue fordeferred tasks, Ch(sdl, 0) is a synchronous channel fornotifying a certain task to execute, EOT is a constant variablewith the unique value −1 denoting the end of a task, andtskid is the id of the executing task), init is the initialvaluation of Var such that Qt and channel sdl are empty,and P = if (Qt �= ∅){getTasksdl{tskid = Qt.Pop()} →sdl!tskid → sdl?EOT → P}else{P}.

Definition 2 (Interrupt Manager): The interrupt managerimr of TinyOS is modeled as an RTS model Rimr , whereVar = {Qi, Ch(imr, 0), Cont(EOA,−1)1, asyncid} (Qi is astack for preempted executions of asynchronous functions,Ch(imr, 0) is a synchronous channel for interrupting anasynchronous execution and notifying preempted executionsto resume, EOA is a constant variable with the unique value−1 denoting the end of an asynchronous execution, andasyncid is the id of the executing function), init is the initial

1Cont() is a function to define constants.

8

valuation of Var such that Qi and channel imr are empty,and P = imr?EOA → if (Qi �= ∅){getAsyncimr{asyncid =Qi.Pop()} → imr?EOA → P}else{P}.

The following presents a formal definition of TinyOSexecution model.

Definition 3 (Execution Model): A TinyOS executionmodel is a 7-tuple (Var, Qt, Qi,S,A, s0, δ), consisting of:

a set of variables declared in all components (Var),a queue for scheduling tasks (Qt),a stack for managing interrupt handlers (Qi),a set of reachable states (S),a set of possible actions (A),an initial state (s0),and a transition function (δ : S ×A → S).

A state s is defined as the following definition.

Definition 4 (State s): A state s of the TinyOS executionmodel is a 2-tuple s = (V, p) where V is the valuation ofVar, Qt and Qi, and p identifies the current execution: o(idle),t(task) or i(interrupt handler).

The firing rules for nesC operations, such as post, interrupt,return and so on, are defined as below.

Below are the firing rules for a statement post(tk) (i.e. topost a task tk). t{tk} means that the current execution is inthe task scheduler with task tk.

[ post1 ]

(V,o)post(tk)→ (V, t{tk})

p �=o[ post2 ]

(V, p)post(tk)→ (V ′{Qt.add(tk)}, t)

In rule post1, the execution is idle, therefore, a newlyposted task can be executed immediately and the executionbecomes t. In rule post2, a task or an interrupt handler isrunning. Since tasks can not preempt other executions, thenewly posted task tk is added to Qt.

The following are the firing rules for interrupt(ih) (i.e.the occurrence of an interrupt with the handler ih).

[ interrupt1 ]

(V, o)interrupt(ih)→ (V, i{ih})

[ interrupt2 ]

(V, t{tk}) interrupt(ih)→ (V ′{Qt.push(tk)}, i{ih})

[ interrupt3 ]

(V, i{ih0}) interrupt→ (V ′{Qi.push(ih0)}, i{ih})

Below are the firing rules for return (i.e. the completionof a task or interrupt handler). i{ih} means that the currentexecution is the interrupt handler ih.

RTS-Model Generator

Model Checker

SimulatorCounterexample

nesC Code

Property

Assertions

nesC to RTS mapping algorithm

Models of library of TinyOS

RTS model

Figure 4. Overview of the framework

Table ITHE MAPPING ALGORITHM

nesC Elements RTS ConstructsSplit-phaseoperations Processes communicating via synchronous channels.

Component Global variables, processes modeling behaviors ofcommands, events, and tasks.

System The interleaving composition of all processes.

Qt = ∅, Qi = ∅

[ return1 ]

(V, p)return→ (V, o)

Qt �= ∅, Qi = ∅

[ return2 ]

(V, p)return→ (V ′{tk = Qt.pop()}, t{tk})

Qi �= ∅

[ return3 ]

(V, p)return→ (V ′{ih = Qi.pop()}, i{ih})

B. Extracting RTS model from nesC

Fig. 4 reflects the architecture of our framework. Theinput of the framework includes nesC source code andassertions representing verification goals. A self-containedparser for the nesC language is implemented to generatecorresponding RTS models from source code. The generatedmodels are then passed to the existent model checker of PATto verify whether the goals are verified and counterexampleswould be provided for unsatisfied goals. Executing graphsof the models and counterexamples can be viewed via thesimulator of PAT. PAT [10], [11] supports a wide range ofmodeling languages including RTS (Real Time System, aprocess algebra with timed operators), which shares similardesign principles with integrated specification languageslike TCOZ [12], [13]. Our framework is implemented asa module of PAT (i.e. nesC module) and is available at [14].

Since TinyOS system library (which encapsulates oper-ating system environment and hardware functionalities aspredefined interfaces and components) is required whenrunning nesC applications, a set of RTS models representingthe TinyOS library is statically provided (such as Timer,Sensor, Led, etc.). These environmental models are usedwhen applying the mapping algorithm for model generation.

9

RTS ModelSplit-phase Operations

Provider

Userchannel User_Interface_C 0;channel User_Interface_E 0;channel Provider_Interface_C 0;channel Provider_Interface_E 0;

User_Provider_Interface_C = User_Interface_C?x --> Provider_Interface_C!x --> User_Provider_Interface_C;User_Provider_Interface_E = User_Interface_E?x --> Provider_Interface_E!x --> User_Provider_Interface_E;

CommandCall

EventSignal

Interface

Figure 5. Modeling Split-phase Operations

Component RTS Model

Synchronous Code:Tasks and synchronous commands, events.

Asynchronous Code:Asynchronous commands and events.

Comp_Sync = (Comp_Intf_Command ||| Comp_Intf_Event ||| Comp_Task ||| . . . );

Comp_Async = (Component_Interface_Async_Command||| . . . ||| Component_Interface_Async_Event);

Local variables Var Com_VariableName;

Figure 6. Modeling a component

As shown in Table I, the mapping algorithm forextracting RTS models from nesC code consists of threesteps: modeling split-phase operation, modeling componentsand building a system-level process to model the applicationas a whole. Each step is explained in detail as follows.

Step 1: model split-phase operationsAs shown in Fig. 5, components interact with each other viainterfaces. A wiring in nesC ”wires” a component to anotherby an interface and the two components are required to useand provide the interface respectively. Wiring is modeled bydefining two processes transferring command calls and eventsignals between the user and the provider.

Definition 5 (Wiring Expression): A wiring expressionuser → prov is modeled as an RTS model Ruser→prov

where Var ={Ch(userc, 0),Ch(usere, 0),Ch(provc, 0),Ch(prove,0)}, init is the valuation such that channelsuserc, usere, provc and prove are empty, andP = (CommandCalls ||| EventSignals). Further, Ch(c, n)defines a channel named c with a buffer of size n (a channelwith 0 buffer size requires synchronous input and output),CommandCalls = (userc?x → provc!x → CommandCalls),and EventSignals = (prove?x → usere!x → EventSignals) .

Step 2: model a componentA component is separated into three parts: componentvariables, synchronous code, and asynchronous code.According to the execution model of TinyOS, the executionis either a task or a interrupt handler. The execution of afunction runs to completion until it is interrupted. Eachfunction (a task, command or event) is specified as aprocess, and a component is the interleaving composition ofall the processes representing its implemented functions, asshown in Fig. 6. The statements in a function are modeled

Table IIEXAMPLE: RTS PROCESSES FOR nesC STATEMENTS

nesC statements RTS processescall intf.cmd() provc!idcmdsignal intf.evt() usere!idevt

post tsk() Qt.Push(tsk)if(B){A}else{C} IF = if (B){A}else{C};while(B){A} WHILE = if(B){A;WHILE}else{Skip};do{A}while(B) WHILE = A; if(B){WHILE}else{Skip};

for(A;B;C){D} FOR = A; ReFor;ReFor = if(B){D;C;ReFor }else{Skip};

as RTS events or processes, as shown in Table II. Toemphasize, tasks are scheduled in a task scheduler and donot execute immediately once it is posted as commandsor events. A queue is defined for posted tasks to wait forbeing scheduled, and a channel is used for communicationbetween tasks and the task scheduler.

Definition 6 (Command Implementation): A commandimplementation cmd is modeled as a RTS model Rcmd

where Var = {idcmd, v1cmd, v2cmd, . . .} (i.e. the unique id ofthe command and the variables defined in the commandimplementation), init is the initial valuation of the variables,and P = provc?idcmd → Cmd. Further, Cmd is an RTSprocess constructed by translating the statements of thecommand implementation.

Definition 7 (Event Implementation): An event imple-mentation evt is modeled as a RTS model Revt whereVar = {idevt, v1evt, v2evt, . . .} (i.e. the unique id of the eventand the variables defined in the event implementation), initis the initial valuation of the variables, and P = usere?idevt → Evt. Further, Evt is an RTS process constructed bytranslating the statements of the event implementation.

Definition 8 (Task): A task tsk is modeled as a RTSmodel Rtsk where Var = {idtsk, v1tsk, v2tsk, . . .} (idtsk is aunique id for the task, and v1tsk, v2tsk, . . . , are the variablesdefined i n the task), init is the initial valuation of thevariables, and P = sdl?idtsk → Tsk; sdl!EOF. Further, Tskis an RTS process constructed by translating the statementsof the task.

Step 3: build the system-level processAfter specifying all components and their wirings, a top-level process is defined as the interleaving of all existentprocesses in runtime to represent the whole system, includ-ing the process modeling the task scheduler.

System = TaskSdl ||| Comp Sync ||| . . . ||| Comp Sync||| Comp Async ||| . . . ||| Comp Async;

The task scheduler is modeled as a process (TaskSdl) asfollows.

TaskSdl = if (Qt.Count() �= 0){getTask{IDtsk = Qt.First()} → sdl!IDtsk→ sdl?EOT → deTask{Qt.Dequeue()}→ TaskSdl

}

10

Process TaskSdl is blocked until the task queue Qt is notempty, and then a task id is fetched from the queue andthe corresponding task is informed to run via channel sdl.As shown in Definition 9, process Tsk (modeling a task) isblocked until the channel sdl has a value equaled to the task’sID. After the execution of the task, it writes channel sdl withEOT to inform the process TaskSdl of its completion, andits id will then be dequeued from Qt.

Process System reserves the semantics of synchronouscode and asynchronous code of nesC, i.e. a synchronousfunction runs atomically if not preempted by asynchronousfunctions and an asynchronous function can be preemptedby other asynchronous function. The process System is thenverified against assertions to prove whether the originalapplication satisfies the defined properties. This processSystem is then verified with assertions to prove whether theoriginal application satisfies the defined properties.

Modeling timing constraints TinyOS maintains middle-wares such as Timer and Alarm to support the real-timefeatures for developing nesC applications. The timing mid-dlewares of TinyOS are modeled as timed processes withtimed operators including Wait, Deadline, Waituntil, Inter-rupt and so on, as illustrated in [3]. These models areimplemented statically as part of the runtime environmentallibrary when automatically constructing the RTS models inour framework.

C. Verification

1) Assertion Annotation Language: To ease the proce-dure of defining verification goals, an expressive and user-friendly assertion annotation language is defined. The an-notation language includes assertions for defining deadlockfreeness, divergence freeness, state reachability, temporalproperties(as LTL formula) and timed refinement. It is usedto define verification goals for checking data races, recursionof operation calls, existence of failures, timing requirements,safety and so on. Examples are given in Table III.

2) Verification Techniques: Various techniques are ap-plied for different kinds of properties, such as deadlock free-ness, divergence freeness, state reachability, temporal prop-erties, and non-timed/timed refinement. Temporal propertiesare written in Linear Temporal Logic (LTL) formulae, whichare converted into Buchi automata. As presented in [15], on-the-fly model checking approach and a depth-first search al-gorithm are used to search for a counterexample. Non-timedrefinement technique has been introduced to model checklinearizability in [16], which adopts partial order reductionfor a modified on-the-fly refinement checking algorithm.Timed refinement checking is proposed in [3], using zone

2ledons is a state defined as LedC.led == 1, i.e. led is on.3P1 is a specification process, eg. P1 ≡ BlinkC.call.leds.ledOn →LedC.leds.ledOn → P1 .4P2 is a specification process, eg. P2≡Led.leds.ledtoggle; Wait[5]; P2.

Table IIISOME EXAMPLES OF ASSERTIONS

Type Assertion Property

DeadlockFreeness

#assert System deadlockfreeThe system is deadlockfree.

Divergence#assert System divergencefree

The system is diver-gence free.

Freeness#assert Systemdivergencefree < T >

The system is timed di-vergence free.

Reachability #assert System reaches ledons2 The system reaches the

state ledons .

Temporal#assert System |=�� BlinkC.Timer0.fired

Timer0 is fired infinitelyoften.

Properties#assert System |=�(BlinkC.Timer0.fired →(�LedsC.Leds.led0Toggle))

led0 should eventuallybe toggled wheneverTimer0 is fired.

Refinement #assert System refines P13

The traces of the systemis a subset of those ofP1.

#assert System refines<T>P24

The timed traces of thesystem is a subset ofthose of P2.

Table IVVERIFICATION RESULTS

System Assertion Result VisitedStates

Time(second)

BlinkTaskP1 True 397 0.18P2 True 1,926 0.50P3 True 1,875 0.55

BlinkTask’P1’ True 158,668 78.27P2’ True 1,397,580 1,420.72P3’ True 1,238,588 1,039.30

abstraction to preserve timed traces and developing modelchecking algorithm based on Difference Bound Matrix.

IV. EXPERIMENTS

In this section, we illustrate the execution of the currentframework with the application BlinkTask, in which a led isturned on and off periodically. In its configuration, BlinkCis wired to TimerC, LedsC and MainC via interface Timer,Leds and Boot, respectively. We also run another applicationBlinkTask’ for comparison, in which 2 timers are used totoggle 2 leds periodically respectively. Our testbed is a PCwith Intel Core2 CPU at 2.33GH and 3.25GB RAM.

During model extraction, timed operator Wait is usedwhen modeling the command startPeriodic implemented byTimerC. The generated RTS model consists of variables,channels and processes. Three kinds of verification goalsare verified against for both applications. P1(P1’) is the goalof deadlock freeness; P2(P2’) is the goal that the timer(s)is(are) fired infinitely often; P3(P3’) is the goal that the ledshould eventually be toggled whenever its correspondingtimer is fired. The results of verification of both applica-tions are shown in Table IV. These examples show thatour approach is useful and efficient for verifying TinyOSapplications. However, we still need to improve the currentframework to support more complex applications withoutdecreasing the efficiency, as discussed in next section.

V. DISCUSSIONS

Currently, our framework supports a large subset of thenesC syntax, and we are still working to support advanced

11

syntax such as multiple wiring and hierarchical components.Besides, we are facing challenges in the following aspects.

First, timing middlewares (such as Timer and Alarm) inTinyOS allow the absolute time to be accessed. A simplemechanism can be maintaining a global variable to representthe system time and increasing it periodically. This methodis problematical because introducing an unbounded globalvariable will make the state space infinitely large. An alter-native is to model absolute time as relative time, which willintroduce more complexity.

Second, state explosion is a common problem whileapplying model checking techniques. As shown in Table IV,during the verification of desirable properties for BlinkTask’,more than 1 million states are visited. One solution isto refine the model extraction methodology for generatingmore abstract models. An alternative is to explore statereduction techniques such as symmetric reduction to reducethe state space. A second alternative is to apply verificationtechniques directly on nesC instead of any formal models.

Third, sensor networks are often required to work inunreliable environments, with lossy channels, unreliable datareading, etc. Events like loss of data are randomized, how-ever, our current approach takes into account no probabilisticbehaviors for simplicity.

In the near future, we will enhance the current frameworkto support the complete syntax of nesC. Meanwhile, themethodology will be refined for extracting models at differ-ent levels of abstraction and state reduction techniques willalso be explored. The current framework models applicationson one sensor node, and we will work on composing amodel of the sensor networked system based on separatenodes. Moreover, we will improve the model extraction withrandomized behaviors (such as data loss and communicationfailure) of sensor network systems, and then probabilisticmodel checking techniques can be applied to verify to ourapproach. Finally, we will improve our framework to befeasible for verifying various applications of sensor networks(such as security protocols, medium access control, powermanagements, sensing and communicating, data aggrega-tion, radio control, etc.).

Due to the gap between the semantics of nesC and thoseof formalisms, formal models extracted from nesC are in-evitably large, complex and redundant. Intuitively, direct ver-ification is straightforward and more efficient as specializedoptimization techniques are possible. However, direct verifi-cation is infeasible without a complete operational semanticsof nesC. We expect to define the operational semantics ofnesC, and generate Labeled Transition Systems (LTS) basedon them. Verification techniques will be applied directlyby exploring the LTS. However, to define the operationalsemantics is not an easy task, since currently there exists noformal description for nesC. Moreover, the diversity of nesCsemantics makes defining its operational semantics moredifficult. At present, we notice that the execution model of

TinyOS application is well-defined. Therefore, we intend todevelop a formal description of this execution model andthen operational semantics can be defined based on it.

VI. CONCLUSION

This paper explains our recent work on automatic formalverification of sensor network systems. Currently, we havedeveloped a framework for automatic generation of RTSmodels from nesC implementations. Our ultimate goal is todevelop direct verification of nesC applications. We believethat our approach contributes to the robustness of sensornetwork systems because it allows nesC programmers tomodel check their code without being troubled by manuallyconstructing formal models.

REFERENCES

[1] J. Hill, R. Szewczyk, A. W. an S. Hollar, D. Culler, and K. Pis-ter, “System architecture directions for networked sensors,” inPLOS’00, 2000, pp. 93–104.

[2] D. Gay, P. Levis, R. v. Behren, M. Welsh, E. Brewer,and D. Culler, “The nesC language: a holistic approach tonetworked embedded systems,” in PLDI’03, 2003, pp. 1–11.

[3] J. Sun, Y. Liu, J. S. Dong, and H. H. Wang, “Verifying statefultimed CSP using implicit clocks and zone abstraction,” inICFEM’09, 2009.

[4] N. S. Rosa and P. R. F. Cunha, “Behavioural specification ofwireless sensor network applications,” in GIIS’07, 2007, pp.66–72.

[5] A. I. McInnes, “Using CSP to model and analyze TinyOSapplications,” in IEEE ECBS’09, 2009, pp. 79–88.

[6] Y. Hanna and H. Rajan, “Slede: framework for automatic veri-fication of sensor network security protocol implementations,”in ICSE Companion’09, 2009, pp. 427–428.

[7] Y. Hanna, H. Rajan, and W. Zhang, “Slede: a domain-specificverification framework for sensor network security protocolimplementations,” in WISEC’08, 2008, pp. 109–118.

[8] G. J. Holzmann, “Software model checking with SPIN,”Advances in Computers, pp. 78–109, 2005.

[9] A. Basu, L. Mounier, M. Poulhies, J. Pulou, and J. Sifakis,“Using BIP for modeling and verification of networked sys-tems – a Case study on TinyOS-based networks,” in NCA’07,2007, pp. 257–260.

[10] J. Sun, Y. Liu, J. S. Dong, and J. Pang, “PAT: towards flexibleverification under fairness,” in CAV, 2009, pp. 709–714.

[11] J. Sun, Y. Liu, J. S. Dong, and H. H. Wang, “Specifying andverifying event-based fairness enhanced systems,” in ICFEM,2008, pp. 5–24.

[12] B. P. Mahony and J. S. Dong, “Timed communicating ObjectZ,” IEEE Trans. Software Eng., vol. 26, no. 2, pp. 150–177,2000.

[13] ——, “Blending Object-Z and Timed CSP: an introductionto TCOZ,” in ICSE, 1998, pp. 95–104.

[14] “PAT website,” http://www.comp.nus.edu.sg/∼pat/.[15] J. Sun, Y. Liu, J. S. Dong, and J. Sun, “Bounded model

checking of compositional processes,” in TASE’08, 2008, pp.23–30.

[16] Y. Liu, W. Chen, Y. A. Liu, and J. Sun, “Model checkinglinearizability via refinement,” in FM’09, 2009, pp. 321–337.

12