[PDF] - INF5140 Specification and Verification of Parallel Systems Spring PDF Document

SLIDE 1

INF5140 – Specification and Verification of Parallel Systems

Spring 2015 June 9, 2015

Abstract This is the “handout” version of the slides for the lecture (i.e., it’s a rendering of the content of the slides in a way that does not waste so much paper when printing out). Note that sometimes overlays are tricky to represent in a handout. Note further that there are also the slides of the student presentations available on the net, they are not included here (with the exception of the TLA part). One part concerning the generation of the Büchi-automaton was presented on the white-board without slides. For that part, we put an book-excerpt as scan on the net.

I Overview of the course 2

1 Introduction 3 1.1 Content of the course . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2 Formal Methods 3 2.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1.1 An Easy Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.2 How to guarantee correctness? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2.1 Software bugs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.3 On formal methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.3.1 What are formal methods? . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.3.2 General Remarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.3.3 Classification of formal methods . . . . . . . . . . . . . . . . . . . . . . . . 8 2.3.4 A few success stories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.3.5 How to choose the right formal method? . . . . . . . . . . . . . . . . . . . . 10 2.4 Formalisms for specification and verification . . . . . . . . . . . . . . . . . . . . . . 11 2.4.1 Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.4.2 Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

II Logics 12

3 First-order logic 13 3.1 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.2 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.3 Proof System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 4 Modal logics 18 4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 4.2 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 4.3 Axiomatic System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 1

SLIDE 2

5 Dynamic logics 23 5.1 Multi-modal logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 5.2 Dynamic logics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 5.3 Semantics of PDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

III Lecture 4: (Hoare Logic and) Temporal Logics 27

6 Linear-Time Temporal Logic (LTL) 28 6.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 6.2 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 6.3 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 6.4 The Past . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 6.5 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 6.6 Nested waiting-for . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 6.7 Formalization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 6.8 Duals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 6.9 Classification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 6.9.1 Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 6.9.2 Safety and Liveness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 6.9.3 Recurrence and Persistence . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 6.9.4 Reactivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 6.9.5 GCD Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 6.10 Exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

IV Logical model checking 40

7 Logic Model Checking: What is it about? 40 7.1 The Basic Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 7.2 General remarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 7.3 Motivating Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 8 Automata and Logic 45 8.1 Finite State Automata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 8.2 Büchi Automata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 8.3 Something on Logic and Automata . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 8.4 Implications in Model Checking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 8.5 Automata Products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 9 Model Checking Algorithm 56 9.1 Preliminaries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 9.2 The Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 10 Final Remarks 57 10.1 Something on Automata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

V TLA & TLA+ 58

does not work in article mode 2

SLIDE 3

Part I

Overview of the course

1 Introduction

1.1 Content of the course

Content

See the homepage of the course:

http://www.uio.no/studier/emner/matnat/ifi/INF5140/v15/

1.2 Evaluation

Evaluation System

1. Two (small) mandatory assignments
Alternative: Write a research report (paper) on a topic related to the course (specifica-

tion and model checking)

2. Paper presentation on related topics
3. Oral exam
The mandatory assignments (as usual) give you the right to take the exam
A minimum will be required on every item above in order to be approved (e.g. you must

present a paper) Remarks

We will give you more precise guidelines during the course
Check the web page regularly.

2 Formal Methods

Outline

2.1 Motivation

2.1.1 An Easy Problem The problem Compute the value of a20 given the following definition1 a0 = 11

2

a1 = 61

11

an+2 = 111 −

1130− 3000

an

an+1

1Thanks to César Muñoz (NASA, Langley) for providing the example.

3

SLIDE 4

A Java Implementation

1

c l a s s mya {

2 3

s t a t i c double a ( i n t n) {

4

i f (n==0)

5

return 1 1 / 2 . 0 ;

6

i f (n==1)

7

return 61/11.0;

8

return 111 − (1130 − 3000/a (n−2))/a (n−1);

9

}

10 11

public s t a t i c void main ( String [ ] argv ) {

12

f o r ( i n t i =0; i <=20; i++)

13

System . out . p r i n t l n (" a("+ i +") = "+a ( i ) ) ;

14

}

15

}

The Solution (?) $ java mya a(0) = 5.5 a(2) = 5.5901639344262435 a(4) = 5.674648620514802 a(6) = 5.74912092113604 a(8) = 5.81131466923334 a(10) = 5.861078484508624 a(12) = 5.935956716634138 a(14) = 15.413043180845833 a(16) = 97.13715118465481 a(18) = 99.98953968869486 a(20) = 99.99996275956511 Should we trust software? In fact the value of an for any n ≥ 0 may be computed by using the following expression: an = 6n+1 + 5n+1 6n + 5n Where limn→∞ an = 6 We get then a20 ≈ 6!

2.2 How to guarantee correctness of a system?

Correctness

A system is correct if it meets its design requirements

Examples:

System: The previous Java program computing an

Requirement: For any n ≥ 0, the program should be conform with the previous equation (limn→∞ an = 6)

System: A telephone system Requirement: If user A want to call user B, then eventually

A will manage to establish a connection 4

SLIDE 5

System: An operating system Requirement: A deadly embrace2 (nowaday’s aka deadlock)

will never happen How to guarantee correctness? Is it possible at all?

How to show a system is correct?

– It is not enough to show that it can meet its requirement – We should show that a system cannot fail to meet its requirement – By testing? Dijkstra wrote (1972): “Program testing can be used to show the presence

f bugs, but never to show their absence”

– By other kind of “proof”? Dijkstra again (1965): “One can never guarantee that a proof is correct, the best one can say is: ’I have not discovered any mistakes”’ – What about automatic proof? It is impossible to construct a general proof procedure for arbitrary programs3

Any hope? In some cases it is possible to mechanically verify correctness;

in other cases . . . we try to do our best What is Validation?

In general, validation is the process of checking if something satisfies a certain criterion
Do not confuse validation with verification4

The following may clarify the difference between these terms: Validation: "Are we building the right product?", i.e., does the product do what the user really requires Verification: "Are we building the product right?", i.e., does the product conform to the specifications Usual approaches for validation The following techniques are used in industry for validation:

Testing

– Check the actual system rather than a model – Focused on sampling executions according to some coverage criteria – Not exhaustive – It is usually informal, though there are some formal approaches

Simulation

– A model of the system is written in a PL, which is run with different inputs – Not exhaustive

Verification

– “Is the process of applying a manual or automatic technique for establishing whether a given system satisfies a given property or behaves in accordance to some abstract description (specification) of the system”5

2A deadly embrace is when two processes obtain access to two mutually dependent shared resources and each

decide to wait indefinitely for the other.

3Undecidability of the halting problem, by Turing. 4Some authors define verification as a validation technique, others talk about V & V –Validation & Verification–

as being complementary techniques.

5From Peled’s book “Software reliability methods”.

5

SLIDE 6

2.2.1 Software bugs Sources of errors Errors may arise at different stages of the software/hardware development:

Specification errors (incomplete or wrong specification)
Transcription from the informal to the formal specification
Modeling errors (abstraction, incompleteness, etc.)
Translation from the specification to the actual code
Handwritten proof errors
Programming errors
Errors in the implementation of (semi-)automatic tools/compilers
Wrong use of tools/programs
. . .

Source of errors Most errors, however, are detected quite late on the development process6 Some (in-)famous software bugs [Garfinkel, 2005]7 July 28, 1962 – Mariner I space probe The Mariner I rocket diverts from its intended direction and

was destroyed by the mission control. Software error caused the miscalculation of rocket’s trajectory. Source

f error: wrong transcription of a handwritten formula into the implementation code.

1985-1987 – Therac-25 medical accelerator A radiation therapy device deliver high radiation doses.

At least 5 patients died and many were injured. Under certain circumstances it was possible to configure the Therac-25 so the electron beam would fire in high-power mode but with the metal X-ray target out of

position. Source of error: a “race condition”.

