Software Verification 2 Automated Verification

Slides:



Advertisements
Similar presentations
1 Verification by Model Checking. 2 Part 1 : Motivation.
Advertisements

Software Verification 2 Automated Verification Prof. Dr. Holger Schlingloff Institut für Informatik der Humboldt Universität and Fraunhofer Institut für.
Model Checking Lecture 2. Three important decisions when choosing system properties: 1automata vs. logic 2branching vs. linear time 3safety vs. liveness.
Software Verification 1 Deductive Verification Prof. Dr. Holger Schlingloff Institut für Informatik der Humboldt Universität und Fraunhofer Institut.
CS 267: Automated Verification Lecture 8: Automata Theoretic Model Checking Instructor: Tevfik Bultan.
1 Model checking. 2 And now... the system How do we model a reactive system with an automaton ? It is convenient to model systems with Transition systems.
Automatic Verification Book: Chapter 6. What is verification? Traditionally, verification means proof of correctness automatic: model checking deductive:
Temporal Logic and the NuSMV Model Checker CS 680 Formal Methods Jeremy Johnson.
CS6133 Software Specification and Verification
Formal Semantics of Programming Languages 虞慧群 Topic 5: Axiomatic Semantics.
Process Synchronization Continued 7.2 The Critical-Section Problem.
Formal Methods of Systems Specification Logical Specification of Hard- and Software Prof. Dr. Holger Schlingloff Institut für Informatik der.
Formal Methods of Systems Specification Logical Specification of Hard- and Software Prof. Dr. Holger Schlingloff Institut für Informatik der Humboldt.
Formal Methods of Systems Specification Logical Specification of Hard- and Software Prof. Dr. Holger Schlingloff Institut für Informatik der.
Formal Methods of Systems Specification Logical Specification of Hard- and Software Prof. Dr. Holger Schlingloff Institut für Informatik der Humboldt.
Formal Methods of Systems Specification Logical Specification of Hard- and Software Prof. Dr. Holger Schlingloff Institut für Informatik der.
Formal Methods of Systems Specification Logical Specification of Hard- and Software Prof. Dr. Holger Schlingloff Institut für Informatik der Humboldt.
Formal Methods of Systems Specification Logical Specification of Hard- and Software Prof. Dr. Holger Schlingloff Institut für Informatik der Humboldt.
Tele Design of Reactive Systems Summer 2001 Prof. Dr. Stefan Leue Institute for Computer Science Albert-Ludwigs-Universität Freiburg
Formal Methods of Systems Specification Logical Specification of Hard- and Software Prof. Dr. Holger Schlingloff Institut für Informatik der.
Discrete Abstractions of Hybrid Systems Rajeev Alur, Thomas A. Henzinger, Gerardo Lafferriere and George J. Pappas.
Information Security of Embedded Systems : Public Key Cryptosystems, Communication Prof. Dr. Holger Schlingloff Institut für Informatik und Fraunhofer.
Specification Formalisms Book: Chapter 5. Properties of formalisms Formal. Unique interpretation. Intuitive. Simple to understand (visual). Succinct.
Review of the automata-theoretic approach to model-checking.
Embedded Systems Laboratory Department of Computer and Information Science Linköping University Sweden Formal Verification and Model Checking Traian Pop.
ESE601: Hybrid Systems Introduction to verification Spring 2006.
Formal Methods of Systems Specification Logical Specification of Hard- and Software Prof. Dr. Holger Schlingloff Institut für Informatik der.
Flavio Lerda 1 LTL Model Checking Flavio Lerda. 2 LTL Model Checking LTL –Subset of CTL* of the form: A f where f is a path formula LTL model checking.
15-820A 1 LTL to Büchi Automata Flavio Lerda A 2 LTL to Büchi Automata LTL Formulas Subset of CTL* –Distinct from CTL AFG p  LTL  f  CTL. f.
Software Verification 1 Deductive Verification Prof. Dr. Holger Schlingloff Institut für Informatik der Humboldt Universität und Fraunhofer Institut.
Software Verification 2 Automated Verification Prof. Dr. Holger Schlingloff Institut für Informatik der Humboldt Universität and Fraunhofer Institut für.
Software Verification 2 Automated Verification Prof. Dr. Holger Schlingloff Institut für Informatik der Humboldt Universität and Fraunhofer Institut für.
Software Verification 1 Deductive Verification Prof. Dr. Holger Schlingloff Institut für Informatik der Humboldt Universität und Fraunhofer Institut.
CIS 842: Specification and Verification of Reactive Systems Lecture Specifications: LTL Model Checking Copyright , Matt Dwyer, John Hatcliff,
Software Verification 2 Automated Verification Prof. Dr. Holger Schlingloff Institut für Informatik der Humboldt Universität and Fraunhofer Institut für.
Recognizing safety and liveness Presented by Qian Huang.
Defining Liveness by Bowen Alpern and Fred B. Schneider Presented by Joe Melnyk.
Software Verification 1 Deductive Verification Prof. Dr. Holger Schlingloff Institut für Informatik der Humboldt Universität und Fraunhofer Institut.
Lecture 5 1 CSP tools for verification of Sec Prot Overview of the lecture The Casper interface Refinement checking and FDR Model checking Theorem proving.
1 Temporal logic. 2 Prop. logic: model and reason about static situations. Example: Are there truth values that can be assigned to x,y simultaneously.
Software Verification 2 Automated Verification Prof. Dr. Holger Schlingloff Institut für Informatik der Humboldt Universität and Fraunhofer Institut für.
Software Verification 1 Deductive Verification Prof. Dr. Holger Schlingloff Institut für Informatik der Humboldt Universität und Fraunhofer Institut.
Today’s Agenda  Quiz 4  Temporal Logic Formal Methods in Software Engineering1.
Software Verification 2 Automated Verification Prof. Dr. Holger Schlingloff Institut für Informatik der Humboldt Universität and Fraunhofer Institut für.
Software Verification 1 Deductive Verification Prof. Dr. Holger Schlingloff Institut für Informatik der Humboldt Universität und Fraunhofer Institut.
Software Verification 1 Deductive Verification Prof. Dr. Holger Schlingloff Institut für Informatik der Humboldt Universität und Fraunhofer.
6/12/20161 a.a.2015/2016 Prof. Anna Labella Formal Methods in software development.
Model Checking Lecture 2. Model-Checking Problem I |= S System modelSystem property.
29/06/2016Verification Synchronous Languages Verification.
Model Checking Lecture 2 Tom Henzinger. Model-Checking Problem I |= S System modelSystem property.
SS 2017 Software Verification Timed Automata
SS 2017 Software Verification Probabilistic modelling – DTMC / MDP
Prof. Dr. Holger Schlingloff 1,2 Dr. Esteban Pavese 1
Prof. Dr. Holger Schlingloff 1,2 Dr. Esteban Pavese 1
Software Verification 2 Automated Verification
SS 2017 Software Verification LTL monitoring
SS 2018 Software Verification LTL Satisfiability applied
SS 2018 Software Verification ML, state machines
SS 2017 Software Verification CTL model checking, BDDs
Axiomatic semantics Points to discuss: The assignment statement
SS 2017 Software Verification Tableaus, CTL model checking
Software Verification 2 Automated Verification
SS 2018 Software Verification Strategic Reasoning
Software Verification 2 Automated Verification
Formal Methods in software development
Formal Methods in software development
Introduction to verification
Formal Methods in software development
Formal Methods in software development
Program correctness Branching-time temporal logics
Presentation transcript:

Software Verification 2 Automated Verification Prof. Dr. Holger Schlingloff Institut für Informatik der Humboldt Universität and Fraunhofer Institut für Rechnerarchitektur und Softwaretechnik

Postscript F*G*p cannot be expressed as G*F*φ ¬ (F*G*p  G*F*p) is obvious Show: there is no pure-past LTL-formula φ such that (F*G*p  G*F*φ) Assume the contrary: there is a pure-past LTL-formula φ such that (F*G*p  G*F*φ) Consider the model M0 = p = ppp... Then M0 ⊨ F*G*p, hence by ass. M0 ⊨ G*F*φ hence (M0,0) ⊨ F*φ and there is a point i0 such that (M0, i0) ⊨ φ Consider the model M1 = (pi0) (¬p) (p). Since φ is pure past, (M1, i0) ⊨ φ Furthermore, M1 ⊨ F*G*p, hence by ass. M1 ⊨ G*F*φ, hence (M1, i0+2) ⊨ F*φ and there is a point i1 > i0+1 such that (M1, i1) ⊨ φ Consider the model M2 where p is false only at (i0+1) and (i1+1). Again (M2, i0) ⊨ φ and (M2, i1) ⊨ φ . Furthermore, M2 ⊨ F*G*p and M2 ⊨ G*F*φ, hence (M2, i1+2) ⊨ F*φ and there is i2>i1+1 such that (M2, i2) ⊨ φ and so on. Let M be the model defined by (M, k) ⊨ p iff for all i, (Mi, k) ⊨ p (thanks, Jochen!) In M , p is false infinitely often and φ is true infinitely often. Hence, M ⊭ F*G*p and M ⊨ G*F*φ, which is a contradiction 12.4.2012

Safety and Liveness Properties Proof of decomposition theorem: φs={w0w1... | for every i, w0w1... wi is a prefix of φ} φl= φ{w0w1... | for some i, w0w1... wi is not a prefix of φ} show: φs is safety, φl is liveness, φ = φs  φl 24.5.2012

Examples (p U+ q) = ((p W+ q)  F+ q) G*(p  F*q) = (G*p  G*F*q) G*p  G*q = G*(H*p  H*q) (holds only initially, in the beginning!) Total program correctness = invariance  termination other direction does not hold 24.5.2012

Example: Peterson’s Mutual Exclusion {t=0; x=0; y=0; {0: while(true){NC1: skip; 1: x=1; 2: t=1; 3: await(t==0  y==0); C1: skip; 4: x=0;} || {0: while(true){NC2: skip; 1: y=1; 2: t=0; 3: await(t==1  x==0); C2: skip; 4: y=0;} } We want to show: G*(¬ C1  ¬ C2)  true G*(3  F* C1)  false!! (G*F*  G*F*)  G*(3  F* C1) 12.4.2012

Language inclusion “Safety property” is a semantic notion The language of any (finitary) LTS is a safety property show that if any finite prefix of an infinite model can be extended to an accepted model, then the whole model is accepted If a safety property is given as an LTS, model checking can be done by “parallel execution” Example 12.4.2012

Verification = language containment? An implementation I satisfies a specification S if L(I)  L(S) “the automata-theoretic approach to model-checking” But not always adequate: 12.4.2012

Simulation relation Simulation relation between models 12.4.2012

Preserving CTL properties Converse does not hold: image finiteness needed! 12.4.2012

Simulation Checking If both models are deterministic, use automata inclusion Otherwise, define a sequence of relations the intersection is the largest possible simulation relation partition refinement algorithm (greatest fixed point) 12.4.2012

12.4.2012

Examples 12.4.2012