DOCSLIB.ORG

Introduction to Model-Checking Theory and Practice

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Introduction to Model-Checking Theory and Practice Introduction to Model-Checking Theory and Practice Beihang International Summer School 2018 Model Checking Linear Temporal Properties Model Checking “Model checking is the method by which a desired behavioral property of a reactive system is verified over a given system (the model) through exhaustive enumeration (explicit or implicit ) of all the states reachable by the system and the behaviors that traverse through them” Amir Pnueli (2000) Basic Properties • reachability (something is possible) • invariant (something is always true) the gate is closed when the train cross the road • safety (something bad never happen: ≡ ¬ 푅푒푎푐ℎ) • liveness (something good may eventually happen) every process will (eventually) gain access to the printer • Fairness (if it may happen ∞ often then it will happen) if messages cannot be lost ∞ often then I will received an ack Model-Checking • We have seen how to use a formal specification language to model the system (⇒ as a graph, but also as a language ℒ) • We have seen how to check basic properties on the reachability graph (and that SCC can be useful) • What if we want to check more general properties? User-Defined Properties • present before (we should see an 푎 before the first 푏) the latch must be locked before take-off • infinitely often (something will always happen, ≠ 퐴푙푤푎푦푠) the timer should always be triggered • leadsto (after every occurrence of 푎 there should be a 푏) there is an audible signal after the alarm is activated • … see example of specification patterns here [Dwyer] Model-Checking System + Requirements informal Description Description M of the of the 휙 behavior property operational denotational formalization verification Does 푀 ⊨ 휙 Does 푀 ≡ 퐺휙 yes / no / c. ex. present 푎 before 푏 • In every execution, action 푎 should occur before 푏 or there should be no 푏 푝1, 푝2, 푝6 푝0, 푝2 푝1, 푝2, 푝4 푝1, 푝5, 푝2 푝1, 푝3 present 푟푐푣 before 푎푐푘 Infinitely often 푎 • every “maximal execution” should have an unbounded number of 푎 equivalently: from every state, it is unavoidable to do an 푎 푝1, 푝2, 푝6 푝0, 푝2 푝1, 푝2, 푝4 푝1, 푝5, 푝2 푝1, 푝3 infinitely 푟푐푣 infinitely 푠푒푛푑 Infinitely often 푎 • every “maximal execution” should have an unbounded number of 푎 equivalently: from every state, it is unavoidable to do an 푎 푝1, 푝2, 푝6 Infinitely 푟푐푣 푝0, 푝2 푝1, 푝2, 푝4 푝1, 푝5, 푝2 푝1, 푝3 Infinitely often 푎 • every “maximal execution” should have an unbounded number of 푎 equivalently: from every state, it is unavoidable to do an 푎 푝1, 푝2, 푝6 Infinitely 푠푒푛푑 푝0, 푝2 푝1, 푝2, 푝4 푝1, 푝5, 푝2 푝1, 푝3 푎 leadsto 푏 • after every occurrence of action 푎 we should eventually find an occurrence of action 푏 or there is no 푎 푝1, 푝2, 푝6 푝0, 푝2 푝1, 푝2, 푝4 푝1, 푝5, 푝2 푝1, 푝3 푠푛푑 leadsto 푟푐푣 Model Checking Linear Temporal Properties using Language Inclusion Model-Checking System + Requirements informal Description Description M of the of the 휙 behavior property operational denotational formalization verification Does 푀 ⊨ 휙 Does 푀 ≡ 퐺휙 yes / no / c. ex. Model-Checking correct behavior 퐿(푀) 퐿 푀 ∩ 퐿 휙 counter-example 퐿 휙 Description Description M of the Does 퐿 푀 ⊆ 퐿(휙) ? of the 휙 behavior property present 푎 before 푏 • In every execution, action 푎 should occur before 푏 or there should be no 푏present 푎 before 푏 a = {a} 1 = {a, b, c, …} !a = {b, c, …} • idea: use set of words (language) of infinite length that go through a “red state” infinitely often present 푎 before 푏 • In every execution, action 푎 should occur before 푏 or there should be no 푏present 푎 before 푏 a = {a} 1 = {a, b, c, …} !a = {b, c, …} • Equivalently: find traces where “red places” are infinitely marked. present 푎 before 푏 푝1, 푝2, 푝6 푝0, 푝2 푝1, 푝2, 푝4 푝1, 푝5, 푝2 푝1, 푝3 02 00 01 present 푟푐푣 before 푎푐푘 12 10 13 14 11 Büchi Automata Büchi automata • In here we consider automata with a set of final, or accepting states 퐹 ⊆ 푄 • we use “red states” to mean accepting • It is a finite state automata with a different acceptance condition. An (infinite) word is accepted if it corresponds to an infinite run that contains infinitely many accepting states a = {a} 1 = {a, b, c, …} !a = {b, c, …} Example 푎. 푎. 푎. … 푎휔 is accepted 푎. 푎. 푏. 푎. 푏. 푎. … 푏. 푎 휔 is accepted 푎. 푎. 푏. 푏. 푏. … 푏 휔 is rejected 푎. 푏. 푎. 푏2. 푎. 푏3. … 푏푛. 푎 휔 is accepted Büchi automata • To find if there exist a word that is not accepted by a Büchi automata, it is enough to find a cycle without accepting state we know how to do it (remember Tarjan’s algorithm) • Same thing if we want to test if ℒ = ∅ Model Checking Linear Temporal Properties using Language Inclusion a better idea Model-Checking 퐿(푀) 퐿 푀 ∩ 퐿 휙 퐿 ∖ 퐿 휙 퐿 휙 Description Description M of the Does 퐿 푀 ∖ 퐿 휙 = ∅ ? of the 휙 behavior property present 푎 before 푏 • We disprove the property if we find a trace where 푏 can be reached without firing action 푎 a = {a} 퐿 ¬ 휙 ≡ 1 = {a, b, c, …} !a = {b, c, …} present 푎 before 푏 푝1, 푝2, 푝6 푝0, 푝2 푝1, 푝2, 푝4 푝1, 푝5, 푝2 푝1, 푝3 present 푟푐푣 before 푎푐푘 Infinitely often 푎 • From every state, it is unavoidable to do an 푎 ≡ 퐿 휙 Infinitely often 푎 • We disprove the property if we find a trace without a single 푎 (maybe after some other transitions fire) ≡ 퐿 ¬ 휙 Infinitely often 푎 10 12 infinitely 푟푐푣 11 10 Infinitely often 푎 100 010 001 001 100 010 100 푎 leadsto 푏 • after every 푎 we eventually find a 푏 We disprove the property if we find an 푎 followed by an infinite sequence (a SCC) without 푏 푠푛푑 leadsto 푟푐푣 What you need to remember • We can check more complex properties using an automata-theoretic approach • It is often easier to try to disprove the property 퐴 푆푦푠 ⊗ 퐴 ¬휙 = ∅ • We need automata that accept infinite words → different acceptance criterion (Büchi-automaton) • There is a link with SCC (infinitely often ≈ cycle) Model Checking LTL, a Principled Approach Model-Checking • We have seen how to use “language inclusion” (product of automata and search for an infinite path) to express temporal properties on a system • What if we want to check more general properties? Is there a more friendly way to define temporal properties ? • How can we derive an automaton from it Classical logic • logic is the systematic study of the form of valid inference • Aristotle (322 BC) • Clarence Lewis (∼1910) for its actual form • A formula is valid iff it is true under every interpretation. • An argument form (or schema) is valid iff every argument is valid wikipedia Non-classical logics • Example of valid argument form (or schema) (퐴 ⇒ 퐵 ∧ 퐴) ⇒ 퐵 • Predicate logic has propositional variables (퐴, 퐵, …) and connectives (∧, ¬, ⇒, …) • There are also non-classical logics, such as modal logics, that extend logic with operators (modalities) expressing the fact that the truth may depends on the context examples are beliefs: I am certain vs it is possible; permissions (deontic logic): it is permissible vs it is obligatory; and time: always vs eventually Temporal logic Amir Pnueli (1941—2009) “In mathematics, logic is static. It deals with connections among entities that exist in the same time frame. When one designs a dynamic computer system that has to react to ever changing conditions, … one cannot design the system based on a static view. It is necessary to characterize and describe dynamic behaviors that connect entities, events, and reactions at different time points. Temporal Logic deals therefore with a dynamic view of the world that evolves over time." Atomic proposition • We start by defining atomic propositions statements about the here and now ! • We assume a set of propositional variables {푝1, 푝2, … , 푝푛} • We will use the language of logic. Atomic Formulas are built from P. V. and from connectives 푎, 푏, … ∷= 푝 ¬푎 푎 ∧ 푏 | … • e.g.: 푝1 ∧ (푝2 ∨ ¬푝3) 푝1 ⇒ 푝2 ≡ ¬푝1 ∨ 푝2 Atomic Prop.: event/state-based • If we want to deal with events (transitions), we can choose atomic propositions 푎, 푏, … that corresponds to event names: • 푡1 • 푑푒푎푑 • We can also choose to deal with states (markings) • 푝1 + 2. 푝3 ≤ 4 푝1 ≡ (푝1 ≥ 1) • 퐹푖푟푎푏푙푒(푡) • 푑푒푎푑 • 푖푛푖푡푖푎푙 (`0) (from now on we consider only “state-based” formulas) Linear Temporal Logic • The logic has two main connectives 퐹 휙: reads “finally” (eventually) 휙 is true 퐺 휙: reads “globally” (always) 휙 is true 휙, 휓, … ∷= 푎 ¬휙 휙1 ∧ 휙2 퐹 휙 퐺 휙 • So you can write formulas such as: 퐺 (푝1 ⇒ 퐹 푝2 + 푝3 ≤ 푝4 ) ¬ 퐹 푑푒푎푑 ∨ 퐺 (¬푝2) 퐹 퐺 푝1 ∧ 퐺 퐹 푝2 퐺 ( 퐺 푡1 ∨ (퐺 푡2)) Linear Temporal Logic • The logic has two main connectives 퐹 휙: reads “finally” (eventually) 휙 is true, also []휙 퐺 휙: reads “globally” (always) 휙 is true, also 〈〉휙 • There is another possible presentation based on two additional connectives 휙 푈 휓: reads “휙 holds until 휓” 푋휙 : reads “next” 휙 holds, also written ()휙 LTL—syntax equivalence 퐹 휙 〈 〉휙 finally 퐺 휙 휙 globally 푋 휙 휙 next 휙 푈 휓 휙 푈 휓 until ! 휙 ¬휙 negation SPIN syntax selt syntax Pinyin name LTL—semantics • LTL formulas are interpreted on (maximal) traces, 푤 = 푤0. 푤1. … . 푤푖. … for “state-based” properties, 푤푖 is a state ≡ the set of atomic propositions true in 푤푖 • We call 푤(푖) the 푖th element in 푤 • We use the notation 푤, 푖 ⊨ 휙 to say that 휙 holds for 푤 from position 푖 푤 ⊨ 휙 ⇔ 푤, 0 ⊨ 휙 satisfaction relation ⊨ LTL—semantics 푤 ⊨ 휙 ? 푤, 2 ⊨ ϕ … 푤, 푖 ⊨ ϕ … 푤, 푘 ⊨ ϕ 푤0 푤1 푤2 … 푤푖 … 푤푘 LTL—atomic propositions • For atomic propositions, 푎, we can say whether it holds for 푤푖 or not (we write 푤푖 ⊨ 푎 if it holds).
Load more

