model checking lecture 2 tom henzinger
Post on 02-Jan-2016
37 Views
Preview:
DESCRIPTION
TRANSCRIPT
Model Checking
Lecture 2
Tom Henzinger
Model-Checking Problem
I |= S
System model System property
a
a,b b
q1
q3q2
System model: State-transition graph
States Q = { q1, q2, q3 }
Atomic observations A = { a, b }
Transition relation Q Q
Observation function [ ] : Q 2A
Run: sequence of states q1, q2
Observation: set of atomic observations
Trace: sequence of observations {a}, {a,b}
-safety (finite runs) vs. liveness (infinite runs)
-linear time (traces) vs. branching time (runs)
-logic (declarative) vs. automata (executable)
System property: 2x2x2 choices
STL (Safe Temporal Logic)
-safety (only finite runs)
-branching (runs, not traces)
-logic
Defining a logic
1. Syntax:
What are the formulas?
2. Semantics:
What are the models?
Does model M satisfy formula ?
M |=
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
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”)
STL Syntax
::= a | | | | U
boolean variable (atomic
observation)
boolean operators
modal operators
STL Model
( K, q )
state-transition graph
state of K
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 exist q0, ..., qn s.t. 1. q = q0 q1 ...
qn 2. for all 0 i < n, (K,qi) |= 3. (K,qn) |=
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
Important safety properties
Invariance a
Sequencing a W b W c W d
= a W (b W (c W d))
Important safety properties: mutex protocol
Invariance (in_cs1 in_cs2)
Sequencing ( req_cs1
in_cs2 W in_cs2 W in_cs2 W in_cs1 )
Branching properties
Deadlock freedom true
Possibility (a b)
(req_cs1 in_cs1)
CTL (Computation Tree Logic)
-safety & liveness
-branching time
-logic
[Clarke & Emerson; Queille & Sifakis 1981]
CTL Syntax
::= a | | | | U |
CTL Model
( K, q )
fair state-transition graph state of K
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) |=
EG exists always
= AF forall eventually
W = ( U ) ( )
U = ( W ) ()
Defined modalities
Important liveness property
Response (a b)
(req_cs1 in_cs1)
If only universial properties are of interest,
why not omit the path quantifiers?
LTL (Linear Temporal Logic)
-safety & liveness
-linear time
-logic
[Pnueli 1977; Lichtenstein & Pnueli 1982]
LTL Syntax
::= a | | | | U
LTL Model
infinite trace t = t0 t1 t2 ...
(K,q) |= iff for all t L(K,q), t |=
(K,q) |= iff exists t L(K,q), t |=
Language of deadlock-free state-transition graph K at state q :
L(K,q) ... set of infinite traces of K starting at q
LTL Semantics
t |= a iff a t0
t |= iff t |= and t |=
t |= iff not t |=
t |= iff t1 t2 ... |=
t |= U iff exists n 0 s.t.1. for all 0 i < n, ti ti+1 ... |
= 2. tn tn+1 ... |=
X next
U U until
= true U F eventually
= G always
W = ( U ) W waiting-for (weak-until)
Defined modalities
Important properties
Invariance a
(in_cs1 in_cs2)
Sequencing a W b W c W d
( req_cs1
in_cs2 W in_cs2 W in_cs2 W in_cs1 )
Response (a b)
(req_cs1 in_cs1)
Composed modalities
a infinitely often a
a almost always a
Where did fairness go ?
Unlike in CTL, fairness can be expressed in LTL !
So there is no need for fairness in the model.
Weak (Buchi) fairness :
(enabled taken )
(enabled taken)
Strong (Streett) fairness :
( enabled ) ( taken )
Starvation freedom, corrected
(in_cs2 out_cs2)
(req_cs1 in_cs1)
CTL cannot express fairness
a a
b b
ba aq0
q1 q2
LTL cannot express branching
Possibility (a b)
So, LTL and CTL are incomparable.
(There are branching logics that can express fairness, e.g. CTL* = CTL + LTL, but they lose the computational attractiveness of CTL.)
Finite Automata
-safety (no infinite runs)
-linear or branching time
-automata (not logic)
Specification Automata
Syntax, given a set A of atomic observations:
S finite set of states
S0 S set of initial states
S S transition relation
: S PL(A) where the formulas of PL are
::= a | |
for a A
Language L(M) of specification automaton
M = (S, S0, , ) :
finite trace t0, ..., tn L(M)
iff
there exists a finite run s0 s1 ... sn of M
such that
for all 0 i n, ti |= (si)
(K,q) |=L M iff L(K,q) L(M)
Linear semantics of specification automata:
language containment
state-transition graph
state of K
specification automaton
finite traces
Invariance specification automaton
in_cs1
in_cs2
Starvation freedom specification automaton
out_cs1
req_cs1
in_cs2req_cs1
in_cs2
in_cs1 req_cs1
in_cs2
Automata are more expressive than logic, because temporal logic cannot count :
This cannot be expressed in LTL.
(How about a (a a) ?)
a true
Checking language containment between finite automata is PSPACE-complete !
L(K,q) L(M)
iff
L(K,q) complement( L(M) ) =
involves determinization (subset construction)
In practice:
1. require deterministic specification automata
2. use monitor automata
3. use branching semantics
Monitor Automata
Syntax:
same as specification automata, except also set E S of error states
Semantics:
define L(M) s.t. runs must end in error states
(K,q) |=C M iff L(K,q) L(M) =
Invariance monitor automaton
in_cs1
in_cs2
in_cs1
in_cs2
Starvation freedom monitor automaton
out_cs1
req_cs1
in_cs2req_cs1
in_cs2
in_cs1 req_cs1
in_cs2
req_cs1
in_cs2
Specification automaton Monitor automaton
M complement(M)
-describe correct traces -describe error traces
-check language containment-check emptiness (linear): (exponential) reachability of error states
“All safety verification is reachability checking.”
Main problem with deterministic specifications and monitor automata:
not suitable for stepwise refinement / abstraction
S1 |= S2 |= S3
“refines”
In practice:
1. require deterministic specification automata
2. use monitor automata
3. use branching semantics
(K,q) |=B M
iff
there exists a simulation relation R Q S s.t. (q,s) R for some initial state s of M
Branching semantics of specification automata:
simulation
states of K
states of M
R Q S is a simulation relation
iff
(q,s) R implies
1. [q] |= (s)
2. for all q’ s.t. q q’ , exists s’ s.t. s s’
and (q’,s’) R.
[Milner 1974]
(K,q) |=L M M language contains (K,q) :exponential check
(K,q) |=B M M simulates (K,q) :quadratic check
X
involves only traces (hence linear !)
involves states (hence branching !)
In practice, simulation is usually the “right” notion.
(If there is language containment, but not simulation, this is usually accidental, not by design.)
Finite Omega-Automata
-safety & liveness (infinite runs !)
-linear or branching time
-automata (not logic)
-specification vs. monitor automata
-linear (language containment) vs. branching (simulation) semantics
We discuss only the linear specification case.
Specification Omega-Automata
Syntax as for finite automata, in addition one of the following acceptance conditions:
Buchi: BA S
coBuchi: CA S
Streett: SA 2S 2S
Rabin: RA 2S 2S
Language L(M) of specification omega-automaton
M = (S, S0, , , A ) :
infinite trace t0, t1, ... L(M)
iff
there exists an infinite run s0 s1 ... of M
such that
1. s0 s1 ... satisfies A
2. for all i 0, ti |= (si)
Let Inf(s) = { p | p = si for infinitely many i }.
The infinite run s satisfies the acceptance condition A
iff
Buchi: Inf(s) BA
coBuchi: Inf(s) CA
Streett: for all (l,r) SA, if Inf(s) l then Inf(s) r
Rabin: for some (l,r) RA, Inf(s) l = and Inf(s) r
Buchi: BA
coBuchi: CA
Streett: (l r)
Rabin: (l r)
(K,q) |=L M iff L(K,q) L(M)
Linear semantics of specification omega-automata:
omega-language containment
infinite traces
Response specification automaton :
(a b) assuming (a b) = false
a b
ba
s1
s2
s3
s0
Buchi condition { s0, s3 }
a a
s0s1
Buchi condition { s0 }
No coBuchi condition
a
Streett condition { ({s0,s1}, {s0}) }
Rabin condition { (,{s0}) }
a a
s0s1
No Buchi condition
coBuchi condition { s0 }
a
Streett condition { ({s1}, ) }
Rabin condition { ({s1}, {s0,s1}) }
a a
s0s1
Buchi condition { s2 }
a
a
s2
-Buchi and coBuchi automata cannot be determinized
-Streett and Rabin automata can be determinized
nondeterministic Buchi =
deterministic Streett = deterministic Rabin =
nondeterministic Streett = nondeterministic Rabin =
omega-regular [Buchi 1960]
Omega-automaton determinization is even harder (conceptually, at least) than finite-automaton determinization [Safra 1989].
So monitor automata and simulation are particularly important.
Omega-automata are strictly more expressive than LTL
Omega-automata: omega-regular languages
LTL: counter-free omega-regular languages
Omega-automata: omega-regular languages = second-order theory of monadic
predicates & successor = omega-regular expressions
LTL: counter-free omega-regular languages = first-order theory of monadic predicates & successor = star-free omega-regular expressions
Structure of the omega-regular languages
Streett = Rabin
Buchi coBuchi
FinitecoFinite
Structure of the counter-free omega-regular languages
positive boolean combinations of and
The location of a linear-time property in the Borel hierarchy indicates how hard (theoretically as well as conceptually) the corresponding model-checking problem is.
positive boolean combinations of and
safety
weak fair
strong fair
response
top related