verification by model checking1 formal methods laboratory university of tehran based on the chapter...

Verification by Model Checking 1

Verification by Model Checking

Formal Methods Laboratory

University of Tehran

Based on the chapter 3 of “Logic in Computer Science”,

Huth & Ryan


Part 1 : Motivation


IntroductionIntroduction

Verification: verifying the correctness of computer systems hardware, software or combination

It is most obvious in safety-critical systems commercially critical mission critical


Verification partsVerification parts

Formal Verification techniques consist of three parts:

1. A framework for modeling systems some kind of specification language

2. A specification language for describing the properties to be verified

3. A verification method for establishing if the description of the system

satisfies the specification


ClassificationClassification

Approaches to verification can be classified in several ways: Proof-based vs. model-based Degree of automation Full- vs. property- verification Intended domain of application

hardware-software, sequential-concurrent, reactive-terminating, …

Pre- vs. postdevelopment


Proof-based verificationProof-based verification

The system description is a set of formula Γ in a suitable logic

The specification is another formula The verification method is finding a proof that

Γ├ ├ means deduction

It typically needs the user guidance and expertise


Model-based verification Model-based verification

The system is represented by a model M for an appropriate logic

The specification is again represented by a formula

The verification method consist of computing whether a model M satisfies M satisfies : M╞

The computation is usually automatic for finite models


Degree of automationDegree of automation

From fully automated to fully manual


Full- vs. property-verificationFull- vs. property-verification

The specification may describe a single property of the system, or it may describe its full behavior (expensive).


Intended domain of applicationIntended domain of application

Hardware, software Sequential, concurrent Reactive , terminating

Reactive: reacts to its environment, and is not meant to terminate (e.g. operating systems, embedded systems, computer hardware)


Pre- vs. post-developmentPre- vs. post-development

Verification is of greater advantage if introduced early in system development


Model checkingModel checking

Model checking is an automatic, model-based, property-verification approach

It is intended to be used for concurrent and reactive systems The purpose of a reactive system is not necessarily to

obtain a final result, but to maintain some interaction with its environment

Concurrency bugs non reproducible not covered by test cases


Temporal LogicTemporal Logic

The idea is that a formula is not statically true or false in a model

The models of temporal logic contain several states a formula can be true in some and false in the others

The static notion of truth is replaced by a dynamic one the formulas may change their truth values

as the system evolves from state to state


Temporal Logic (cont.)Temporal Logic (cont.)

In model checking: The models M are transition systems The properties φ are formulas in temporal logic

Model checking steps:1. Model the system using the description language of a

model checker : M2. Code the property using the specification language of

the model checker : φ

3. Run the model checker with the inputs M and φ


Model checkerModel checker

M

ModelChecker

p → F qyes

no

φ

Error Trace


Linear vs. BranchingLinear vs. Branching

Linear-time logics think of time as a set of paths path is a sequence of time instances

Branching time logics represent time as a tree it is rooted at the present moment and branches out

into the future

Many logics were suggested during last years that fit into one of above categories

We study LTL in linear time logics and CTL in branching time logics


Linear vs. Branching (cont.)Linear vs. Branching (cont.)

Linear Time Every moment has a

unique successor Infinite sequences (words) Linear Time Temporal

Logic (LTL)

Branching Time Every moment has

several successors Infinite tree Computation Tree

Logic (CTL)


CTLCTL

Branching time


Computational tree logicComputational tree logic

Syntax: ::= F | T | p | (~) | ( /\ ) | (\/) | ( -> ) | AX | EX | A[U] | E[U] | AG | EG | AF | EFWhere p ranges over atomic formulas/descriptions.


AX, EX, AG, EG, AU, AF, EF : temporal connectives The first of the pair

A means “ along All paths” E means “ along at least (there Exist) one path”

The second one of the pair X means “ neXt state” F means “some Future state” G means “ all future states (Globally)” U means “ Until”


Convention Binding priorities

Unary connectives: ~, AG, EG, AF, EF,AX, EX /\ , \/ -> , AU, EU


Well-formed CTL formulas: EGr AG(q -> EGr) different from AGq -> EGr , which is (AGq) -> (EGr) A[p U EFr] EF EG p -> AFr Page 153: some well-formed and some not well-

formed


EF(rUq) ?? U can only be paired with an A or an E EF E[rUq] or EF A[rUq]

