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

automated reasoning ltl model checking
SMART_READER_LITE
LIVE PREVIEW

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


slide-1
SLIDE 1

Automated Reasoning Lecture 9, page 1 LTL Model Checking

Automated Reasoning LTL Model Checking

Alan Bundy

slide-2
SLIDE 2

Automated Reasoning Lecture 9, page 2 LTL Model Checking

Introduction

So far we have looked at theorem proving

Powerful, especially where good sets of rewrite rules

  • r 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

slide-3
SLIDE 3

Automated Reasoning Lecture 9, page 3 LTL Model Checking

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

slide-4
SLIDE 4

Automated Reasoning Lecture 9, page 4 LTL Model Checking

Systems Design

systems design high level architecture coding detailed design code structure requirements systems engineering

  • peration

testing

Finding errors earlier means cost savings later and more reliable product. Ideally we should build models to analyse potential violations of a systems requirements and not progress until

  • ur models are provably

correct. We should only be testing minor issues here.

slide-5
SLIDE 5

Automated Reasoning Lecture 9, page 5 LTL Model Checking

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

slide-6
SLIDE 6

Automated Reasoning Lecture 9, page 6 LTL Model Checking

Model Checking

We build a formal model A A for 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.

slide-7
SLIDE 7

Automated Reasoning Lecture 9, page 7 LTL Model Checking

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

slide-8
SLIDE 8

Automated Reasoning Lecture 9, page 8 LTL Model Checking

Finite State Automata

A finite state automaton is a tuple (S, s0, L, T, F) where:

S is a finite set of states s0 is a distinguished initial state, s0 ∈ 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.s0 is the initial state of A etc

slide-9
SLIDE 9

Automated Reasoning Lecture 9, page 9 LTL Model Checking

Example of FSA

5

S0

0

S4

4

S5

2

1 6

S1 S3

3

S2

Welcome card inserted Thanks, Goodbye cancel - card out Sorry wrong correct problem - card out sufficient funds - cash and card out Enter PIN Try again ack Amount?

A = (S, s0, L, F, T) A.S = {s0, s1, s2, s3, s4, s5} A.L = {0,1, 2, 3, 4, 5, 6 } A.F = {s4, s5} A.T = {(s0, 0, s1), (s1, 1, s2), ... }

An interpretation of the above automaton could be a simplified example of a bank ATM machine:

slide-10
SLIDE 10

Automated Reasoning Lecture 9, page 10 LTL Model Checking

Determinism

A finite state automaton A=(S, s0, L, F, T) is deterministic iff

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

∀s, I, s',s''. (s, I, s') ∈ A.T ∧ (s, I,s'') ∈ A.T  s' ≡ s''

slide-11
SLIDE 11

Automated Reasoning Lecture 9, page 11 LTL Model Checking

Automaton Runs

A run σ of a finite state automaton (S,s0,T,L,F) is an ordered set (possibly infinite) of transitions from T starting at s0 (σ0=s0): σ = {(σ0,l0,σ1), (σ1,l1,σ2), (σ2,l2,σ3), ...} σ uniquely specifies a sequence of states σi in S and a sequence of

labels li in L (called words or strings). We will write σi ∈ σ if σi is contained in any transition in σ (and likewise for li).

Welcome card inserted Thanks, Goodbye cancel - card out Sorry wrong correct problem - card out sufficient funds - cash and card out Enter PIN Try again ack Amount?

(infinite) state sequence from a run: { Welcome, { Enter PIN, Try again }* } corresponding word in L is: { card inserted, { wrong, ack }* }

Note: {X}* represents zero or more repetitions of X

slide-12
SLIDE 12

Automated Reasoning Lecture 9, page 12 LTL Model Checking

Acceptance

An accepting run of a finite state automaton A is a finite run σ for which the final transition (σn-1,In-1,σn) satisfies

σn

A.F ∈ (i.e. the run ends in a final state)

Welcome card inserted Thanks, Goodbye cancel - card out Sorry wrong correct problem - card out sufficient funds - cash and card out Enter PIN Try again ack Amount?

state sequence of an accepting run: { Welcome, Enter PIN, Amount?, Sorry } corresponding word in L is: { card inserted, correct, problem-card out }

slide-13
SLIDE 13

Automated Reasoning Lecture 9, page 13 LTL Model Checking

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.

Welcome card inserted Thanks, Goodbye cancel - card out Sorry wrong correct problem - card out sufficient funds - cash and card out Enter PIN Try again ack Amount?

The complete language for this automaton can be characterised as follows: {card inserted, {wrong, ack}*, {cancel... + {correct, {sufficient funds... + problem... }}}}

+ represents a choice * represents zero or more repetitions

slide-14
SLIDE 14

Automated Reasoning Lecture 9, page 14 LTL Model Checking

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. σ σ+ σ

slide-15
SLIDE 15

