1 / 107

Verification by Model Checking

Verification by Model Checking. Formal Methods Laboratory University of Tehran. Based on the chapter 3 of “Logic in Computer Science”, Huth & Ryan. Part 1 : Motivation. Introduction. Verification: verifying the correctness of computer systems hardware, software or combination

ilithya
Download Presentation

Verification by Model Checking

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Verification by Model Checking Formal Methods Laboratory University of Tehran Based on the chapter 3 of “Logic in Computer Science”, Huth & Ryan Verification by Model Checking

  2. Part 1 : Motivation Verification by Model Checking

  3. Introduction • Verification: verifying the correctness of computer systems • hardware, software or combination • It is most obvious in • safety-critical systems • commercially critical • mission critical Verification by Model Checking

  4. Verification parts • Formal Verification techniques consist of three parts: • A framework for modeling systems • some kind of specification language • A specification language • for describing the properties to be verified • A verification method • for establishing if the description of the system satisfies the specification Verification by Model Checking

  5. Classification • Approaches to verification can be classified in several ways: • Proof-based vs. model-based • Degree of automation • Full- vs. property- verification • Intended domain of application • hardware-software, sequential-concurrent, reactive-terminating, … • Pre- vs. post- development Verification by Model Checking

  6. Proof-based verification • The system description is a set of formula Γ in a suitable logic • The specification is another formula  • The verification method is finding a proof that Γ├ • ├ means deduction • It typically needs the user guidance and expertise Verification by Model Checking

  7. Model-based verification • The system is represented by a model M for an appropriate logic • The specification is again represented by a formula  • The verification method consist of computing whether a model M satisfies  • M satisfies  : M╞  • The computation is usually automatic for finite models Verification by Model Checking

  8. Degree of automation • From fully automated to fully manual Verification by Model Checking

  9. Full- vs. property-verification • The specification may describe a single property of the system, or it may describe its full behavior (expensive). Verification by Model Checking

  10. Intended domain of application • Hardware, software • Sequential, concurrent • Reactive , terminating • Reactive: reacts to its environment, and is not meant to terminate (e.g. operating systems, embedded systems, computer hardware) Verification by Model Checking

  11. Pre- vs. post-development • Verification is of greater advantage if introduced early in system development Verification by Model Checking

  12. Model checking • Model checking is an automatic, model-based, property-verification approach • It is intended to be used for concurrent and reactive systems • The purpose of a reactive system is not necessarily to obtain a final result, but to maintain some interaction with its environment • Concurrency bugs • non reproducible • not covered by test cases Verification by Model Checking

  13. Temporal Logic • The idea is that a formula is not statically true or false in a model • The models of temporal logic contain several states • a formula can be true in some and false in the others • The static notion of truth is replaced by a dynamic one • the formulas may change their truth values as the system evolves from state to state Verification by Model Checking

  14. Temporal Logic (cont.) • In model checking: • The models M are transition systems • The properties φ are formulas in temporal logic • Model checking steps: 1. Model the system using the description language of a model checker : M 2. Code the property using the specification language of the model checker : φ 3. Run the model checker with the inputs M and φ Verification by Model Checking

  15. p →F q yes φ Model Checker no Error Trace M Model checker Verification by Model Checking

  16. Linear vs. Branching • Linear-time logics think of time as a set of paths • path is a sequence of time instances • Branching time logics represent time as a tree • it is rooted at the present moment and branches out into the future • Many logics were suggested during last years that fit into one of above categories • We study LTL in linear time logics and CTL in branching time logics Verification by Model Checking

  17. Linear Time Every moment has a unique successor Infinite sequences (words) Linear Time Temporal Logic (LTL) Linear vs. Branching (cont.) • Branching Time • Every moment has several successors • Infinite tree • Computation Tree Logic (CTL) Verification by Model Checking

  18. CTL • Branching time Verification by Model Checking

  19. Computational tree logic • Syntax: ::= F | T | p | (~) | ( /\ ) | (\/) | ( -> ) | AX | EX | A[U] | E[U] | AG | EG | AF | EF Where p ranges over atomic formulas/descriptions. Verification by Model Checking

  20. AX, EX, AG, EG, AU, AF, EF : temporal connectives • The first of the pair • A means “ along All paths” • E means “ along at least (there Exist) one path” • The second one of the pair • X means “ neXt state” • F means “some Future state” • G means “ all future states (Globally)” • U means “ Until” Verification by Model Checking

  21. Convention • Binding priorities • Unary connectives: ~, AG, EG, AF, EF,AX, EX • /\ , \/ • -> , AU, EU Verification by Model Checking

  22. Well-formed CTL formulas: • EGr • AG(q -> EGr) different from AGq -> EGr , which is (AGq) -> (EGr) • A[p U EFr] • EF EG p -> AFr • Page 153: some well-formed and some not well-formed Verification by Model Checking

  23. EF(rUq) ?? • U can only be paired with an A or an E • EF E[rUq] or EF A[rUq] • AF[(rUq) /\ (pUr)] ?? • Boolean connective (/\) cannot be directly inside A[] or E[] Verification by Model Checking

  24. Example • The parse tree of A[AX ~p U E[EX(p/\q)U ~p]] according to precedence rules • Fig. 3.1, page 155 Verification by Model Checking

  25. Transition System • A model M = (S, →, L) for CTL is • S: a finite set of states • → : a binary relation on S, such that every s  S has some s ' S with s → s ' • L : a labeling function L: S → P( Atoms) • P( Atoms) means the power set of Atoms • The interpretation of the labeling function is that each state s has a set of atomic propositions L(s) which are true at that particular state Verification by Model Checking

  26. s0 p,q q q,r s2 s1 Example S = {s0, s1, s2} transitions = s0→ s1, s1→ s1 , s2→ s1 , s2→ s0 , s0 → s2 L(s0) = {p,q} L(s1) = {q} L(s2) = {q,r} Verification by Model Checking

  27. Deadlock • We will call the transition systems simply models in our discussions • According to the definition of a model, for each sS there is at least one s'  S • No state of a system may be deadlocked • If a system has a deadlock, we always add an extra state sd representing the deadlock Verification by Model Checking

  28. s0 s1 s0 s1 s2 s2 s3 s3 sd Deadlock state s3 doesn’t have any further transitions adding a deadlock state sd Verification by Model Checking

  29. Unwinding • We can unwind the transition system to obtain an infinite computation tree • The execution paths of a model M are explicitly represented in the tree obtained by unwinding the tree Verification by Model Checking

  30. an arbitrary path s0 p,q s0 s1 s1 s1 s1 s2 s2 s2 p,q q,r q,r q,r q q q q s0 p,q q q,r s2 s1 s0 s2 p,q q,r Unwinding: example Verification by Model Checking

  31. Formal Semantics • Let M = (S, →, L) be a model and п = s1→… be a path in M • Whether п satisfies an CTL formula is defined by the satisfaction relation ╞ as follows: 1 2 3 4 Verification by Model Checking

  32. M,s|= T and M,s|≠F for all s ∈S • M,s |= p iff p ∈L(s) • M,s |= ~ iff M,s |≠ • M,s |= 1 /\ 2 iff M,s |= 1 and M,s |= 2 • M,s |= 1 \/ 2 iff M,s |= 1 or M,s |= 2 • M,s |= 1 -> 2 iff M,s |≠1 or M,s |= 2 Verification by Model Checking

  33. Next • 7. M,s |= AX iff for all s1 such that s->s1 we have M,s|= . Thus, AX says “in every next state” • 8. M,s |= EX iff for some s1 such that s->s1 we have M,s|= . Thus, EX says “in some next state” Verification by Model Checking

  34. Globally • 9. M,s |= AG holds iff for all paths s1->s2->s3-> … where s1 equals s, and for all si along the path, we have M,si |= . For all computation paths beginning in s the property  holds Globally (including the initial state). Verification by Model Checking

  35. 10. M,s |= EG holds iff there is a path s1->s2->s3-> … where s1 equals s, and for all si along the path, we have M,si |= . There exist a path beginning in s such that the property  holds Globally (including the initial state). Verification by Model Checking

  36. Finally • 11. M,s |= AF holds iff for all paths s1->s2->s3-> … where s1 equals s, there is some si along the path, such that we have M,si |= . For all computation paths beginning in s there will be some Future state where  holds. Verification by Model Checking

  37. 12. M,s |= EF holds iff there is a path s1->s2->s3-> … where s1 equals s, and for some si along the path, we have M,si |= . There exist a path beginning in s such that the property  holds insome Future state. Verification by Model Checking

  38. Until • 13. M,s |= A[1 U 2] holds iff for all paths s1 -> s2 -> s3 -> … where s1 equals s, that path satisfies 1 U 2 , i.e. there is some si along the path, such that we have M,si |= 2, and, for each j<i, we have M,sj |= 1. • 14. M,s |= E[1 U 2] … Verification by Model Checking

  39. A note for Until • Until says nothing about what happens after the Until has been realized • This can be different from natural English speaking • For example: • “She continued working until she married” • We may interpret the sentence as she discontinued working after marriage • The above understanding is related to this formula • working U ( marriage G ⌐working) Verification by Model Checking

  40. P.160: EF, EG • P.161: AF, AG • P.162: Until Verification by Model Checking

  41. Some practical patterns • It is possible to get to a state where started holds, but ready does not hold • EF (started ⌐ready) • For any state, if a request occurs, then it will eventually be acknowledged • AG (requested → AF acknowledged) • Whatever happens, a certain process will eventually be permanently deadlocked • AF (AG deadlock) Verification by Model Checking

  42. Some practical patterns (cont.) • A certain process is enabledinfinitely often on every computation path • AG (AF enabled) • In other words, in a path of the system there must never be a point at which the condition enabled becomes false and stays false forever Verification by Model Checking

  43. Part 2 : LTL Amir Pnueli The Weizmann Institute of Science Verification by Model Checking

  44. LTL • LTL : Linear-time Temporal Logic • It has some connectives for referring to the future • It models time as a sequence of states, extending infinitely to future • computation path • The future is not determined, we should consider several paths for different futures • Any one of the paths can be the actual path that is realized Verification by Model Checking

  45. Atoms • We work with a fixed set of atomic formulas (like p, q, r,…) • They stands for atomic facts which hold for a system • Process 897 is blocked • The variable x2 is zero • The content of register R1 is 01010 Verification by Model Checking

  46. Syntax of LTL • The syntax of LTL in BNF is: • where p is any propositional atom from some set Atoms • X, F, G, U, R, W : temporal connectives Verification by Model Checking

  47. Temporal Connectives • X : neXt state • F : some Future state ( eventually) • G : all future states (Globally) • U : Until • R : Release • W : Weak-until Verification by Model Checking

  48. Operator precedence • Unary operators including negation have strongest precedence • ¬p U q is parsed as (¬p) U q rather than ¬(p U q) • Temporal binary operators have stronger precedence than non-temporal binary operators • p  q U r is parsed as: p  (q U r) • The precedence over propositional logic is as usual • First do the AND • then the ORs and XORs • finally the IMPLIES and EQUIVALENCEs. Verification by Model Checking

  49.  W G F p r q p Example • The parse tree of Fp  Gq →p W r according to precedence rules Verification by Model Checking

  50. Transition System • A transition system is a structure M = (S, →, L) where • S: a finite set of states • → : a binary relation on S, such that every s  S has some s ' S with s → s ' • L : a labeling function L: S → P( Atoms) • P( Atoms) means the power set of Atoms • The interpretation of the labeling function is that each state s has a set of atomic propositions L(s) which are true at that particular state Verification by Model Checking

More Related