automated reasoning ltl model checking
play

Automated Reasoning LTL Model Checking Alan Bundy Automated - PowerPoint PPT Presentation

Automated Reasoning LTL Model Checking Alan Bundy Automated Reasoning LTL Model Checking Lecture 9, page 1 Introduction So far we have looked at theorem proving Powerful, especially where good sets of rewrite rules or decision procedures


  1. Automated Reasoning LTL Model Checking Alan Bundy Automated Reasoning LTL Model Checking Lecture 9, page 1

  2. Introduction So far we have looked at theorem proving Powerful, especially where good sets of rewrite rules or decision procedures have been defined But often requires interactive guidance or specialised domain knowledge to automate Another approach to formal reasoning is model checking Used to decide whether certain properties hold of some formally specified model of a domain Automatic technique which searches through the states of the model for a solution Automated Reasoning LTL Model Checking Lecture 9, page 2

  3. Motivation Model checking can be applied to verify formally the correctness of systems used in critical situations Successfully used in hardware and protocol verification Now being applied to verify software systems software commonly tested through trial and error at unit level and systems level (simulation) major errors can and do and do slip through classic testing modes were never meant to be applied to multi- threaded systems Automated Reasoning LTL Model Checking Lecture 9, page 3

  4. Systems Design requirements Ideally we should build systems engineering models to analyse Finding errors potential violations of a systems design earlier means systems requirements high level architecture cost savings later and not progress until and more our models are provably reliable product. detailed design correct. code structure coding We should only be testing minor issues here. testing operation Automated Reasoning LTL Model Checking Lecture 9, page 4

  5. Formal Verification To ensure correct behaviour of a system, the basic engineering approach could be: requirements → logic prototype → logic model analysis → formal verification Theorem Proving or Model Checking Automated Reasoning LTL Model Checking Lecture 9, page 5

  6. Model Checking We build a formal model A A f or a given problem or system (e.g. a bank ATM machine) Let ℒ (A) denote the possible behaviours Let ℒ (P) denote the set of valid or desired behaviours (i.e. those where some property P P is satisfied) To show that the model A always satisfies P , it is sufficient to show that: ℒ (A) ⊆ ℒ (P) Or, equivalently: ℒ (A) ∩ ℒ ( ¬ P) = ∅ Model checkers will try to prove this. If the intersection is non-empty, they will find some behaviour which corresponds to a counterexample. Automated Reasoning LTL Model Checking Lecture 9, page 6

  7. Temporal Model Checking In most systems the truth of certain formulae is dynamic So model checking is based on temporal logic Various temporal logics exist: computation tree logic (CTL): time represented as a tree, rooted at the present moment and branching out into the future linear-time temporal logic (LTL): time is a set of paths, where a path is a sequence of time instances we will be looking at a model checker called Spin Spin which is based on LTL LTL is closely linked with the theory of finite state automata, which we can use to model systems Automated Reasoning LTL Model Checking Lecture 9, page 7

  8. Finite State Automata A finite state automaton is a tuple ( S , s 0 , L , T , F ) where: S is a finite set of states s 0 is a distinguished initial state, s 0 ∈ S L is a finite set of labels (sometimes called the alphabet) T is a set of transitions, T ⊆ ( S x L x S ) F is a set of final states, F ⊆ S In dot notation, given an automaton A A.S is the set of states of A A. s 0 is the initial state of A etc Automated Reasoning LTL Model Checking Lecture 9, page 8

  9. Example of FSA  0  4 A = ( S, s 0 , L, F, T ) S 0 S 1 S 4 A.S = { s 0 , s 1 , s 2 , s 3 , s 4 , s 5 }  2  6  1  3 A.L = {  0 ,  1 ,  2 ,  3 ,  4 ,  5 ,  6 }  5 A.F = { s 4 , s 5 } S 3 S 2 S 5 A.T = { (s 0 ,  0 , s 1 ), (s 1 ,  1 , s 2 ), ... } card cancel - inserted Enter card out Thanks, Welcome PIN Goodbye An interpretation of the above automaton could be a sufficient funds - wrong simplified example of a bank correct cash and card out ack ATM machine: problem - Try card out Amount? Sorry again Automated Reasoning LTL Model Checking Lecture 9, page 9

  10. Determinism A finite state automaton A = ( S, s 0 , L, F, T) is deterministic iff ∀ s , I, s',s'' . ( s , I , s' ) ∈ A.T ∧ ( s, I,s'' ) ∈ A.T  s' ≡ s'' the destination state is uniquely determined by the source state and the transition label an automaton is called non-deterministic if it does not have this property so the bank machine example is deterministic Automated Reasoning LTL Model Checking Lecture 9, page 10

  11. Automaton Runs A run σ of a finite state automaton ( S,s 0 ,T,L,F ) is an ordered set (possibly infinite) of transitions from T starting at s 0 ( σ 0 =s 0 ): σ = {( σ 0 ,l 0 , σ 1 ), ( σ 1 ,l 1 , σ 2 ), ( σ 2 ,l 2 , σ 3 ), ...} σ uniquely specifies a sequence of states σ i in S and a sequence of labels l i in L (called words or strings). We will write σ i ∈ σ if σ i is contained in any transition in σ (and likewise for l i ). card cancel - inserted Enter card out Thanks, Welcome (infinite) state sequence from a run: PIN Goodbye { Welcome , { Enter PIN , Try again }* } sufficient funds - wrong correct cash and card out ack corresponding word in L is: problem - { card inserted , { wrong , ack }* } Try card out Amount? Sorry again Note : { X }* represents zero or more repetitions of X Automated Reasoning LTL Model Checking Lecture 9, page 11

  12. Acceptance An accepting run of a finite state automaton A is a finite run σ for which the final transition ( σ n-1 ,I n-1 , σ n ) satisfies ∈ A.F (i.e. the run ends in a final state) σ n card cancel - state sequence of an accepting run: inserted Enter card out Thanks, Welcome PIN Goodbye { Welcome, Enter PIN, Amount?, Sorry } sufficient funds - wrong correct cash and card out ack corresponding word in L is: problem - Try card out Amount? Sorry again { card inserted , correct, problem-card out } Automated Reasoning LTL Model Checking Lecture 9, page 12

  13. Accepted Language The language of an automaton A , ℒ (A) , is formally defined as the set of words in A.L that correspond to the set of accepting runs of automaton A. The complete language for this automaton can be card cancel - characterised as follows: inserted Enter card out Thanks, Welcome PIN Goodbye {card inserted, {wrong, ack}*, sufficient funds - wrong correct cash and card out ack {cancel... + {correct, problem - Try card out {sufficient funds... + Amount? Sorry again problem... }}}} + represents a choice * represents zero or more repetitions Automated Reasoning LTL Model Checking Lecture 9, page 13

  14. Infinite Runs Some FSAs permit infinite runs (e.g. bank machine example) This type of FSA is called an ω -automata. We will be considering a special type called B ü chi automata, each of whose infinite runs, σ , can be split into two parts: a set σ + of transitions that are taken finitely many times; a set σ  of transitions that repeat infinitely many times. σ σ  σ + Automated Reasoning LTL Model Checking Lecture 9, page 14

  15. B ü chi Acceptance “Final” states do not make sense for infinite runs. So how can we define acceptance for an ω -automata A? Let A.F denote a set of accepting states We say an infinite run σ is ω -accepting if it passes through an accepting state infinitely often: ∃ i ≥ 0. ( σ i ,l i , σ i+1 ) ∈ σ ∧ σ i ∧ σ i ∈ σ ω ∈ A.F This is known as B ü chi acceptance Automated Reasoning LTL Model Checking Lecture 9, page 15

  16. Decidability Issues Model checking is most interested in the following two properties of B ü chi automata: language emptiness (are there any accepting runs?) language intersection (are there any runs that are accepted by 2 or more automata?) Both properties are formally decidable Spin's model checking is based on these two checks Spin determines if the intersection of the language of a property automaton and a system automaton is empty Properties that can be stated in linear temporal logic (LTL) can be converted into B ü chi automata Automated Reasoning LTL Model Checking Lecture 9, page 16

  17. Linear Temporal Logic We need a clear, concise and unambiguous notation for stating desired properties of systems Propositional linear temporal logic (LTL) gives us this It provides a direct link with the theory of ω -automata Assumes time is discrete discrete LTL is propositional logic + temporal operators We will work with the operators (temporal connectives): NB: there are two  X Next conventions for notation.  F Eventually “LTL” notation is in blue  G Always (used in lecture and Spin). U U “CTL” notation is in red Strong Until (used in Huth & Ryan). W W Weak Until Automated Reasoning LTL Model Checking Lecture 9, page 17

  18. Syntax Well formed formulae (wff) in temporal logic are defined as: true and false are wffs if p is a propositional symbol representing a property which is true or false for any state in our model, then p is a wff if p and q are wff, so are: ¬ p , p ∧ q , p ∨ q , p  q ,  p ,  p ,  p , p U q , p W q if p is a wff, then ( p ) is a wff nothing else is a wff Automated Reasoning LTL Model Checking Lecture 9, page 18

Recommend


More recommend