Hoare Logic and Model Checking 1. You should be able to model simple - PowerPoint PPT Presentation

Hoare Logic and Model Checking 1. You should be able to model simple systems in NuSMV, an LTL Other interesting books: • “Model Checking” by Clarke, Grumberg, and Peled • “Principles of Model Checking” by Baier and Katoen 3 Course aims I have three aims in this course: model checker, Model Checking 3. You should know enough to be able to learn more about the fjrst two points above in your own time. I have six 50 minute lectures to: • Cover 30 years of work in model checking, • Cover a fjeld that has given rise to multiple Turing Awards, • Is a great example of a fusion of theory and practice. Copies in library Modelling and Reasoning about Systems” by Huth and Ryan Course mostly follows material in: “Logic in Computer Science: Book Lecture 7: Introduction and background Dominic Mulligan Based on previous slides by Alan Mycroft and Mike Gordon Programming, Logic, and Semantics Group, University of Cambridge Academic year 2016–2017 1 Administrivia Course website: www.cl.cam.ac.uk/teaching/1617/HLog+ModC/ Contact me with questions/comments: dpm36@cam.ac.uk Six lecture half course One and a half supervisions 2 4 2. You should be able to write the world’s worst CTL model checker,

Model checking: an application • A formal model of the system to be verifjed, Clarke, Emerson, and Sifakis won 2007 Turing Award for work Dedicated conferences and model checking competitions Multiple existing implementations of model checking Three decades of non-stop development Pioneers were Clarke, Emerson, Queille, and Sifakis Model checking originated in 1980s Origins 6 • or a counterexample execution, or trace. • Either an assurance that the property holds of the system, As output, a model checker gives: • A property of the system to be established. A model checker takes as input: of “formal methods” We focus on one type of formal method: model checking Model checking from distance 5 • Mathematical proof can establish absence of bugs • Testing can show presence of bugs, but not absence Can establish theorems about system behaviour: Systems now amenable to mathematical proof • Use mathematics to describe behaviour of objects • Use mathematical methods to reason about objects • Treat designs and implementations as mathematical objects One common approach to building “better” systems is: Systems as mathematical objects 7

What is model checking good for? • Clinical guidelines (e.g. stroke treatment and care), 9 A general tool for reasoning about systems Can be used for reasoning about systems , widely construed: • Railway interlocking mechanisms, traffjc lights, etc. • Cancer pathways, metabolic networks, • Automated planning as model checking, • Many other applications... • Can be used repeatedly through implementation phase, 10 Not a panacea But there’s also disadvantages: • State space explosion, • Some specifjcation languages are unintuitive, • Still not widely used as matter of course, • Not well suited to programs with complex data. • Many industrial success stories. • Can be used early in the design process, Model checking is well suited to reasoning about: • Refjne designs and implementations, • Concurrent and reactive systems, • Asynchronous and synchronous circuits and hardware, • Programs with complex control fmow, • Protocols, etc. Often have insidious, hard to reproduce bugs Counterexamples help: • Aid in “intelligent debugging” Other advantages: 8 Model checking advantages (I) Model checking is largely “push button”: • Decidable, • Requires little interaction from user, • Can be used by engineers with minimal training, • Some model checkers can understand Verilog/Java/C fjles. 11

Temporal properties FOL? • it may never rain in Cambridge again (!?) • it may be dry now in Cambridge, but may rain tonight, • It may be raining now in Trondheim but is not in Cambridge, Note that truth of utterance is relative to time and place: How should a truth value be assigned? It is raining Consider the following utterance: A linguistic puzzle 13 Natural numbers do not “evolve” through time Notion of truth is static Truth-value assigned by denotation function never changes “Static” truth 12 Semantics works well for fjrst-order logic relative to a valuation. • Provide interpretations of function symbols and relations, • Fix a domain, Recall semantics of fjrst-order logic from Logic and Proof : Obvious contender: fjrst-order logic (FOL) Q: what language should we express system properties in? 14 • Extend to a recursively-defjned denotation for formulae, defjned Works well for mathematics: 2 + 2 = 4 unconditionally

