Institute for Applied Information Processing and Communications 1 Karin Greimel Semmering, 2008-05-19 Open Implication.

Slides:



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

The Quest for Correctness Joseph Sifakis VERIMAG Laboratory 2nd Sogeti Testing Academy April 29th 2009.
Copyright 2000 Cadence Design Systems. Permission is granted to reproduce without modification. Introduction An overview of formal methods for hardware.
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.
Model Checking Lecture 2. Three important decisions when choosing system properties: 1automata vs. logic 2branching vs. linear time 3safety vs. liveness.
Avoiding Determinization Orna Kupferman Hebrew University Joint work with Moshe Vardi.
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)
Auto-Generation of Test Cases for Infinite States Reactive Systems Based on Symbolic Execution and Formula Rewriting Donghuo Chen School of Computer Science.
Algorithmic Software Verification VII. Computation tree logic and bisimulations.
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:
An Introduction to the Model Verifier verds Wenhui Zhang September 15 th, 2010.
Synthesis of Reactive systems Orna Kupferman Hebrew University Moshe Vardi Rice University.
Temporal Logic and the NuSMV Model Checker CS 680 Formal Methods Jeremy Johnson.
Timed Automata.
Model Checking Inputs: A design (in some HDL) and a property (in some temporal logic) Outputs: Decision about whether or not the property always holds.
Nir Piterman Department of Computer Science TexPoint fonts used in EMF. Read the TexPoint manual before you delete this box.: AAAAA Bypassing Complexity.
CIS 540 Principles of Embedded Computation Spring Instructor: Rajeev Alur
Digitaalsüsteemide verifitseerimise kursus1 Formal verification: Property checking Property checking.
Review of topics Final exam : -May 2nd to May 7 th - Projects due on May 7th.
1 Temporal Logic u Classical logic:  Good for describing static conditions u Temporal logic:  Adds temporal operators  Describe how static conditions.
CSE 555 Protocol Engineering Dr. Mohammed H. Sqalli Computer Engineering Department King Fahd University of Petroleum & Minerals Credits: Dr. Abdul Waheed.
Approaches to Reactive System Synthesis J.-H. Roland Jiang.
On-the-fly Model Checking from Interval Logic Specifications Manuel I. Capel & Miguel J. Hornos Dept. Lenguajes y Sistemas Informáticos Universidad de.
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.
Semantics with Applications Mooly Sagiv Schrirber html:// Textbooks:Winskel The.
ESE601: Hybrid Systems Introduction to verification Spring 2006.
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 Formal Engineering of Reliable Software LASER 2004 school Tutorial, Lecture1 Natasha Sharygina Carnegie Mellon University.
1 Temporal Logic-Overview FM Temporal Logic u Classical logic: Good for describing static conditions u Temporal logic: Adds temporal operators Describe.
Final Exam Review Cummulative Chapters 0, 1, 2, 3, 4, 5 and 7.
Solving Games Without Determinization Nir Piterman École Polytechnique Fédéral de Lausanne (EPFL) Switzerland Joint work with Thomas A. Henzinger.
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
Using Mathematica for modeling, simulation and property checking of hardware systems Ghiath AL SAMMANE VDS group : Verification & Modeling of Digital systems.
Benjamin Gamble. What is Time?  Can mean many different things to a computer Dynamic Equation Variable System State 2.
Model Checking Lecture 3 Tom Henzinger. Model-Checking Problem I |= S System modelSystem property.
Languages of nested trees Swarat Chaudhuri University of Pennsylvania (with Rajeev Alur and P. Madhusudan)
CIS 540 Principles of Embedded Computation Spring Instructor: Rajeev Alur
CIS 842: Specification and Verification of Reactive Systems Lecture Specifications: LTL Model Checking Copyright , Matt Dwyer, John Hatcliff,
CIS 540 Principles of Embedded Computation Spring Instructor: Rajeev Alur
Orna Kupferman Hebrew University Formal Verification -- Deciding the Undecidable.
Avoiding Determinization Orna Kupferman Hebrew University Joint work with Moshe Vardi.
1 CSEP590 – Model Checking and Automated Verification Lecture outline for August 6, 2003.
Graz University of Technology Professor Horst Cerjak, Barbara Jobstmann San Jose, Nov 15Optimizations for LTL Synthesis Barbara Jobstmann.
Verification & Validation By: Amir Masoud Gharehbaghi
CIS 540 Principles of Embedded Computation Spring Instructor: Rajeev Alur
Foundations of (Theoretical) Computer Science Chapter 2 Lecture Notes (Section 2.2: Pushdown Automata) Prof. Karen Daniels, Fall 2010 with acknowledgement.
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.
CIS 540 Principles of Embedded Computation Spring Instructor: Rajeev Alur
Variants of LTL Query Checking Hana ChocklerArie Gurfinkel Ofer Strichman IBM Research SEI Technion Technion - Israel Institute of Technology.
Specify, Compile, Run: Hardware from PSL Speaker: Chen-Hsuan Adonis Lin Advisor: Jie-Hong Roland Jiang 2016年2月22日星期一 2016年2月22日星期一 2016年2月22日星期一 1.
About Alternating Automata Daniel Choi Provable Software Laboratory KAIST.
Today’s Agenda  Quiz 4  Temporal Logic Formal Methods in Software Engineering1.
6/12/20161 a.a.2015/2016 Prof. Anna Labella Formal Methods in software development.
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.
Orna Kupferman Yoad Lustig
CIS 842: Specification and Verification of Reactive Systems
Program Synthesis is a Game
Alternating tree Automata and Parity games
Translating Linear Temporal Logic into Büchi Automata
Introduction to verification
Chapter 2: Analysis and Verification of Non-Real-Time Systems
Presentation transcript:

