1. Lecture 4&5: Model Checking: A quick introduction Professor Aditya Ghose Director, Decision Systems Lab School of IT and Computer Science University of Wollongong

2. Formal requirements modeling Important for safety- and mission-critical systems Formal modeling techniques closely tied in with verification techniques used to establish the correctness of the models Most formal methods come with: –A language for describing (behavioural) models of the proposed system –A specification language for describing the properties to be verified –A verification method to determine if a given model satisfies certain properties

3. Types of verification Proof-based: Model written as a theory, D, in a suitable formal language. Verification involves determining whether for a property p, D |- p is the case (p is often written in the same language as D). This may require substantial guidance from the user. Model-based: System behavior model written as a finite model M of an appropriate logic. A property p to be tested is written as a sentence in the same logic. Verification involves determining whether M |= p This is usually fully automated, but the restriction on finite models limits applicability

4. A brief note on modal logic Modal logic extends classical logic to deal with the problems of reasoning about time, knowledge, belief etc. Semantics of modal logic rely on the notion of possible worlds and an accessibility relation on these worlds. Common modal operators:  (necessity),  (possibility) 1.p: p is true in all worlds accessible from the current one  p: p is true in at least one of the worlds accessible from the current one Common temporal logic operators: p is true in the next time point, p is true in all future time points, there exists a time point in the future where p becomes true etc.

5. Model checking: I Widely used for concurrent, reactive systems Exploits dynamic notion of truth in temporal logics – a sentence may be true in some state and false is some other Models are state transition systems and properties are sentences in temporal logic Steps in model checking: –Model the system in the description language of the model checker, generating a model M –Code the property p in the specification language of the model checker –Run the model checker with inputs M and p

6. Model checking: II Model checker outputs “yes” if M |= p Otherwise it outputs “no” but also provides a trace of system behavior which causes this failure (this is very useful for debugging models) Note: models are not complete descriptions of system behavior but finite abstractions Types of temporal logic: –Branching-time vs linear-time –Continuous-time vs discrete-time In this lecture we will focus on Computation Tree Logic (developed by Emerson and Clarke) which is branching- time and discrete

7. Branching time models Arrows indicate accessibility relation:

8. CTL models M =(S, A CTL model M =(S, →, L) where: S is a set of states → is binary relation on S such for every s in S, we have some s’ in S such that s→s’ L is a labeling function which, given an input state, returns the set of atoms that are true in that state (the label of that state)

9. 1.M, s M, s 1.M, s ⊨ ⊤ and M, s ⊭ ⊥ for all s ∊ S. 2.M, s ⊨ p iff p ∊ L(s). 3.M, s ⊨ ¬p iff M, s ⊭ p. 4.M, s M, s M, s 4.M, s ⊨ p1 ∧ p2 iff M, s ⊨ p1 and M, s ⊨ p2. 5.M, s M, s M, s 5.M, s ⊨ p1 ∨ p2 iff M, s ⊨ p1 or M, s ⊨ p2. 6.M, s M, s M, s 6.M, s ⊨ p1 → p2 iff M, s ⊭ p1 or M, s ⊨ p2. 7.M, s M, s 1 7.M, s ⊨ AX p iff for all s 1 such that s → s 1 we have M, s 1 ⊨ p. Thus AX says: ‘in every next state’. 8.M, s M, s 1 8.M, s ⊨ EX p iff for some s 1 such that s → s 1 we have M, s 1 ⊨ p. Thus AX says: ‘in some next state’. E is dual to A – in exactly the same way that ∃ is dual to ∀ in predicate logic.

10. 9.M, s ⊨ AG p holds iff for all paths s 1 → s 2 → s 3 → …, where s 1 equals s, and all s i along the path, we have M, s i ⊨ p. Mnemonically: for All computation paths beginning in s the property p holds Globally. Note that ‘along the path’ includes the path’s initial state s. 10.M, s ⊨ EG p holds iff there is a path s 1 → s 2 → s 3 → …, where s 1 equals s, and for all s i along the path, we have M, s i ⊨ p. Mnemonically: there exists a path in s such that p holds Globally along the path. 11.M, s ⊨ AF p holds iff for all paths s 1 → s 2 → s 3 → …, where s 1 equals s, there is some s i such that M, s i ⊨ p. Mnemonically: for all computation path beginning in s there will be some Future state where p holds. 12.M, s ⊨ EF p holds iff there is a path s 1 → s 2 → s 3 → …, where s 1 equals s, there is some s i such that M, s i ⊨ p. Mnemonically: there exists a computation path beginning in s such that p holds in some future state; 13.M, s ⊨ A[ p1 ∪ p2 ] holds iff for all paths s 1 → s 2 → s 3 → …, where s 1 equals s, that path satisfies p1 ∪ p2, i.e. there is some s i along the path, such that M, s i ⊨ p2, and, for each j < i, we have M, s j ⊨ p1. Mnemonically: All computation paths beginning in s satisfy that p1 until p2 holds on it. 14.M, s ⊨ E[ p1 ∪ p2 ] holds iff there is a paths s 1 → s 2 → s 3 → …, where s 1 equals s, and that path satisfies p1 ∪ p2. Mnemonically: there exists a computation paths beginning in s satisfy that p1 until p2 holds on it. CTL semantics: II

11. It is possible to get to a state where started holds, but ready does not hold: EF(started ∧ ¬ready). For any state, if a request (of some resource) occurs, then it will eventually be acknowledged: AG(requested → AF acknowledged). A certain process is enabled infinitely often on every computation path: AG(AF enabled). Whatever happens, a certain process will eventually be permanently dead- locked: AF(AG deadlock) From any state it is possible to get to a restart state: AG(EF restart). An upwards travelling elevator at the second floor does not change its direction when it has possible wishing to get to the fifth floor: AG(floor = 2 ∧ direction = up ∧ → A[direction = up ∪ floor = 5]) Here, our atomic descriptions are boolean expressions built from system variables, e.g. floor = 2. The elevator can remain idle on the third floor with its doors closed: AG(floor = 3 ∧ idle ∧ door = closed → EG(floor = 3 ∧ idle ∧ door = closed)). Example properties

12. SMV inputs: An example MODULE main VAR request: boolean; status: {ready, busy}; ASSIGN init(status) := ready; next(status):= case request: busy 1: {ready, busy}; esac; SPEC AG (request -> AF status = busy) (The next slide shows the state transition systems corresponding to this SMV input specification)