AF[(rUq) /\ (pUr)] ?? Boolean connective (/\) cannot be directly inside A[]

or E[]


ExampleExample

The parse tree of A[AX ~p U E[EX(p/\q)U ~p]] according to precedence rules

Fig. 3.1, page 155


Transition SystemTransition System

A model M = (S, →, L) for CTL is S: a finite set of states → : a binary relation on S, such that every s S has

some s ' S with s → s ' L : a labeling function L: S → P( Atoms)

P( Atoms) means the power set of Atoms

The interpretation of the labeling function is that each state s has a set of atomic propositions L(s) which are true at that particular state


ExampleExample

p,q

q,rq

s0

s1s2

S = {s0, s1, s2}

transitions = s0 → s1 , s1

→ s1 , s2 → s1 , s2 → s0 , s0 → s2

L(s0) = {p,q}

L(s1) = {q}

L(s2) = {q,r}


DeadlockDeadlock

We will call the transition systems simply models in our discussions

According to the definition of a model, for each s S there is at least one s' S

No state of a system may be deadlocked If a system has a deadlock, we always add an

extra state sd representing the deadlock


Deadlock stateDeadlock state

s0 s1

s2

s3

s3 doesn’t have any further transitions

adding a deadlock state sd

s0 s1

s2

s3

sd


UnwindingUnwinding

We can unwind the transition system to obtain an infinite computation tree

The execution paths of a model M are explicitly represented in the tree obtained by unwinding the tree


Unwinding: exampleUnwinding: example

p,q

q,rq

s0

s1s2

p,q

p,q

s0

q,r

s2

q

s1

q

s1

q,r

s2s0

p,qq,r

s2s0

q

s1

q,rs2

q

s1

an arbitrary path


Formal SemanticsFormal Semantics

Let M = (S, →, L) be a model and п = s1 →… be a path in M

Whether п satisfies an CTL formula is defined by the satisfaction relation ╞ as follows:

1

2

3

4


NextNext

7. M,s |= AX iff for all s1 such that

s->s1 we have M,s|= .

Thus, AX says “in every next state” 8. M,s |= EX iff for some s1 such that s->s1 we

have M,s|= .

Thus, EX says “in some next state”


GloballyGlobally

9. M,s |= AG holds iff for all paths

s1->s2->s3-> … where s1 equals s, and for all si along the path, we have M,si |= .

For all computation paths beginning in s the property holds Globally (including the initial state).


10. M,s |= EG holds iff there is a path s1->s2->s3-> … where s1 equals s, and for all si along the path, we have M,si |= .

There exist a path beginning in s such that the property holds Globally (including the initial state).


FinallyFinally

11. M,s |= AF holds iff for all paths

s1->s2->s3-> … where s1 equals s, there is some si along the path, such that we have M,si |= .

For all computation paths beginning in s there will be some Future state where holds.


12. M,s |= EF holds iff there is a path s1->s2->s3-> … where s1 equals s, and for some si along the path, we have M,si |= .

There exist a path beginning in s such that the property holds in some Future state.


UntilUntil

13. M,s |= A[1 U 2] holds iff for all paths

s1 -> s2 -> s3 -> … where s1 equals s, that path satisfies 1 U 2 , i.e. there is some si along the path, such that we have M,si |= 2, and, for each j<i, we have M,sj |= 1.

14. M,s |= E[1 U 2] …


A note for UntilA note for Until

Until says nothing about what happens after the Until has been realized

This can be different from natural English speaking For example:

“She continued working until she married” We may interpret the sentence as she discontinued

working after marriage The above understanding is related to this formula

working U ( marriage G ⌐working)


P.160: EF, EG P.161: AF, AG P.162: Until


Some practical patternsSome practical patterns

It is possible to get to a state where started holds, but ready does not hold EF (started ⌐ready)

For any state, if a request occurs, then it will eventually be acknowledged AG (requested → AF acknowledged)

Whatever happens, a certain process will eventually be permanently deadlocked AF (AG deadlock)


Some practical patterns (cont.)Some practical patterns (cont.)

A certain process is enabled infinitely often on every computation path AG (AF enabled) In other words, in a path of the system there must never be

a point at which the condition enabled becomes false and stays false forever


Part 2 : LTL

Amir PnueliThe Weizmann

Institute of Science


LTLLTL

LTL : Linear-time Temporal Logic It has some connectives for referring to the future It models time as a sequence of states, extending

infinitely to future computation path