6Picture borrowed from G.Holzmann’s slides (http://spinroot.com/spin/Doc/course/index.html) 7Source: Garfinkel’s article “History’ worst software bugs”

6

SLIDE 7

Some (in-)famous software bugs8 1988 – Buffer overflow in Berkeley Unix finger daemon An Internet worm infected more than

6000 computers in a day. The use of a C routine gets() had no limits on its input. A large input allows the worm to take over any connected machine. Kind of error: Language design error (Buffer overflow).

1993 – Intel Pentium floating point divide A Pentium chip made mistakes when dividing floating

point numbers (errors of 0.006%). Between 3 and 5 million chips of the unit have to be replaced (estimated cost: 475 million dollars). Kind of error: Hardware error.

Some (in-)famous software bugs9 June 4, 1996 – Ariane 5 Flight 501 Error in a code converting 64-bit floating-point numbers into 16-

bit signed integer. It triggered an overflow condition which made the rocket to disintegrate 40 seconds after

launch. Error: Exception handling error.

November 2000 – National Cancer Institute, Panama City A therapy planning software allowed

doctors to draw some “holes” for specifying the placement of metal shields to protect healthy tissue from radiation. The software interpreted the “hole” in different ways depending on how it was drawn, exposing the patient to twice the necessary radiation. 8 patients died; 20 received overdoses. Error: Incomplete specification / wrong use.

2.3 On formal methods

2.3.1 What are formal methods? What are formal methods?

“Formal methods are a collection of notations and techniques for describing and analyzing

systems”10

Formal means the methods used are based on mathematical theories, such as logic, automata,

graphs or set theory

Formal specification techniques are used to unambiguously describe the system itself or its

properties

Formal analysis/verification techniques serve to verify that a system satisfies its specification

(or to help finding out why it is not the case) What are formal methods? Some terminology

The term verification is used in different ways

– Sometimes used only to refer the process of obtaining the formal correctness proof of a system (deductive verification) – In other cases, used to describe any action taken for finding errors in a program (including model checking and testing) – Sometimes testing is not considered to be a verification technique We will use the following definition (reminder):

Formal verification is the process of applying a manual or automatic formal technique for estab-

lishing whether a given system satisfies a given property or behaves in accordance to some abstract description (formal specification) of the system Saying ’a program is correct’ is only meaningful w.r.t. a given spec!

8Source: Garfinkel’s article “History’ worst software bugs” 9Source: Garfinkel’s article “History’ worst software bugs” 10From D. Peled’s book “Software Reliability Methods” [Peled, 2001].

7

SLIDE 8

2.3.2 General Remarks Limitations

Software verification methods do not guarantee, in general, the correctness of the code itself

but rather of an abstract model of it

It cannot identify fabrication faults (e.g. in digital circuits)
If the specification is incomplete or wrong, the verification result will also be wrong
The implementation of verification tools may be faulty
The bigger the system (number of possible states) more difficult is to analyze it (state explo-

sion problem) Any advantage? OF COURSE! Formal methods are not intended to guarantee absolute reliability but to increase the confidence

n system reliability. They help minimizing the number of errors and in many cases allow to find

errors impossible to find manually 2.3.3 Classification of formal methods Using formal methods Formal methods are used in different stages of the development process, giving a classification

f formal methods
1. We describe the system giving a formal specification
2. We can then prove some properties about the specification
3. We can proceed by:
Deriving a program from its specification (formal synthesis)
Verifying the specification w.r.t. implementation

Formal specification

A specification formalism must be unambiguous: it should have a precise syntax and seman-

tics – Natural languages are not suitable

A trade-off must be found between expressiveness and analysis feasibility

– More expressive the specification formalism more difficult its analysis Do not confuse the specification of the system itself with the specification of some of its properties

Both kinds of specifications may use the same formalism but not necessarily For example:

– The system specification can be given as a program or as a state machine – System properties can be formalized using some logic 8

SLIDE 9

Proving properties about the specification To gain confidence about the correctness of a specification it is useful to:

Prove some properties of the specification to check that it really means what it is supposed

to

Prove the equivalence of different specifications

Example

a should be true for the first two points of time, and then oscillates

– First attempt: a(0) ∧ a(1) ∧ ∀t · a(t + 1) = ¬a(t) INCORRECT! - The error may be found when trying to prove some properties – Correct specification: a(0) ∧ a(1) ∧ ∀t ≥ 0 · a(t + 2) = ¬a(t + 1) Formal synthesis

It would be helpful to automatically obtain an implementation from the specification of a

system

Difficult since most specifications are declarative and not constructive

– They usually describe what the system should do; not how it can be achieved Example.

1. Specify the operational semantics of a programming language in a constructive logic (Calculus
f Constructions)
2. Prove the correctness of a given property w.r.t. the operational semantics in Coq
3. Extract an OCAML code from the correctness proof (using Coq’s extraction mechanism)

Verifying specifications w.r.t. implementations There are mainly two approaches:

Deductive approach (automated theorem proving)

– Describe the specification Φspec in a formal model (logic) – Describe the system’s model Φimp in the same formal model – Prove that Φimp = ⇒ Φspec

Algorithmic approach

– Describe the specification Φspec as a formula of a logic – Describe the system as an interpretation Mimp of the given logic (e.g. as a finite automaton) – Prove that Mimp is a “model” (in the logical sense) of Φspec 2.3.4 A few success stories A few success stories

Esterel Technologies (Synchronous languages – Airbus, Avionics, Semiconductor & Telecom,

...) – Scade/Lustre – Esterel

Astrée (Abstract interpretation – Used in Airbus)
Java PathFinder (model checking — find deadlocks on multi-threaded Java programs)
Verification of circuits design (model checking)
Verification of different protocols (model checking and verification of infinite-state systems)

9

SLIDE 10

2.3.5 How to choose the right formal method? Classification of systems Before discussing how to choose the right formal method we need a classification of systems

Different kind of systems and not all methodologies/techniques may be applied to all kind of

systems

Systems may be classified depending on [Schneider, 2004]: 11

– Their architecture – The type of interaction Classification of systems According to the system architecture

Asynchronous vs. Synchronous Hardware
Analog vs. Digital Hardware
Mono- vs. Multi-processor systems
Imperative vs. Functional vs. Logical vs. Object-oriented Software
Concurrent vs. Sequential Software
Conventional vs. Real-time Operating Systems
Embedded vs. Local vs. Distributed Systems

Classification of systems According to the type of interaction

Transformational systems: Read inputs and produce outputs - These systems should

always terminate

Interactive systems: Idem previous, but they are not assumed to terminate (unless ex-

plicitly required) – Environment has to wait till the system is ready

Reactive systems: Non-terminating systems. The environment decides when to interact

with the system - These systems must be fast enough to react to an environment action (real-time systems) Taxonomy of properties

Many specification formalisms can be classified depending on the kind of properties they are

able to express/verify

Properties may be organized in the following categories

– Functional correctness: The program for computing the square root really computes it – Temporal behavior: The answer arrives in less than 40 seconds – Safety properties (“something bad never happens”): Traffic lights of crossing streets are never green simultaneously – Liveness properties (“something good eventually happens”): Process A will eventually be executed – Persistence properties (stabilization): For all computations there is a point where process A is always enabled – Fairness properties (some property will hold infinitely often): No process is ignored infinitely often by an O.S.

11Here we follow Klaus Schneider’s book “Verification of reactive systems”.

10

SLIDE 11

When and which formal method to use?

It depends on the problem, the underlying system and the property we want to prove

Examples: – Digital circuits ... (BDDs, model checking) – Communication protocol with unbounded number of processes.... (verification of infinite- state systems) – Overflow in programs (static analysis and abstract interpretation) – ...

Open distributed concurrent systems with unbounded number of processes interacting through

shared variables and with real-time constraints => VERY DIFFICULT!! Need the combination of different techniques

2.4 Formalisms for specification and verification

2.4.1 Specifications Some formalisms for specification An incomplete list of formalisms for specifying systems:

Logic-based formalisms

– Modal and temporal logics (E.g. LTL, CTL) – Real-time temporal logics (E.g. Duration calculus, TCTL) – Rewriting logic

Automata-based formalisms

– Finite-state automata – Timed and hybrid automata

Process algebra

– CCS (LOTOS, ...) – π-calculus

Visual formalisms

– MSC (Message Sequence Chart) – Statecharts – Petri nets 2.4.2 Verification Some techniques and methodologies for verification

Algorithmic verification

– Finite-state systems (model checking) – Infinite-state systems – Hybrid systems – Real-time systems

Deductive verification (theorem proving)
Abstract interpretation
Formal testing (black box, white box, structural, ...)
Static analysis

11

SLIDE 12

Summary

Formal methods are useful and needed
Which FM to use depends on the problem, the underlying system and the property we want

to prove

In real complex systems, only part of the system may be formally proved and no single FM

can make the task

Our course will concentrate on

– Temporal logic as a specification formalism – Safety, liveness and (maybe) fairness properties – SPIN (LTL Model Checking) – Few other techniques from student presentation (e.g., abstract interpretation, CTL model checking, timed automata) Ten Commandments of formal methods From “Ten commandments revisited” [Bowen and Hinchey, 2005]

1. Choose an appropriate notation
2. Formalize but not over-formalize
3. Estimate costs
4. Have a formal method guru on call
5. Do not abandon your traditional methods
6. Document sufficiently
7. Do not compromise your quality standards
8. Do not be dogmatic
9. Test, test, and test again
10. Do reuse

Further reading This part is based on many different sources. The following references have been consulted:

Klaus Schneider: Verification of reactive systems, 2003. Springer. Chap. 1 [Schneider, 2004]
G. Andrews: Foundations of Multithreaded, Parallel, and Distributed Programming, 2000.

Addison Wesley. Chap. 2 [Andrews, 2000]

Z. Manna and A. Pnueli: Temporal Verification of Reactive Systems: Safety, Chap. 012

[Manna and Pnueli, 1992]

Part II

Logics

Introduction Today: we start with the specification language Logic is “the” specification language for us.13

12This chapter is also the base of lectures 3 and 4. 13Note: there is no such thing as “the logics”. There are many . . .

12

SLIDE 13

There are many logics to choose from. Today we see two of them: – First-order logic (FOL) can be used to describe the state of a program. – Modal logic can be used to describe the change of state of a program. Other logics that we will see in other lectures: – Temporal logics has features not available in FOL like posibility to describe sequences

f states.

– Hoare logic is specially desighed to reson about programs. – Dynamic logics is more expressive than Hoare logic and has more abstract constructs and is more in the tradition of modal logic.

3 First-order logic

3.1 Syntax

First-order logic Syntax Language The symbols of our first-order language are

variables (a countable set of them V = {X, Y, . . . })
relation symbols P = {P, Q, . . . } of varying arity (incl. .

= of arity 2)

function symbols F = {f, g, . . . } of varying arity (if the arity of f is 0 then f is called a

constant symbols)14

the propositional connectives ¬, ∨, ∧, → and ↔
the quantifiers ∀ and ∃

First-order logic Syntax Expressions (terms)

Variables are atomic expressions.
If f is a function symbol of arity n, and t1, . . . , tn are terms, then the following is also an

expression. f(t1, . . . , tn) If n = 0, f is a constant. Example 1. <2-> Using infix notation, the following are expressions: x U ∪ V y − 1 U ∩ V (x + y) + z U \ V

14Cf. also the notion of signature in the term-rewriting talk later (by L. Tveito, 2015)

13

SLIDE 14

Syntax Atomic formulae

⊤ (top) and ⊥ (bottom) are atomic formulae.
If P is a relation symbol of arity n, and t1, . . . , tn are terms, then the following is an atomic

formulae. P(t1, . . . , tn) Example 2. <2-> Using infix notation, the following are atomic formulae. ⊤ x ∈ U x < y + 1 U ⊆ V x . = x − 1 U ∩ V . = ∅ Syntax Boolean formulae

All atomic formulae are boolean formulae.
If ϕ and ψ are boolean formulae, so are the following.

¬ϕ (ϕ ∨ ψ) (ϕ ∧ ψ) (ϕ → ψ) (ϕ ↔ ψ) Example 3. <2-> Some examples of Boolean formulas are: ¬¬⊤ ¬(x < y + 1) → ⊥ P → (Q → P) Syntax First-order formulae

All boolean formulae are first-order formulae.
Let x be a variable. If ϕ is a first-order formulae, so are the following.

(∃x)ϕ (∀x)ϕ

If ϕ and ψ are first-order formulae, so are the following.

¬ϕ (ϕ ∨ ψ) (ϕ ∧ ψ) (ϕ → ψ) (ϕ ↔ ψ)

L denotes the set of first-order formulae.

Example 4. <2-> Q(y) ∨ (∀x)P(x) (∀x)(∀y)(x < y → (∃z)(x < z ∧ z < y)) 14

SLIDE 15

3.2 Semantics

First-order model Definition 5. A model is a pair M = (D, I), such that

D is a non-empty set (the domain)
I is mapping (the interpretation), such that

– f I : Dn → D for every function symbol f of arity n – P I ⊆ Dn for every relation symbol P of arity n Observation

We will assume an implicit model, whose domain will include the natural numbers and sets
f natural numbers, and it will be obvious what function and relation symbols should be

mapped to.

For instance if + is a function symbol +I is the addition function on the natural numbers,

and . = is mapped to a suitable =. Valuation / state Given a model Definition 6 (Valuation). A valuation s over a set of variables V is a mapping from V to D.

another often-found name for that: variable assignment
here, in the context of using logics to speak about programs, where variables in the formula

may refer to program variables: we will often call a valuation a state Example 7. <2-> Let V = {x, y, z}, let x and z be variables of type natural number, and y a variable of type set of natural numbers.

s(x) = 256
s(y) = {1, 2, 3}
s(z) = 512

Valuation of an expression/term Definition 8. To every FOL expression t we associate a value s(t) from the domain D in a homomorphic way: s(f(t1, . . . , tn)) = f I(s(t1), . . . , s(tn)) Example 9. <2-> s((2 ∗ x) + z) = s([2 ∗ x]I) +I s(z) = (s(2I) ∗I s(x)) +I s(z) = (2 ∗ s(x)) + s(z) = (2 ∗ 256) + 512 = 1024 15

SLIDE 16

Free and bound variable occurrences Definition 10.

A variable occurrence is free in a formula if it is not within the scope of a
quantifier. A variable occurrence that is not free is bound.
Let s1 and s2 be states over V , and x ∈ V . s2 is an x-variant of s1 if

s1(y) = s2(y) for all y ∈ V \ {x}. Thus, x is the only variable the states disagree on. Substitution Definition 11 (Substitution).

Let ϕ be a first order formula, x a variable and t an expres-

sion.

Then ϕ[t/x] is ϕ, only with every free occurrence of the x replaced with t.
Note, the same definition is also used in the lecture about term rewriting (used on terms,

not on general FOL formula, but it’s “the same”.)

Some other notation has been used like ϕx←c. The one used now is the (most) standard one.
A really exact definition would have to cater for situations like (∀x.x + y = 19)[x + 1/y].

We say that ϕ is true in the model M, written M |

= ϕ, if M, s | = ϕ for every state s.

We say that ϕ is valid, written |

= ϕ, if M | = ϕ for every model M. Observation

We will abuse this notation, and write |

= ϕ if ϕ is true in our implicit model, and refer to this as state-validity.

For instance: |

= x + y . = y + x.

In a model where +I is the subtraction function, this will obviously not hold.

16

SLIDE 17

Exercises

Model the statement: “There are infinitely many primes”.

(∀x)(∃y)(x ≤ y ∧ (∀z)(z divides y → (z = 1 ∨ z = y))) where we define: z divides y (∃w)(z · w = y). Can define prime(y) (∀z)(z divides y → (z = 1 ∨ z = y))

“There is a person with at least two neighbors”

(∃x, y, z)(y = z ∧ Neigh(x, y) ∧ Neigh(x, z)) where Neigh(·, ·) is a binary relation. Model now: “There is a person with exactly two neighbors” (∃x, y, z)(y = z ∧ Neigh(x, y) ∧ Neigh(x, z) ∧ ((∀w)Neigh(x, w) → (w = y ∨ w = z))).

“Every even number can be written as a sum of two primes”

(∀x)((even(x) ∧ x > 2) → (∃y, z)(prime(y) ∧ prime(z) ∧ y + z = x)) where the shorthand even(x) (∃w)(2 · w = x). We assume the domain − with standard ·, +, >.

3.3 Proof System

Deductions and proof systems Definition 15. A proof system for a given logic consists of

axioms (or axiom schemata), which are formulae assumed to be true, and
inference rules, of approx. the form

ϕ1 . . . ϕn ψ

where ϕ1, . . . , ϕn are premises and ψ the conclusion. Derivations and proofs Definition 16.

A derivation from a set of formulae S is a sequence of formulae, where each

formula is either in S, an axiom or can be obtained by applying an inference rule to formulae earlier in the sequence.

A proof is a derivation from the empty set.
A theorem is the last formula in a proof.
A proof system is

– sound if every theorem is valid. – complete if evey valid formula is a theorem.

We do not study soundness and completeness in this course.

17

SLIDE 18

Proof systems and proofs: remarks

the “definitions” from the previous slides: not very formal
in general: a proof system: a “mechanical” (= formal and constructive) way of conclusions

from axioms (= “given” formulas), and other already proven formulas

Many different “representations” of how to draw conclusions exists
the one sketched on the previous slide

– works with “sequences” – corresponds to the historically oldest “style” of proof systems (“Hilbert-style”) – otherwise, in that naive form: impractical (but sound & complete). – nowadays, better ways and more suitable for computer support of representation exists (especially using trees). For instance natural deduction style system

for the course, those variations don’t matter.

a proof system for prop. logic Observation We can axiomatize a subset of propositional logic as follows. ϕ → (ψ → ϕ) (A1) (ϕ → (ψ → χ)) → ((ϕ → ψ) → (ϕ → χ)) (A2) ((ϕ → ⊥) → ⊥) → ϕ (DN)

ϕ ϕ → ψ ψ

(MP) Let us call this logic PPL. Note: As said, it’s only one of many different ways and styles to axiomatize logic (here prop. logic) A proof system Example 17. p → p is a theorem of PPL: (p → ((p → p) → p)) → ((p → (p → p)) → (p → p)) AX2 (1) p → ((p → p) → p) AX1 (2) (p → (p → p)) → (p → p) MP on (1) and (2) (3) p → (p → p) AX1 (4) p → p MP on (3) and (4) (5) Observation A proof can be represented as a tree of inferences where the leaves are axioms.

4 Modal logics

4.1 Introduction

Introduction

Modal Logic is the logic of necessity and possibility, in that originally the intended meaning
f the modal operators and ♦ was

18

SLIDE 19

– ϕ: ϕ is necessarily true. – ♦ϕ: ϕ is possibly true.

Depending on what we intend to capture, we can interpret ϕ differently.

temporal ϕ will always hold. doxastic I believe ϕ. epistemic I know ϕ. intuitionistic ϕ is provable. deontic It ought to be the case that ϕ.

We will restrict here the modal operators to and ♦ (and mostly work with a temporal

“mind-set”.

4.2 Semantics

Kripke structure Definition 18 (Kripke model).

A Kripke frame is a structure (W, R) where

– W is a non-empty set of worlds, and – R ⊆ W × W is called the accessibility relation between worlds.

A Kripke model M is a structure (W, R, V ) where

– (W, R) is a frame, and – V : W → 2Φ labels each world with a set of propositional variables. Remark: some also consider propositional variables as propositional constants, propositional “symbols”, it’s unimportant. Kripke models are sometimes called Kripke structures. Example Example 19. Let M = (W, R, V ) be the Kripke model such that

W = {w1, w2, w3, w4, w5}
R = {(w1, w5), (w1, w4), (w4, w1), . . . }
V = w1 : ∅, w2 : {φ}, w3 : {φ′}, . . .

19

SLIDE 20

The semantics only differs for and ♦.
We don’t put any restriction on the accessibility relation R.
The “mental picture” of what to think of and ♦ depends on the properties of R (and what

we think R actually represent) Different kinds of accessibility relations Definition 21. A binary relation R ⊆ W × W is

reflexive if every element in W is R-related to itself.

(∀a)aRa

transitive if

(∀abc)(aRb ∧ bRc → aRc)

euclidean if

(∀abc)(aRb ∧ aRc → bRc)

total if

(∀a)(∃b)(aRb) Modal Logic Semantics If (W, R, V ), s | = ϕ for all s and V , we write (W, R) | = ϕ Example 22.

(W, R) |

= ϕ → ϕ iff R is reflexive.

(W, R) |

= ϕ → ♦ϕ iff R is total.

(W, R) |

= ϕ → ϕ iff R is transitive.

(W, R) |

= ¬ϕ → ¬ϕ iff R is euclidean. Observation The axioms above are said to “hold on a frame”, which means, for any valuation and at any state. 20

SLIDE 21

Modal Logic Exercises Prove the double implications from the slide before!

1. The forward implications are based on the fact that we quantify over all valuations and all
states. More precisely; assume an arbitrary frame (W, R) which does NOT have the property

(e.g., reflexive). Find a valuation and a state where the axiom does not hold. You have now the contradiction . . .

2. For the backward implication take an arbitrary frame (W, R) which has the property (e.g.,

euclidian). Take an arbitrary valuation and an arbitrary state on this frame. Show that the axiom holds in this state under this valuation. Sometimes one may need to use an inductive argument or to work with properties derived from the main property on R (e.g., if R is euclidian then (∀w1, w2 ∈ W)(w1Rw2 → w2Rw2))

4.3 Axiomatic System

An axiomatic System Every normal modal logic has the following inference rules.

ϕ is a tautology instance ϕ

(PL)

ϕ ϕ → ψ ψ

(MP)

ϕ ϕ

(G) We will only be concerned with normal modal logics. Sample axioms for different accessibility relations The following are formulae that can be used to axiomatize logics with different properties. (ϕ → ψ) → (ϕ → ψ) (K) ϕ → ♦ϕ (D) ϕ → ϕ (T) ϕ → ϕ (4) ¬ϕ → ¬ϕ (5) (ϕ → ψ) → (ψ → ϕ) (3) ((ϕ → ϕ) → ϕ) → (♦ϕ → ϕ)) (Dum)

Every normal logic has K as axiom schema.
Observe that T implies D.

Different “flavors” of modal logic Logic Axioms Interpretation Properties of R D K D deontic total T K T reflexive K45 K 4 5 doxastic transitive/euclidean S4 K T 4 reflexive/transitive S5 K T 5 epistemic reflexive/euclidean reflexive/symmetric/transitive equivalence relation 21

SLIDE 22

Exercises

1. Consider the frame (W, R) with W = {1, 2, 3, 4, 5} and (i, i + 1) ∈ R

Choose the valuation V (p) = {2, 3} and V (q) = {1, 2, 3, 4, 5} to get the model M = (W, R, V ). Which of the following statements are correct in M and why? (a) M, 1 | = ♦p Correct (b) M, 1 | = ♦p → p Incorrect (c) M, 3 | = ♦(q ∧ ¬p) ∧ (q ∧ ¬p) Correct (d) M, 1 | = q ∧ ♦(q ∧ ♦(q ∧ ♦(q ∧ ♦q))) Correct (e) M | = q Correct . . . but why? Exercises 2 (bidirectional frames) We call a frame (W, R) bidirectional iff R = RF ⊎ RP s.t. ∀w, w′(wRF w′ ↔ w′RP w). i.e.: The R can be separated into two disjoind relations RF and RP , which one is the inverse

f the other.

Consider the model M = (W, R, V ) from before. Which of the following statements are correct in M and why? (a) M, 1 | = ♦p Incorrect (b) M, 1 | = ♦p → p Correct (c) M, 3 | = ♦(q ∧ ¬p) ∧ (q ∧ ¬p) Incorrect (d) M, 1 | = q ∧ ♦(q ∧ ♦(q ∧ ♦(q ∧ ♦q))) Correct (e) M | = q Correct . . . but is it the same explanation as before? (f) M | = q → ♦♦p Exercises 3 (validities) Which of the following are valid in modal logic. For those that are not, argue why and find a class of frames on which they become valid.

1. ⊥

Valid on frames where R = ∅.

2. ♦p → p

Valid on frames where R is a partial function.

3. p → ♦p

Valid on bidirectional frames.

4. ♦p → ♦p

Valid on Euclidian frames. 22

SLIDE 23

5 Dynamic logics

Introduction Problem

FOL is very15 expressive but undecidable. Good for mathematics but not ideal for computers.

!! FOL can talk about the state of the system. But how to talk about change of state in a natural way?

modal logic: gives us the power to talk about changing of state. Modal logics is natural when
ne is interested in systems that are essentially modeled as states and transitions between

states.16 !! We want to talk about programs, states of programs, and change of the state of the computer via executing programming instructions, like assignments. Outline

1. Multi-modal logic
2. Dynamic logic

5.1 Multi-modal logic

Multi-modal Logic

Consider a model (Kripke structure) (W, Ra, Rb) where Ra and Rb are two relations over W.
Multi-modal logic has one modality for each relation:

φ ::= p | ⊥ | φ → φ | ♦aφ | ♦bφ (6) where p is from a set of propositional constants (i.e., functional symbols of arity 0) and the

ther operators are derived as usual:

φ ::= φ ∨ φ | φ ∧ φ | ¬φ | aφ | bφ (7)

Semantics is natural:

M, w | = ♦aφ iff ∃w′ : wRaw′ and M, w′ | = φ (8)

The other modality ♦b: analogously for relation Rb

Remarks about Multi-modal logics As seen: multi-model logic is an obvious generalization of the modal logic from before

1. The two relations can overlap; i.e., their intersection need not be empty
2. of course: There may be more than two relations, for each relation one modality.
3. There may be infinitely many relations and infinitely many modalities.17

15At leat relatively. There are much more expressive logics again. FOL has also some serious restrictions. 16Modal logic can be seen as FOL with one free variable, but we loose the beauty of ML. 17One has to be careful then, though. Infinitely many modalities may pose serious theoretical challenges (not just

for the question how to deal with them computationally). We ignore issues concerning that in this lecture. As a further remark: later there will be a talk concerning TLA, temporal logic of actions. There, there are many actions, thus again thee are many “modalities” in a way.

23

SLIDE 24

5.2 Dynamic logics

Dynamic logics

different variants
special case of multi-model logics
variants of Hoare-logics
here PDL on regular programs

Regular programs Dynamic logic is a multi-modal logic to talk about programs.

Dynamic logic (here) talks about regular programs.

Regular programs are formed syntactically from:

atomic programs Π0 = {a, b, ...}, which are indivisible, single-step, basic programming con-

structs

sequential composition α ·β, which means that program α is executed/done first and then β.
nondeterministic choice α+β, which nondeterministically chooses one of α and β and executes

it.

iteration α∗, which executes α some nondeterministically chosen finite number of times.
the special skip and fail programs (denoted 1 resp. 0)

Tests Programs are denoted α, β ∈ Π and are build according to the grammar: Definition 23 (Syntax). α ::= a ∈ Π0 | 1 | 0 | α · α | α + α | α∗ | φ? (9) Where we added tests φ?. Tests can be seen as special atomic programs which may have logical structure, but their execution terminates in the same state iff the test succeeds (is true), otherwise fails if the test is deemed false in the current state. The logical structure of tests can be:

simple Boolean tests: φ ::= ⊤ |⊥| φ → φ | φ ∨ φ | φ ∧ φ
or complex tests: ϕ? where ϕ is a logical formula in Dynamic Logic

Propositional Dynamic Logic: Syntax Dynamic Logic formulas are build from two sets of symbols that are interdefined in a particular way:

1. Programs, which we denote α... ∈ Π
2. Formulas, which we denote ϕ... ∈ Φ

α ::= a ∈ Π0 | 1 | 0 | α · α | α + α | α∗ | ϕ? (10) ϕ ::= p, q ∈ Φ0 | ⊤ |⊥| ϕ → ϕ | [α]ϕ (11) where Φ0 is a set of propositional constants. What we defined now is called Propositional Dynamic Logic (PDL) because it is based on propositional logic only (i.e., the propositional constants). 24

SLIDE 25

PDL: remarks

Each program α: interpreted as a relation Rα

⇒ multi-modal logic.

[α]ϕ defines many modalities, one modality for each program, each interpreted over the

relation defined by the program α.

The relations of the basic programs are just given.
Operations on/composition of programs are interpreted as operations on relations.
∞ many complex programs ⇒ ∞ many relations/modalities
But we think of a single modality [..]ϕ with programs inside.
[..]ϕ is the universal one, with ..ϕ defined as usual.

Intiutive meaning/semantics of [α]ϕ “If program α is started in the current state, then however (if at all) it terminates, in the final state, ϕ holds.”

Exercises

Exercises Programs Define the following programming constructs in PDL:

skip

1 ↔ ⊤?

fail

0 ↔⊥?

if ϕ then α else β

(ϕ? · α) + (¬ϕ? · β)

if ϕ then α

(ϕ? · α) + (¬ϕ? · skip)

case ϕ1 then α1; . . .

(ϕ1? · α1) + · · · + (ϕn? · αn)

case ϕn then αn while ϕ do α

(ϕ? · α)∗ · ¬ϕ?

repeat α until ϕ

α · (¬ϕ? · α)∗ · ϕ?

(General while loop) while ϕ1 then α1 | · · · | ϕn then αn od

(ϕ1? · α1 + · · · + ϕn? · αn)∗·

·(¬ϕ1 ∧ · · · ∧ ϕn)?

5.3 Semantics of PDL

Semantics: Regular Kripke structures Definition 24 (Labeled Kripke structures).

A labeled Kripke structure is a (W, R, Σ) where

– R =

l∈Σ Rl is union of many relations indexed by the labels of Σ.

The labels of Σ can be thought as programs.

A Regular Kripke structure is a Kripke str. labeled in a special way:

– ∀a ∈ Π0 basic programs choose some relation Ra; – The other compound programs are interpreted as relations: – for 1 take the identity relation R1 = I; – for 0 take the empty relation R0 = ∅; – α = α1 · α2 then Rα = Rα1 ◦ Rα2 (relation composition) – α = α1 + α2 then Rα = Rα1 ∪ Rα2 (union of relations) – α = α∗

1 then Rα = n≥0 Rn α1 where:

(refl-trans. closure) R0

α1 I

Rn+1

α1

Rα1 ◦ Rn

α1

25

SLIDE 26

Kripke models and interpreting PDL formulas Now: adding valutions ⇒ Kripke model Definition 25 (Semantics). A PDL formula ϕ is true in the world w of a regular Kripke model M, i.e., we have attached a valuation V also, written M, w | = ϕ, if: M, w | = pi iff pi ∈ V (w) for all propositional constants M, w | =⊥ and M, w | = ⊤ M, w | = ϕ1 → ϕ2 iff whenever M, w | = ϕ1 then also M, w | = ϕ2 M, w | = [α]ϕ iff M, w′ | = ϕ for all w′ such that wRαw′ M, w | = αϕ iff M, w′ | = ϕ for some w′ such that wRαw′ Test programs Intuition: tests interpreted as subsets of the identity relation. Rϕ? = {(w, w) | w | = ϕ} ⊆ I (12) More precisely:

for ⊤? the relation becomes R⊤? = I

(testing ⊤ succeeds everywhere and is as the skip program)

for ⊥? the relation becomes R⊥? = ∅

(⊥ is nowhere true and is as the fail program)

R(ϕ1∧ϕ2)? = {(w, w) | w |

= ϕ1 and w | = ϕ2}

Testing a complex formula involving [α]ϕ is like looking in the future at the program and

what it can do and then deciding on the action to take...

Exercises

Exercises: Play with binary relations Facts:

Composition of relations distributes over union of relations.

R ◦ (

i Qi) = i(R ◦ Qi)

(

i Qi) ◦ R = i(Qi ◦ R)

R∗ I ∪ R ∪ R ◦ R ∪ · · · ∪ Rn ∪ . . .

n≥0 Rn

Show the following:

1. Rn ◦ Rm = Rn+m for n, m ≥ 0
2. R ◦ R∗ = R∗ ◦ R
3. R ◦ (Q ◦ R)∗ = (R ◦ Q)∗ ◦ R
4. (R ∪ Q)∗ = (R∗ ◦ Q)∗ ◦ Q∗
5. R∗ = I ∪ R ◦ R∗

26

SLIDE 27

Exercises Play with programs in DL Facts:

In DL we say that two programs α and β are equivalent iff they represent the same binary

relation Rα = R = Rβ. Show:

1. Two programs α and β are equivalent iff for some arbitrary propositional constant p the

formula αp ↔ βp.

2. The two programs below are equivalent:

while φ1 do α; while φ2 do β if φ1 then α; while φ1 ∨ φ2 do if φ2 then β else α Hint: encode them in PDL and use (1) or work only with relations Exercises Play with programs in DL Use a semantic argument to show that the following formula is valid: p ∧ [a∗]((p → [a]¬p) ∧ (¬p → [a]p)) ↔ [(a · a)∗]p ∧ [a · (a · a)∗]¬p What does the formula say (considering a as some atomic programming instruction)? Axiomatic System of PDL Take all tautologies of propositional logic (i.e., the axiom system of PL from Lecture 2) and add Axioms: [α](φ1 → φ2) → ([α]φ1 → [α]φ2) (1) [α](φ1 ∧ φ2) ↔ [α]φ1 ∧ [α]φ2 (2) [α + β]φ ↔ [α]φ ∧ [β]φ (3) [α · β]φ ↔ [α][β]φ (4) [φ?]ψ ↔ φ → ψ (5) φ ∧ [α][α∗]φ ↔ [α∗]φ (6) φ ∧ [α∗](φ → [α]φ) → [α∗]φ (IND) Rules: take the (MP) modus ponens and (G) generalization of Modal Logic. Further reading On Dynamic Logic, a book nicely written, with examples and easy presentation: David Harel, Dexter Kozen, and Jerzy Tiuryn: [Harel et al., 2000] – Chap. 3 for beginners, a general introduction to logic concepts – This lecture is based on Chap. 5 (which has some connections with Chap. 4 and is strongly based on mathematical notions which can be reviewed in Chap. 1) 27

SLIDE 28

Part III

Lecture 4: (Hoare Logic and) Temporal Logics

6 Linear-Time Temporal Logic (LTL)

Remark We have left out this semester Hoare logic.

6.1 Introduction

Introduction Temporal Logic?

Temporal logic is the logic of “time”18
It is a modal logic.
There are different ways of modeling time.

– linear time vs. branching time – time instances vs. time intervals – discrete time vs. continuous time – past and future vs. future only FOL (repetition) First Order Logic

We have used FOL to express properties of states.

– x : 21, y : 49 | | = x < y – x : 21, y : 7 | | = x < y

A computation is a sequence of states.
To express properties of computations, we need to extend FOL.
This we can do using temporal logic.

LTL: speaking about “time” In Linear Temporal Logic (LTL) (also called linear-time temporal logic) we can describe such properties as follows: assume time is a sequence19 of discrete points i in time, then: if i is now,

p holds in i and every following point (the future)
p holds in i and every preceding point (the past)

We will only be concerned with the future. . . .

p

i−2

p

i−1

p

i

p

i+1

p

i+2

. . .

18pay attention, it will be something kind of abstract, it’s mostly not what’s known as real-time, but there are

variants of temporal logics which can handle real-time. They won’t occur in this lecture .

19a sequence is linear

28

SLIDE 29

LTL operators We extend our first-order language20 L to a temporal language LT by adding the temporal

perators , ♦, , U, R and W.

Interpretation of the operators ϕ ϕ will always (in every state) hold ♦ϕ ϕ will eventually (in some state) hold ϕ ϕ will hold at the next point in time ϕU ψ ψ will eventually hold, and until that point ϕ will hold ϕRψ ψ holds until (incl.) the point (if any) where ϕ holds (release) ϕW ψ ϕ will hold until ψ holds (weak until or waiting for)

6.2 Syntax

Syntax We define LTL formulae as follows. Definition 26.

L ⊆ LT : first-order formulae are also LTL formulae.
If ϕ is an LTL formula, so are the following.

ϕ ♦ϕ ϕ ¬ϕ

If ϕ and ψ are LTL formulae, so are

ϕU ψ ϕRψ (ϕW ψ) (ϕ ∨ ψ) (ϕ ∧ ψ) (ϕ → ψ) (ϕ ↔ ψ)

nothing else

6.3 Semantics

Paths and computations Definition 27.

A path is an infinite sequence

σ = s0, s1, s2, . . .

f states.
σk denotes the path sk, sk+1, sk+2, . . .
σk denotes the state sk.
All computations are paths, but not vice versa.

20Note: it’s equally ok to extend a propositional language the same way. The difference is between a first-order

LTL or propositional LTL.

29

SLIDE 30

We say that ϕ is (temporally) valid, written |

= ϕ, if σ | = ϕ for all paths σ.

We say that ϕ and ψ are equivalent, written ϕ ∼ ψ, if

| = ϕ ↔ ψ (i.e. σ | = ϕ iff σ | = ψ, for all σ). Example 31. distributes over ∧, while ♦ distributes over ∨. (ϕ ∧ ψ) ∼ (ϕ ∧ ψ) ♦(ϕ ∨ ψ) ∼ (♦ϕ ∨ ♦ψ) Semantics σ | = p

p
p

1

p

2

p

3

p

4

. . . σ | = ♦p

1
2
p

3

4

. . . σ | = p 30

SLIDE 31

p

1

2
3
4

. . . σ | = pU q (sequence of p’s is finite)

p
p

1

p

2

q

3

4

. . . σ | = pRq ( The sequence of qs may be infinite)

q
q

1

q

2

p,q

3

4

. . . σ | = pW q. The sequence of ps may be infinite. (pW q ∼ pU q ∨ p).

p
p

1

p

2

p

3

p

4

. . .

6.4 The Past

The past Observation

[Manna and Pnueli, 1992] uses pairs (σ, j) of paths and positions instead of just the path σ

because they have past-formulae: formulae without future operators (the ones we use) but possibly with past operators, like −1 and ♦−1. (σ, j) | = −1ϕ iff (σ, k) | = ϕ for all k, 0 ≤ k ≤ j (σ, j) | = ♦−1ϕ iff (σ, k) | = ϕ for some k, 0 ≤ k ≤ j

However, it can be shown that for any formula ϕ, there is a future-formula (formulae without

past operators) ψ such that (σ, 0) | = ϕ iff (σ, 0) | = ψ The past: examples Example 32. What is a future version of (p → ♦−1q)? (σ, 0) | = (p → ♦−1q)

p→♦−1q
p→♦−1q
p→♦−1q
p→♦−1q
. . .

(σ, 0) | = qR(p → q)

p→q
p→q
p→q,q
. . .

6.5 Examples

Examples Example 33. ϕ → ♦ψ: Inf ϕ holds initially, then ψ holds eventually.

ϕ
ψ
. . .

This formula will also hold in every path where ϕ does not hold initially.

¬ϕ
. . .

31

SLIDE 32

Example: Response Example 34 (Response). (ϕ → ♦ψ) Every ϕ-position coincides with or is followed by a ψ-position.

ϕ
ψ
ϕ,ψ

. . . This formula will also hold in every path where ϕ never holds.

¬ϕ
¬ϕ
¬ϕ
¬ϕ
¬ϕ

. . . Examples Example 35. ♦ψ There are infinitely many ψ-positions.

ϕ
ϕ
ϕ
. . .

This formula can be obtained from the previous one, (ϕ → ♦ψ), by letting ϕ = ⊤: (⊤ → ♦ψ). Example: permanence Example 36. ♦ϕ Eventually ϕ will hold permanently.

ϕ
ϕ
ϕ
ϕ

. . . Equivalently: there are finitely many ¬ϕ-positions. LTL example Example 37. (¬ϕ)W ψ The first ϕ-position must coincide or be preceded by a ψ-position.

¬ϕ
¬ϕ
¬ϕ
ψ
ϕ
. . .

ϕ may never hold

¬ϕ
¬ϕ
¬ϕ
¬ϕ
¬ϕ
¬ϕ
¬ϕ

. . . LTL Example Example 38. (ϕ → ψW χ) Every ϕ-position initiates a sequence of ψ-positions, and if terminated, by a χ-position.

ϕ,ψ
ψ
ψ
χ
ϕ,ψ

. . . The sequence of ψ-positions need not terminate.

ϕ,ψ
ψ
ψ
ψ
ψ
ψ

. . . 32

SLIDE 33

6.6 Nested waiting-for

Nested waiting-for A nested waiting-for formula is of the form (ϕ → (ψmW (ψm−1W · · · (ψ1W ψ0) · · · ))), where ϕ, ψ0, . . . , ψm ∈ L. For the sake of convenience, we write (ϕ → ψm W ψm−1 W · · · W ψ1 W ψ0). Every ϕ-position initiates a succession of intervals, beginning with a ψm-interval, ending with a ψ1-interval and possibly terminated by a ψ0-position. Each interval may be empty or extend to infinity. . . .

ϕ,ψm
ψm
ψm
ψm−1
ψm−1

. . . . . .

ψ2
ψ2
ψ1
ψ1
ψ0

. . .

6.7 Formalization

Capturing informally understood temporal specifications formally It can be difficult to correctly formalize informally stated requirements in temporal logic. Example 39. How does one formalize the informal requirement “ϕ implies ψ”?

ϕ → ψ? ϕ → ψ holds in the initial state.
(ϕ → ψ)? ϕ → ψ holds in every state.
ϕ → ♦ψ? ϕ holds in the initial state, ψ will hold in some state.
(ϕ → ♦ψ)? We saw this earlier.
None of these is necessarily what we intended

6.8 Duals

Duals Definition 40 (Duals). For binary boolean connectives21 ◦ and •, we say that • is the dual of ◦ if ¬(ϕ ◦ ψ) ∼ (¬ϕ • ¬ψ). Similarly for unary connectives: • is the dual of ◦ if ¬ ◦ ϕ ∼ •¬ϕ. Duality is symmetric:

If • is the dual of ◦ then
◦ is the dual of •, thus
we may refer to two connectives as dual (of each other).

21Those are not concrete connectives or operators, they are meant as “placeholders”

33

SLIDE 34

Dual connectives Which connectives are duals?

∧ and ∨ are duals:

¬(ϕ ∧ ψ) ∼ (¬ϕ ∨ ¬ψ).

¬ is its own dual:

¬¬ϕ ∼ ¬¬ϕ.

What is the dual of →? It’s ←:

¬(ϕ ← ψ) ∼ ϕ ← ψ ∼ ψ → ϕ ∼ ¬ϕ → ¬ψ Complete sets of connectives

A set of connectives is complete (for boolean formulae) if every other connective can be

defined in terms of them.

Our set of connectives is complete (e.g., ← can be defined), but also subsets of it, so we don’t

actually need all the connectives. Example 41. <3-> {∨, ¬} is complete.

∧ is the dual of ∨.
ϕ → ψ is equivalent to ¬ϕ ∨ ψ.
ϕ ↔ ψ is equivalent to (ϕ → ψ) ∧ (ψ → ϕ).
⊤ is equivalent to p ∨ ¬p
⊥ is equivalent to p ∧ ¬p

Duals in LTL We can extend the notions of duality and completeness to temporal formulae. Duals of temporal operators

What is the dual of ? And of ♦?
and ♦ are duals.

¬ϕ ∼ ♦¬ϕ ¬♦ϕ ∼ ¬ϕ

Any other?
U and R are duals.

¬(ϕU ψ) ∼ (¬ϕ)R(¬ψ) ¬(ϕRψ) ∼ (¬ϕ)U (¬ψ) 34

SLIDE 35

Complete set of LTL operators We don’t need all our temporal operators either. Proposition 1. <2-> {∨, ¬, U , } is complete for LTL. Proof:

♦ϕ ∼ ⊤U ϕ
ϕ ∼ ⊥Rϕ
ϕRψ ∼ ¬(¬ϕU ¬ψ)
ϕW ψ ∼ ϕ ∨ (ϕU ψ)

6.9 Classification

6.9.1 Properties Classification of properties We can classify properties expressible in LTL. Classification safety ϕ liveness ♦ϕ

bligation ϕ ∨ ♦ψ

recurrence ♦ϕ persistence ♦ϕ reactivity ♦ϕ ∨ ♦ψ 6.9.2 Safety and Liveness Safety

important basic class of properties
relation to testing and run-time verification
“nothing bad ever happens”

Definition 42 (Safety).

A safety formula is of the form

ϕ for some first-order formula ϕ.

A conditional safety formula is of the form

ϕ → ψ for (first-order) formulae ϕ and ψ.

Safety formulae express invariance of some state property ϕ: that ϕ holds in every state of

the computation. 35

SLIDE 36

Safety property example Example 43.

Mutual exclusion is a safety property. Let Ci denote that process Pi is executing

in the critical section. Then ¬(C1 ∧ C2) expresses that it should always be the case that not both P1 and P2 are executing in the critical section.

Observe that the negation of a safety formula is a liveness formula; the negation of the

formula above is the liveness formula ♦(C1 ∧ C2) which expresses that eventually it is the case that both P1 and P2 are executing in the critical section. Liveness properties Definition 44 (Liveness).

A liveness formula is of the form

♦ϕ for some first-order formula ϕ.

A conditional liveness formula is of the form

ϕ → ♦ψ for first-order formulae ϕ and ψ.

Liveness formulae guarantee that some event ϕ eventually happens: that ϕ holds in at least
ne state of the computation.

Connection to Hoare logic Observation

Partial correctness is a safety property. Let P be a program and ψ the post condition.

(terminated(P) → ψ)

In the case of full partial correctness, where there is a precondition ϕ, we get a conditional

safety formula, ϕ → (terminated(P) → ψ), which we can express as { ϕ } P { ψ } in Hoare Logic. Total correctness and liveness Observation

Total correctness is a liveness property. Let P be a program and ψ the post condition.

♦(terminated(P) ∧ ψ)

In the case of full total correctness, where there is a precondition ϕ, we get a conditional

liveness formula, ϕ → ♦(terminated(P) ∧ ψ). 36

SLIDE 37

Duality of partial and total correctness Observation Partial and total correctness are dual. Let PC(ψ) (terminated → ψ) TC(ψ) ♦(terminated ∧ ψ) Then ¬PC(ψ) ∼ PC(¬ψ) ¬TC(ψ) ∼ TC(¬ψ) Obligation Definition 45 (Obligation).

A simple obligation formula is of the form

ϕ ∨ ♦ψ for first-order formula ϕ and ψ.

An equivalent form is

♦χ → ♦ψ which states that some state satisfies χ only if some state satisfies ψ. Obligation (2) Proposition 2. Every safety and liveness formula is also an obligation formula. Proof: This is because of the following equivalences. ϕ ∼ ϕ ∨ ♦⊥ ♦ϕ ∼ ⊥ ∨ ♦ϕ and the facts that | = ¬⊥ and | = ¬♦⊥. 6.9.3 Recurrence and Persistence Recurrence Definition 46 (Recurrence).

A recurrence formula is of the form

♦ϕ for some first-order formula ϕ.

It states that infinitely many positions in the computation satisfies ϕ.

Observation A response formula, of the form (ϕ → ♦ψ), is equivalent to a recurrence formula, of the form ♦χ, if we allow χ to be a past-formula. (ϕ → ♦ψ) ∼ ♦(¬ϕ)W −1ψ 37

SLIDE 38

Recurrence Proposition 3. Weak fairness22 can be specified as the following recurrence formula. ♦(enabled(τ) → taken(τ)) Observation An equivalent form is (enabled(τ) → ♦taken(τ)), which looks more like the first-order formula we saw last time. Persistence Definition 47 (Persistence).

A persistence formula is of the form

♦ϕ for some first-order formula ϕ.

It states that all but finitely many positions satisfy ϕ23
Persistence formulae are used to describe the eventual stabilization of some state property.

Recurrence and Persistence Observation Recurrence and persistence are duals. ¬(♦ϕ) ∼ (♦¬ϕ) ¬(♦ϕ) ∼ (♦¬ϕ) 6.9.4 Reactivity Reactivity Definition 48 (Reactivity).

A simple reactivity formula is of the form

♦ϕ ∨ ♦ψ for first-order formula ϕ and ψ.

A very general class of formulae are conjunctions of reactivity formulae.
An equivalent form is

♦χ → ♦ψ, which states that if the computation contains infinitely many χ-positions, it must also contain infinitely many ψ-positions. Reactivity Proposition 4. Strong fairness can be specified as the following reactivity formula. ♦enabled(τ) → ♦taken(τ)

22weak and strong fairness will be “recurrent” (sorry for the pun) themes. For instance they will show up again

in the TLA presentation.

23In other words: only finitely (“but”) many position satisfy ¬ϕ. So at some point onwards, it’s always ϕ.

38

SLIDE 39

6.9.5 GCD Example GCD Example Below is a computation σ of our recurring GCD program.

a and b are fixed: σ |

= (a . = 21 ∧ b . = 49).

at(l) denotes the formulae (π .

= {l}).

terminated denotes the formula at(l8).

P-computation States are of the form π, x, y, g. σ : l1, 21, 49, 0 → lb

2, 21, 49, 0 → l6, 21, 49, 0 →

l1, 21, 28, 0 → lb

2, 21, 28, 0 → l6, 21, 28, 0 →

l1, 21, 7, 0 → la

2, 21, 7, 0 → l4, 21, 7, 0 →

l1, 14, 7, 0 → la

2, 14, 7, 0 → l4, 14, 7, 0 →

l1, 7, 7, 0 → l7, 7, 7, 0 → l8, 7, 7, 7 → · · · GCD Example Does the following properties hold for σ? And why?

1. terminated (safety)
2. at(l1) → terminated
3. at(l8) → terminated
4. at(l7) → ♦terminated (conditional liveness)
5. ♦at(l7) → ♦terminated (obligation)
6. (gcd(x, y) .

= gcd(a, b)) (safety)

7. ♦terminated (liveness)
8. ♦(y .

= gcd(a, b)) (persistence)

9. ♦terminated (recurrence)

6.10 Exercises

Exercises Exercises

1. Show that the following formulae are (not) LTL-valid.

(a) ϕ ↔ ϕ (b) ♦ϕ ↔ ♦♦ϕ (c) ¬ϕ → ¬ϕ (d) (ϕ → ψ) → (ψ → ϕ) (e) (ϕ → ψ) ∨ (ψ → ϕ) (f) ♦ϕ → ♦ϕ (g) ♦ϕ ↔ ♦♦ϕ

2. A modality is a sequence of ¬, and ♦, including the empty sequence ǫ. Two modalities σ

and τ are equivalent if σϕ ↔ τϕ is valid. 39

SLIDE 40

(a) Which are the non-equivalent modalities in LTL, and (b) what are their relationship (ie. implication-wise)?

Part IV

Logical model checking

Credits Credits:

Many slides (all the figures with blue background and few others) were taken from Holzmann’s

slides on “Logical Model Checking”, course given at Caltech http://spinroot.com/spin/ Doc/course/index.html (http://spinroot.com/spin/Doc/course/index.html) Outline

Contents 7 Logic Model Checking: What is it about?

7.1 The Basic Method

Logic Model Checking (1)

Model checking is a technique for verifying finite-state concurrent systems
Theoretically speaking, model checking consists of the following tasks:
1. Modeling the system
It may require the use of abstraction
Often using some kind of automaton
2. Specifying the properties the design must satisfy
It is impossible to determine all the properties the systems should satisfy
Often using some kind of temporal logic
3. Verifying that the system satisfies its specification
In case of a negative result: error trace
An error trace may be product of a specification error

Logic Model Checking (2) The application of model checking at the design stage of a system typically consists of the following steps:

1. Choose the properties (correctness requirements) critical to the sytem you want to build

(software, hardware, protocols)

2. Build a model of the system (will use for verification) guided by the above correctness re-

quirements

The model should be as small as possible (for efficiency)
It should, however, capture everything which is relevant to the properties to be verified

40

SLIDE 41

if I is empty then S satisfies p if I is non-empty then S can violate p

and I will contain a counter-example that proves it

S ¬p

all possible executions all invalid executions

I

executions that are possible and invalid

3. Select the appropriate verification method based on the model and the properties (LTL-,

CTL∗-based, probabilistic, timed, weighted)

4. Refine the verification model and correctness requirements until all correctness concerns are

adequately satisfied

Main causes of combinatorial complexity in SPIN/Promela24

– The number of and size of buffered channels – The number of asynchronous processes The Basic Method There are different model checking techniques. We will use the automata-theoretic approach which is implemented in the SPIN model checker (tool). Theoretically:

System: L(S)

(set of possible behaviors/traces/words of S)

Property: L(P)

(the set of valid/desirable behaviors)

Prove that L(S) ⊆ L(P)

(everything possible is valid) – Proving language inclusion is complicated

Method

– Let L(P) be the language Σω \ L(P) of words not accepted by P – Prove L(S) ∩ L(P) = ∅ ∗ There is no accepted word by S disallowed by P This will be clear at the end of the talk, .... I hope The Basic Method Graphically: Scope of the method

Logic model checkers (LMC) are suitable for concurrent and multi-threading finite state

systems

Some of the errors LMC may catch:

– Deadlocks (two or more competing processes are waiting for the other to finish, and thus neither ever

does)

24and in other model checkers.

41

SLIDE 42

1950 2004 1975 1968 1989 1980 1995 2000 1936

C C++ 1976-1979: first experiments with reachability analyzers (e.g., Jan Hajek: ‘Approver’) 1981: Ed Clarke and Allen Emerson introduce the term ‘model checking’ and the logic CTL* 1980: earliest predecessor

f Spin: ‘pan’ (Bell Labs)

1993: BDDs and the SMV model checker (Ken McMillan, CMU) 1989: Spin version 0 verification of class of

regular properties

1995: partial order reduction in Spin. LTL conversion in Spin. (Doron Peled) Spin SMV

the two most popular logic model checking systems today: Spin: an explicit state LTL model checker based on automata theoretic verification method targeting software verification (asynchronous systems) SMV: a symbolic CTL model checker targeting hardware circuit verification (synchronous systems) (there are hundreds of other model checkers – there are also several variants of Spin)

1986: Pierre Wolper and Moshe Vardi define the automata theoretic framework for LTL model checking 1986: Mazurkiewicz paper on trace theory 1977: Amir Pnueli introduces linear temporal logic for system verification LTL CTL 2001: support for embedded C code in Spin version 4.0 Spin 4.0 1968: two terms introduced: software crisis software engineering 1960: early work on

automata theory,

e.g., by J.R. Buchi 2003: breadth-first search mode added in Spin version 4.1 Fortran Algol 1975: Edsger Dijkstra’s paper

n Guarded Command Languages

1978: Tony Hoare’s paper on Communicating Sequential Processes 1940-50: the first computers are built 1955: early work on tense logics (predecessors of LTL) 1936: first theory on computability, e.g., Turing machines

key theoretical developments underlying Spin

pan

C

– Livelocks (two or more processes continually change their state in response to changes in the other

processes)

– Starvation (a process is perpetually denied access to necessary resources) – Priority and locking problems – Race conditions (attempting to perform two or more operations at the same time, which must be

done in the proper sequence in order to be done correctly)

– Resource allocation problems – Dead code (unreachable code) – Violation of certain system bounds – Logic problems: e.g, temporal relations A bit of history The following diagram shows the evolution of the theoretical foundations of LMC:

7.2 General remarks

On correctness (reminder)

A system is correct if it meets its design requirements.

– There is no notion of “absolute” correctness: It is always w.r.t. a given specification

Getting the properties (requirements) right is as important as getting the model of the system

right

Examples of correctness requirements

– A system should not deadlock – No process should starve another – Fairness assumptions ∗ E.g., an infinite often enabled process should be executed infinitely often – Causal relations ∗ E.g., each time a request is send, and acknowledgment must be received (response property) 42

SLIDE 43

in real-life conflicts ultimately get resolved by human judgment. computers, though, must be able to resolve it with fixed algorithms

after-you, no after-you blocking me-first, no me-first blocking

On models and abstraction

The use of abstraction is needed for building models (systems may be extremely big)

– A model is always an abstraction of the reality

The choice of the model/abstractions depends on the requirements to be checked
A good model keeps only relevant information

– A trade-off must be found: too much detail may complicate the model; too much abstraction may oversimplify the reality

Time and probability are usually abstracted away in LMC

Building verification models

Statements about system design and system requirement must be separated

– One formalism for specifying behavior (system design) – Another formalism for specifying system requirements (correctness properties)

The two types of statements define a verification model
A model checker can now

– Check that the behavior specification (the design) is logically consistent with the requirement specification (the desired properties)

7.3 Motivating Examples

Distributed Algorithms Two asynchronous processes may easily get blocked when competing for a shared resource A Small Multi-threaded Program Thread Interleaving A Simpler Example 43

SLIDE 44

int x, y, r; int *p, *q, *z; int **a; thread_1(void) /* initialize p, q, and r */ { p = &x; q = &y; z = &r; } thread_2(void) /* swap contents of x and y */ { r = *p; *p = *q; *q = r; } thread_3(void) /* access z via a and p */ { a = &p; *a = z; **a = 12; }

3 a s y n c h r

n
u

s t h r e a d s a c c e s s i n g s h a r e d d a t a 3 s t a t e m e n t s e a c h h

w

m a n y t e s t r u n s a r e n e e d e d t

c

h e c k t h a t n

d

a t a c

r

r u p t i

n

c a n

c

c u r ?

the number of possible thread

interleavings is...

9! 6! 3!

---- · ----- · ---- = 1,680

6!.3! 3!.3! 3!

placing 3 sets of 3 tokens in 9 slots

are all these executions okay?
can we check them all? should we

check them all?

in classic system testing, how many

would normally be checked? start 1 3 2

1,680 possible executions

consider two 2-state automata

– representing two asynchronous processes

ne can print an arbitrary number of ‘0’ digits, or stop
the other can print an arbitrary number of ‘1’ digits, or stop

how many different combined executions are there? i.e., how many different binary numbers can be printed? how would one test that this system does what we think it does? print ‘0’ print ‘1’ stop stop Q: how could a model checker deal with possibly infinite executions?

44

SLIDE 45

s0 s1 s2 s4 s3 α α α α0 α α α α2

2 2 2

α α α α4

4 4 4

α α α α5

5 5 5

α α α α1

1 1 1

α α α α3

3 3 3

A.S: { s0, s1, s2, s3, s4 } A.L = { α α α α0

0, α

, α , α , α1

1 1 1, α

, α , α , α2

2 2 2, α

, α , α , α3

3 3 3, α

, α , α , α4

4 4 4, α

, α , α , α5

5 5 5 }

A.F = { s4 } A.T = {(s0,α α α α0,s1), (s1, α α α α1,s2), ...} A: {S, s0, L, F, T}

8 Automata and Logic

8.1 Finite State Automata

Finite State Automata Definition 49. A finite state automaton is a tuple (S, s0, L, F, T), where

S is finite set of states
s0 ∈ S is a distinguished initial state
L is a finite set of labels (symbols)
F ⊆ S is the (possibly empty) set of final states
T ⊆ S × L × S is the transition relation, connecting states in S

We will, in general, follow Holzmann’s notation: A.S denotes the state S of automaton A, A.T denotes the transition relation T of A, and so on.... If understood from the context, we will avoid the use of A._ Finite State Automata Example Finite State Automata Example: An Interpretation The above automaton may be interpreted as a Process Scheduler: Determinism vs. non-determinism Definition 50. A finite state automaton A = (S, s0, L, F, T) is deterministic iff ∀s ∀l, ((s, l, s′) ∈ A.T ∧ (s, l, s′′) ∈ A.T) = ⇒ s′ ≡ s′′ I.e., the destination state of a transition is uniquely determined by the source state and the transition label. An automaton is called non-deterministic if it does not have this property Examples:

The automaton corresponding to the process scheduler is deterministic
Automaton from definition is non-deterministic (think of distinction between relations and

partial functions) 45

SLIDE 46

idle start execute pre-empt ready run waiting block unblock end stop s0 s1 s2 s4 s3 α α α α0 α α α α2

2 2 2

α α α α4

4 4 4

α α α α5

5 5 5

α α α α1

1 1 1

α α α α3

3 3 3

idle ready execute

end

waiting start pre-empt run block unblock stop

Definition of a Run Definition 51. A run of a finite state automaton A = (S, s0, L, F, T) is an ordered and possibly infinite set of transitions (a sequence) from T σ = {(s0, l0, s1), (s1, l1, s2), . . .)} such that ∀i, i ≥ 0 s.th. (si, li, si+1) ∈ T Each run corresponds to a state sequence in S and a word in L Definition of a Run Example

