model checking lecture 1
DESCRIPTION
Model Checking Lecture 1. Outline. 1 Specifications: logic vs. automata, linear vs. branching, safety vs. liveness 2 Graph algorithms for model checking Symbolic algorithms for model checking Pushdown systems. Model checking , narrowly interpreted : - PowerPoint PPT PresentationTRANSCRIPT
![Page 1: Model Checking Lecture 1](https://reader035.vdocuments.site/reader035/viewer/2022062408/56813c64550346895da5f0ce/html5/thumbnails/1.jpg)
Model Checking
Lecture 1
![Page 2: Model Checking Lecture 1](https://reader035.vdocuments.site/reader035/viewer/2022062408/56813c64550346895da5f0ce/html5/thumbnails/2.jpg)
Outline
1 Specifications: logic vs. automata, linear vs. branching, safety vs. liveness
2 Graph algorithms for model checking
3 Symbolic algorithms for model checking
4 Pushdown systems
![Page 3: Model Checking Lecture 1](https://reader035.vdocuments.site/reader035/viewer/2022062408/56813c64550346895da5f0ce/html5/thumbnails/3.jpg)
Model checking, narrowly interpreted:
Decision procedures for checking if a given Kripke structure is a model for a given formula of a modal logic.
![Page 4: Model Checking Lecture 1](https://reader035.vdocuments.site/reader035/viewer/2022062408/56813c64550346895da5f0ce/html5/thumbnails/4.jpg)
Why is this of interest to us?
Because the dynamics of a discrete system can be captured by a Kripke structure.
Because some dynamic properties of a discrete system can be stated in modal logics.
Model checking = System verification
![Page 5: Model Checking Lecture 1](https://reader035.vdocuments.site/reader035/viewer/2022062408/56813c64550346895da5f0ce/html5/thumbnails/5.jpg)
Model checking, generously interpreted:
Algorithms, rather than proof calculi, for system verification which operate on a system model (semantics), rather than a system description (syntax).
![Page 6: Model Checking Lecture 1](https://reader035.vdocuments.site/reader035/viewer/2022062408/56813c64550346895da5f0ce/html5/thumbnails/6.jpg)
There are many different model-checking problems:
for different (classes of) system models
for different (classes of) system properties
![Page 7: Model Checking Lecture 1](https://reader035.vdocuments.site/reader035/viewer/2022062408/56813c64550346895da5f0ce/html5/thumbnails/7.jpg)
A specific model-checking problem is defined by
I |= S
“implementation” (system model)
“specification” (system property)
“satisfies”, “implements”, “refines” (satisfaction relation)
![Page 8: Model Checking Lecture 1](https://reader035.vdocuments.site/reader035/viewer/2022062408/56813c64550346895da5f0ce/html5/thumbnails/8.jpg)
A specific model-checking problem is defined by
I |= S
“implementation” (system model)
“specification” (system property)
“satisfies”, “implements”, “refines” (satisfaction relation)
more detailed
more abstract
![Page 9: Model Checking Lecture 1](https://reader035.vdocuments.site/reader035/viewer/2022062408/56813c64550346895da5f0ce/html5/thumbnails/9.jpg)
Characteristics of system models which favor model checking over other verification techniques:
ongoing input/output behavior (not: single input, single result)
concurrency (not: single control flow)
control intensive (not: lots of data manipulation)
![Page 10: Model Checking Lecture 1](https://reader035.vdocuments.site/reader035/viewer/2022062408/56813c64550346895da5f0ce/html5/thumbnails/10.jpg)
Examples
-control logic of hardware designs
-communication protocols
-device drivers
![Page 11: Model Checking Lecture 1](https://reader035.vdocuments.site/reader035/viewer/2022062408/56813c64550346895da5f0ce/html5/thumbnails/11.jpg)
Paradigmatic example:
mutual-exclusion protocol
loop
out: x1 := 1; last := 1
req: await x2 = 0 or last = 2
in: x1 := 0
end loop.
loop
out: x2 := 1; last := 2
req: await x1 = 0 or last = 1
in: x2 := 0
end loop.
||
P1 P2
![Page 12: Model Checking Lecture 1](https://reader035.vdocuments.site/reader035/viewer/2022062408/56813c64550346895da5f0ce/html5/thumbnails/12.jpg)
Model-checking problem
I |= S
system model system property
satisfaction relation
![Page 13: Model Checking Lecture 1](https://reader035.vdocuments.site/reader035/viewer/2022062408/56813c64550346895da5f0ce/html5/thumbnails/13.jpg)
Model-checking problem
I |= S
system model system property
satisfaction relation
![Page 14: Model Checking Lecture 1](https://reader035.vdocuments.site/reader035/viewer/2022062408/56813c64550346895da5f0ce/html5/thumbnails/14.jpg)
Important decisions when choosing a system model
-state-based vs. event-based
-interleaving vs. true concurrency
-synchronous vs. asynchronous interaction
-etc.
![Page 15: Model Checking Lecture 1](https://reader035.vdocuments.site/reader035/viewer/2022062408/56813c64550346895da5f0ce/html5/thumbnails/15.jpg)
Particular combinations of choices yield
CSP
Petri nets
I/O automata
Reactive modules
etc.
![Page 16: Model Checking Lecture 1](https://reader035.vdocuments.site/reader035/viewer/2022062408/56813c64550346895da5f0ce/html5/thumbnails/16.jpg)
While the choice of system model is important for ease of modeling in a given situation,
the only thing that is important for model checking is that the system model can be translated into some form of state-transition graph.
![Page 17: Model Checking Lecture 1](https://reader035.vdocuments.site/reader035/viewer/2022062408/56813c64550346895da5f0ce/html5/thumbnails/17.jpg)
a
a,b b
q1
q3q2
![Page 18: Model Checking Lecture 1](https://reader035.vdocuments.site/reader035/viewer/2022062408/56813c64550346895da5f0ce/html5/thumbnails/18.jpg)
State-transition graph
Q set of states {q1,q2,q3}
A set of atomic observations {a,b}
Q Q transition relation q1 q2
[ ]: Q 2A observation function [q1] = {a}
set of observations
![Page 19: Model Checking Lecture 1](https://reader035.vdocuments.site/reader035/viewer/2022062408/56813c64550346895da5f0ce/html5/thumbnails/19.jpg)
Mutual-exclusion protocol
loop
out: x1 := 1; last := 1
req: await x2 = 0 or last = 2
in: x1 := 0
end loop.
loop
out: x2 := 1; last := 2
req: await x1 = 0 or last = 1
in: x2 := 0
end loop.
||
P1 P2
![Page 20: Model Checking Lecture 1](https://reader035.vdocuments.site/reader035/viewer/2022062408/56813c64550346895da5f0ce/html5/thumbnails/20.jpg)
oo001
rr112
ro101 or012
ir112
io101
pc1: {o,r,i} pc2: {o,r,i} x1: {0,1} x2: {0,1} last: {1,2}
33222 = 72 states
![Page 21: Model Checking Lecture 1](https://reader035.vdocuments.site/reader035/viewer/2022062408/56813c64550346895da5f0ce/html5/thumbnails/21.jpg)
The translation from a system description to a state-transition graph usually involves an exponential blow-up !!!
e.g., n boolean variables 2n states
This is called the “state-explosion problem.”
![Page 22: Model Checking Lecture 1](https://reader035.vdocuments.site/reader035/viewer/2022062408/56813c64550346895da5f0ce/html5/thumbnails/22.jpg)
Finite state-transition graphs don’t handle:- recursion (need pushdown models)
- process creation
We will talk about some of these issues in a later lecture.
State-transition graphs are not necessarily finite-state
![Page 23: Model Checking Lecture 1](https://reader035.vdocuments.site/reader035/viewer/2022062408/56813c64550346895da5f0ce/html5/thumbnails/23.jpg)
Model-checking problem
I |= S
system model system property
satisfaction relation
![Page 24: Model Checking Lecture 1](https://reader035.vdocuments.site/reader035/viewer/2022062408/56813c64550346895da5f0ce/html5/thumbnails/24.jpg)
Three important decisions when choosing system properties:
1 automata vs. logic
2 branching vs. linear time
3 safety vs. liveness
![Page 25: Model Checking Lecture 1](https://reader035.vdocuments.site/reader035/viewer/2022062408/56813c64550346895da5f0ce/html5/thumbnails/25.jpg)
Three important decisions when choosing system properties:
1 automata vs. logic
2 branching vs. linear time
3 safety vs. liveness
The three decisions are orthogonal, and they lead to substantially different model-checking problems.
![Page 26: Model Checking Lecture 1](https://reader035.vdocuments.site/reader035/viewer/2022062408/56813c64550346895da5f0ce/html5/thumbnails/26.jpg)
Three important decisions when choosing system properties:
1 automata vs. logic
2 branching vs. linear time
3 safety vs. liveness
The three decisions are orthogonal, and they lead to substantially different model-checking problems.
![Page 27: Model Checking Lecture 1](https://reader035.vdocuments.site/reader035/viewer/2022062408/56813c64550346895da5f0ce/html5/thumbnails/27.jpg)
Safety vs. liveness
Safety: something “bad” will never happen
Liveness: something “good” will happen (but we don’t know when)
![Page 28: Model Checking Lecture 1](https://reader035.vdocuments.site/reader035/viewer/2022062408/56813c64550346895da5f0ce/html5/thumbnails/28.jpg)
Safety vs. liveness for sequential programs
Safety: the program will never produce a wrong result (“partial
correctness”)
Liveness: the program will produce a result (“termination”)
![Page 29: Model Checking Lecture 1](https://reader035.vdocuments.site/reader035/viewer/2022062408/56813c64550346895da5f0ce/html5/thumbnails/29.jpg)
Safety vs. liveness for sequential programs
Safety: the program will never produce a wrong result (“partial
correctness”)
Liveness: the program will produce a result (“termination”)
![Page 30: Model Checking Lecture 1](https://reader035.vdocuments.site/reader035/viewer/2022062408/56813c64550346895da5f0ce/html5/thumbnails/30.jpg)
Safety vs. liveness for state-transition graphs
Safety: those properties whose violation always has a finite witness
(“if something bad happens on an infinite run, then it happens already on some finite prefix”)
Liveness: those properties whose violation never has a finite witness (“no matter what happens along a finite run, something good could still happen later”)
![Page 31: Model Checking Lecture 1](https://reader035.vdocuments.site/reader035/viewer/2022062408/56813c64550346895da5f0ce/html5/thumbnails/31.jpg)
a
a,b b
q1
q3q2
Run: q1 q3 q1 q3 q1 q2 q2
Trace: a b a b a a,b a,b
![Page 32: Model Checking Lecture 1](https://reader035.vdocuments.site/reader035/viewer/2022062408/56813c64550346895da5f0ce/html5/thumbnails/32.jpg)
State-transition graph S = ( Q, A, , [] )
Finite runs: finRuns(S) Q*
Infinite runs: infRuns(S) Q
Finite traces: finTraces(S) (2A)*
Infinite traces: infTraces(S) (2A)
![Page 33: Model Checking Lecture 1](https://reader035.vdocuments.site/reader035/viewer/2022062408/56813c64550346895da5f0ce/html5/thumbnails/33.jpg)
Safety: the properties that can be checked on finRuns
Liveness: the properties that cannot be checked on finRuns
![Page 34: Model Checking Lecture 1](https://reader035.vdocuments.site/reader035/viewer/2022062408/56813c64550346895da5f0ce/html5/thumbnails/34.jpg)
Safety: the properties that can be checked on finRuns
Liveness: the properties that cannot be checked on finRuns
(they need to be checked on infRuns)
This is much easier.
![Page 35: Model Checking Lecture 1](https://reader035.vdocuments.site/reader035/viewer/2022062408/56813c64550346895da5f0ce/html5/thumbnails/35.jpg)
Example: Mutual exclusion
It cannot happen that both processes are in their critical sections simultaneously.
![Page 36: Model Checking Lecture 1](https://reader035.vdocuments.site/reader035/viewer/2022062408/56813c64550346895da5f0ce/html5/thumbnails/36.jpg)
Example: Mutual exclusion
It cannot happen that both processes are in their critical sections simultaneously.
Safety
![Page 37: Model Checking Lecture 1](https://reader035.vdocuments.site/reader035/viewer/2022062408/56813c64550346895da5f0ce/html5/thumbnails/37.jpg)
Example: Bounded overtaking
Whenever process P1 wants to enter the critical section, then process P2 gets to enter at most once before process P1 gets to enter.
![Page 38: Model Checking Lecture 1](https://reader035.vdocuments.site/reader035/viewer/2022062408/56813c64550346895da5f0ce/html5/thumbnails/38.jpg)
Example: Bounded overtaking
Whenever process P1 wants to enter the critical section, then process P2 gets to enter at most once before process P1 gets to enter.
Safety
![Page 39: Model Checking Lecture 1](https://reader035.vdocuments.site/reader035/viewer/2022062408/56813c64550346895da5f0ce/html5/thumbnails/39.jpg)
Example: Starvation freedom
Whenever process P1 wants to enter the critical section, provided process P2 never stays in the critical section forever, P1 gets to enter eventually.
![Page 40: Model Checking Lecture 1](https://reader035.vdocuments.site/reader035/viewer/2022062408/56813c64550346895da5f0ce/html5/thumbnails/40.jpg)
Example: Starvation freedom
Whenever process P1 wants to enter the critical section, provided process P2 never stays in the critical section forever, P1 gets to enter eventually.
Liveness
![Page 41: Model Checking Lecture 1](https://reader035.vdocuments.site/reader035/viewer/2022062408/56813c64550346895da5f0ce/html5/thumbnails/41.jpg)
a
a,b b
q1
q3q2
infRuns finRuns
![Page 42: Model Checking Lecture 1](https://reader035.vdocuments.site/reader035/viewer/2022062408/56813c64550346895da5f0ce/html5/thumbnails/42.jpg)
a
a,b b
q1
q3q2
infRuns finRuns
* closure
*finite branching
![Page 43: Model Checking Lecture 1](https://reader035.vdocuments.site/reader035/viewer/2022062408/56813c64550346895da5f0ce/html5/thumbnails/43.jpg)
For state-transition graphs, all properties are safety properties !
![Page 44: Model Checking Lecture 1](https://reader035.vdocuments.site/reader035/viewer/2022062408/56813c64550346895da5f0ce/html5/thumbnails/44.jpg)
Example: Starvation freedom
Whenever process P1 wants to enter the critical section, provided process P2 never stays in the critical section forever, P1 gets to enter eventually.
Liveness
![Page 45: Model Checking Lecture 1](https://reader035.vdocuments.site/reader035/viewer/2022062408/56813c64550346895da5f0ce/html5/thumbnails/45.jpg)
a
a,b b
q1
q3q2
Fairness constraint:
the green transition cannot be ignored forever
![Page 46: Model Checking Lecture 1](https://reader035.vdocuments.site/reader035/viewer/2022062408/56813c64550346895da5f0ce/html5/thumbnails/46.jpg)
a
a,b b
q1
q3q2
Without fairness: infRuns = q1 (q3 q1)* q2 (q1
q3)
With fairness: infRuns = q1 (q3 q1)* q2
![Page 47: Model Checking Lecture 1](https://reader035.vdocuments.site/reader035/viewer/2022062408/56813c64550346895da5f0ce/html5/thumbnails/47.jpg)
Two important types of fairness
1 Weak (Buchi) fairness: a specified set of transitions cannot be enabled forever without being taken
2 Strong (Streett) fairness:a specified set of transitions cannot be enabled infinitely often without being
taken
![Page 48: Model Checking Lecture 1](https://reader035.vdocuments.site/reader035/viewer/2022062408/56813c64550346895da5f0ce/html5/thumbnails/48.jpg)
a
a,b b
q1
q3q2
Strong fairness
![Page 49: Model Checking Lecture 1](https://reader035.vdocuments.site/reader035/viewer/2022062408/56813c64550346895da5f0ce/html5/thumbnails/49.jpg)
a
a,b
q1
q2
Weak fairness
![Page 50: Model Checking Lecture 1](https://reader035.vdocuments.site/reader035/viewer/2022062408/56813c64550346895da5f0ce/html5/thumbnails/50.jpg)
Fair state-transition graph S = ( Q, A, , [], WF, SF)
WF set of weakly fair actions
SF set of strongly fair actions
where each action is a subset of
![Page 51: Model Checking Lecture 1](https://reader035.vdocuments.site/reader035/viewer/2022062408/56813c64550346895da5f0ce/html5/thumbnails/51.jpg)
Weak fairness comes from modeling concurrency
loop x:=0 end loop.
loop x:=1 end loop.
||
x=0 x=1
Weakly fair action Weakly fair action
![Page 52: Model Checking Lecture 1](https://reader035.vdocuments.site/reader035/viewer/2022062408/56813c64550346895da5f0ce/html5/thumbnails/52.jpg)
Strong fairness comes from modeling choice
Strongly fair action Strongly fair action
loop m: n: x:=0 | x:=1 end loop.
pc=n x=0
pc=n x=1
pc=m x=0
pc=m x=1
![Page 53: Model Checking Lecture 1](https://reader035.vdocuments.site/reader035/viewer/2022062408/56813c64550346895da5f0ce/html5/thumbnails/53.jpg)
Weak fairness is sufficient for asynchronous models (“no process waits forever if it can move”).
Strong fairness is necessary for modeling resource contention.
Strong fairness makes model checking more difficult.
![Page 54: Model Checking Lecture 1](https://reader035.vdocuments.site/reader035/viewer/2022062408/56813c64550346895da5f0ce/html5/thumbnails/54.jpg)
Fairness changes only infRuns, not finRuns.
Fairness can be ignored for checking safety properties.
![Page 55: Model Checking Lecture 1](https://reader035.vdocuments.site/reader035/viewer/2022062408/56813c64550346895da5f0ce/html5/thumbnails/55.jpg)
The vast majority of properties to be verified are safety.
While nobody will ever observe the violation of a true liveness property, fairness is a useful abstraction that turns complicated safety into simple liveness.
Two remarks
![Page 56: Model Checking Lecture 1](https://reader035.vdocuments.site/reader035/viewer/2022062408/56813c64550346895da5f0ce/html5/thumbnails/56.jpg)
Three important decisions when choosing system properties:
1 automata vs. logic
2 branching vs. linear time
3 safety vs. liveness
The three decisions are orthogonal, and they lead to substantially different model-checking problems.
![Page 57: Model Checking Lecture 1](https://reader035.vdocuments.site/reader035/viewer/2022062408/56813c64550346895da5f0ce/html5/thumbnails/57.jpg)
Fair state-transition graph S = ( Q, A, , [], WF, SF )
Finite runs: finRuns(S) Q*
Infinite runs: infRuns(S) Q
Finite traces: finTraces(S) (2A)*
Infinite traces: infTraces(S) (2A)
![Page 58: Model Checking Lecture 1](https://reader035.vdocuments.site/reader035/viewer/2022062408/56813c64550346895da5f0ce/html5/thumbnails/58.jpg)
Linear time: the properties that can be checked on infTraces
Branching time: the properties that cannot be checked on infTraces
Branching vs. linear time
![Page 59: Model Checking Lecture 1](https://reader035.vdocuments.site/reader035/viewer/2022062408/56813c64550346895da5f0ce/html5/thumbnails/59.jpg)
a
xxx
a
b bc c
Same traces {axb, axc} Different runs {q0 q1 q3, q0 q2 q4}, {q0 q1 q3, q0 q1 q4}
q0q0
q2q1 q1
q4 q4q3q3
![Page 60: Model Checking Lecture 1](https://reader035.vdocuments.site/reader035/viewer/2022062408/56813c64550346895da5f0ce/html5/thumbnails/60.jpg)
a
xxx
a
b bc c
q0q0
q2q1 q1
q4 q4q3q3
Linear-time:In all traces, an x must happen immediately followed by b
![Page 61: Model Checking Lecture 1](https://reader035.vdocuments.site/reader035/viewer/2022062408/56813c64550346895da5f0ce/html5/thumbnails/61.jpg)
a
xxx
a
b bc c
q0q0
q2q1 q1
q4 q4q3q3
Linear-time:In all traces, an x must happen immediately followed by b or c
![Page 62: Model Checking Lecture 1](https://reader035.vdocuments.site/reader035/viewer/2022062408/56813c64550346895da5f0ce/html5/thumbnails/62.jpg)
a
xxx
a
b bc c
q0q0
q2q1 q1
q4 q4q3q3
Branching-time:An x must happen immediately following which a b may happen and a c may happen
![Page 63: Model Checking Lecture 1](https://reader035.vdocuments.site/reader035/viewer/2022062408/56813c64550346895da5f0ce/html5/thumbnails/63.jpg)
a
aaa
a
b bc c
Same traces, different runs (different trace trees)
![Page 64: Model Checking Lecture 1](https://reader035.vdocuments.site/reader035/viewer/2022062408/56813c64550346895da5f0ce/html5/thumbnails/64.jpg)
Three important decisions when choosing system properties:
1 automata vs. logic
2 branching vs. linear time
3 safety vs. liveness
The three decisions are orthogonal, and they lead to substantially different model-checking problems.
![Page 65: Model Checking Lecture 1](https://reader035.vdocuments.site/reader035/viewer/2022062408/56813c64550346895da5f0ce/html5/thumbnails/65.jpg)
LinearBranching
Safety STL
Liveness LTL CTL
Logics
![Page 66: Model Checking Lecture 1](https://reader035.vdocuments.site/reader035/viewer/2022062408/56813c64550346895da5f0ce/html5/thumbnails/66.jpg)
STL (Safe Temporal Logic)
- safety (only finite runs)
- branching
![Page 67: Model Checking Lecture 1](https://reader035.vdocuments.site/reader035/viewer/2022062408/56813c64550346895da5f0ce/html5/thumbnails/67.jpg)
Defining a logic
1. Syntax:
What are the formulas?
2. Semantics:
What are the models?
Does model M satisfy formula ?
M |=
![Page 68: Model Checking Lecture 1](https://reader035.vdocuments.site/reader035/viewer/2022062408/56813c64550346895da5f0ce/html5/thumbnails/68.jpg)
Propositional logics:
1. boolean variables (a,b) & boolean operators (,)
2. model = truth-value assignment for variables
Propositional modal (e.g., temporal) logics:
1. ... & modal operators (,)
2. model = set of (e.g., temporally) related prop. models
![Page 69: Model Checking Lecture 1](https://reader035.vdocuments.site/reader035/viewer/2022062408/56813c64550346895da5f0ce/html5/thumbnails/69.jpg)
Propositional logics:
1. boolean variables (a,b) & boolean operators (,)
2. model = truth-value assignment for variables
Propositional modal (e.g., temporal) logics:
1. ... & modal operators (,)
2. model = set of (e.g., temporally) related prop. models observations
state-transition graph (“Kripke structure”)
atomic observations
![Page 70: Model Checking Lecture 1](https://reader035.vdocuments.site/reader035/viewer/2022062408/56813c64550346895da5f0ce/html5/thumbnails/70.jpg)
STL Syntax
::= a | | | | U
boolean variable (atomic
observation)
boolean operators
modal operators
![Page 71: Model Checking Lecture 1](https://reader035.vdocuments.site/reader035/viewer/2022062408/56813c64550346895da5f0ce/html5/thumbnails/71.jpg)
STL Model
( K, q )
state-transition graph (Kripke
structure)
state of K
![Page 72: Model Checking Lecture 1](https://reader035.vdocuments.site/reader035/viewer/2022062408/56813c64550346895da5f0ce/html5/thumbnails/72.jpg)
STL Semantics
(K,q) |= a iff a [q]
(K,q) |= iff (K,q) |= and (K,q) |=
(K,q) |= iff not (K,q) |=
(K,q) |= iff exists q’ s.t. q q’ and (K,q’) |=
(K,q) |= U iff exists q = q0 q1 ... qn. 1. for all 0
i < n, (K,qi) |= 2. (K,qn) |=
![Page 73: Model Checking Lecture 1](https://reader035.vdocuments.site/reader035/viewer/2022062408/56813c64550346895da5f0ce/html5/thumbnails/73.jpg)
EX exists next
= AX forall next
U EU exists until
= true U EF exists eventually
= AG forall always
W = ( () U ( ))
AW forall waiting-for (forall weak-
until)
Defined modalities
![Page 74: Model Checking Lecture 1](https://reader035.vdocuments.site/reader035/viewer/2022062408/56813c64550346895da5f0ce/html5/thumbnails/74.jpg)
Exercise
1. Derive the semantics of W :
(K,q) |= W iff for all q0, q1, q2, … s.t. q = q0 q1 q2
…, either for all i0, (K,qi) |= , or exists n0 s.t. 1. for all 0 i < n, (K,qi) |= 2. (K,qn) |=
2. Derive the semantics of ( () U ()) :
(K,q) |= ( () U ()) iff ???
![Page 75: Model Checking Lecture 1](https://reader035.vdocuments.site/reader035/viewer/2022062408/56813c64550346895da5f0ce/html5/thumbnails/75.jpg)
(K,q) |= W
For all executions starting from q, is satisfied at or before a (the first) violation of .
(K,q) |= W iff(K,q) |= ( () U ( )) iff (exists q = q0 q1 ... qn. for all 0 i < n. (K,qi) |= and (K,qn) |= ) ifffor all q = q0 q1 ... qn. exists 0 i < n. (K,qi) |= or (K,qn) |= ifffor all q = q0 q1 ... qn. exists 0 i n. (K,qi) |= or (K,qn) |= ifffor all q = q0 q1 ... qn. (K,qn) |= exists 0 i n. (K,qi) |=
![Page 76: Model Checking Lecture 1](https://reader035.vdocuments.site/reader035/viewer/2022062408/56813c64550346895da5f0ce/html5/thumbnails/76.jpg)
Important safety properties
Invariance a
Sequencing a W b W c W d
= a W (b W (c W d))
![Page 77: Model Checking Lecture 1](https://reader035.vdocuments.site/reader035/viewer/2022062408/56813c64550346895da5f0ce/html5/thumbnails/77.jpg)
Important safety properties: mutex protocol
Invariance (pc1=in pc2=in)
Sequencing ( pc1=req
(pc2in) W (pc2=in) W (pc2in) W (pc1=in))
![Page 78: Model Checking Lecture 1](https://reader035.vdocuments.site/reader035/viewer/2022062408/56813c64550346895da5f0ce/html5/thumbnails/78.jpg)
Branching properties
Deadlock freedom true
Possibility (a b)
(pc1=req (pc1=in))
![Page 79: Model Checking Lecture 1](https://reader035.vdocuments.site/reader035/viewer/2022062408/56813c64550346895da5f0ce/html5/thumbnails/79.jpg)
CTL (Computation Tree Logic)
-safety & liveness
-branching time
[Clarke & Emerson; Queille & Sifakis 1981]
![Page 80: Model Checking Lecture 1](https://reader035.vdocuments.site/reader035/viewer/2022062408/56813c64550346895da5f0ce/html5/thumbnails/80.jpg)
CTL Syntax
::= a | | | | U |
![Page 81: Model Checking Lecture 1](https://reader035.vdocuments.site/reader035/viewer/2022062408/56813c64550346895da5f0ce/html5/thumbnails/81.jpg)
CTL Model
( K, q )
fair state-transition graph state of K
![Page 82: Model Checking Lecture 1](https://reader035.vdocuments.site/reader035/viewer/2022062408/56813c64550346895da5f0ce/html5/thumbnails/82.jpg)
CTL Semantics
(K,q) |= iff exist q0, q1, ... s.t.
1. q = q0 q1 ... is an infinite fair run
2. for all i 0, (K,qi) |=
![Page 83: Model Checking Lecture 1](https://reader035.vdocuments.site/reader035/viewer/2022062408/56813c64550346895da5f0ce/html5/thumbnails/83.jpg)
EG exists always
= AF forall eventually
W = ( U ) ( )
U = ( W ) ()
Defined modalities
![Page 84: Model Checking Lecture 1](https://reader035.vdocuments.site/reader035/viewer/2022062408/56813c64550346895da5f0ce/html5/thumbnails/84.jpg)
Important liveness property
Response (a b)
(pc1=req (pc1=in))