Institute for Applied Information Processing and Communications 1 Karin Greimel Semmering, Open Implication

Institute for Applied Information Processing and Communications 2 Karin Greimel Semmering, Open Implication Outline Context Introduction –LTL specifications, systems –example Formal Definition, Complexity Algorithms –with optimal complexity –Safraless –GR(1) Experimental Results Summary

Institute for Applied Information Processing and Communications 3 Karin Greimel Semmering, Open Implication Big Picture What do HW and SW designers do? 1.Write a specification 2.Implement system 3.Check if sys. realizes spec. 4.Debug Our idea of HW/SW design: 1.Write specification 2.Automatically construct 3.Relax

Institute for Applied Information Processing and Communications 4 Karin Greimel Semmering, Open Implication LTL Specifications Linear Temporal Logic: High level specification language Boolean logic + temporal operators (X, G, F, U) Semantics defined over infinite sequences (= words = traces) Describe behavior of open systems Open system ( = Moore machine = transducer): Interacts with its environment (output and input variables) Examples: controller for elevator, traffic light, arbiter for a bus Definitions: An open system realizes an LTL formula iff all traces of the open system satisfy the formula. Verification: Does a given system realize the specification. Realizability: Is there an open system that realizes a given spec.? Synthesis: Automatically construct an open system realizing the spec..

Institute for Applied Information Processing and Communications 5 Karin Greimel Semmering, Open Implication LTL Specifications - Example Part of a requirement for an arbiter: a... acknowledgement, output variable r... request, input variable f = GF(r) → G(a→X(¬a)) If there is always a request at some point, then always if there is an ack., there is no ack. in the next step. Open system realizing f, all traces satisfy f:

Institute for Applied Information Processing and Communications 6 Karin Greimel Semmering, Open Implication Example Equivalence Are f and g equivalent? Consider w = (a,¬r) ω, w satisfies f but not g. Find an open system which realizes f but not g? f = GF(r) → G(a→X(¬a)) g = G(a→X(¬a)) Not equivalent!

Institute for Applied Information Processing and Communications 7 Karin Greimel Semmering, Open Implication Definitions Motivation: Synthesis of g: find a smaller specification f such that f → o g and synthesise f. Verification of g: find a smaller specification f such that f → o g and f → o g and verify f. Definition: Given two LTL formulas f and g, f open-implies g (f → o g) if all open systems realizing f also realize g. Definition: Given two LTL formulas f and g, f trace-implies g if all traces satisfying f also satisfy g.

Institute for Applied Information Processing and Communications 8 Karin Greimel Semmering, Open Implication Comparison Definition of equivalence of LTL specifications with respect to open systems and with respect to traces. + Open-implication is weaker: f = GF(r) → G(a→X(¬a)) and g = G(a→X(¬a)) are not trace equivalent but open equivalent. - Open-implication has a very high complexity: same complexity as realizability, consider f → o false, 2EXP.

