An Introduction to Input/Output Automata Qihua Wang.

Slides:



Advertisements
Similar presentations
Formal Methods in Software Engineering
Advertisements

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.
Timed Automata.
1 COMP 382: Reasoning about algorithms Unit 9: Undecidability [Slides adapted from Amos Israeli’s]
1 Mechanical Verification of Timed Automata Myla Archer and Constance Heitmeyer Presented by Rasa Bonyadlou 24 October 2002.
Introduction to Computability Theory
Interface Automata 29-September Modeling Temporal Behavior of Component Component behaves with Environment Traditional (pessimistic) approach –
Introduction to Computability Theory
1 Introduction to Computability Theory Lecture7: PushDown Automata (Part 1) Prof. Amos Israeli.
Introduction to Computability Theory
CPSC 411, Fall 2008: Set 12 1 CPSC 411 Design and Analysis of Algorithms Set 12: Undecidability Prof. Jennifer Welch Fall 2008.
CS 582 / CMPE 481 Distributed Systems Fault Tolerance.
CPSC 668Set 16: Distributed Shared Memory1 CPSC 668 Distributed Algorithms and Systems Fall 2006 Prof. Jennifer Welch.
Conformance Simulation Relation ( ) Let and be two automata over the same alphabet simulates () if there exists a simulation relation such that Note that.
1 Lecture 7 Halting Problem –Fundamental program behavior problem –A specific unsolvable problem –Diagonalization technique revisited Proof more complex.
1 Lecture 7 Halting Problem –Fundamental program behavior problem –A specific unsolvable problem –Diagonalization technique revisited Proof more complex.
Aho-Corasick String Matching An Efficient String Matching.
Specification Formalisms Book: Chapter 5. Properties of formalisms Formal. Unique interpretation. Intuitive. Simple to understand (visual). Succinct.
A Denotational Semantics For Dataflow with Firing Edward A. Lee Jike Chong Wei Zheng Paper Discussion for.
Review of the automata-theoretic approach to model-checking.
CS5371 Theory of Computation Lecture 8: Automata Theory VI (PDA, PDA = CFG)
DEVS and DEVS Model Dr. Feng Gu. Cellular automata with fitness.
Data Flow Analysis Compiler Design Nov. 8, 2005.
System-Level Types for Component-Based Design Paper by: Edward A. Lee and Yuhong Xiong Presentation by: Dan Patterson.
Chapter 8 Asynchronous System Model by Mikhail Nesterenko “Distributed Algorithms” by Nancy A. Lynch.
Timed UML State Machines Ognyana Hristova Tutor: Priv.-Doz. Dr. Thomas Noll June, 2007.
Comparison of methods for supervisory control and submodule construction 1 Gregor v. Bochmann, University of Ottawa Comparison of methods for supervisory.
Chapter 10 State Machine Diagrams
Formal Model for Simulations Instructor: DR. Lê Anh Ngọc Presented by – Group 6: 1. Nguyễn Sơn Hùng 2. Lê Văn Hùng 3. Nguyễn Xuân Hậu 4. Nguyễn Xuân Tùng.
Modeling Process CSCE 668Set 14: Simulations 2 May be several algorithms (processes) runs on each processor to simulate the desired communication system.
Benjamin Gamble. What is Time?  Can mean many different things to a computer Dynamic Equation Variable System State 2.
AUTOMATA THEORY Reference Introduction to Automata Theory Languages and Computation Hopcraft, Ullman and Motwani.
Pushdown Automata (PDAs)
Modelling III: Asynchronous Shared Memory Model Chapter 9 by Nancy A. Lynch presented by Mark E. Miyashita.
Dina Workshop Analysing Properties of Hybrid Systems Rafael Wisniewski Aalborg University.
CS6133 Software Specification and Verification
PARTIALLY SYNCHRONOUS ALGORITHMS PRESENTED BY: BINAMRA DUTTA.
Design Concepts By Deepika Chaudhary.
Timed I/O Automata: A Mathematical Framework for Modeling and Analyzing Real-Time Systems Frits Vaandrager, University of Nijmegen joint work with Dilsun.
6.852: Distributed Algorithms Spring, 2008 Class 13.
Natallia Kokash (Accepted for PACO’2011) ACG, 31/05/ Input-output conformance testing for channel-based connectors 1.
Submodule construction in logics 1 Gregor v. Bochmann, University of Ottawa Using First-Order Logic to Reason about Submodule Construction Gregor v. Bochmann.
Programming Languages and Design Lecture 3 Semantic Specifications of Programming Languages Instructor: Li Ma Department of Computer Science Texas Southern.
Recognizing safety and liveness Presented by Qian Huang.
Defining Liveness by Bowen Alpern and Fred B. Schneider Presented by Joe Melnyk.
1Computer Sciences Department. Book: INTRODUCTION TO THE THEORY OF COMPUTATION, SECOND EDITION, by: MICHAEL SIPSER Reference 3Computer Sciences Department.
1Computer Sciences Department. Book: INTRODUCTION TO THE THEORY OF COMPUTATION, SECOND EDITION, by: MICHAEL SIPSER Reference 3Computer Sciences Department.
Concurrency Properties. Correctness In sequential programs, rerunning a program with the same input will always give the same result, so it makes sense.
CIS 540 Principles of Embedded Computation Spring Instructor: Rajeev Alur
CIS 540 Principles of Embedded Computation Spring Instructor: Rajeev Alur
1Computer Sciences Department. Book: INTRODUCTION TO THE THEORY OF COMPUTATION, SECOND EDITION, by: MICHAEL SIPSER Reference 3Computer Sciences Department.
Exercise 1 Consider a language with the following tokens and token classes: ID ::= letter (letter|digit)* LT ::= " " shiftL ::= " >" dot ::= "." LP ::=
Chapter 8 Asynchronous System Model by Mikhail Nesterenko “Distributed Algorithms” by Nancy A. Lynch.
CSCE 668 DISTRIBUTED ALGORITHMS AND SYSTEMS Fall 2011 Prof. Jennifer Welch CSCE 668 Set 16: Distributed Shared Memory 1.
Formal Verification. Background Information Formal verification methods based on theorem proving techniques and model­checking –To prove the absence of.
NP-Completeness  For convenience, the theory of NP - Completeness is designed for decision problems (i.e. whose solution is either yes or no).  Abstractly,
/ PSWLAB Thread Modular Model Checking by Cormac Flanagan and Shaz Qadeer (published in Spin’03) Hong,Shin Thread Modular Model.
Chapter 5 Finite Automata Finite State Automata n Capable of recognizing numerous symbol patterns, the class of regular languages n Suitable for.
Operational Semantics Mooly Sagiv Tel Aviv University Sunday Scrieber 8 Monday Schrieber.
Today’s Agenda  Quiz 4  Temporal Logic Formal Methods in Software Engineering1.
Agenda  Quick Review  Finish Introduction  Java Threads.
Introduction to distributed systems description relation to practice variables and communication primitives instructions states, actions and programs synchrony.
Complexity of Compositional Model Checking of Computation Tree Logic on Simple Structures Krishnendu Chatterjee Pallab Dasgupta P.P. Chakrabarti IWDC 2004,
Sequential Flexibility
CIS Automata and Formal Languages – Pei Wang
Copyright © Cengage Learning. All rights reserved.
Modeling Arithmetic, Computation, and Languages
High-Level Abstraction of Concurrent Finite Automata
Linear Time Properties
Presentation transcript:

An Introduction to Input/Output Automata Qihua Wang

Organization Overview of the I/O automaton model Composition of I/O automata Fairness Specification Introduction to proof techniques

Overview of the Model Model for discrete event systems consisting of concurrently-operating components –Instead of simply computing some function of their input and halting, they receive input from and react to their environment. –Each system component is modeled as an I/O automaton

Overview of the Model Distinction between those actions whose performance is under the control of the automaton and those actions whose performance is under the control of its environment. An automaton's actions are classified as either `input', `output', or `internal‘. AutomatonEnvironment Output Input

Overview of the Model An automaton can establish restrictions on when it will perform an output or internal action, but it is unable to block the performance of an input action. “If the environment behaves correctly, then the automaton behaves correctly.”

Overview of the Model I/O automata may be nondeterministic I/O automata can be composed to yield other I/O automata Fair execution A problem to be solved by an I/O automaton is formalized as an arbitrary set of (finite and infinite) sequences of external actions. Solve a problem Abstraction mapping

Some Uses Describe concurrent algorithms Algorithm correctness proofs Complexity analysis

The Input/Output Automaton Model Interface between the automaton and environment: action signature –in(S), out(S), int(S) External actions –ext(S) = in(S) ∪ out(S) Locally-controlled actions: –local(S) = out(S) ∪ int(S)

The Input/Output Automaton Model Five components: –An action signature sig(A), –A set states(A) of states, –A nonempty set start(A) in states(A) as start states, –A transition relation steps(A): states(A) × acts(A) × states(A) with the property that for every state s’ and input action π there is a transition (s’,π, s) in steps(A), –An equivalence relation part(A) partitioning the set local(A) into at most a countable number of equivalence classes.

The Input/Output Automaton Model If (s’,π, s) a step of A, then π is said to be enabled in s’. Two fundamental assumptions –Unable to block its input –The performance of an action is controlled by at most one system component

The Input/Output Automaton Model An execution fragment is a finite sequence s 0, π 1, s 1, π 2, …… π n, s n or an infinite sequence of A such that (s’ i, π i+1, s i+1 ) is a step of A for every i. An execution is an execution fragment beginning with a start state. Denoted the set of executions by execs(A), finexecs(A).

The Input/Output Automaton Model The schedule of an execution fragment α is the subsequence of α consisting of the actions appearing in α. The set of schedules is denoted by sched(α), finsched(α). The behavior of an execution or schedule α of A is the sequence of α consisting of external actions and is denoted by beh(α). Event : A particular occurrence of an action

Candy Machine The signature of CM-1 State of CM-1 : variable ‘button-pushed’ Initial state : button_pushed = 0

