Lecture 13 :Temporal logic and automata

Download Report

Transcript Lecture 13 :Temporal logic and automata

Model checking
1
And now... the system


How do we model a reactive system with an automaton ?
It is convenient to model systems with

Transition systems (textutal representation),
or, equivalenely, with a

Kripke structures (automata representation).
2
Kripke structures



A convenient model for describing reactive systems
Implicitly all states are accepting.
M=hS, , I, Li




S: States (finite).
 µ S x S is the transition relation.
I µ S are the Initial states.
L: S ) 2AP (where AP is a set of atomic propositions)
Convention:
we will only
write the
positive
literals.
3
A Kripke structure


Note: the alphabet is NOT the set AP.
Rather it is 2AP
4
From a Kripke structure to a Buchi automata

Given a Kripke structure M=hS, M, IM, Li...
...we can build an equivalent
Buchi automata BM = h, S, ¢, I, Fi where





 = 2Prop
S // same states
(s, t) 2 ¢ iff (s,t) 2 ¢M and a = L(s) // transition relation
I = IM // same initial state
F = S //every state is accepting
Example

Recall that this
is {p,q}
The system: M =
p,q
p
becomes the Buchi automaton
(recall: a transition is labelled with
an element of 2AP)
p,q

p

p
Correctness condition

An LTL formula  = a set of allowed computations
(‘models’).

A Kripke structure M = a set of computations.

Are the computations of M models of  ?
7
Correctness
Sequences satisfying Spec
Program
computations
All sequences
8
Incorrectness
Counter
examples
Sequences satisfying Spec
Program
computations
All sequences
9
Model-Checking: formally

Language of a model M: L(M)
Language of a specification : L().

We need: L(M)  L().

This is called Model-Checking

If yes, we write M ²  .
10
Model checking – example
: G (p U q)
s0
p,y
p,x
s2
s1
p
q
q,x
model M
spec B
M²?
Let  = s0,s1.
2 L(M) but   L(B).
Hence L(M) * L(B).
11
How to model-check?

Show that L(Model)  L(Spec).

Equivalently:
Show that L(Model)  L(Spec) = Ø.

How? Check that Amodel £ A:Spec is empty.
M
S
MµS
M
:S
MÅ:S;
12
What do we need to know?
L(Model)  L(Spec) = Ø.
1.
2.
3.
4.
How
How
How
How
to
to
to
to
translate from LTL to an automaton ?
complement an automaton?
intersect two automata?
check for emptiness of an automaton ?
13
How to complement?


Complementation is hard!
We know how to translate an LTL formula to a Buchi
automaton. So we can:


Build an automaton A for , and complement A, or
Negate the property, obtaining ¬ (the sequences that should
never occur). Build an automaton for ¬ .
14
But... reacall...


Theoretically, model checking gives us a proof of
correctness
Practically, it mainly attempts to increase reliability:



Automated systematic debugging
VERY good at finding errors!
Why ?




Possible bugs in the model checker
Capacity limitations
Wrong or missing properties
...
15
From programs to Kripke structures

Supposed that we wish to model-check a program /
concurrent program –

How can we represent it as a Kripke structure ?
16
Kripke structures


Kripke structures are suitable for modeling a
synchronous system.
When we move from state s to state s’, the values of the
atoms in the state are changed synchronously.

Is this the case for programs ?

How can we describe programs as transition systems?
17
Programs as transition systems


Programs we know are sequential.
What is the result of this computation :
...
x = y;
y = x;

We need to model the location in the program

We will use a variable called the program counter (PC)
18
Example: A program that maintains mutual exclusion
Initially: pc0=L0 Æ pc1=L1
L0:While True do
nc0:wait (Turn=0);
||
L1:While True do
cr0:Turn=1
Possible transitions:
nc1:wait (Turn=1);
cr1:Turn=0
T0: (pc0=L0,
T1: (pc0=nc0 Æ Turn=0,
T2: (pc0=cr0,
pc0=nc0)
pc0=cr0)
pc0 = L0 Æ Turn=1)
T3: (pc1=L1,
T4: (pc1=nc1 Æ Turn=1,
T5: (pc1=cr1,
pc1=nc1)
pc1=cr1)
pc1 = L1 Æ Turn = 0)
19
And now as a Kripke structure
PC0 = L0,
PC1 = L1
Turn=0
L0,L1
Turn=1
L0,L1
Turn=0
L0,nc1
Turn=0
nc0,L1
Turn=1
L0,nc1
Turn=1
nc0,L1
Turn=0
Turn=0
cr0,L1
Turn=1
L0,cr1
Turn=1
Turn=0
Turn=1
cr0,nc1
nc0,cr1
nc0,nc1
nc0,nc1
20
G :(pc0=cr0 Æ pc1=cr1)
(a safety property)
Turn=0
L0,L1
Turn=1
L0,L1
Turn=0
L0,nc1
Turn=0
nc0,L1
Turn=1
L0,nc1
Turn=1
nc0,L1
Turn=0
Turn=0
cr0,L1
Turn=1
L0,cr1
Turn=1
Turn=0
Turn=1
cr0,nc1
nc0,cr1
nc0,nc1
nc0,nc1
21
G(Turn=0 ! F Turn=1)
(a liveness property)
Turn=1
L0,L1
Turn=0
L0,L1
Turn=0
L0,nc1
Turn=0
nc0,L1
Turn=1
L0,nc1
Turn=1
nc0,L1
Turn=0
Turn=0
cr0,L1
Turn=1
L0,cr1
Turn=1
Turn=0
Turn=1
cr0,nc1
nc0,cr1
nc0,nc1
nc0,nc1
22
What properties can we check?

Examples:



Invariants: a property that has to hold in each state.
Deadlock detection: can we reach a state where the program
is blocked?
Dead code: does the program have parts that are never
executed?
23
If it is so good, is this all we need?

Model checking works only for finite state systems.
Would not work with




Unconstrained integers.
Unbounded message queues.
General data structures:
 queues
 trees
 stacks
Parametric algorithms and systems.
24
The state space explosion problem

Need to represent the state space of a program in
the computer memory.


Each state can be as big as the entire memory!
Many states:


Each integer variable has 232 possibilities. Two such variables
have 264 possibilities.
In concurrent protocols, the number of states usually grows
exponentially with the number of processes.
25
If it is so constrained, is it of any use?


Many protocols are finite state.
Many programs or procedures are finite state in
nature. Can use abstraction techniques.
26
If it is so constrained, is it of any use?



Sometimes it is possible to decompose a program,
and prove part of it by model checking and part by
other methods.
Many techniques to reduce the state space explosion
We will NOT learn about such techniques, but let us
mention some names:


Data structures such as Binary Decision Diagrams,
Reductions, such as Partial Order Reduction.
27