Automated Reasoning Lecture 9, page 15 LTL Model Checking

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,li,σi+1) ∈ σ ∧ σi A.F ∈ ∧ σi ∈ σω This is known as Büchi acceptance

slide-16
SLIDE 16

Automated Reasoning Lecture 9, page 16 LTL Model Checking

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

slide-17
SLIDE 17

Automated Reasoning Lecture 9, page 17 LTL Model Checking

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): Next

X Eventually

F Always

G Strong Until U U Weak Until W W

NB: there are two conventions for notation. “LTL” notation is in blue (used in lecture and Spin). “CTL” notation is in red (used in Huth & Ryan).

slide-18
SLIDE 18

Automated Reasoning Lecture 9, page 18 LTL Model Checking

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

slide-19
SLIDE 19

Automated Reasoning Lecture 9, page 19 LTL Model Checking

Precedence

not ¬ next

always

eventually

weak until W strong until U and ∧

  • r

∨ implies

The connectives of temporal logic have the following precedences:

Brackets can be dropped if there is no ambiguity, e.g. (((p))  ((q ∨ s))) becomes

p  (q ∨ s)

(((p) ∧ (q))  (p W r)) becomes

p ∧q  p W r

precedence

slide-20
SLIDE 20

Automated Reasoning Lecture 9, page 20 LTL Model Checking

Semantics: Notation

The symbol ╞ is used to mean that a state sequence (or state) satisfies a temporal well-formed formula (or property): σ[i] ╞ p ⇔ property p holds for state sequence {σi,σi+1, ...}. σ╞ f ⇔ a temporal wff f holds for state sequence σ where σ[i] denotes the suffix of σ starting after the ith transition, i.e. {(σi,li,σi+1), (σi+1,li+1,σi+2), ...}, with σ[0]=σ (NB: Huth and Ryan use the alternate notation πi for σ[i]) With this notation, we can give formal definitions for the temporal operators just introduced (, , , W, U).

slide-21
SLIDE 21

Automated Reasoning Lecture 9, page 21 LTL Model Checking

Always, Eventually and Next

Always: σ ╞ p ⇔ ∀i≥0. (σ[i] ╞ p) p captures the notion that the property p remains invariantly true throughout a state sequence. Eventually: σ ╞ p ⇔ ∃i≥0. (σ[i] ╞ p)

p captures the notion that the property p is guaranteed to

eventually become true at least once in a run. Next: σ[i] ╞ p ⇔ σ[i+1] ╞ p p states that the property p is true in the immediately following state of the run.

slide-22
SLIDE 22

Automated Reasoning Lecture 9, page 22 LTL Model Checking

Until

There are 2 variations of until: Strong until: σ ╞ (p U q) ⇔ ∃i≥0. (σ[i] ╞ q) ( ∧ ∀k. 0≤k<i → (σ[k] ╞ p)) This definition demands that q does hold in some future state. Weak until: σ ╞ (p W q) ⇔ (∃i≥0. (σ[i]╞ q) ( ∧ ∀k. 0≤k<i → (σ[k] ╞ p))) ∨ (∀j≥0. (σ[j] ╞ p)) This definition does not require that q ever become true (in which case p must be true forever once we reach state i).

slide-23
SLIDE 23

Automated Reasoning Lecture 9, page 23 LTL Model Checking

LTL Formulae

Formula Pronounced Type/Template invariance guarantee response precedence recurrence (progress) stability (non-progress) correlation p always p

p

eventually p

p q

p implies eventually q

p  q U r

p implies q until r p always eventually p

p

eventually always p

p  q eventually p implies

eventually q

Some standard LTL formulae are:

slide-24
SLIDE 24

Automated Reasoning Lecture 9, page 24 LTL Model Checking

Behaviour Specifications

How do we state: It is always the case that eventually we are either always in the state Thanks Goodbye or always in state Sorry ?

(( ( Thanks Goodbye ) ∨ ( Sorry) ) )

Is this true?

Welcome card inserted Thanks, Goodbye cancel - card out Sorry wrong correct problem - card out sufficient funds - cash and card out Enter PIN Try again ack Amount?

slide-25
SLIDE 25

Automated Reasoning Lecture 9, page 25 LTL Model Checking

Behaviour Specifications (II)

The previous expression is not true! It is possible that Enter Pin and Try Again loop forever. The following expression is true: It is always the case that if we are eventually always not in Try Again then eventually we are either always in the state Thanks Goodbye or always in the state Sorry.  ( ( ¬Try Again )  (( Thanks Goodbye ∨  Sorry ) ) )

Welcome card inserted Thanks, Goodbye cancel - card out Sorry wrong correct problem - card out sufficient funds - cash and card out Enter PIN Try again ack Amount?

slide-26
SLIDE 26

Automated Reasoning Lecture 9, page 26 LTL Model Checking

Summary

Introduction to model checking Model systems using FSAs Model system behaviour using LTL temporal operators , , , U, W Next time: model checking using Spin