INF5140 – Specification and Verification ofParallel SystemsOverview, lecture 1

Spring 2015

January 23, 2015

1 / 75

Content

See the homepage of the course:

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

2 / 75

Evaluation System

1. Two (small) mandatory assignmentsAlternative: Write a research report (paper) on a topic relatedto the course (specification and model checking)

2. Paper presentation on related topics3. Oral exam

The mandatory assignments (as usual) give you the right totake the examA minimum will be required on every item above in order to beapproved (e.g. you must present a paper)

RemarksWe will give you precise guidelines during the courseCheck the web page regularly

3 / 75

Formal Methods

Outline

Content of the CourseEvaluationAbout Ourselves

1 Formal MethodsMotivation

An Easy ProblemHow to guarantee correctness of a system?

Software BugsOn Formal Methods

What are Formal Methods?General RemarksClassification of Formal MethodsA Few Success StoriesHow to Choose the Right Formal Method?

Formalisms for Specification and VerificationSpecificationVerification

5 / 75

The Problem

Compute the value of a20 given the following definition1

a0 = 112

a1 = 6111

an+2 = 111−1130− 3000

anan+1

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

A Java Implementation

class mya {

static double a(int n) {if (n==0)

return 11/2.0;if (n==1)

return 61/11.0;return 111 - (1130 - 3000/a(n-2))/a(n-1);

}

public static void main(String[] argv) {for (int i=0;i<=20;i++)

System.out.println("a("+i+") = "+a(i));}

}

7 / 75

The Solution (?)

$ java myaa(0) = 5.5a(2) = 5.5901639344262435a(4) = 5.674648620514802a(6) = 5.74912092113604a(8) = 5.81131466923334a(10) = 5.861078484508624a(12) = 5.935956716634138a(14) = 15.413043180845833a(16) = 97.13715118465481a(18) = 99.98953968869486a(20) = 99.99996275956511

8 / 75

Should we Trust Software?

In fact the value of an for any n ≥ 0 may be computed by using thefollowing expression:

an =6n+1 + 5n+1

6n + 5n

Where

limn→∞ an = 6

We get then

a20 ≈ 6!

9 / 75

Correctness

A system is correct if it meets its design requirements

Examples:System: The previous Java program computing anRequirement: For any n ≥ 0, the program should be conformwith the previous equation (limn→∞ an = 6)

System: A telephone systemRequirement: If user A want to call user B, then eventually Awill manage to establish a connectionSystem: An operating systemRequirement: A deadly embrace2 will never happen

2A deadly embrace is when two processes obtain access to two mutuallydependent shared resources and each decide to wait indefinitely for the other.

10 / 75

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 requirementWe should show that a system cannot fail to meet itsrequirementBy testing? Dijkstra wrote (1972): “Program testing can beused to show the presence of bugs, but never to show theirabsence”By other kind of “proof”? Dijkstra again (1965): “One cannever 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 ageneral proof procedure for arbitrary programs3

Any hope? In some cases it is possible to mechanically verifycorrectness; in other cases... we try to do our best

3Undecidability of the halting problem, by Turing.11 / 75

What is Validation?

In general, validation is the process of checking if somethingsatisfies a certain criterionDo 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 requiresVerification: "Are we building the product right?", i.e., does the

product conform to the specifications

4Some authors define verification as a validation technique, others talkabout V & V –Validation & Verification– as being complementary techniques.

12 / 75

Usual Approaches for Validation

The following techniques are used in industry for validation:

TestingCheck the actual system rather than a modelFocused on sampling executions according to some coveragecriteria – Not exhaustiveIt is usually informal, though there are some formal approaches

SimulationA model of the system is written in a PL, which is run withdifferent inputs – Not exhaustive

Verification“Is the process of applying a manual or automatic techniquefor establishing whether a given system satisfies a givenproperty or behaves in accordance to some abstract description(specification) of the system”5

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

Source of Errors

Errors may arise at different stages of the Software/Hardwaredevelopment:

Specification errors (incomplete or wrong specification)Transcription from the informal to the formal specificationModeling errors (abstraction, incompleteness, etc)Translation from the specification to the actual codeHandwritten proof errorsProgramming errorsErrors in the implementation of (semi-)automatic tools /compilersWrong use of tools/programs. . .

14 / 75

Source of Errors

Most errors, however, are detected quite late on the developmentprocess6