The future is not determined, we should consider several paths for different futures Any one of the paths can be the actual path that is

realized


AtomsAtoms

We work with a fixed set of atomic formulas (like p, q, r,…)

They stands for atomic facts which hold for a system Process 897 is blocked The variable x2 is zero

The content of register R1 is 01010


Syntax of LTLSyntax of LTL

The syntax of LTL in BNF is:

where p is any propositional atom from some set Atoms

X, F, G, U, R, W : temporal connectives


Temporal ConnectivesTemporal Connectives

X : neXt state F : some Future state ( eventually) G : all future states (Globally) U : Until R : Release W : Weak-until


Operator precedenceOperator precedence

Unary operators including negation have strongest precedence ¬p U q is parsed as (¬p) U q rather than ¬(p U q)

Temporal binary operators have stronger precedence than non-temporal binary operators p q U r is parsed as: p (q U r)

The precedence over propositional logic is as usual First do the AND then the ORs and XORs finally the IMPLIES and EQUIVALENCEs.


ExampleExample

The parse tree of Fp Gq →p W r according to precedence rules

r

W

GF

qp

p

→


Transition SystemTransition System

A transition system is a structure M = (S, →, L) where S: a finite set of states → : a binary relation on S, such that every s S has

some s ' S with s → s ' L : a labeling function L: S → P( Atoms)

P( Atoms) means the power set of Atoms

The interpretation of the labeling function is that each state s has a set of atomic propositions L(s) which are true at that particular state


ExampleExample

p,q

q,rq

s0

s1s2

S = {s0, s1, s2}

transitions = s0 → s1 , s1

→ s1 , s2 → s1 , s2 → s0 , s0 → s2

L(s0) = {p,q}

L(s1) = {q}

L(s2) = {q,r}


DeadlockDeadlock

We will call the transition systems simply models in our discussions

According to the definition of a model, for each s S there is at least one s' S

No state of a system may be deadlocked If a system has a deadlock, we always add an

extra state sd representing the deadlock


Deadlock stateDeadlock state

s0 s1

s2

s3

s3 doesn’t have any further transitions

adding a deadlock state sd

s0 s1

s2

s3

sd


PathsPaths

A path in a model M = (S, →, L) is an infinite sequence of states s1, s2, s3,…in S such that, for each i 1, si → si+1.

We write paths as s1 → s2 → s3 → …

Each arbitrary path ( e.g. п = s1 → s2 →…) represents a possible future of the system first it is in s1, then s2 and so on

We write пi for the suffix starting at si

п2 is s2 → s3 →…


UnwindingUnwinding

We can unwind the transition system to obtain an infinite computation tree

The execution paths of a model M are explicitly represented in the tree obtained by unwinding the tree


Unwinding: exampleUnwinding: example

p,q

q,rq

s0

s1s2

p,q

p,q

s0

q,r

s2

q

s1

q

s1

q,r

s2s0

p,qq,r

s2s0

q

s1

q,rs2

q

s1

an arbitrary path


Informal semanticsInformal semantics

Globally p : G p G p is true in a state if p holds at all points of time

(along the path) starting from that state

p =

Suppose G p holds in the initial state

0 1 2 3


Informal semantics (cont.)Informal semantics (cont.)

Eventually p : F p F p is true in a state if p holds at some points in

the future, stating from the state

p =

Suppose F p holds in the initial state

0 1 2 3



Next p : X p X p is true along a path starting in a state if p

holds in the next state

p =

Suppose X p holds in state at t=2

0 1 2 3



p Until q : p U q p U q is true in state s if

q is true in some state reachable from s p is true in all states from s until q holds

p = q =

Suppose p U q holds in the initial state

0 1 2 3


A note for UntilA note for Until

Until says nothing about what happens after the Until has been realized

This can be different from natural English speaking For example:

“She continued working until she married” We may interpret the sentence as she discontinued

working after marriage The above understanding is related to this formula

working U ( marriage G ⌐working)


Formal SemanticsFormal Semantics

Let M = (S, →, L) be a model and п = s1 →… be a path in M

Whether п satisfies an LTL formula is defined by the satisfaction relation ╞ as follows:

1

2

3

4


Formal Semantics (cont.)Formal Semantics (cont.)

5

6

7

8

9

10


Formal Semantics (cont.)Formal Semantics (cont.)

Until and Release are dual : φ R ≡ ⌐ (⌐φ U ⌐ )