Recommended publications
  • Model Checking
    Lecture 1: Model Checking Edmund Clarke School of Computer Science Carnegie Mellon University 1 Cost of Software Errors June 2002 “Software bugs, or errors, are so prevalent and so detrimental that they cost the U.S. economy an estimated $59.5 billion annually, or about 0.6 percent of the gross domestic product … At the national level, over half of the costs are borne by software users and the remainder by software developers/vendors.” NIST Planning Report 02-3 The Economic Impacts of Inadequate Infrastructure for Software Testing 2 Cost of Software Errors “The study also found that, although all errors cannot be removed, more than a third of these costs, or an estimated $22.2 billion, could be eliminated by an improved testing infrastructure that enables earlier and more effective identification and removal of software defects.” 3 Model Checking • Developed independently by Clarke and Emerson and by Queille and Sifakis in early 1980’s. • Properties are written in propositional temporal logic. • Systems are modeled by finite state machines. • Verification procedure is an exhaustive search of the state space of the design. • Model checking complements testing/simulation. 4 Advantages of Model Checking • No proofs!!! • Fast (compared to other rigorous methods) • Diagnostic counterexamples • No problem with partial specifications / properties • Logics can easily express many concurrency properties 5 Model of computation Microwave Oven Example State-transition graph describes system evolving ~ Start ~ Close over time. ~ Heat st ~ Error Start ~ Start ~ Start ~ Close Close Close ~ Heat Heat ~ Heat Error ~ Error ~ Error Start Start Start Close Close Close ~ Heat ~ Heat Heat Error ~ Error ~ Error 6 Temporal Logic l The oven doesn’t heat up until the door is closed.
    [Show full text]
  • Model Checking TLA Specifications
    Model Checking TLA+ Specifications Yuan Yu1, Panagiotis Manolios2, and Leslie Lamport1 1 Compaq Systems Research Center {yuanyu,lamport}@pa.dec.com 2 Department of Computer Sciences, University of Texas at Austin [email protected] Abstract. TLA+ is a specification language for concurrent and reac- tive systems that combines the temporal logic TLA with full first-order logic and ZF set theory. TLC is a new model checker for debugging a TLA+ specification by checking invariance properties of a finite-state model of the specification. It accepts a subclass of TLA+ specifications that should include most descriptions of real system designs. It has been used by engineers to find errors in the cache coherence protocol for a new Compaq multiprocessor. We describe TLA+ specifications and their TLC models, how TLC works, and our experience using it. 1 Introduction Model checkers are usually judged by the size of system they can handle and the class of properties they can check [3,16,4]. The system is generally described in either a hardware-description language or a language tailored to the needs of the model checker. The criteria that inspired the model checker TLC are completely different. TLC checks specifications written in TLA+, a rich language with a well-defined semantics that was designed for expressiveness and ease of formal reasoning, not model checking. Two main goals led us to this approach: – The systems that interest us are too large and complicated to be completely verified by model checking; they may contain errors that can be found only by formal reasoning. We want to apply a model checker to finite-state models of the high-level design, both to catch simple design errors and to help us write a proof.
    [Show full text]
  • Introduction to Model Checking and Temporal Logic¹
    Formal Verification Lecture 1: Introduction to Model Checking and Temporal Logic¹ Jacques Fleuriot [email protected] ¹Acknowledgement: Adapted from original material by Paul Jackson, including some additions by Bob Atkey. I Describe formally a specification that we desire the model to satisfy I Check the model satisfies the specification I theorem proving (usually interactive but not necessarily) I Model checking Formal Verification (in a nutshell) I Create a formal model of some system of interest I Hardware I Communication protocol I Software, esp. concurrent software I Check the model satisfies the specification I theorem proving (usually interactive but not necessarily) I Model checking Formal Verification (in a nutshell) I Create a formal model of some system of interest I Hardware I Communication protocol I Software, esp. concurrent software I Describe formally a specification that we desire the model to satisfy Formal Verification (in a nutshell) I Create a formal model of some system of interest I Hardware I Communication protocol I Software, esp. concurrent software I Describe formally a specification that we desire the model to satisfy I Check the model satisfies the specification I theorem proving (usually interactive but not necessarily) I Model checking Introduction to Model Checking I Specifications as Formulas, Programs as Models I Programs are abstracted as Finite State Machines I Formulas are in Temporal Logic 1. For a fixed ϕ, is M j= ϕ true for all M? I Validity of ϕ I This can be done via proof in a theorem prover e.g. Isabelle. 2. For a fixed ϕ, is M j= ϕ true for some M? I Satisfiability 3.
    [Show full text]
  • Model Checking and the Curse of Dimensionality
    Model Checking and the Curse of Dimensionality Edmund M. Clarke School of Computer Science Carnegie Mellon University Turing's Quote on Program Verification . “How can one check a routine in the sense of making sure that it is right?” . “The programmer should make a number of definite assertions which can be checked individually, and from which the correctness of the whole program easily follows.” Quote by A. M. Turing on 24 June 1949 at the inaugural conference of the EDSAC computer at the Mathematical Laboratory, Cambridge. 3 Temporal Logic Model Checking . Model checking is an automatic verification technique for finite state concurrent systems. Developed independently by Clarke and Emerson and by Queille and Sifakis in early 1980’s. The assertions written as formulas in propositional temporal logic. (Pnueli 77) . Verification procedure is algorithmic rather than deductive in nature. 4 Main Disadvantage Curse of Dimensionality: “In view of all that we have said in the foregoing sections, the many obstacles we appear to have surmounted, what casts the pall over our victory celebration? It is the curse of dimensionality, a malediction that has plagued the scientist from the earliest days.” Richard E. Bellman. Adaptive Control Processes: A Guided Tour. Princeton University Press, 1961. Image courtesy Time Inc. 6 Photographer Alfred Eisenstaedt. Main Disadvantage (Cont.) Curse of Dimensionality: 0,0 0,1 1,0 1,1 2-bit counter n-bit counter has 2n states 7 Main Disadvantage (Cont.) 1 a 2 | b n states, m processes | 3 c 1,a nm states 2,a 1,b 3,a 2,b 1,c 3,b 2,c 3,c 8 Main Disadvantage (Cont.) Curse of Dimensionality: The number of states in a system grows exponentially with its dimensionality (i.e.
    [Show full text]
  • Formal Verification, Model Checking
    Introduction Modeling Specification Algorithms Conclusions Formal Verification, Model Checking Radek Pel´anek Introduction Modeling Specification Algorithms Conclusions Motivation Formal Methods: Motivation examples of what can go wrong { first lecture non-intuitiveness of concurrency (particularly with shared resources) mutual exclusion adding puzzle Introduction Modeling Specification Algorithms Conclusions Motivation Formal Methods Formal Methods `Formal Methods' refers to mathematically rigorous techniques and tools for specification design verification of software and hardware systems. Introduction Modeling Specification Algorithms Conclusions Motivation Formal Verification Formal Verification Formal verification is the act of proving or disproving the correctness of a system with respect to a certain formal specification or property. Introduction Modeling Specification Algorithms Conclusions Motivation Formal Verification vs Testing formal verification testing finding bugs medium good proving correctness good - cost high small Introduction Modeling Specification Algorithms Conclusions Motivation Types of Bugs likely rare harmless testing not important catastrophic testing, FVFV Introduction Modeling Specification Algorithms Conclusions Motivation Formal Verification Techniques manual human tries to produce a proof of correctness semi-automatic theorem proving automatic algorithm takes a model (program) and a property; decides whether the model satisfies the property We focus on automatic techniques. Introduction Modeling Specification Algorithms Conclusions
    [Show full text]
  • Formal Verification of Diagnosability Via Symbolic Model Checking
    Formal Verification of Diagnosability via Symbolic Model Checking Alessandro Cimatti Charles Pecheur Roberto Cavada ITC-irst RIACS/NASA Ames Research Center ITC-irst Povo, Trento, Italy Moffett Field, CA, U.S.A. Povo, Trento, Italy mailto:[email protected] [email protected] [email protected] Abstract observed system. We propose a new, practical approach to the verification of diagnosability, making the following contribu• This paper addresses the formal verification of di• tions. First, we provide a formal characterization of diagnos• agnosis systems. We tackle the problem of diagnos• ability problem, using the idea of context, that explicitly takes ability: given a partially observable dynamic sys• into account the run-time conditions under which it should be tem, and a diagnosis system observing its evolution possible to acquire certain information. over time, we discuss how to verify (at design time) Second, we show that a diagnosability condition for a given if the diagnosis system will be able to infer (at run• plant is violated if and only if a critical pair can be found. A time) the required information on the hidden part of critical pair is a pair of executions that are indistinguishable the dynamic state. We tackle the problem by look• (i.e. share the same inputs and outputs), but hide conditions ing for pairs of scenarios that are observationally that should be distinguished (for instance, to prevent simple indistinguishable, but lead to situations that are re• failures to stay undetected and degenerate into catastrophic quired to be distinguished. We reduce the problem events). We define the coupled twin model of the plant, and to a model checking problem.
    [Show full text]
  • ACM 2007 Turing Award Edmund Clarke, Allen Emerson, and Joseph Sifakis Model Checking: Algorithmic Verification and Debugging
    ACM 2007 Turing Award Edmund Clarke, Allen Emerson, and Joseph Sifakis Model Checking: Algorithmic Verification and Debugging ACM Turing Award Citation precisely describe what constitutes correct behavior. This In 1981, Edmund M. Clarke and E. Allen Emerson, work- makes it possible to contemplate mathematically establish- ing in the USA, and Joseph Sifakis working independently ing that the program behavior conforms to the correctness in France, authored seminal papers that founded what has specification. In most early work, this entailed constructing become the highly successful field of Model Checking. This a formal proof of correctness. In contradistinction, Model verification technology provides an algorithmic means of de- Checking avoids proofs. termining whether an abstract model|representing, for ex- ample, a hardware or software design|satisfies a formal Hoare-style verification was the prevailing mode of formal specification expressed as a temporal logic formula. More- verification going back from the late-1960s until the 1980s. over, if the property does not hold, the method identifies This classic and elegant approach entailed manual proof con- a counterexample execution that shows the source of the struction, using axioms and inference rules in a formal de- problem. ductive system, oriented toward sequential programs. Such proof construction was tedious, difficult, and required hu- The progression of Model Checking to the point where it man ingenuity. This field was a great academic success, can be successfully used for complex systems has required spawning work on compositional or modular proof systems, the development of sophisticated means of coping with what soundness of program proof systems, and their completeness; is known as the state explosion problem.
    [Show full text]
  • Model Checking Software in Cyberphysical Systems
    Model Checking Software in Cyberphysical Systems Marjan Sirjani Ehsan Khamespanah Edward A. Lee School of IDT ECE Department Department of EECS Mälardalen University University of Tehran UC Berkeley Västerås, Sweden Tehran, Iran Berkeley, USA [email protected] [email protected] [email protected] Abstract—Model checking a software system is about verifying where software reads sensor data and issues commands to that the state trajectory of every execution of the software satisfies physical actuators, ignoring this relationship is more dangerous. formally specified properties. The set of possible executions is For CPS, verification is ultimately about assuring properties modeled as a transition system. Each “state” in the transition system represents an assignment of values to variables, and a state of the physical world not the software abstraction. This means trajectory (a path through the transition system) is a sequence that it is not sufficient to study the software alone. We need of such assignments. For cyberphysical systems (CPSs), however, to also study its interactions with its environment. we are more interested in the state of the physical system than Of course, there is nothing new about formally studying the values of the software variables. The value of model checking the interactions of software with its environment. In 1977, for the software therefore depends on the relationship between the state of the software and the state of the physical system. This example, Pnueli was developing temporal logics for reactive relationship can be complex because of the real-time nature of systems [1]. In 1985, Harel and Pnueli singled out reactive the physical plant, the sensors and actuators, and the software systems as being “particularly problematic when it comes to that is almost always concurrent and distributed.
    [Show full text]
  • Model Checking TLA+ Specifications
    Model Checking TLA+ Specifications Yuan Yu, Panagiotis Manolios, and Leslie Lamport 25 June 1999 Appeared in Correct Hardware Design and Verifica- tion Methods (CHARME ’99), Laurence Pierre and Thomas Kropf editors. Lecture Notes in Computer Sci- ence, number 1703, Springer-Verlag, (September 1999) 54–66. Table of Contents 1 Introduction 54 2TLA+ 57 3CheckingModelsofaTLA+ Specification 58 4 How TLC Works 60 5 Representing States 62 6 Using Disk 63 7 Experimental Results 64 8 Status and Future Work 64 Model Checking TLA+ Specifications Yuan Yu1, Panagiotis Manolios2, and Leslie Lamport1 1 Compaq Systems Research Center [email protected], [email protected] 2 Department of Computer Sciences, University of Texas at Austin [email protected] Abstract. TLA+ is a specification language for concurrent and reactive systems that combines the temporal logic TLA with full first-order logic and ZF set theory. TLC is a new model checker for debugging a TLA+ specification by checking invariance properties of a finite-state model of the specification. It accepts a subclass of TLA+ specifications that should include most descriptions of real system designs. It has been used by engineers to find errors in the cache coherence protocol for a new Compaq multiprocessor. We describe TLA+ specifications and their TLC models, how TLC works, and our experience using it. 1 Introduction Model checkers are usually judged by the size of system they can handle and the class of properties they can check [3, 16, 4]. The system is generally described in either a hardware-description language or a language tailored to the needs of the model checker.
    [Show full text]
  • Model Checking with Mbeddr
    Model Checking for State Machines with mbeddr and NuSMV 1 Abstract State machines are a powerful tool for modelling software. Particularly in the field of embedded software development where parts of a system can be abstracted as state machine. Temporal logic languages can be used to formulate desired behaviour of a state machine. NuSMV allows to automatically proof whether a state machine complies with properties given as temporal logic formulas. mbedder is an integrated development environment for the C programming language. It enhances C with a special syntax for state machines. Furthermore, it can automatically translate the code into the input language for NuSMV. Thus, it is possible to make use of state-of-the-art mathematical proofing technologies without the need of error prone and time consuming manual translation. This paper gives an introduction to the subject of model checking state machines and how it can be done with mbeddr. It starts with an explanation of temporal logic languages. Afterwards, some features of mbeddr regarding state machines and their verification are discussed, followed by a short description of how NuSMV works. Author: Christoph Rosenberger Supervising Tutor: Peter Sommerlad Lecture: Seminar Program Analysis and Transformation Term: Spring 2013 School: HSR, Hochschule für Technik Rapperswil Model Checking with mbeddr 2 Introduction Model checking In the words of Cavada et al.: „The main purpose of a model checker is to verify that a model satisfies a set of desired properties specified by the user.” [1] mbeddr As Ratiu et al. state in their paper “Language Engineering as an Enabler for Incrementally Defined Formal Analyses” [2], the semantic gap between general purpose programming languages and input languages for formal verification tools is too big.
    [Show full text]
  • Model Checking Accomplishments and Opportunities
    Model Checking Accomplishments and Opportunities Rajeev Alur Systems Design Research Lab University of Pennsylvania www.cis.upenn.edu/~alur/ Debugging Tools q Program Analysis Type systems, pointer analysis, data-flow analysis q Simulation Effective in discovering bugs in early stages q Testing Expensive! q Formal Verification Mathematical proofs, Not yet practical Quest for Better Debugging q Bugs are expensive! Pentium floating point bug, Arian-V disaster q Testing is expensive! More time than design and implementation q Safety critical applications Certification mandated model yes temporal Model Checker property error-trace Advantages Automated formal verification, Effective debugging tool Moderate industrial success In-house groups: Intel, Microsoft, Lucent, Motorola… Commercial model checkers: FormalCheck by Cadence Obstacles Scalability is still a problem (about 100 state vars) Effective use requires great expertise Cache consistency: Gigamax Real design of a distributed multiprocessor Global bus UIC UIC UIC Cluster bus M P M P Read-shared/read-owned/write-invalid/write-shared/… Deadlock found using SMV Similar successes: IEEE Futurebus+ standard, network RFCs Talk Outline ü Introduction Ü Foundations q MOCHA q Current Trends and Future Components of a Model Checker q Modeling language Concurrency, non-determinism, simple data types q Requirements language Invariants, deadlocks, temporal logics q Search algorithms Enumerative vs symbolic + many optimizations q Debugging feedback Reachability Problem Model variables X ={x1, … xn} Each var is of finite type, say, boolean Initialization: I(X) condition over X Update: T(X,X’) How new vars X’ are related to old vars X as a result of executing one step of the program Target set: F(X) Computational problem: Can F be satisfied starting with I by repeatedly applying T ? Graph Search problem Symbolic Solution Data type: region to represent state-sets R:=I(X) Repeat If R intersects T report “yes” Else if R contains Post(R) report “no” Else R := R union Post(R) Post(R(X))= (Exists X.
    [Show full text]
  • Lecture 17 Model Checking I
    G52CON: Concepts of Concurrency Lecture 17 Model Checking "I Brian Logan School of Computer Science [email protected] Outline of this lecture" •# model checking •# transition systems and properties •# example: simple transition system •# SMV description and specification languages •# truth of CTL formulas © Brian Logan 2014 G52CON Lecture Lecture 17: Model Checking 2 Exercise 5" // Process 1 // Process 2 init1; init2; while(true) { while(true) { c1 = 0; // entry protocol c2 = 0; // entry protocol while (c2 == 0) {}; while (c1 == 0) {}; crit1; crit2; c1 = 1; // exit protocol c2 = 1; // exit protocol rem1; rem2; } } //shared variables integer c1 == 1 c2 == 1; © Brian Logan 2014 G52CON Lecture Lecture 17: Model Checking 3 Exercise 5a" // Process 1 // Process 2 init1; init2; while(true) { while(true) { c1 = 0; // entry protocol c2 = 0; // entry protocol while (c2 == 0) { while (c1 == 0) { if (turn == 2) { if (turn == 1) { c1 = 1; c2 = 1; while (turn == 2) {}; while (turn == 1) {}; c1 = 0; c2 = 0; } } } } crit1; crit2; turn = 2; // exit protocol turn = 1; // exit protocol c1 = 1; c2 = 1; rem1; rem2; }! } c1 == 1 c2 == 1 turn == 1 © Brian Logan 2014 G52CON Lecture Lecture 17: Model Checking 4 Formal verification" Formal verification consists of three parts: •# a description language for describing the system to be verified; •# a specification language for describing the properties to be verified; and •# a verification method to establish whether the description of the system satisfies the specification © Brian Logan 2014 G52CON Lecture Lecture 17: Model Checking 5 Proof-based approaches to verification" In a proof-based approach •# the system description is a set of formulas Γ in some logic •# the specification is another formula φ in the same logic •# the verification method consists of trying to find a proof that Γ |- φ This is time consuming and requires expertise on the part of the user.
    [Show full text]