A state sequence from a run: {idle, ready, {execute, waiting}∗}
The corresponding word in L: {start, run, {block, unblock}∗}

Remarks: 46

SLIDE 47

state sequence of an accepting run:

{ idle, ready, execute, waiting, execute, end }

the corresponding word in L:

{start, run, block, unblock, stop }

idle ready execute

end

waiting start pre-empt run block unblock stop

idle ready execute

end

waiting start pre-empt run block unblock stop

{ start, run, { { pre-empt, run } + { block, unblock } }*, stop }

a characterization of the complete language of automaton A (an infinite set of words): the shortest word in the language: { start, run, stop } a regular expression +: choose *: repeat zero

r more times

Figure 1: X

A single state sequence may correspond to more than one word
For non-deterministic automata, the same word may correspond to different state sequence

Definition of Acceptance Definition 52. An accepting run of a finite state automaton A = (S, s0, L, F, T) is a finite run σ in which the final transition (sn−1, ln−1, sn) has the property that sn ∈ A.F Example: Language Accepted by an Automaton Definition 53. The language L(A) of automaton A = (S, s0, L, F, T) is the set of words in A.L that correspond to the set of all the accepting runs of A Notice that there can be infinitely many words in the language of even a small finite state automaton Example: 47

SLIDE 48