11

12


ReleaseRelease

Release R is dual of U; that is:

φ R ≡ ⌐ (⌐φ U ⌐ )

must remain true up to and including the moment when φ becomes true (if there is one);

φ releases


Weak UntilWeak Until

φ W : Weak Until is related to the Until with the difference that it does not require that is eventually hold

Essentially φ W is a short form for writing φ U Gφ


LTL satisfaction by a systemLTL satisfaction by a system

Suppose M = ( S, →, L) is a model, s S, and φ an LTL formula

We write M, s╞ φ if for every execution path п of M starting at s, we have п╞ φ

Sometimes M, s╞ φ is abbreviated as s╞ φ


ExampleExample

p,q

p,q

s0

q,r

s2

q

s1

q

s1

q,r

s2s0

p,qq,r

s2s0

q

s1

q,rs2

q

s1

1. M, s0╞ X q

2. M, s0╞ G ⌐(p r)

3. M, s1 ╞ G q

4. M, s0 ╞ p U q


Some practical patternsSome practical patterns

It is impossible to get to a state where started holds, but ready does not hold G ⌐(started ⌐ready)

For any state, if a request occurs, then it will eventually be acknowledged G (requested → F acknowledged)

Whatever happens, a certain process will eventually be permanently deadlocked F G deadlock


Some practical patterns (cont.)Some practical patterns (cont.)

A certain process is enabled infinitely often on every computation path G F enabled In other words, in a path of the system there must never be

a point at which the condition enabled becomes false and stays false forever

If a process is enabled infinitely often, then it runs infinitely often G F enabled → G F running


LTL weaknessLTL weakness

The features which assert the existence of a path are not (directly) expressible in LTL

This problem can be solved by: checking whether all paths satisfy the negation of the required property

A positive answer to this is a negative answer to our original question and vice versa.

BUT: properties which mix universal and existential path quantifiers cannot in general be expressed in LTL


LTL Weakness: ExamplesLTL Weakness: Examples

LTL cannot express these features: From any state it is possible to get to a restart state

(i.e., there is a path from all states to a state satisfying restart)

The lift can remain idle on the third floor with its door closed (i.e., from the state in which it is on the third floor, there is a path along which it stays there)

LTL cannot assert these because it cannot directly assert the existence of paths

However, CTL can express these properties


Expressing Properties by CTLExpressing Properties by CTL

From any state it is possible to get to a restart state (i.e., there is a path from all states to a state satisfying restart) AG(EF restart)

The lift can remain idle on the third floor with its door closed (i.e., from the state in which it is on the third floor, there is a path along which it stays there) AG (floor3 & idle & doorclosed → EG (floor3 & idle &

doorclosed))


EquivalenceEquivalence

We say that two LTL formulas φ and are semantically equivalent φ ≡ if for all models M and all paths п in M: п╞ φ iff п╞

The equivalence of φ and means that φ and are semantically interchangeable

F and G are duals of each other ⌐G φ ≡ F ⌐φ ⌐F φ ≡ G ⌐φ

X is dual with itself ⌐X φ ≡ X ⌐φ


F distributes over and G over F (φ ) ≡ Fφ F G (φ ) ≡ Gφ F

Note that the above formulas are dual But these equivalences do not hold

F (φ ) Fφ F G (φ ) Gφ F

Equivalence (cont.)Equivalence (cont.)

≡

≡


Equivalence (cont.)Equivalence (cont.)

Expressing F and G by U and R F φ ≡ ┬ U φ G φ ≡ ┴ R φ

W and R work rather similarly φ W ≡ R (φ ) φ R ≡ W (φ )


Adequate Sets Adequate Sets

Definition: A set of connectives is adequate if all connectives can be expressed using it

X cannot be derived from any combination of the others

Each of these sets is adequate for LTL {U,X} {R,X} {W,X}


Model checking example:Model checking example:Mutual exclusionMutual exclusion

The mutual exclusion problem (mutex) Avoiding the simultaneous access to some kind of

resources by the critical sections of concurrent processes

The problem is to find a protocol for determining which process is allowed to enter its critical section

Some expected properties for a correct protocol: Safety, Liveness, Non-blocking, No strict sequencing


Safety: Only one process is in its critical section at any time.

Liveness: Whenever any process requests to enter its critical section, it will eventually be permitted to do so.

Non-blocking: A process can always request to enter its critical section.

