T Reactive Systems: Kripke Structures and Automata

Similar documents
Timo Latvala. January 28, 2004

Model Checking with Automata An Overview

Formal Methods in Software Engineering. Lecture 07

Formal Methods for Software Development

Introduction to Linear-Time Temporal Logic. CSE 814 Introduction to LTL

lec3:nondeterministic finite state automata

Formal Specification and Verification

Model checking and timed CTL

T Parallel and Distributed Systems (4 ECTS)

Overview. Discrete Event Systems - Verification of Finite Automata. What can finite automata be used for? What can finite automata be used for?

Definition: A context-free grammar (CFG) is a 4- tuple. variables = nonterminals, terminals, rules = productions,,

Finite automata. We have looked at using Lex to build a scanner on the basis of regular expressions.

Implementation of Lexical Analysis

Implementation of Lexical Analysis

Petri Nets ee249 Fall 2000

Synchronization: Semaphores

Implementation of Lexical Analysis

CS5371 Theory of Computation. Lecture 8: Automata Theory VI (PDA, PDA = CFG)

Automated Formal Methods for Embedded Systems

Implementation of Lexical Analysis

Linear Temporal Logic. Model Checking and. Based on slides developed by Natasha Sharygina. Carnegie Mellon University.

Implementation of Lexical Analysis. Lecture 4

The UPPAAL Model Checker. Julián Proenza Systems, Robotics and Vision Group. UIB. SPAIN

Computer Science Technical Report

COMP 763. Eugene Syriani. Ph.D. Student in the Modelling, Simulation and Design Lab School of Computer Science. McGill University

CSE450. Translation of Programming Languages. Lecture 20: Automata and Regular Expressions

Distributed Systems Programming (F21DS1) Formal Verification

Reducing Fair Stuttering Refinement of Transaction Systems

System Correctness. EEC 421/521: Software Engineering. System Correctness. The Problem at Hand. A system is correct when it meets its requirements

Software Testing IV. Prof. Dr. Holger Schlingloff. Humboldt-Universität zu Berlin

CS2 Language Processing note 3

Model checking pushdown systems

Lexical Analysis. Lecture 3-4

Modeling and Analysis of Fischer s Algorithm

Model checking Timber program. Paweł Pietrzak

4/6/2011. Model Checking. Encoding test specifications. Model Checking. Encoding test specifications. Model Checking CS 4271

Finite State Verification. CSCE Lecture 14-02/25/2016

Lexical Analysis. Lecture 2-4

Model-Checking Concurrent Systems. The Model Checker Spin. The Model Checker Spin. Wolfgang Schreiner

CSC Discrete Math I, Spring Sets

Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn. 2.3 Timed Automata and Real-Time Statecharts

Implementation of Lexical Analysis

Implementation of Lexical Analysis

Efficient Synthesis of Production Schedules by Optimization of Timed Automata

Software Model Checking: Theory and Practice

(Refer Slide Time: 0:19)

Material from Recitation 1

6.852 Lecture 17. Atomic objects Reading: Chapter 13 Next lecture: Atomic snapshot, read/write register

want turn==me wait req2==0

Model Checking Revision: Model Checking for Infinite Systems Revision: Traffic Light Controller (TLC) Revision: 1.12

[module 2.2] MODELING CONCURRENT PROGRAM EXECUTION

Further Topics in Modelling & Verification

Lexical Analysis. Implementation: Finite Automata

CSE450. Translation of Programming Languages. Automata, Simple Language Design Principles

Formal Languages and Compilers Lecture IV: Regular Languages and Finite. Finite Automata

Safra's Büchi determinization algorithm

Thread Synchronization: Too Much Milk

Outline. Petri nets. Introduction Examples Properties Analysis techniques. 1 EE249Fall04

CLAN: A Tool for Contract Analysis and Conflict Discovery

Lecture 6,

CS 536 Introduction to Programming Languages and Compilers Charles N. Fischer Lecture 5

Formal Verification for UML/SysML models

Lecture 1: Conjunctive Queries

CSE 105 THEORY OF COMPUTATION

Lexical Analysis. COMP 524, Spring 2014 Bryan Ward

G52LAC Languages and Computation Lecture 6

Network Protocol Design and Evaluation

Lexical Analysis. Chapter 2

Model-Checking Concurrent Systems

Lecture 2: Symbolic Model Checking With SAT

Temporal Logic of Actions (TLA) (a brief introduction) Shmuel Katz Computer Science Department The Technion

CS505: Distributed Systems

Computing with Infinitely Many Processes under assumptions on concurrency and participation -M.Merritt&G.Taubenfeld. Dean Christakos & Deva Seetharam