sample property: “if first p becomes true and then later q becomes true, then r can no longer become true”

interpretation:

p q !r r !p !q error

correctness claim: it is an error if in a run we see first p then q and then r

this property is easily expressed with the standard definition of acceptance reaching this state constitutes a complete match of the pattern that specifies the correctness violation

a classic liveness property: “if p then eventually q” this property can only be violated by an infinite run… the standard notion of acceptance applies only to finite runs...

Problem: we cannot express this with the standard definition of acceptance: we cannot express that a run may not remain in the error state infinitely long...

p !q !p error

attempted interpretation:

q

Reasoning about Runs Reasoning about Infinite Runs We need, thus, to extend the notion of run, acceptance, ...

8.2 Büchi Automata

Büchi Acceptance

An infinite run is often called an ω-run (“omega run”)
An acceptance property for ω-runs are called ω-acceptance and can be defined in different

ways – The so-called Büchi, Müller, Rabin, Streett, etc, acceptance conditions – We adopt here the one introduced by Büchi [Büchi, 1962] [Büchi, 1960] Definition 54. An accepting ω-run of finite state automaton A = (S, s0, L, F, T) is an infinite run σ such that ∃i ≥ 0, (si−1, li−1, si) ∈ σ s.th. si ∈ A.F ∧ si ∈ σω 48