No strict sequencing: Processes need not enter their critical section in strict sequence.


Modeling mutexModeling mutex

Consider each process to be either in its non-critical state n, trying to enter the critical section t or in it c

Each individual process has this cycle: n → t → c → n → t → c → n …

The processes phases are interleaved


2 process mutex2 process mutex

s0

n1 n2

c1 n2t1 t2

n1 t2t1 n2

n1 c2

t1 c2c1 t2

s1s5

s2s6

s7s4

s3

The processes are asynchronous interleaved one of the processes makes a transition while the other remains

in its current state


The propertiesThe properties

Safety: G ⌐(c1 c2) This formula is satisfied in all states

Liveness: G (t1 → F c1) This formula is not satisfied in the initial state! s0 → s1 → s3 → s7 → s1 → s3 → s7 → …

… p.189 Second attempt: page 191, fig. 3.8


Safety: Only one process is in its critical section at any time:

G ⌐(c1 c2). Liveness: Whenever any process requests to enter its

critical section, it will eventually be permitted to do so: G (t1 → F c1).

Non-blocking: A process can always request to enter its critical section:

(in CTL): AG(n1 → EX t1). No strict sequencing: Processes need not enter their

critical section in strict sequence: Expressing the negation in LTL: G(c1 → c1 W(~c1 & ~c1 W c2)) (in CTL): EF(c1 & E[c1 U (~c1 & E[~c2 U c1])])


s0

n1 n2

c1 n2t1 t2

n1 t2t1 n2

n1 c2

t1 c2c1 t2

s1s5

s2s6

s7s4

s3


CTL* and the expressive powers of CTL* and the expressive powers of LTL and CTLLTL and CTL

CTL over LTL: CTL allows explicit quantification over paths

LTL over CTL: CTL does not allow one to select a range of paths by describing them with a formula, as LTL does. In LTL: all paths which have a p along them also have

a q along them: Fp → Fq In CTL none of these are the same: AF p → AF q Or AG (p → AF q)


CTL*CTL*

Drop the CTL constraint that every … The syntax of CTL* involves two classes of

formulas: State formula, which are evaluated in states Path formulas, which are evaluated along paths


FairnessFairness

Fairness: Fairness is a subtle subject There are several popular definitions of Fairness, such as weak

fairness, strong fairness, …

1. Weak (Buchi) fairness: an action cannot be enabled forever without being taken

FG (enabled taken ) = GF (enabled → taken)

2. Strong (Streett) fairness: an action cannot be enabled infinitely often without being taken

(GF enabled ) → (GF taken )

(Thomas A. Henzinger, Four Lectures on Model Checking)


The propertiesThe properties

Strong fairness makes model checking more difficult

We consider only weak fairness for our example Weak Fairness: GF ( t1 → c1)

This constraint is also violated in the cycle s0 → s1 → s3 → s7 → s1 → s3 → s7 → …


Part 3 : Model Checking with Spin


Practical or TheoreticalPractical or Theoretical

Model checking, despite its theoretical appearance is also a practical subject An outstanding symposium:

“The International SPIN Workshop on Practical Aspects of Model Checking”

Many hardware design companies, including Intel, have adopted model checking as part of their basic design method

Some model checking systems such as NuSMV or SPIN have shown great capability


Plan for this partPlan for this part

In this part of the lecture, we will model a well known problem in the computer science The mutual exclusion problem

We will study the modeling approach in the Spin model checker

To get familiar with this tool, you have to model some more problems yourself


SpinSpin

SPIN (Simple Promela Interpreter) [Holzmann 1991]

Spin is the state-of-the-art model checker More than two decades of research

12 workshops so far Concurrent systems are described in a modeling

language called Promela

Gerard J. Holzmann

NASA JPL Laboratory for Reliable Software


Spin (cont.)Spin (cont.)

It was the winner of the 2001 ACM Software System Award

Some other Software System Award winners: 1983 UNIX 1986 TeX 1987 SMALLTALK 1991 TCP/IP 2002 Java

The award citation: "For SPIN, a highly successful and widely used software model-

checking system based on "formal methods" from Computer Science. It has made advanced theoretical verification methods applicable to large and highly complex software systems."


PromelaPromela

Protocol/Process Meta Language Specification language to model finite-state

systems Loosely based on CSP

dynamic creation of concurrent processes communication via message channels can be

synchronous (i.e. rendezvous), or asynchronous (i.e. buffered)