Institute for Applied Information Processing and Communications 9 Karin Greimel Semmering, Open Implication Characteristic f = GF(r) → G(a→X(¬a)) g = G(a→X(¬a)) Not trace equivalent (a,¬r) ω but open equivalent. Start with (a,¬r). Can not continue with a. (a,¬r) ω is f-clairvoyant. The difference between f trace-implies g and f open-implies g are f-clairvoyant words.

Institute for Applied Information Processing and Communications 10 Karin Greimel Semmering, Open Implication Algorithm - Idea Find an open system that realizes f but not g, then ¬(f → o g): –An open system does not realize g iff there exists a trace that satisfies ¬g. Calculate realizability for f and satisfiability for ¬g simultaneously. An open system can be represented by a tree: every trace of the open system corresponds to a path in the tree.

Institute for Applied Information Processing and Communications 11 Karin Greimel Semmering, Open Implication Algorithm with optimal complexity 1) Realizability (2EXP): –f → Deterministic Parity Tree automaton –f realizable iff language of the DPT is not empty –tree accepted by the DPT ≙ open system realizing f 2) Satisfiability (PSPACE): –¬g → Nondeterministic Büchi Word automaton –¬g satisfiable iff language of NBW is not empty –word accepted by the NBW ≙ word satisfying ¬g

Institute for Applied Information Processing and Communications 12 Karin Greimel Semmering, Open Implication Algorithm - Safraless Calculate realizability avoiding Safra’s determinization construction (O. Kupferman and M. Y. Vardi. Safraless decision procedures.): f → Universal Co-Büchi Tree automaton tree accepted by the UCT ≙ open system realizing f UCT → Nondeterministic Büchi Tree automaton with bound k tree accepted by the NBT k ≙ open system of size ≤ k realizing f + easier to implement + incremental approach, useful to find counter examples - does not meet the lower bound

Institute for Applied Information Processing and Communications 13 Karin Greimel Semmering, Open Implication Implementation Consider a subset of LTL: General Reactivity of Rank 1 (GR(1)) (N. Piterman, A. Pnueli and Y. Sa‘ar. Synthesis of reactive(1) designs) : g = g e → g s environment assumption → system guaranty Environment assumptions and system guaranties can be represented by deterministic Büchi automata. Example: f = GFr → G(a→X(¬a)) f → o g?: Calculate realizability for f and satisfiability for ¬g simultaneously, by solving a fixpoint formula. Symbolic algorithm in P.

Institute for Applied Information Processing and Communications 14 Karin Greimel Semmering, Open Implication Results of Arbiter Case Study: new → o old R. Bloem, S. Galler, B. Jobstmann, N. Piterman, A. Pnueli und M. Weiglhofer: - Automatic hardware synthesis from specification: A case study - Specify, compile, run: Hardware from PSL Time for synthesis new + open implication << time for old synthesis

Institute for Applied Information Processing and Communications 15 Karin Greimel Semmering, Open Implication Summary Defined open implication: –Compared to trace-implication Developed 3 algorithms: –Automata theoretic with optimal complexity –Automata theoretic avoiding Safras construction –Fixpoint formula for GR(1) with implementation Case study

Institute for Applied Information Processing and Communications 16 Karin Greimel Semmering, Open Implication Thank you for your attention References: O. Kupferman and M. Y. Vardi. Safraless decision procedures. In Symposium on Foundations of Computer Science (FOCS’05), pages , N. Piterman, A. Pnueli and Y. Sa‘ar. Synthesis of reactive(1) designs. In Proc. Verification, Model Checking and Abstract Interpretation, pages , 2006 R. Bloem, S. Galler, B. Jobstmann, N. Piterman, A. Pnueli und M. Weiglhofer. Automatic hardware synthesis from specifications: A case study. In DATE, R. Bloem, S. Galler, B. Jobstmann, N. Piterman, A. Pnueli und M. Weiglhofer. Specify, compile, run: Hardware from PSL. In 6 th International Workshop on Compiler Optimization Meets Compiler Verification, pages 3-16, 2007.