SLIDE 49

i.e., at least one state in A.F is visited infinitely often. Automata with the above acceptance condition are called Büchi automata Büchi Automata Example

an accepting ω-run for this automaton: { idle, ready, {execute, ready}* } the corresponding ω-word: {start, run, { pre-empt, run}* }

idle ready

execute end

waiting start pre-empt run block unblock stop

the ω-language of an automaton is the set of all ω-words accepted

Generalized Büchi Automata Definition 55. A generalized Büchi automaton is an automaton A = (S, s0, L, F, T), where F ⊆ 2S (F = {f1, . . . , fn} and fi ⊆ S). A run σ of A is accepting if for each fi ∈ F, inf(σ) ∩ fi = ∅.

A generalized Büchi Automaton differs from a Büchi Automaton by allowing multiple ac-

cepting sets instead of only one

Generalized Büchi automata are not more expressive than usual Büchi automata

The Stutter Extension Rule

It would be convenient to include the acceptance for finite runs as a special case of acceptance

for infinite runs - For that we need: – Let ε be a predefined nil symbol – The label set of the automaton is extended to L ∪ {ε} – To determine ω-acceptance, a finite run is (thought to be) extended into an equivalent infinite run by stuttering the final state on ε Definition 56. The stutter extension of a finite run σ with final state sn, is the ω-run σ (sn, ε, sn)ω The Stutter Extension Rule Example 49