6Picture borrowed from G.Holzmann’s slides(http://spinroot.com/spin/Doc/course/index.html)

15 / 75

Some Famous Software Bugsa

aSource: Garfinkel’s article “History’ worst software bugs”

July 28, 1962 – Mariner I space probe The Mariner I rocket diverts fromits intended direction and was destroyed by the mission control.Software error caused the miscalculation of rocket’s trajectory.Source of error: wrong transcription of a handwritten formulainto the implementation code.

1985-1987 – Therac-25 medical accelerator A radiation therapy devicedeliver high radiation doses. At least 5 patients died and manywere injured. Under certain circumstances it was possible toconfigure the Therac-25 so the electron beam would fire inhigh-power mode but with the metal X-ray target out ofposition. Source of error: a “race condition”.

16 / 75

Some Famous Software Bugsa

aSource: Garfinkel’s article “History’ worst software bugs”

1988 – Buffer overflow in Berkeley Unix finger daemon An Internetworm infected more than 6000 computers in a day. The use ofa C routine gets() had no limits on its input. A large inputallows the worm to take over any connected machine. Kind oferror: Language design error (Buffer overflow).

1993 – Intel Pentium floating point divide A Pentium chip mademistakes when dividing floating point numbers (errors of0.006%). Between 3 and 5 million chips of the unit have to bereplaced (estimated cost: 475 million dollars). Kind of error:Hardware error.

17 / 75

Some Famous Software Bugsa

aSource: Garfinkel’s article “History’ worst software bugs”

June 4, 1996 – Ariane 5 Flight 501 Error in a code converting 64-bitfloating-point numbers into 16-bit signed integer. It triggeredan overflow condition which made the rocket to disintegrate 40seconds after launch. Error: Exception handling error.

November 2000 – National Cancer Institute, Panama City A therapyplanning software allowed doctors to draw some “holes” forspecifying the placement of metal shields to protect healthytissue from radiation. The software interpreted the “hole” indifferent ways depending on how it was drawn, exposing thepatient to twice the necessary radiation. 8 patients died; 20received overdoses. Error: Incomplete specification / wronguse.

18 / 75

What are Formal Methods?

“Formal methods are a collection of notations and techniquesfor describing and analyzing systems”7

Formal means the methods used are based on mathematicaltheories, such as logic, automata, graph or set theoryFormal specification techniques are used to unambiguouslydescribe the system itself or its propertiesFormal analysis/verification techniques serve to verify that asystem satisfies its specification (or to help finding out why itis not the case)

7From D.Peled’s book “Software Reliability Methods”.19 / 75

What are Formal Methods?Some Terminology

The term verification is used in different ways

Sometimes used only to refer the process of obtaining theformal correctness proof of a system (deductive verification)In other cases, used to describe any action taken for findingerrors in a program (including model checking and testing)Sometimes testing is not considered to be a verificationtechnique

We will use the following definition (reminder):

Formal verification is the process of applying a manual or automaticformal technique for establishing whether a given system satisfies agiven property or behaves in accordance to some abstractdescription (formal specification) of the system

Saying ’a program is correct’ is only meaningful w.r.t. a given spec!

20 / 75

Limitations

Software verification methods do not guarantee, in general, thecorrectness of the code itself but rather of an abstract modelof itIt cannot identify fabrication faults (e.g. in digital circuits)If the specification is incomplete or wrong, the verificationresult will also be wrongThe implementation of verification tools may be faultyThe bigger the system (number of possible states) moredifficult is to analyze it (state explosion problem)

21 / 75

Any advantage?

OF COURSE!

Formal methods are not intended to guarantee absolute reliabilitybut to increase the confidence on system reliability. They help

minimizing the number of errors and in many cases allow to finderrors impossible to find manually

22 / 75

Using Formal Methods

Formal methods are used in different stages of the developmentprocess, giving a classification of formal methods

1. We describe the system giving a formal specification2. We can then prove some properties about the specification3. We can proceed by:

Deriving a program from its specification (formal synthesis)Verifying the specification w.r.t. implementation

23 / 75

Formal Specification

A specification formalism must be unambiguous: it shouldhave a precise syntax and semantics

Natural languages are not suitableA trade-off must be found between expressiveness and analysisfeasibility

More expressive the specification formalism more difficult itsanalysis

Do not confuse the specification of the system itself with thespecification of some of its properties

Both kinds of specifications may use the same formalism butnot necessarilyFor example:

The system specification can be given as a program or as astate machineSystem properties can be formalized using some logic

24 / 75

Proving Properties about the Specification

To gain confidence about the correctness of a specification it isuseful to:

Prove some properties of the specification to check that itreally means what it is supposed toProve the equivalence of different specifications

Example

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

First attempt: a(0) ∧ a(1) ∧ ∀t · a(t + 1) = ¬a(t)INCORRECT! - The error may be found when trying to provesome propertiesCorrect specification:a(0) ∧ a(1) ∧ ∀t ≥ 0 · a(t + 2) = ¬a(t + 1)

25 / 75

Formal synthesis

It would be helpful to automatically obtain an implementationfrom the specification of a systemDifficult since most specifications are declarative and notconstructive

They usually describe what the system should do; not how itcan be achieved

Example.1. Specify the operational semantics of a programming language

in a constructive logic (Calculus of Constructions)2. Prove the correctness of a given property w.r.t. the

operational semantics in Coq3. Extract an OCAML code from the correctness proof (using

Coq’s extraction mechanism)

26 / 75

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 modelProve that Φimp =⇒ Φspec

Algorithmic approachDescribe the specification Φspec as a formula of a logicDescribe the system as an interpretation Mimp of the givenlogic (e.g. as a finite automaton)Prove that Mimp is a “model” (in the logical sense) of Φspec

27 / 75

A Few Success Stories

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

Scade/LustreEsterel

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

28 / 75

Classification of Systems

Before discussing how to choose the right Formal Method we needa classification of systems

Different kind of systems and not all methodologies/techniquesmay be applied to all kind of systemsSystems may be classified depending on: 8

Their architectureThe type of interaction

8Here we follow Klaus Schneider’s book “Verification of reactive systems”.29 / 75

Classification of SystemsAccording to the System Architecture

Asynchronous vs. Synchronous HardwareAnalog vs. Digital HardwareMono- vs. Multi-processor systemsImperative vs. Functional vs. Logical vs. Object-orientedSoftwareConcurrent vs. Sequential SoftwareConventional vs. Real-time Operating SystemsEmbedded vs. Local vs. Distributed Systems

30 / 75

Classification of SystemsAccording to the Type of Interaction

Transformational systems: Read inputs and produce outputs- These systems should always terminateInteractive systems: Idem previous, but they are notassumed to terminate (unless explicitly required) –Environment has to wait till the system is readyReactive systems: Non-terminating systems. Theenvironment decides when to interact with the system - Thesesystems must be fast enough to react to an environmentaction (real-time systems)

31 / 75

Taxonomy of Properties

Many specification formalisms can be classified depending onthe kind of properties they are able to express/verifyProperties may be organized in the following categories

Functional correctness: The program for computing the squareroot really computes itTemporal behavior: The answer arrives in less than 40 secondsSafety properties (“something bad never happens”): Trafficlights of crossing streets are never green simultaneouslyLiveness properties (“something good eventually happens”):Process A will eventually be executedPersistence properties (stabilization): For all computationsthere is a point where process A is always enabledFairness properties (some property will hold infinitely often):No process is ignored infinitely often by an O.S.

32 / 75

When and Which Formal Method to Use?

It depends on the problem, the underlying system and theproperty we want to proveExamples:

Digital circuits ... (BDDs, model checking)Communication protocol with unbounded number ofprocesses.... (verification of infinite-state systems)Overflow in programs (static analysis and abstractinterpretation)...

Open distributed concurrent systems with unbounded numberof processes interacting through shared variables and withreal-time constraints => VERY DIFFICULT!!Need the combination of different techniques

33 / 75

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 formalismsFinite-state automataTimed and hybrid automata

Process algebraCCS (LOTOS, ...)π-calculus

Visual formalismsMSC (Message Sequence Chart)StatechartsPetri nets

34 / 75

Some Techniques and Methodologies for Verification

Algorithmic verificationFinite-state systems (model checking)Infinite-state systemsHybrid systemsReal-time systems

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

35 / 75

Summary

Formal Methods are useful and neededWhich FM to use depends on the problem, the underlyingsystem and the property we want to proveIn real complex systems, only part of the system may beformally proved and no single FM can make the task

Our course will concentrate onTemporal logic as a specification formalismSafety, liveness and (maybe) fairness propertiesSPIN (LTL Model Checking)Few other techniques from student presentation (e.g., abstractinterpretation, CTL model checking, timed automata)

36 / 75

Ten Commandments of Formal Methods

From “Ten commandments revisited”, by J.P. Bowen and M.G.Hinchey (In: FMICS’05, ACM. Sept. 2005, pp.8–16)1. Choose an appropriate notation2. Formalize but not over-formalize3. Estimate costs4. Have a formal method guru on call5. Do not abandon your traditional methods6. Document sufficiently7. Do not compromise your quality standards8. Do not be dogmatic9. Test, test and test again10. Do reuse

37 / 75

Further Reading

The content of this talk was based in many different sources. Thefollowing chapter is a good survey:

Klaus Schneider: Verification of reactive systems, 2003.Springer. Chap. 1

For lecture 2 (28/01/2009):G. Andrews: Foundations of Multithreaded, Parallel, andDistributed Programming, 2000. Addison Wesley. Chap. 2Z. Manna and A. Pnueli: Temporal Verification of ReactiveSystems: Safety, Springer-Verlag, 1995. Chap. 09

9This chapter is also the base of lectures 3 and 4.38 / 75

References I

[Blackburn et al., 2001] Blackburn, P., de Rijke, M., and Venema, Y. (2001).Modal Logic.Cambridge University 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. StanfordUniversity Press.

[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.

39 / 75