Candy Machine Transition relation for CM-1

Candy Machine CM-2 : HEATHBAR action has ‘false ’ as its precondition. CM-3 : All the three candy dispensation actions have ‘false’ as their precondition.

Candy Machine Customer CUST-1 continues to request candy bars, nondeterministically choose which button to push. The state of CUST-1 consists of one variable ‘waiting’, which takes on values ‘yes’ and ‘no’. CUST-2 pushes button 2 repeatedly until the machine dispenses a HEATHBAR, and then pushes button 1 forever. Besides ‘waiting’, CUST-2 has another state variable ‘heathbar_received’.

Candy Machine CUST-3 is similar to CUST-1except that it may make a transition to a ‘satiated’ state from which it no longer requests any candy bars.

Composition Construct an automaton modeling a complex system by composing automata modeling the simpler system components. When compose a collection of automata, identify an output action π of one automaton with the input action π of each automaton having π as an input action When one automaton having π as an output action performs π, all automata having π as an action perform π simultaneously (automata not having π as an action do nothing).

Composition E.g. in the composition of CM-1 and CUST-1, the output action PUSH1 of the customer with the input action PUSH1 of the candy machine. The occurrence of PUSH1 causes both the candy machine and the customer to perform PUSH1, causing button pushed to be set to 1 in the candy machine's local state, and waiting to be set to `yes' in the customer's local state. This synchronization models a form of communication from the customer to the candy machine.

Composition A countable collection {S i } of action signatures is said to be strongly compatible if for all i ≠ j, we have 1.out(S i ) ∩ out(S j ) = Φ, 2.int(S i ) ∩ acts(S j ) = Φ, and 3.No action is contained in infinitely many sets acts(S i ). A collection of automata are strongly compatible if their action signatures are strongly compatible

Composition The composition signature S of a countable collection of strongly compatible action signatures {S i } is defined to be: Internal actions of the components become internal actions of the composition, output actions become output actions, and all other actions become input actions.

Composition Automaton composition –part(A) = ∪part(A i )

Composition An execution of a composition induces executions of the component automata. Given an execution α = s 0 π 1 s 1 π 2 …… of A, let α|A i be the sequence obtained by deleting π k s k when π k is not an action of A i and replacing the remaining s k by s k [i].

Fairness The property that infinitely often the component is given the opportunity to perform one of its locally controlled actions –E.g. CUST-4 does not wait for a candy bar before pressing a button again. One behavior of the composition CM-1∙CUST-4 is the infinite sequence 1111… –CM-1∙CUST-4 has equivalent classes {S, H, A} and {1, 2} –Being fair to each component means being fair to each equivalence class of locally controlled actions. –11S11S… is a fair behavior of CM-1∙CUST-4

Fairness Fair execution: the following condition hold for each equivalence class C: 1.If α is finite, then no action of C is enabled in the final state of α. 2.If α is infinite, then either α contains infinitely many events from C, or α contains infinitely many occurrences of states in which no action of C is enabled.

Problem Specification A problem specification is simply a set of allowable `behaviors’. The automaton solves the problem in the sense that every `behavior’ it exhibits is a `behavior' allowed by the problem specification.

Problem Specification Schedule module H: 1.an action signature sig(H), and 2.a set scheds(H) of schedules. Fair behaviors Composition of strongly compatible schedule modules

Problem Specification A problem is simply a schedule module P. An automaton A solves a problem P if A and P have the same external action signature and fairbehs(A) fairbehs(P). An automaton A implements a problem P if A and P have the same external action signature (that is, the same external interface) and finbehs(A) finbehs(P).

Problem Specification Safety properties are informally characterized by the fact that they specify a property that must hold in every state of a computation. Liveness properties are informally characterized by the fact that they specify events that must eventually be performed.

Problem Specification E.g. SAFE-CM has the same action signature as CM-1, and has as its set of schedules the set of sequences over the symbols 1, 2, S, H, A satisfying the following condition: Every S is immediately preceded by a 1, and every A or H is immediately preceded by a 2. Prove that CM-1 is a safe candy machine

Problem Specification Define ‘well-formedness’ conditions on the interaction between the machine and its environment

Problem Specification E.g. Define a sequence of candy machine actions to be well-formed if it consists of alternating input and output (push and dispensation) actions, starting with an input action. LIVE-CM : ‘If the sequence is well-formed, then every 1 event is followed by a later S event, and every 2 event is followed by a later H or A event.’ CM-3 is not a live candy machine. CM-1 and CM-2 are live candy machines.

Problem Specification In general, given an automaton A and a problem P, it is not the case that if A solves P then A implements P, nor is it the case that if A implements P then A solves P.

Proof Techniques Modular Decomposition –we reason about the behavior of a composition by reasoning about the behavior of the component automata individually. Hierarchical Decomposition –given automaton solves a second, that the second solves a third, and so on until the final automaton solves the given problem. –use possibilities mapping from one automaton to another

Other Application Network Resource Allocation Synchronizers Communication Concurrency Control Shared Atomic Objects Dataflow Real-Time Computing

Thank you! End