Features from Dijkstra’s guarded command language


Promela modelsPromela models A Promela model consist of:

1. type declarations

2. channel declarations

3. global variable declarations

4. process declarations

5. [init process]behaviour of the processes:local variables + statements

- simple vars- structured vars- vars can be accessed by all processes

initialises variables andstarts processes

chan ch = [dim] of {type, …} asynchronous: dim > 0 rendezvous: dim == 0

mtype, constants,typedefs (records)


Promela Model (cont.)Promela Model (cont.)

It corresponds to a finite transition system no unbounded: {data, channels, processes, process

creations}mtype = {MSG, ACK} ;

chan toS = ...

bool flag ;

proctype Sender ( bool a) {

....

}

init {

...

}

Processbody

Create Processes


ProcessProcess

A process is defined by a proctype definition executes concurrently with all other processes,

independently of speed or behavior communicates with other processes

using global (shared) variables using channels

There may be several processes of the same type. Each process has its own local state:

process counter (location within the proctype) contents of the local variables


Process (cont.)Process (cont.) A process type (proctype) consist of

a name a list of formal parameters local variable declarations body

proctype Sender(chan in; chan out) { bit sndB, rcvB; do :: out ! MSG, sndB -> in ? ACK, rcvB; if :: sndB == rcvB -> sndB = 1-sndB :: else -> skip fi od}

name

body

formal parameters

The body consist of a sequence of statements.

local variables


proctype Foo(byte x) { ... }

init { int pid2 = run Foo(2); run Foo(27);}

active[3] proctype Bar() { ...}

Process (cont.)Process (cont.)

Process are created using the run statement (which returns the process id).

Processes can be created at any point in the execution (within any process).

Processes start executing after the run statement.

Processes can also be created by adding active in front of the proctype declaration.

number of procs. (opt.)

parameters will be initialised to 0


Basic typesbit turn=1; [0..1]bool flag; [0..1]byte counter; [0..255]short s; [-215.. 215 –1] int msg; [-231.. 231 –1]

Arraysbyte a[27];bit flags[4];

Typedef (records)typedef Record { short f1; byte f2;}Record rr;rr.f1 = ..

Variables and TypesVariables and Types Five different (integer)

basic types.

Arrays

Records (structs)

Type conflicts are detectedat runtime

Default initial value of basic variables (local and global) is 0

array indexing start at 0

variable declaration


int ii;bit bb;

bb=1;ii=2;

short s=-1;

typedef Foo { bit bb; int ii;};Foo f;f.bb = 0;f.ii = -2;

ii*s+27 == 23;printf(“value: %d”, s*s);

Variables and Types (cont.)Variables and Types (cont.)

Variables should be declared.

Variables can be given a value by:

initialization assignment argument passing message passing

Variables can be used in expressions.

assignment =

equality test ==

declaration &initialization


StatementsStatements

A statement is either Executable : if evaluates to non-zero Blocked : if evaluates to zero

An assignment statement is always executable Examples :

1 always executable 0 always blocked (halt) 2 < 3 always executable X < 10 executable, if X is less than 10 5 + Y executable, if Y is not equal to -5


Statements (cont.)Statements (cont.)

Skip always executable (does nothing !) Run is only executable if a new process can be

created ( number of processes is bounded). Printf always executable Are separated by ( ; ) or by ( -> ), arrow is

sometimes also used to show causal relation between successive statements


if-statementif-statement If there is at least one choice executable, if statement is

executable One of the executable choices is non-deterministically

chosen If no choice is executable, the if-statement is blocked

until it becomes executable

if

:: choice1 -> stat1.1; stat1.2; stat1.3; …


:: …

:: choicen -> statn.1; statn.2; statn.3; …

fi


do-statementdo-statement

Behaves in the same way as if-statement with respect to choices

The only difference is it repeats break ( always executable ) exits a do-loop

do



:: …

:: choicen -> statn.1; statn.2; statn.3; …

od


Interleaving semanticsInterleaving semantics

Promela processes execute concurrently. Non-deterministic scheduling of processes. Processes are interleaved, not statements within a

single process. Statements of different processes do not occur at

the same time. All statements are atomic.


Any question?

verification by model checking1 formal methods laboratory university of tehran based on the chapter...

Documents

property verification

verification method

model checking12 model

model checking2

model checking9

model checking10

postdevelopment verification

propertyverification