SLIDE 50

run: { idle, ready, execute, waiting, execute, [end,]* } word: {start, run, block, unblock, stop, ε

ε ε ε* }

idle ready

execute end

waiting start pre-empt run block unblock stop

ε ε ε ε

we can now use one single acceptance rule to reason about the liveness properties of both finite and infinite runs

8.3 Something on Logic and Automata

From Kripke Structures to Büchi Automata

LTL formulas can be interpreted on sets of infinite runs of Kripke structures

We recall the definition (slightly different from previous lecture) Definition 57. A Kripke structure M is a four-tuple (W, R, W0, V ) where

W is a finite non-empty set of states (worlds)
R ⊆ W × W is a total accessibility relation between states (transition relation)
W0 ⊆ W is the set of starting states
V : W −

→ 2AP is a map labeling each state with a set of propositional variables A path in M is an infinite sequence σ = w0, w1, w2, . . . of worlds such that for every i ≥ 0, wiRwi+1. One can think of a path as an infinite branch in a tree corresponding to the unwind of the Kripke structure. From Kripke Structures to Büchi Automata Obtaining the automaton

An ω-regular automaton A = (S, s0, L, F, T) can be obtained from a Kripke structure M =

(W, R, W0, V ) as follows

S = W ∪ {i}
s0 = {i}
L = 2AP
F = W ∪ {i}
For s, s′ ∈ S s.th. (s, l, s′) ∈ T iff (s, s′) ∈ R ∧ l = V (s′)
(i, l, s) ∈ T iff s ∈ W0 ∧ l = V (s)

From Kripke Structures to Büchi Automata Example A Kripke structure (whose only infinite run is a model to q and ♦p, for instance): The corresponding Büchi Automaton: 50

SLIDE 51

s0

{p, q}

s1

{q}

i

{p,q}

s0

{q}

s1

{p,q}

Figure 2: Büchi-Automaton