Automata & languages. A primer on the Theory of Computation. The imitation game (2014) Benedict Cumberbatch Alan Turing ( ) Laurent Vanbever

Automata Theory for Reasoning about Actions

Last lecture CMSC330. This lecture. Finite Automata: States. Finite Automata. Implementing Regular Expressions. Languages. Regular expressions

2.1 Sets 2.2 Set Operations

CS 531: Notes II. January 31, 2014

Safety and liveness for critical sections

Administrivia. Lexical Analysis. Lecture 2-4. Outline. The Structure of a Compiler. Informal sketch of lexical analysis. Issues in lexical analysis

WHEN concurrent processes share a resource such as a file

Finite State Verification. CSCE Lecture 21-03/28/2017

Assignment 4 CSE 517: Natural Language Processing

MAVEN: modular aspect verification and interference analysis

The SPIN Model Checker

Distributed Memory LTL Model Checking

Formal Definition of Computation. Formal Definition of Computation p.1/28

An Introduction to UPPAAL. Purandar Bhaduri Dept. of CSE IIT Guwahati

Graphical Tool For SC Automata.

6 NFA and Regular Expressions

Rational subsets in HNN-extensions

Overview of Timed Automata and UPPAAL

Discrete Mathematics Lecture 4. Harper Langston New York University

Formal Verification by Model Checking

Automatic synthesis of switching controllers for linear hybrid systems: Reachability control

Reducing Clocks in Timed Automata while Preserving Bisimulation

Specification and Analysis of Real-Time Systems Using Real-Time Maude

DISCRETE-event dynamic systems (DEDS) are dynamic

1. [5 points each] True or False. If the question is currently open, write O or Open.

Lecture 2 Finite Automata

Transcription:

Tik-79.186 Reactive Systems 1 T-79.186 Reactive Systems: Kripke Structures and Automata Spring 2005, Lecture 3 January 31, 2005

Tik-79.186 Reactive Systems 2 Properties of systems invariants: the system never reaches a bad state ; in each reachable state P holds deadlock freedom mutual exclusion etc. safety: a bad sequence of things does no happen ; each violation of a safety property can be observed by looking at finite history of the system behavior. Example: the system should not reboot without the reset button being pressed first. Invariants are a simple subclass of safety properties. liveness: something good should eventually happen ; Example: X occurs infinitely often. Alternative formulation: there is progress in the system.

Tik-79.186 Reactive Systems 3 How to Specify and Check Properties? Even simple looking systems can easily have thousands or millions of reachable states and enabled transitions. It does not make sense to graphically represent or manually explore each node and arc of so large graphs. Invariant properties, such as deadlock freedom or the unreachability of a forbidden state, can be formulated as conditions concerning one state at a time, which a reachability analysis algorithm can easily verify when adding nodes to the reachability graph. Formulating and verifying safety, and (especially) liveness properties ( something good should eventually happen ) call for new methods, such as temporal logic and model checking.

Tik-79.186 Reactive Systems 4 Kripke Structures Temporal logics are traditionally defined in terms of Kripke structures. A Kripke structure is a modeling formalism independent way of representing the behavior of a system. A Kripke structure is basically a graph having the reachable states of the system as nodes and state transitions of the system as edges. It also contains a labeling of the states of the system with properties that hold in each state. To obtain a Kripke structure form the reachability graph one first needs to fix a set of atomic propositions AP, which denote the properties of individual states we are interested in. The labeling of the states (with markings) of the reachability graph is replaced with the labeling showing which atomic propositions hold in that state. (Note: This does NOT mean states with the same label should be merged!) After this the labels (with transitions) on the arcs of the reachability graph are removed, and the result is the Kripke structure. (Note: The removal of arc labels might result in a merging of some edges.)

Tik-79.186 Reactive Systems 5 Definition of Kripke Structures Definition 1 Let AP be a non-empty set of atomic propositions. A Kripke structure is a four tuple M = (S, s 0, R, L), where S is a finite set of states, s 0 S is an initial state, R S S is a transition relation, for which it holds that s S : s S : (s, s ) R, and L : S 2 AP is labeling, a function which labels each state with the atomic propositions which hold in that state.

Tik-79.186 Reactive Systems 6 Kripke Structures Kripke structures are the model used to give semantics (definition of when a specified property holds) for the most widely used specification languages for reactive systems, namely temporal logics. Kripke structures can be seen as describing the behavior of the modeled system in an modeling language independent manner. Therefore, temporal logics are really modeling formalism independent. The definition of atomic propositions is the only thing that can needs to be adjusted for each formalism. Note that in Kripke structures deadlock states are disallowed. This is for technical reasons (it simplifies the theory somewhat). Should a reachability graph contain a deadlock state, in the corresponding Kripke structure we add an edge from the deadlock state back to itself.

