1 Formal Methods in SE Qaisar Javaid Assistant Professor Lecture # 11.

Slides:



Advertisements
Similar presentations
Model Checking Lecture 3. Specification Automata Syntax, given a set A of atomic observations: Sfinite set of states S 0 Sset of initial states S S transition.
Advertisements

Automated Theorem Proving Lecture 1. Program verification is undecidable! Given program P and specification S, does P satisfy S?
Translating from logic to automata Book: Chapter 6.
Model Checking and Testing combined
Black Box Checking Book: Chapter 9 Model Checking Finite state description of a system B. LTL formula. Translate into an automaton P. Check whether L(B)
Automatic Verification Book: Chapter 6. How can we check the model? The model is a graph. The specification should refer the the graph representation.
Modeling issues Book: chapters 4.12, 5.4, 8.4, 10.1.
Two algorithms for checking emptiness. How to check for emptiness? Is L (A) = ; ? Need to check if there exists an accepting computation (passes through.
CS 267: Automated Verification Lecture 2: Linear vs. Branching time. Temporal Logics: CTL, CTL*. CTL model checking algorithm. Counter-example generation.
CS 267: Automated Verification Lecture 8: Automata Theoretic Model Checking Instructor: Tevfik Bultan.
Partial Order Reduction: Main Idea
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:
C O N T E X T - F R E E LANGUAGES ( use a grammar to describe a language) 1.
PROTOCOL VERIFICATION & PROTOCOL VALIDATION. Protocol Verification Communication Protocols should be checked for correctness, robustness and performance,
1 1 CDT314 FABER Formal Languages, Automata and Models of Computation Lecture 3 School of Innovation, Design and Engineering Mälardalen University 2012.
Timed Automata.
1 Partial Order Reduction. 2 Basic idea P1P1 P2P2 P3P3 a1a1 a2a2 a3a3 a1a1 a1a1 a2a2 a2a2 a2a2 a2a2 a3a3 a3a3 a3a3 a3a3 a1a1 a1a1 3 independent processes.
Rigorous Software Development CSCI-GA Instructor: Thomas Wies Spring 2012 Lecture 13.
CS 267: Automated Verification Lecture 10: Nested Depth First Search, Counter- Example Generation Revisited, Bit-State Hashing, On-The-Fly Model Checking.
PSWLAB S PIN Search Algorithm from “THE SPIN MODEL CHECKER” by G Holzmann Presented by Hong,Shin 9 th Nov SPIN Search Algorithm.
1 Temporal Claims A temporal claim is defined in Promela by the syntax: never { … body … } never is a keyword, like proctype. The body is the same as for.
CIS 540 Principles of Embedded Computation Spring Instructor: Rajeev Alur
1 Introduction to Computability Theory Lecture12: Decidable Languages Prof. Amos Israeli.
CSE 555 Protocol Engineering Dr. Mohammed H. Sqalli Computer Engineering Department King Fahd University of Petroleum & Minerals Credits: Dr. Abdul Waheed.
Specification Formalisms Book: Chapter 5. Properties of formalisms Formal. Unique interpretation. Intuitive. Simple to understand (visual). Succinct.
Abstractions. Outline Informal intuition Why do we need abstraction? What is an abstraction and what is not an abstraction A framework for abstractions.
1 Carnegie Mellon UniversitySPINFlavio Lerda SPIN An explicit state model checker.
Temporal Logic and Model Checking. Reactive Systems We often classify systems into two types: Transformational: functions from inputs available at the.
1 Translating from LTL to automata Book: Chapter 6.
Witness and Counterexample Li Tan Oct. 15, 2002.
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.
1 Completeness and Complexity of Bounded Model Checking.
Witness and Counterexample Li Tan Oct. 15, 2002.
Automata and Formal Lanugages Büchi Automata and Model Checking Ralf Möller based on slides by Chang-Beom Choi Provable Software Lab, KAIST.
1 Translating from LTL to automata. 2 Why translating? Want to write the specification in some logic. Want to check that an automaton (or a Kripke structure)
LTL – model checking Jonas Kongslund Peter Mechlenborg Christian Plesner Kristian Støvring Sørensen.
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.
1 Carnegie Mellon UniversitySPINFlavio Lerda Bug Catching SPIN An explicit state model checker.
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.
Regular Model Checking Ahmed Bouajjani,Benget Jonsson, Marcus Nillson and Tayssir Touili Moran Ben Tulila
Model Checking Lecture 4 Tom Henzinger. Model-Checking Problem I |= S System modelSystem property.
1 Completeness and Complexity of Bounded Model Checking.
Basics of automata theory
Model Checking Lecture 3 Tom Henzinger. Model-Checking Problem I |= S System modelSystem property.
CIS 842: Specification and Verification of Reactive Systems Lecture Specifications: LTL Model Checking Copyright , Matt Dwyer, John Hatcliff,
Copyright , Doron Peled and Cesare Tinelli. These notes are based on a set of lecture notes originally developed by Doron Peled at the University.
Formal methods: Model Checking and Testing Prof. Doron A. Peled University of Warwick, UK and Bar Ilan University, Israel.
Four Lectures on Model Checking Tom Henzinger University of California, Berkeley.
CIS 540 Principles of Embedded Computation Spring Instructor: Rajeev Alur
Constraints Assisted Modeling and Validation Presented in CS294-5 (Spring 2007) Thomas Huining Feng Based on: [1]Constraints Assisted Modeling and Validation.
CIS 540 Principles of Embedded Computation Spring Instructor: Rajeev Alur
Translating from logic to automata (Book: Chapter 6)
1 CSEP590 – Model Checking and Automated Verification Lecture outline for July 9, 2003.
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.
Variants of LTL Query Checking Hana ChocklerArie Gurfinkel Ofer Strichman IBM Research SEI Technion Technion - Israel Institute of Technology.
Today’s Agenda  Quiz 4  Temporal Logic Formal Methods in Software Engineering1.
Model Checking Doron A. Peled University of Warwick Coventry, UK
Honors Track: Competitive Programming & Problem Solving 2-Satisfiability José Kuiper.
CIS 540 Principles of Embedded Computation Spring Instructor: Rajeev Alur
Model Checking Lecture 2. Model-Checking Problem I |= S System modelSystem property.
Model Checking Lecture 2 Tom Henzinger. Model-Checking Problem I |= S System modelSystem property.
Complexity of Compositional Model Checking of Computation Tree Logic on Simple Structures Krishnendu Chatterjee Pallab Dasgupta P.P. Chakrabarti IWDC 2004,
15-820A 1 LTL Model Checking A Flavio Lerda.
Automatic Verification
Alternating tree Automata and Parity games
An explicit state model checker
Translating Linear Temporal Logic into Büchi Automata
Presentation transcript:

1 Formal Methods in SE Qaisar Javaid Assistant Professor Lecture # 11

2 Automatic Verification

3 How can we check the model? The model is a graph. The specification should refer the the graph representation. Apply graph theory algorithms.

4 What properties can we check? Invariant: a property that needs to hold in each state. Deadlock detection: can we reach a state where the program is blocked? Dead code: does the program have parts that are never executed.

5 How to perform the checking? Apply a search strategy (Depth first search, Breadth first search). Check states/transitions during the search. If property does not hold, report counter example!

6 If it is so good, why learn deductive verification methods? Model checking works only for finite state systems. Would not work with Unconstrained integers. Unbounded message queues. General data structures: queues trees stacks parametric algorithms and systems.

7 The state space explosion Need to represent the state space of a program in the computer memory. Each state can be as big as the entire memory! Many states: Each integer variable has 2^32 possibilities. Two such variables have 2^64 possibilities. In concurrent protocols, the number of states usually grows exponentially with the number of processes.

8 If it is so constrained, is it of any use? Many protocols are finite state. Many programs or procedure are finite state in nature. Can use abstraction techniques. Sometimes it is possible to decompose a program, and prove part of it by model checking and part by theorem proving. Many techniques to reduce the state space explosion.

9 Depth First Search Program DFS For each s such that Init(s) dfs(s) end DFS Procedure dfs(s) for each s’ such that R(s,s’) do If new(s’) then dfs(s’) end dfs.

10 Start from an initial state q3q3 q4q4 q2q2 q1q1 q5q5 q1q1 q1q1 Stack: Hash table:

11 Continue with a successor q3q3 q4q4 q2q2 q1q1 q5q5 q 1 q 2 q1q2q1q2 Stack: Hash table:

12 One successor of q 2. q3q3 q4q4 q2q2 q1q1 q5q5 q 1 q 2 q 4 q1q2q4q1q2q4 Stack: Hash table:

13 Backtrack to q 2 (no new successors for q 4 ). q3q3 q4q4 q2q2 q1q1 q5q5 q 1 q 2 q 4 q1q2q1q2 Stack: Hash table:

14 Backtracked to q 1 q3q3 q4q4 q2q2 q1q1 q5q5 q 1 q 2 q 4 q1q1 Stack: Hash table:

15 Second successor to q 1. q3q3 q4q4 q2q2 q1q1 q5q5 q 1 q 2 q 4 q 3 q1q3q1q3 Stack: Hash table:

16 Backtrack again to q 1. q3q3 q4q4 q2q2 q1q1 q5q5 q 1 q 2 q 4 q 3 q1q1 Stack: Hash table:

17 How can we check properties with DFS? Invariants: check that all reachable states satisfy the invariant property. If not, show a path from an initial state to a bad state. Deadlocks: check whether a state where no process can continue is reached. Dead code: as you progress with the DFS, mark all the transitions that are executed at least once.

18 The state graph:Successor relation between states. Turn=0 L0,L1 Turn=0 L0,NC1 Turn=0 NC0,L1 Turn=0 CR0,NC1 Turn=0 NC0,NC1 Turn=0 CR0,L1 Turn=1 L0,CR1 Turn=1 NC0,CR1 Turn=1 L0,NC1 Turn=1 NC0,NC1 Turn=1 NC0,L1 Turn=1 L0,L1

19 ¬ (PC0=CR0/\PC1=CR1) is an invariant! Turn=0 L0,L1 Turn=0 L0,NC1 Turn=0 NC0,L1 Turn=0 CR0,NC1 Turn=0 NC0,NC1 Turn=0 CR0,L1 Turn=1 L0,CR1 Turn=1 NC0,CR1 Turn=1 L0,NC1 Turn=1 NC0,NC1 Turn=1 NC0,L1 Turn=1 L0,L1

20 Want to do more! Want to check more properties. Want to have a unique algorithm to deal with all kinds of properties. This is done by writing specification in more complicated formalisms. We will see that in the next lecture.

21 [](Turn=0  <>Turn=1) Turn=0 L0,L1 Turn=0 L0,NC1 Turn=0 NC0,L1 Turn=0 CR0,NC1 Turn=0 NC0,NC1 Turn=0 CR0,L1 Turn=1 L0,CR1 Turn=1 NC0,CR1 Turn=1 L0,NC1 Turn=1 NC0,NC1 Turn=1 NC0,L1 Turn=1 L0,L1

22 Turn=0 L0,L1 Turn=0 L0,NC1 Turn=0 NC0,L1 Turn=0 CR0,NC1 Turn=0 NC0,NC1 Turn=0 CR0,L1 Turn=1 L0,CR1 Turn=1 NC0,CR1 Turn=1 L0,NC1 Turn=1 NC0,NC1 Turn=1 NC0,L1 Turn=1 L0,L1 init New initial state Convert graph into Buchi automaton

23 Turn=0 L0,L1 Turn=1 L0,L1 init Propositions are attached to incoming nodes. All nodes are accepting. Turn=1 L0,L1 Turn=0 L0,L1

24 Correctness condition We want to find a correctness condition for a model to satisfy a specification. Language of a model: L(Model) Language of a specification: L(Spec). We need: L(Model)  L(Spec).

25 Correctness All sequences Sequences satisfying Spec Program executions

26 How to prove correctness? Show that L(Model)  L(Spec). Equivalently: ______ Show that L(Model)  L(Spec) = Ø. Also: can obtain Spec by translating from LTL!

27 What do we need to know? How to intersect two automata? How to complement an automaton? How to translate from LTL to an automaton?

28 Intersecting M 1 =(S 1, ,T 1,I 1,A 1 ) and M 2 =(S 2, ,T 2,I 2,S 2 ) Run the two automata in parallel. Each state is a pair of states: S 1 x S 2 Initial states are pairs of initials: I 1 x I 2 Acceptance depends on first component: A 1 x S 2 Conforms with transition relation: (x 1,y 1 )-a->(x 2,y 2 ) when x 1 -a->x 2 and y 1 -a->y 2.

29 Example (all states of second automaton accepting!) a b ct0t0 t1t1 a a b,c s0s0 s1s1 States: (s 0,t 0 ), (s 0,t 1 ), (s 1,t 0 ), (s 1,t 1 ). Accepting: (s 0,t 0 ), (s 0,t 1 ). Initial: (s 0,t 0 ).

30 a b c t0t0 t1t1 a a b,c s0s0 s1s1 s 0,t 0 s 0,t 1 s 1,t 1 s 1,t 0 b b a c a c

31 More complicated when A 2  S 2 a b ct0t0 t1t1 a a b,c s0s0 s1s1 Should we have acceptance when both components accepting? I.e., {(s 0,t 1 )}? No, consider (ba)  It should be accepted, but never passes that state. s 0,t 0 s 0,t 1 s 1,t 1 b a c a c

32 More complicated when A 2  S 2 a b ct0t0 t1t1 a a b,c s0s0 s1s1 Should we have acceptance when at least one components is accepting? I.e., {(s 0,t 0 ),(s 0,t 1 ),(s 1,t 1 )}? No, consider b c  It should not be accepted, but here will loop through (s 1,t 1 ) s 0,t 0 s 0,t 1 s 1,t 1 b c a c a

33 Intersection - general case q0q0 q2q2 q3q3 q1q1 q 0,q3q 1,q 3 q1,q2q1,q2 a a, c c c, b b c c b a

34 Version 0: to catch q 0 Version 1: to catch q 2 q 0,q 3 q 1,q 3 q1,q2q1,q2 q 0,q 3 q 1,q 3 q 1,q 2 Move when see accepting of left (q 0 )Move when see accepting of right (q 2 ) Version 0 Version 1 c c c c b a b a

35 Version 0: to catch q 0 Version 1: to catch q 2 q 0,q 3 q 1,q 3 q1,q2q1,q2 q 0,q 3 q 1,q 3 q 1,q 2 Move when see accepting of left (q 0 )Move when see accepting of right (q 2 ) Version 0 Version 1 c c c c b a b a

36 Make an accepting state in one of the version according to a component accepting state q 0,q 3,0 q 1,q 3,0q 1,q 2,0 q 0,q 3,1q 1,q 3,1 q 1,q 2,1 Version 1 Version 0 c c c c b a b a

37 How to check for emptiness? s 0,t 0 s 0,t 1 s 1,t 1 b a c a c

38 Emptiness... Need to check if there exists an accepting run (passes through an accepting state infinitely often).

39 Strongly Connected Component (SCC) A set of states with a path between each pair of them. Can use Tarjan’s DFS algorithm for finding maximal SCC’s.

40 Finding accepting runs If there is an accepting run, then at least one accepting state repeats on it forever. Look at a suffix of this run where all the states appear infinitely often. These states form a strongly connected component on the automaton graph, including an accepting state. Find a component like that and form an accepting cycle including the accepting state.

41 Equivalently... A strongly connected component: a set of nodes where each node is reachable by a path from each other node. Find a reachable strongly connected component with an accepting node.

42 How to complement? Complementation is hard! Can ask for the negated property (the sequences that should never occur). Can translate from LTL formula  to automaton A, and complement A. But: can translate ¬  into an automaton directly!

43 Model Checking under Fairness Express the fairness as a property φ. To prove a property ψ under fairness, model check φ  ψ. Fair (φ) Bad (¬ψ)Program Counter example

44 Model Checking under Fairness Specialize model checking. For weak process fairness: search for a reachable strongly connected component, where for each process P either it contains on occurrence of a transition from P, or it contains a state where P is disabled.

45 Translating from logic to automata (Book: Chapter 6)

46 Why translating? Want to write the specification in some logic. Want model-checking tools to be able to check the specification automatically.

47 Generalized Büchi automata Acceptance condition F is a set F={f 1, f 2, …, f n } where each f i is a set of states. To accept, a run needs to pass infinitely often through a state from every set f i.

48 Translating into simple Büchi automaton q0q0 q2q2 q1q1 q0q0 q2q2 q1q1 Version 0 Version 1 c c c c b a b a

49 Translating into simple Büchi automaton q0q0 q2q2 q1q1 q0q0 q2q2 q1q1 Version 0 Version 1 c c c c b b a

50 Translating into simple Büchi automaton q0q0 q2q2 q1q1 q0q0 q2q2 q1q1 Version 0 Version 1 c c c c b a b a

51 Preprocessing Convert into normal form, where negation only applies to propositional variables. ¬[]  becomes <>¬ . ¬<>  becomes [] ¬ . What about ¬ (  U  )? Define operator R such that ¬ (  U  ) = (¬  ) R (¬  ), ¬ (  R  ) = (¬  ) U (¬  ).

52 Semantics of pR q p qqqqqqq q qq qqqq ¬p¬p ¬p¬p ¬p¬p ¬p¬p ¬p¬p ¬p¬p ¬p¬p ¬p¬p ¬p¬p ¬p¬p ¬p¬p ¬p¬p ¬p¬p

53 Replace ¬ true by false, and ¬ false by true. Replace ¬ (  \/  ) by ( ¬  ) /\ ( ¬  ) and ¬ (  /\  ) by ( ¬  ) \/ ( ¬  )

54 Eliminate implications, <>, [] Replace  ->  by ( ¬  ) \/ . Replace <>  by (true U  ). Replace []  by (false R  ).

55 Example Translate ( []<>P )  ( []<>Q ) Eliminate implication ¬( []<>P ) \/ ( []<>Q ) Eliminate [], <>: ¬( false R ( true U P ) ) \/ ( false R ( true U Q ) ) Push negation inwards: (true U (false R ¬ P ) ) \/ ( false R ( true U Q ) )

56 The data structure Incoming NewOld Next Name

57 The main idea  U  =  \/ (  /\ O (  U  ) )  R  =  /\ (  \/ O (  R  ) ) This separates the formulas to two parts: one holds in the current state, and the other in the next state.

58 How to translate? Take one formula from “New” and add it to “Old”. According to the formula, either Split the current node into two, or Evolve the node into a new version.

59 Splitting Incoming New Old Next Incoming New Old Next Incoming New Old Next Copy incoming edges, update other field.

60 Evolving Incoming New Old Next Incoming New Old Next Copy incoming edges, update other field.

61 Possible cases:  U , split: Add  to New, add  U  to Next. Add  to New. Because  U  =  \/ (  /\ O (  U  )).  R , split: Add  to New. Add  to New,  R  to Next. Because  R  =  /\ (  \/ O (  R  )).

62 More cases:  \/ , split: Add  to New. Add  to New.  /\ , evolve: Add  to New. O , evolve: Add  to Next.

63 How to start? Incoming NewOld Next init aU(bUc)

64 Incoming init aU(bUc) Incoming aU(bUc) bUcbUc a init

65 Incoming aU(bUc)bUcbUc init Incoming aU(bUc) c (bUc) b bUcbUcbUcbUc

66 When to stop splitting? When “New” is empty. Then compare against a list of existing nodes “Nodes”: If such a with same “Old”, “Next” exists, just add the incoming edges of the new version to the old one. Otherwise, add the node to “Nodes”. Generate a successor with “New” set to “Next” of father.

67 Incoming a,aU(bUc) aU(bUc) init Incoming aU(bUc) Creating a successor node. When we enter to Nodes a new node (with different Old or Next than any other node), we start a new node by copying Next to New, and making an edge to the new successor.

68 How to obtain the automaton? There is an edge from node X to Y labeled with propositions P (negated or non negated), if X is in the incoming list of Y, and Y has propositions P in field “Old”. Initial node is init. Incoming NewOld Next X Node Y a, b, ¬c

69 The resulted nodes. a, aU(bUc) b, bUc, aU(bUc)c, bUc, aU(bUc) b, bUcc, bUc

70 a, aU(bUc) b, bUc, aU(bUc)c, bUc, aU(bUc) b, bUcc, bUc All nodes with incoming edge from “init”. Initial nodes

71 Include only atomic propositions Init a b c cb

72 Acceptance conditions Use “generalized Buchi automata”, where there are several acceptance sets f 1, f 2, …, f n, and each accepted infinite sequence must include at least one state from each set infinitely often. Each set corresponds to a subformula of form  U . Guarantees that it is never the case that  U  holds forever, without .

73 Accepting w.r.t. bU c a, aU(bUc) b, bUc, aU(bUc)c, bUc, aU(bUc) b, bUcc, bUc All nodes with c, or without bUc.

74 Acceptance w.r.t. aU (bU c) a, aU(bUc) b, bUc, aU(bUc)c, bUc, aU(bUc) b, bUcc, bUc All nodes with bUc or without aU(bUc).