From Logic to Automata

For any LTL formula ψ there exists a Büchi automaton that accepts precisely those runs for

which the formula ψ is satisfied

Example: The formula ♦p corresponds to the following nondeterministic Büchi automa-

ton:

p s1 p

true

s0

Figure 3: From LTL to automata We will see the algorithm next lecture... For the moment, believe me that it is indeed the case Omega-regular Properties Expressiveness

8.4 Implications in Model Checking

Implications in Model Checking

At the beginning we said that the automata-based model checking method was based on the

following check: L(S) ∩ L(P) = ∅ where S is a model of the system and P of the property

So, the following Büchi automata’s decidable properties are important for model checking

– Language emptiness: are there any accepting runs? 51

SLIDE 52

something not expressible in pure LTL:

– (p) can hold after an even number of execution steps, but never holds after an odd number of steps – [] X (p) certainly does not capture it: – p && [](p -> X!p) && [](!p -> Xp) does not capture it either (because now p must always hold after all even steps): – ∃ ∃ ∃ ∃t, t && [] (t -> X !t) && [](!t -> Xt) && [](!t -> !p) this formula expresses it correctly

true p (ltl2ba -f) p !p true !p

Figure 4: ω-regular properties

same box means ‘equally expressive’ single arrow means ‘more expressive than’ no arrow means ‘expressiveness is not comparable’

tree automata

∃ ∃ ∃ ∃ LTL

word automata

Büchi automata (never claims) CTL* CTL LTL LTL without X modal µ-calculus

Figure 5: Expressiveness – Language intersection: are there any runs accepted by two or more automata? – Language complementation How does it work? Implications for Model Checking In theory:

The system is represented as a Büchi automaton A

– The automaton corresponds to the asynchronous product of automata A1, . . . , An (representing the asynchronous processes) A =

n

i=1

Ai

The property is originally given as an LTL formula ψ
The property ψ is translated into a Büchi automaton B25

25Alternatively, the property can be given directly as a Büchi automaton

52

SLIDE 53

We perform the following check:

L(A) ∩ L(B) = ∅ But... complementing a Büchi automaton is difficult! Implications in Model Checking In practice (e.g., in SPIN) we want to avoid automata complementation:

Assume A as before
The negation of the property ψ is automatically translated into a Büchi automaton B (since

L(B) ≡ L(B))

By making the synchronous product of A and B (B ⊗ A) we can check whether the system

satisfies the property L(A) ∩ L(B) = ∅ – If the intersection is empty, the property ψ holds for A – Otherwise, use an accepted word of the nonempty intersection as a counterexample

8.5 Automata Products

Asynchronous Product Definition 58. The asynchronous product of a finite set of finite automata A1, . . . An is a new finite state automaton A = (S, s0, L, T, F) where:

A.S is the Cartesian product A1.S × A2.S × . . . × An.S
A.s0 is the n-tuple (A1.s0, A2.s0, . . . , An.s0)
A.L is the union set A1.L ∪ A2.L ∪ . . . ∪ An.L
A.T is the set of tuples ((x1, . . . , xn), l, (y1, . . . , yn)) such that ∃i, 1 ≤ i ≤ n, (xi, l, yi) ∈ Ai.T

and ∀j, 1 ≤ j ≤ n, j = i = ⇒ (xj ≡ yj)

A.F contains those states from A.S that satisfy ∀(A1.s, A2.s, . . . , An.s) ∈ A.F, ∃i, 1 ≤ i ≤

n, Ai.s ∈ Ai.F Asynchronous Product Example

Assume two non-terminating asynchronous processes A1 and A2:

– A1 tests whether the value of a variable x is odd, in which case updates it to 3 ∗ x + 1 – A2 tests whether the value of a variable x is even, in which case updates it to x/2

Let ψ the following property: ♦(x ≥ 4)

– The negation of the formula is: ♦(x < 4) Question: Given an initial value for x, does the property hold? Asynchronous Product Example Remark In Promela semantics an expression statement has to evaluate to non-zero to be executable. So to test whether a variable x is odd we write !(x%2), and (x%2) for checking whether x is even. Given x=4, !(4%2) evaluates to !(0) or written more clearly as !(false) which is (true). 53

SLIDE 54

s0 s1 (x%2) x=3x+1 A1 s0 s1 !(x%2) x=x/2 A2 s0 s1 true x<4 x<4 B s0,s0 s1,s0 s0,s1 s1,s1 (x%2) x=3x+1 (x%2) x=3x+1 x=x/2 x=x/2 !(x%2) !(x%2)

Π Π Π Π

an unreachable state under Promela interpretation

f statement (label) semantics

int x

note that variable x also holds state information we have to take Promela semantics into account to determine which states are really reachable

⊗

we can also “expand” the automaton into a pure automaton, without variables

Figure 6: Asynchronous product Asynchronous Product Example Asynchronous Product Example

s0,s0 s1,s0 s0,s1 s1,s1 (x%2) x=3x+1 (x%2) x=3x+1 x=x/2 x=x/2 !(x%2) !(x%2) s0,s0 4 s0,s1 4 s0,s0 2 s0,s1 2 s1,s0 1 s0,s0 1 !(x%2) x=x/2 !(x%2) x=x/2 (x%2) x=3x+1 “pure” finite state asynchronous product automaton for initial value x = 4 (the value of x is now part of the state of the automaton)

Figure 7: Asynchronous product Asynchronous Product Remarks

Not all the states in A.S are necessary reachable from A.s0

– Their reachability depends on the semantics given to the labels in A.L (the interpretation

f the labels depends on Promela semantics as we’ll see in a future lecture)
The transitions in the product automaton are the transitions from the component automata

arranged such that only one of the components automata can execute at a time – This gives an interleaving semantics of the processes 54

SLIDE 55

Promela has also rendez-vous synchronization (A special global variable has to be set)

– Some transitions may synchronize by sending and receiving a message

For hardware verification, the asynchronous product is defined differently: each of the com-

ponents with enabled transitions is making a transition (simultaneously) Synchronous Product Definition 59. The synchronous product ⊗ of a finite set of two finite automata P and B is a new finite state automaton A = (S, s0, L, T, F) where:

A.S is the Cartesian product P ′.S × B.S where P ′ is the stutter closure of P

– A self-loop labeled with ε is attached to every state in P without outgoing transitions in P.T)

A.s0 is the pair (P.s0, B.s0)
A.L is the set of pairs (l1, l2) such that l1 ∈ P ′.L and l2 ∈ B.L
A.T is the set of pairs (t1, t2) such that t1 ∈ P ′.T and t2 ∈ B.T
A.F is the set of pairs (s1, s2) such that s1 ∈ P ′.F or s2 ∈ B.F

Synchronous Product Example

the example: B ⊗ Π Ai

s0 s1 true x<4 x<4 B all paths with accept states dead-end here; not stutter possible are there any accepting cycles? if not, then the property <>[](x<4) cannot be satisfied and its negation holds !<>[](x<4) []![](x<4) []<>!(x<4) []<>(x>=4)

⊗ ⊗ ⊗ ⊗

s0,s0, 4,s0 s0,s1 4,s0 s0,s0 2,s0 s0,s1 2,s0 s1,s0 1,s0 s0,s0 1,s0 !(x%2) x=x/2 !(x%2) x=x/2 (x%2) x=3x+1 x=x/2 (x%2) s1,s0 1,s1 s0,s0 1,s1 s0,s1 2,s1 s0,s0 4,s1 s0,s0 4 s0,s1 4 s0,s0 2 s0,s1 2 s1,s0 1 s0,s0 1 !(x%2) x=x/2 !(x%2) x=x/2 (x%2) x=3x+1 i=1 2

Figure 8: Synchronous product Synchronous Product Remarks

We require the stutter-closure of P since P is a finite state automaton (the asynchronous

product of the processes automata) and B is a standard Büchi automaton obtained form a LTL formula

Not all the states in A.S or A.F are necessary reachable from A.s0
The main difference between asynchronous and synchronous products are on the definitions
f L and T – In a synchronous product:

55

SLIDE 56

s0 s1

s2
s3

s4

s5

Figure 9: Strongly connected component – The transitions correspond to joint transitions of the component automata – The labels are pairs: the combination of the two labels of the original transitions in the component automata

In general P ⊗ B ≡ B ⊗ P, but given that in SPIN B is particular kind of automaton (labels

are state properties, not actions), we have then P ⊗ B ≡ B ⊗ P

9 Model Checking Algorithm

9.1 Preliminaries

Strongly-connected components Definition 60. A subset S′ ⊆ S in a directed graph is strongly-connected if there is a path between any pair of nodes in S′, passing only through nodes in S′. A strongly-connected component (SCC) is a maximal set of such nodes, i.e. it is not possible to add any node to that set and still maintain strong connectivity Strongly-connected Components Example

Strongly-connected subsets: S = {s0, s1},

S′ = {s1, s3, s4}, S′′ = {s0, s1, s3, s4}

Strongly-connected components: Only S′′ = {s0, s1, s3, s4}

Checking Emptiness

Let σ be an accepting run of a Büchi automaton A = (S, s0, L, T, F)

– Since S is finite, there is some suffix σ′ of σ s.t. every state on σ′ is reachable from any

ther state on σ′

– I.e., the states on σ′ are contained in a SCC of the graph of A – This component is reachable from an initial state and contains an accepting state

Thus, checking non-emptiness of L(A) is equivalent to finding a SCC in the graph of A that

is reachable from an initial state and contains an accepting state – There are different algorithms for finding SCC. E.g.: ∗ Tarjan’s version of the depth-first search (DFS) algorithm ∗ SPIN nested depth-first search algorithm

If the language L(A) is non-empty, then there is a counterexample which can be represented

in a finite way – It is ultimately periodic, i.e., it is of the form σ1σω

2 , where σ1 and σ2 are finite sequences

56

SLIDE 57

9.2 The Algorithm

Model Checking Algorithm

Let A be the automaton specifying the system and B the automaton corresponding to the

negation of the property ψ

1. Construct the intersection automaton C = A ∩ B
2. Apply an algorithm to find SCCs reachable from the initial states of C
3. If none of the SCCs found contains an accepting state
The model A satisfies the property/specification ψ
4. Otherwise,

(a) Take one strongly-connected component SC of C (b) Construct a path σ1 from an initial state of C to some accepting state s of SC (c) Construct a cycle from s and back to itself (such cycle exists since SC is a strongly- connected component) (d) Let σ2 be such cycle, excluding its first state s (e) Announce that σ1σω

2 is a counterexample that is accepted by A, but it is not allowed

by the property/specification ψ

10 Final Remarks

10.1 Something on Automata

Kripke Structures and Büchi Automata Observation

In Peled’s book “Software Reliability Methods” [Peled, 2001] the definition of a Büchi au-

tomaton is very similar to our Kripke structure, with the addition of acceptance states – There is a labeling of the states associating to each state a set of subsets of propositions (instead of having the propositions as transition labels)

We have chosen to define Büchi Automata in the way we did since this definition is compatible

with the implementation of SPIN – It was taken from Holzmann’s book “The SPIN Model Checker” [Holzmann, 2003] Automata Products Observation

We have defined synchronous and asynchronous automata products with the aim of using

SPIN (based on Holzmann’s book) – The definition of asynchronous product is intended to capture the idea of (software) asynchronous processes running concurrently – The synchronous product is defined between an automaton specifying the concurrent asynchronous processes and an automaton obtained from an LTL formula (or obtained from a Promela never claim) – The purpose for adding the stutter closure (in the definition of the synchronous product) is to make it possible to verify both properties of finite and infinite sequences with the same algorithm 57

SLIDE 58

I.e., you might find different definitions in the literature!

– In particular, in Peled’s book the automata product is defined differently, since the definition of Büchi automata is different

Part V

TLA & TLA+

Model Checking TLA+ Specifications Shiji Bijo shijib@ifi.uio.no Introduction TLA: temporal logic of actions combination of – Logic of actions – standard temporal logics

Formal specification language for describing and reasoning concurrent and distributed sys-

tems.

inventend and “pushed” by Leslie Lamport
TLA+: extension of TLA
Supported by TLC model checker
also: deductive verification (TLAPS is a proof system).

– deductive verification applicable if: system has form of a mathematical theory 58

SLIDE 59

Model checking vs. deductive verification

Leslie is “in love with” logics (logics is good, programming notation is bad).
remember: model checking: model |

=? ϕ – (mostly) for finite state systems – automatic method

deductive verification

– (mostly) requires user interaction – can handle infinite systems