Other examples • Assign truth values to claims about evolving systems. Worlds are system states, or timepoints As modal logics, natural notion of truth is Kripkean • Modalities make truth of formulae relative to time. • Family of modal logics , • Applied to verifjcation by Pnueli (1996 Turing Award winner), for reasoning about time, • Developed by philosopher A. N. Prior in 1950s (as “tense logic”) Temporal logic: Idea : use temporal logic for specifying system behaviour Temporal logics 17 Propositions hold in some worlds but not others Truth is no longer static, but has a dynamic fmavour • What is true now need not be true in next state evolution, The lift car only moves after the doors have fully closed We also need an alternative notion of truth: Need a logic that can handle temporal properties “Dynamic” truth 16 Model checkers establish temporal properties of systems Time-relative properties are called temporal properties Like the weather, systems evolve through time Moral: systems evolve through time 15 of malloc All uses of free are preceded by an accompanying use before taking evasive action control software will audibly and visually alert the pilots After detecting a possible mid-air collision, the aircraft 18

What is time? Modelling systems Pictorial model of vending machine 20 How can we model this “system”? The machine dispenses their drink, user removes it Users insert money and make a drink selection Machine can dispense coke, or water Consider a simple example: a vending machine Vending machine 19 Q: how should we model time? • Both popular industrially and academically time: LTL and CTL • We focus on two temporal logics with different conceptions of In this course: Temporal logics exist with all these features (and more!) • Should we consider time intervals? • Does the future ‘branch’? Does the past? • Is time continuous, or discrete? Large design space: 21

Some notes 23 Pictorial model of lift 24 It waits with its doors open for passengers The lift has an up and down button Consider an example: a lift in a two-storey building Lift water are dispensed? Model is very abstract Is there a trace of the machine where both coke and water? From the start state, can we get the machine to dispense Some example properties 22 Abstractness dependent on properties we wish to establish We say nothing about e.g. internal electronics of machine 25

Some example properties Can the lift ever move without a button being pressed? Can the lift ever keep passengers inside indefjnitely? 26 Clocked sequential circuit 27 Pictorial model of circuit 28 Example properties 29 R = register, with a “memory” and initially holding 0 Output bit Y is set infjnitely often

Some notes r := r - y Example property 32 • and so on... Transitions between states follow semantics of language: States modelled as tuples (representation of “state space”): Abstract representation 31 q := q + 1 04 05 03 00 Representation of states now tied to system being modelled States no longer mysterious abstract objects 30 while y <= r do: A simple imperative program r := x 01 q := 0 02 33 We now have two start states: not restraining initial value of X • Concrete state representation = [0 .. 5] × Z × Z × Z × Z • State = � pc, x, y, r, q � We will always eventually reach a point where pc = 5 • � 0 , x, y, r, q � → � 1 , x, y, x, q � • � 1 , x, y, r, q � → � 2 , x, y, r, 0 � • If y ≤ r then � 2 , x, y, r, q � → � 3 , x, y, r, q � • If r < y then � 2 , x, y, r, q � → � 5 , x, y, r, q �

Labelled transition systems Example: handling clocked sequential circuits Temporal (modal) logics let us reason about models TS and labelling function is model of system (+ satisfaction relation) Model for modal logic = Kripke Frame + labelling function Recall from Logic and Proof : A transition system is also known as a Kripke Frame Kripke Frames 35 Transition Systems (LTS) 36 Also satisfy: 34 Do not care what caused them! We only care about transitions and states In this course actions are ignored (use TS rather than LTS) Examples abstracted as transition systems (TS) : • A (fjnite) set of states S , with initial states S 0 ⊆ S • A transition relation → ⊆ S × S • A set of labels , or atomic propositions , AP • A labelling function L : S → P ( AP ) Clocked sequential circuit with n inputs, m outputs, k registers • S = { 0 , 1 } n + k • S 0 = { ( a 1 , . . . , a n , c 1 , . . . , c k ) | c i = 0 , a j ∈ { 0 , 1 }} • AP = { x 1 , . . . , x n , y 1 , . . . , y m , . . . c 1 , . . . , c m } • L = λ s. { x i | x i = 1 at s } ∪ { c i | c i = 1 at s } ∪ { y i | y i = 1 at s } • → = derived from semantics of circuit diagram