Tik-79.186 Reactive Systems 7 Example:Reachability Graph of a Mutex System The following is a reachability graph of a model of a Mutex algorithm. idle0 s0 P:<0,NC>+<1,NC> T:<NONE> idle1 try0 try1 non_critical0 s1 P:<0,TRY>+<1,NC> T:<0> s2 P:<0,NC>+<1,TRY> T:<1> non_critical1 try1 try0 s4 P:<0,CS>+<1,NC> T:<0> go_critical0 s3 P:<0,TRY>+<1,TRY> T:<0> s5 P:<0,TRY>+<1,TRY> T:<1> go_critical1 s6 P:<0,NC>+<1,CS> T:<1> try1 go_critical0 go_critical1 try0 s7 P:<0,CS>+<1,TRY> T:<0> s8 P:<0,TRY>+<1,CS> T:<1> non_critical0 non_critical1

Tik-79.186 Reactive Systems 8 Example: Kripke Structure of the Mutex System s0 L = {NC0, NC1} s1 L = {TRY0, NC1} s2 L = {NC0, TRY1} s4 L = {CS0, NC1} s3 L = {TRY0, TRY1} s5 L = {TRY0, TRY1} s6 L = {NC0, CS1} s7 L = {CS0, TRY1} s8 L = {TRY0, CS1}

Tik-79.186 Reactive Systems 9 Kripke Structures and Automata As can be directly seen from the definition Kripke structures have a close relationship with automata. The changes are the following: labeling is on states instead of having labels on arcs, the labeling consists of a subset of AP instead of an element of Σ, there is at most one arc between any two states, and there is no definition of final states. (One can think of all the states being final.)

Tik-79.186 Reactive Systems 10 From Kripke Structure to Finite State Automaton An often used trick is to actually use an automaton directly derived from the Kripke structure in model checking. We define an automaton A M, which accepts exactly the (finite) sequences of valuations in a path through the Kripke structure.

Tik-79.186 Reactive Systems 11 From Kripke Structures to Finite State Automaton Let M = (S, s 0, R, L) be a Kripke structure over a set of atomic propositions AP. Define an automaton A M = (Σ, S M, S 0 M, M, F M ), where Σ = 2 AP, S M = S {s i }, S 0 M = {si }, For all s, s S M, a Σ : (s, a, s ) M iff L(s ) = a and (((s, s ) R) or (s = s i and s = s 0 )); and F M = S M.

Tik-79.186 Reactive Systems 12 Example: The Automaton A M All states are final. si {NC0, NC1} s0 {NC0, NC1} {NC0, NC1} {NC0, NC1} {TRY0, NC1} {NC0, TRY1} s1 s2 {CS0, NC1} {TRY0, TRY1} {TRY0, TRY1} {NC0, CS1} s4 s3 s5 s6 {CS0, TRY1} {CS0, TRY1} {TRY0, CS1} {TRY0, CS1} s7 s8 {NC0, TRY1} {TRY0, NC1}

Tik-79.186 Reactive Systems 13 Model Checking of Safety Properties with Automata An example safety property for a path in the Kripke structure is the following: Spec: A (finite) path in the Kripke structure satisfies Spec iff it does not contain a state having both CR0 and CR1 holding at the same time. It is easy to give a specification automaton S which accepts all sequences of A M corresponding to paths which satisfy this property. (A two-state deterministic automaton will suffice.)

Tik-79.186 Reactive Systems 14 In this case the complement of the specification Spec is the following: A (finite) path in the Kripke structure satisfies Spec iff it contains a state in which both CR0 and CR1 hold at the same time. It can be checked by an automaton S (also a simple two-state deterministic automaton). Now all paths through the Kripke structure satisfy Spec iff there is no path which satisfies Spec.

Tik-79.186 Reactive Systems 15 Implementing Safety Model Checking To implement this, we can use automata theory to obtain the product automaton P = A M S, and check that indeed L(P) =. (By observing that no accepting state of P is reachable from its initial states.) Thus in our running example the safety property Spec holds for all paths through the Kripke structure M.

Tik-79.186 Reactive Systems 16 Why not Use Automata as the Specification Language? For even slightly more complicated specifications expressing the specification directly as an automaton can be too complicated. This is one of the reasons temporal logics are more widely used as a specification formalisms as are automata. It is expensive to complement automata. Thus even if the specification can be easily expressed as an automaton, its complement can be too big to handle. Liveness properties cannot be handled by finite state automata on finite strings. Thus to handle liveness, we have to change our definition of automata. This brings new problems we have not encountered so far. Automata are, however, one of the main implementation techniques in implementing model checking algorithms for more expressive temporal logics, a subject which we will discuss next.