TLA/TLA+: Note: framework with one uniform (logical) notation for “specification” of the

system and the “properties” to be verified. ⇒ verification (MC or deductive) here then means implication How does one “program” in logics?

remember: Lamport does not use programming notation!
However: underlying a very conventional “progamming model”:

execution is change of state! ⇒ “logical” representation of change of state prime notation (prime = “′”) – BAD: x:=x+1! (in PL’s mostly written x=x+1) ⇒ GOOD: x′ = x + 1 States, actions, predicates

in principle: rather conventional concepts
state = mapping of variables to values s : Var → Val
Notation: [

[F] ] semantic meaning to syntactic object F 26

actions

– syntax for state transformers or transitions – boolean expression over variables and primed variable (Var and Var ′) – meaning of an action A: relation between states (= “state transformer”). Notation s[ [A] ]t

predicate P: as usual = boolean expression
s[

[P] ] is true or false for all states s

P includes only unprimed variables and constants

26Syntactic objects includes variables, states, predicates, actions etc.

59

SLIDE 60

Validity and provability

valid formula = “always” true.27
for actions: “universal transition relation” States × States

Valid action | = A

s1[

[A] ]s2 for all states s1 and s2 (13)

similarly for predicates |

= P

s[

[P] ] is true for all states s .

Formula F is provable by rules of the logic.
notation: provability of formula F in a given proof system (for instance for TLA.

⊢ F (14)

Soundness: Every provable formula is valid, ⊢ F ⇒|

= F Rigid (and flexible) var’s

so far: variables mainly motivated by the “programming language” motivation (states of a

program, state change/transition)

remember: TLA = uniform (logic-based) formalism for specs. and programs
often: not only program variables, but also logical variables

– don’t change their values (= no primed versions) – used to talk/reason about the program

For instance: parameters of a system
one name used here rigid variables (the other ones = flexible vars)28
compare: Pre/post conditions in Hoare-logic:

{ x = 3 } x := x + 1 { x = 4 } { x = y } x := x + 1 { x = y + 1 } Quantification (and rigid var’s)

rigid var’s can be used in actions, expressions, predicates etc
rigid variables cannot be primed, but quantfied over
flexible variables: can be primed, but not quantified over
A state is still an assignment of values to flexible variables
(Note: validity |

= of actions need to take free rigid variables into account). | = x′ + y + m ∈ Nat ⇒ ∀n ∈ Nat : n(x′ + y + m) ≥ (x′ + y + m)

27Independent from variable values etc. “always” is not meant as TL . 28Other terminology exists as well

60

SLIDE 61

Temporal logic

remember = TLA = actions + temporal logics
choice for TLA: linear time temporal logics!
standard operators:

– boolean connectives – temporal operators (♦ can be defined as usual) – remark: U is not included. – note: not included

the role of is taken by the actions
semantics: standard, based on infinite sequences of states
validity of temporal formulas |

= ϕ, also as expected: ϕ is valid, if it’s true for all infinite sequences of states29 Unseful formulas and “Leads to”

as repetition

– infinitely often: ♦ϕ – stabilization/eventually always: ♦ϕ

“leads to” (written ):

ϕ1 ϕ2

(ϕ1 → ♦ϕ2)

Raw TLA as intermediate step to TLA

elementary temporal formulas = actions
raw logics: logical operators and and actions
However: RTLA is too powerful: can express properties which should not be expressible.
note: for the next illustrative very simple example, RTLA would be ok (at least at first sight).

Simple program

1

var natural x , y=0;

2

do // i n f i n i t e loop

3

true → x := x + 1

4

[ ] // choice

5

true → y := y + 1

6

d

InitΦ

(x = 0) ∧ (y = 0)

initial condition A1

(x′ = x + 1) ∧ (y′ = y)

1st branch does step A2

(x′ = x) ∧ (y′ = y + 1)

2nd branch does step A

A1 ∨ A2

non-determinism Φ

InitΦ ∧ A
Note: A describes all steps of the simple program

⇒ A

Remark: instead of choice, would not change things

29Independent from any model, etc.

61

SLIDE 62

Why is RTLA too strict?

note: Φ describes (more or less) exactly how the program behaves
Isn’t that a good thing?
Note: an exact description corresponds to a closed world assumption

⇒ – No room for partial description, for instance: describing one program running in parallel with other programs (not captured (yet) by the specification) – No room for changes (“refinement”)

Example: Hour-minute-clock refined to an hour-minute-second clock

TLA: Adding stuttering

a program stutters = “it does nothing”, resp. something outside the program does something
doing nothing = variables unchanged

1

var natural x , y=0;

2

do // i n f i n i t e loop

3

true → x := x + 1

4

[ ] // choice

5

true → y := y + 1

6

d

Φ

InitΦ ∧ A

∨ (x′ = x ∧ y′ = y) closed program spec.open program spec. TLA

TLA formulas must be stutter invariant
writing “stutter equations” like before explicitly is cumbersome

⇒ special action syntax: [A]x

A ∨ (x′ = x)

(15)

can be used also for many variables (or even more generally for so-called “state functions”,

left out here)

TLA: actions can only be written like equation (15)
In the previous example

Φ InitΦ ∧ [A]x,y (16) What about “liveness properties”?

spec. Φ from (16) is safety property

1

var natural x , y=0;

2

do // i n f i n i t e loop

3

true → x := x + 1

4

[ ] // choice

5

true → y := y + 1

6

d

62

SLIDE 63

does this progam satisfy (not strictly TLA):

♦(x = 1) ♦(x + y = 1)

as closed program: first property NO, second property YES
stuttering-invariants is a problem for “progress”

Liveness under stuttering Remember: safety prop Never anything bad happens (“”) Liveness prop. Eventually something “good” happens (“♦”)

program should not stutter forever
(Safety-only) specification Φ of before: does not capture progress of the program (but it

should) Φ InitΦ ∧ [A]x,y ∧ ♦A (17) Φ InitΦ ∧ [A]x,y ∧ ♦Ax,y (18) (remember: ♦ ¬¬): [A]x

A ∨ (x′ = x)

Ax

A ∧ (x′ = x)

What about fairness?

cf. our program again:

1

var natural x , y=0;

2

do // i n f i n i t e loop

3

true → x := x + 1

4

[ ] // choice

5

true → y := y + 1

6

d

Does it/should it satisfy “♦(x = 1)”

one can refine the previous spec:

Φ InitΦ ∧ [A]x,y ∧ ♦A1x,y ∧ ♦A2x,y (19)

these two red formulas are rough examples of fairness assumptions

Weak and strong fairness standard “slogans”: weak fairness An action which is “long enough” continu-

usly enabled, is taken.

strong fairness (drop somehow the “continuous): an action which is “often enough” enabled, is taken.

two “actions” needed

– enabled 30 (= in principle executable)

30 For any action A, enabled A is a predicate that is true for a state iff it is possible to taken an A step starting

in that state.

63

SLIDE 64

– executed (= actually executed)

weak fairness

((♦executed) ∨ ♦(¬enabled)) (20)

strong fairness

((♦executed) ∨ ♦(¬enabled)) (21) How to decrypt the formulas

Weak fairness:

((♦executed) ∨ ♦(¬enabled)) = (♦executed) ∨ ♦(¬enabled) (ϕ1 ∨ ϕ2) = ϕ1 ∨ ϕ2 Hint: try the negated formula: ¬weakfair

strong fairness

((♦executed) ∨ ♦(¬enabled)) Hint: again, try the negated formula: ¬strongfair System Specification in TLA TLA system spec. TLA system specifications have the form Init ∧ [Next]v ∧ L (22) – Init: State predicate of initial state(s) – Next: Action formula specifies the next-state relation.

usually disjunction A1 ∨

A2 ∨ ... ∨ An of all possible actions Ai – v: all flexible variables – L: Temporal formula asserting liveness property - usually written as conjunction WFv(Ai)∧ ..... ∧ SFv(An)of fairness conditions on actions The example again, e.g.: Φ InitΦ ∧ [A]x,y ∧ WF x,y(A1) ∧ WF x,y(A2) (23) What about “parallel” programs?

again: it’s a logical framework, there’s no programming languages
however

parallel composition = conjunction 64

SLIDE 65

TLA+ TLA is a program logic that expresses both programs and properties with a single language and TLA+ is a complete specification language based on TLA.

Modular structure
Specifications can be incrementally refined to low level designs
TLA+ is untyped: e.g. 5 = TRUE, 17 ∧ “abc”
Type correctness checked by asserting invariance property

Type correctness of a TLA+ specification Sp is an invariance property asserting that, in every state reached during every possible execution satisfying Sp, each state variable is an element of an appropriate set (its type). One finds type errors by checking this invariance property. TLA+: Type correctness example

1

MODULE HourClock

2 3

EXTENDS Naturals

4

VARIABLE hr

5 6

HCinit hr ∈ (0..23)

7

HCnext hr ′ = (hr%23) + 1

8

HC HCinit ∧ [HCnext]hr ∧ WF hrHCnext

9 10

TH E ORE M HC ⇒ HCinit # Type Correctness

HCinit is the Type Invariant also.

This theorem asserts that the formula, HC ⇒ HCinit, is true for all possible executions of HC. Refinement

1

MODULE HourMinuteClock

2

EXTENDS Naturals, Hourclock

3

VARIABLE min

4 5

HMCinit HCinit ∧ min ∈ (0..59)

6

Min min′ = (min%59) + 1

7

Hr (min = 59 ∧ HCnext) ∨ (min < 59 ∧ hr′ = hr)

8

HMCnext Min ∨ Hr

9

HMC HMCinit ∧ [HMCnext]hr,min ∧ WFhr,minHMCnext

10

THEOREM HMC ⇒ HC 65

SLIDE 66

TLC

Interactive theorem provers

– Applicable to TLA/TLA+ specifications – Tedious to apply, needs more expertise

TLC: TLA+model checker

– Finite state models can be analyzed – Brute-Force model checker, explicit state representation – Accepts TLA+specification and configuration file as inputs Configuration file SPECIFICATION Prog INVARIANT TypeInv PROPERTY NoDeadLock How TLC Works

Distributed and non-distributed mode
Uses disk for storing internal data structures and main memory as cache
Set of worker threads and a master thread to co-ordinate
A set seen and a FIFO queue sq
Initially compute all states satisfying initial predicate and keeps in seen and sq
Remove state s from head of sq and compute next state t for all possible subactions

– Check if t is in seen. – If it isn’t, check if t satisfies the invariant. – If it does, add t to seen (with a pointer to s). – If t satisfies the constraint, add it to the end of sq.

An error is reported if a next state t is found that does not satisfy the invariant, or if s has

no next state(uses pointers to predecessor to generate error traces)

State explosion problem

References

[Andrews, 2000] Andrews, G. R. (2000). Foundations of Multithreaded, Parallel, and Distributed

Programming. Addison-Wesley.

[Blackburn et al., 2001] Blackburn, P., de Rijke, M., and Venema, Y. (2001). Modal Logic. Cam- bridge University Press. [Bowen and Hinchey, 2005] Bowen, J. P. and Hinchey, M. G. (2005). Ten commandments revisited: a ten-year perspective on the industrial application of formal methods. In FMICS ’05: Proceed- ings of the 10th international workshop on Formal methods for industrial critical systems, pages 8–16, New York, NY, USA. ACM Press. [Büchi, 1960] Büchi, J. R. (1960). Weak second-order arithmentic and finite automata. Zeitschrift für mathematische Logik und Grundlagen der Mathematik, 6:66–92. [Büchi, 1962] Büchi, J. R. (1962). On a decision method in restricted second-order logic. In Proceedings of the 1960 Congress on Logic, Methodology and Philosophy of Science, pages 1–11. Stanford University Press. 66

SLIDE 67

[Garfinkel, 2005] Garfinkel, S. (2005). History’s worst software bugs. Available at http:// archive.wired.com/software/coolapps/news/2005/11/69355?currentPage=all. [Harel et al., 2000] Harel, D., Kozen, D., and Tiuryn, J. (2000). Dynamic Logic. Foundations of

Computing. MIT Press.

[Holzmann, 2003] Holzmann, G. J. (2003). The Spin Model Checker. Addison-Wesley. [Manna and Pnueli, 1992] Manna, Z. and Pnueli, A. (1992). The temporal logic of reactive and concurrent systems—Specification. Springer-Verlag, New York. [Peled, 2001] Peled, D. (2001). Software Reliability Methods. Springer-Verlag. [Schneider, 2004] Schneider, K. (2004). Verification of Reactive Systems. Springer-Verlag. 67