Interacting Discrete Event Systems: Modelling, Verification, and Supervisory Control Sherif S. Abdelwahed February 4, 2002.

Slides:



Advertisements
Similar presentations
Automatic Verification Book: Chapter 6. How can we check the model? The model is a graph. The specification should refer the the graph representation.
Advertisements

Process Algebra Book: Chapter 8. The Main Issue Q: When are two models equivalent? A: When they satisfy different properties. Q: Does this mean that the.
Modeling issues Book: chapters 4.12, 5.4, 8.4, 10.1.
Ch:8 Design Concepts S.W Design should have following quality attribute: Functionality Usability Reliability Performance Supportability (extensibility,
February 12, 2007 WALCOM '2007 1/22 DiskTrie: An Efficient Data Structure Using Flash Memory for Mobile Devices N. M. Mosharaf Kabir Chowdhury Md. Mostofa.
Language and Automata Theory
Modular Processings based on Unfoldings Eric Fabre & Agnes Madalinski DistribCom Team Irisa/Inria UFO workshop - June 26, 2007.
Lecture 24 MAS 714 Hartmut Klauck
Based on text by S. Mourad "Priciples of Electronic Systems" Digital Testing: Design Representation and Fault Detection
1 University of Pennsylvania Grigoris Karvounarakis February 2004 Conversation Specification: A New Approach to Design and Analysis of E- Service Composition.
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:
C O N T E X T - F R E E LANGUAGES ( use a grammar to describe a language) 1.
1 1 CDT314 FABER Formal Languages, Automata and Models of Computation Lecture 3 School of Innovation, Design and Engineering Mälardalen University 2012.
Timed Automata.
Supervisory Control of Hybrid Systems Written by X. D. Koutsoukos et al. Presented by Wu, Jian 04/16/2002.
Model Checker In-The-Loop Flavio Lerda, Edmund M. Clarke Computer Science Department Jim Kapinski, Bruce H. Krogh Electrical & Computer Engineering MURI.
Parosh Aziz Abdulla Pritha Mahata Aletta Nyl é n Uppsala University Downward Closed Language Generators.
Background information Formal verification methods based on theorem proving techniques and model­checking –to prove the absence of errors (in the formal.
Parametric Throughput Analysis of Synchronous Data Flow Graphs
1 Flexible Subtyping Relations for Component- Oriented Formalisms and their Verification David Hurzeler PhD Examination, 9/11/2004.
Convertibility Verification and Converter Synthesis: Two Faces of the Same Coin Jie-Hong Jiang EE249 Discussion 11/21/2002 Passerone et al., ICCAD ’ 02.
1 Model Checking, Abstraction- Refinement, and Their Implementation Based on slides by: Orna Grumberg Presented by: Yael Meller June 2008.
Discrete Abstractions of Hybrid Systems Rajeev Alur, Thomas A. Henzinger, Gerardo Lafferriere and George J. Pappas.
An Introduction to Input/Output Automata Qihua Wang.
Abstractions. Outline Informal intuition Why do we need abstraction? What is an abstraction and what is not an abstraction A framework for abstractions.
Validating Streaming XML Documents Luc Segoufin & Victor Vianu Presented by Harel Paz.
1 Ivan Lanese Computer Science Department University of Bologna Italy Concurrent and located synchronizations in π-calculus.
A Platform-based Design Flow for Kahn Process Networks Abhijit Davare Qi Zhu December 10, 2004.
A Local Facility Location Algorithm Supervisor: Assaf Schuster Denis Krivitski Technion – Israel Institute of Technology.
1 Formal Engineering of Reliable Software LASER 2004 school Tutorial, Lecture1 Natasha Sharygina Carnegie Mellon University.
February 17, 2015Applied Discrete Mathematics Week 3: Algorithms 1 Double Summations Table 2 in 4 th Edition: Section th Edition: Section th.
Feng Lu Chuan Heng Foh, Jianfei Cai and Liang- Tien Chia Information Theory, ISIT IEEE International Symposium on LT Codes Decoding: Design.
Comparison of methods for supervisory control and submodule construction 1 Gregor v. Bochmann, University of Ottawa Comparison of methods for supervisory.
ECE 720T5 Winter 2014 Cyber-Physical Systems Rodolfo Pellizzoni.
A Framework for Distributed Model Predictive Control
CS143 Review: Normalization Theory Q: Is it a good table design? We can start with an ER diagram or with a large relation that contain a sample of the.
Dina Workshop Analysing Properties of Hybrid Systems Rafael Wisniewski Aalborg University.
1 Sequential Machine Theory Prof. K. J. Hintz Department of Electrical and Computer Engineering Lecture 1 Adaptation to this.
Design Concepts By Deepika Chaudhary.
Lyra – A service-oriented and component-based method for the development of communicating systems (by Sari Leppänen, Nokia/NRC) Traditionally, the design,
CS 367: Model-Based Reasoning Lecture 5 (01/29/2002) Gautam Biswas.
1 CD5560 FABER Formal Languages, Automata and Models of Computation Lecture 3 Mälardalen University 2010.
A Framework on Synchronization Verification in System-Level Design Thanyapat Sakunkonchak Satoshi Komatsu Masahiro Fujita Fujita Laboratory University.
Inferring Finite Automata from queries and counter-examples Eggert Jón Magnússon.
1 CSEP590 – Model Checking and Automated Verification Lecture outline for August 6, 2003.
Control Synthesis and Reconfiguration for Hybrid Systems October 2001 Sherif Abdelwahed ISIS Vanderbilt University.
1 CS 552/652 Speech Recognition with Hidden Markov Models Winter 2011 Oregon Health & Science University Center for Spoken Language Understanding John-Paul.
Lecture 5 1 CSP tools for verification of Sec Prot Overview of the lecture The Casper interface Refinement checking and FDR Model checking Theorem proving.
Architecture View Models A model is a complete, simplified description of a system from a particular perspective or viewpoint. There is no single view.
Chapter 8 Asynchronous System Model by Mikhail Nesterenko “Distributed Algorithms” by Nancy A. Lynch.
Software Quality and Safety Pascal Mbayiha.  software engineering  large, complex systems  functionality, changing requirements  development difficult.
Copyright 1999, 2003, 2008 G.v. Bochmann 1 Course Notes on Formal Methods for the Development of Distributed Real-Time Applications Gregor v. Bochmann.
/ PSWLAB Thread Modular Model Checking by Cormac Flanagan and Shaz Qadeer (published in Spin’03) Hong,Shin Thread Modular Model.
98 Nondeterministic Automata vs Deterministic Automata We learned that NFA is a convenient model for showing the relationships among regular grammars,
Computacion Inteligente Least-Square Methods for System Identification.
Diagnostic Information for Control-Flow Analysis of Workflow Graphs (aka Free-Choice Workflow Nets) Cédric Favre(1,2), Hagen Völzer(1), Peter Müller(2)
Abstractions Eric Feron. Outline Principles of abstraction Motivating example Abstracting variables Abstracting functions Abstracting operators Recommended.
Complexity Relief Techniques for Model Checking METU, Aug SOFTWARE VERIFICATION WORKSHOP Hüsnü Yenigün Sabanci University Informatics Institute,
Control of Dynamic Discrete-Event Systems Lenko Grigorov Master’s Thesis, QU supervisor: Dr. Karen Rudie.
Application of Design Patterns to Geometric Decompositions V. Balaji, Thomas L. Clune, Robert W. Numrich and Brice T. Womack.
SS 2017 Software Verification Timed Automata
Abstraction and Refinement for Large Scale Model Checking
LPV: a new technique, based on linear programming, to formally prove or disprove safety properties J-L Lambert, valiosys.
As the last CC-list represents Maximum Compatible Classes we conclude:
Modeling Arithmetic, Computation, and Languages
Automatic Verification
FORMAL LANGUAGES AND AUTOMATA THEORY
Lecture on Linear Algebra
High-Level Abstraction of Concurrent Finite Automata
Presentation transcript:

Interacting Discrete Event Systems: Modelling, Verification, and Supervisory Control Sherif S. Abdelwahed February 4, 2002

Introduction Practical systems are usually composed of a set of interacting components Components interaction define the system architecture The state space of the composite system grows exponentially with the number of components Direct approaches to DES analysis requires exhaustive search of the system state space Problem Study the relation between the systems architecture and its behaviour Utilize architectural information to new analysis procedures where the composition complexity can be avoided or reduced Focus on the verification and supervisory control problems Proposed approach

System Environment Modeling Multiprocess Systems System components: The set of elementary processes of the system. Usually given or obtained by decomposition. The environment: The composition rule for the components. Usually assumed to be the synchronous product. The architecture: The way the components interact and communicate; An abstract specification of the system components. Main dimensions Interaction Specification component

Elements of Process Space A multiprocess environment defined formally by: Index set a set I defining a collection of processes Alphabet vector A set of alphabets  = {  i | i  I } Composition rule synchronous product Process space Main sets: set of all language vectors L(  ) (Models) set of languages L(  ) (behaviours) Main operations: Decomposition operation (projection) P  : L(  )  L(  ) : L  {P i (L ) | i  I} Composition rule (sync. product) B  : L(  )  L(  ) : L  || L i Basic elements language vector L = {L i | i  I} Events all events:  =  i  I  i sync. events  s async. events  a Basic sets and operations Language vectors Languages composition decomposition

Behavioral Analysis of Multiprocess Systems Problem Compare a multiprocess system to a (flat) specification Issues Different structures Conversion has to be made Behaviour comparison multiprocess system specification  ? (flat) system Composition approach Works directly without further adjustment Computationally inefficient; state explosion problem Struc. specification Decomposition approach Decomposition may be more efficient for relatively small size specifications (typical) Does not work directly due to:  Decomposed structure is not in general behaviourally equivalent to the specification  Existence of redundant information in the system components that does not contribute to its behaviour

Model Adjustments Do not contain any redundant information in their components so that P  B  (L) = L Redundant information in the components can be removed by tracing shared behaviour Compact language vectors A non-compact language vector L = {L 1,L 2 } ab c d x xy y L2L2 L1L1 In general, due to information lost in projections L  B  P  (L) Lost information can recovered by using a compensator K such that L = B  P  (L)  K The set of compensators for L is not empty and has a supremal element C  (L) = L  [B  P  (L) ] c Language compensation L P 1 (L) P 2 (L) P 3 (L) PP L compensator +

Interacting Discrete Event Systems A language vector can only represent a set of parallel processes A more structured model is needed to represent different forms of interactions A general interacting discrete event system (IDES) can be represented as L = ( L, K) where L is a language vector and K is an interacting specification language The model Interaction specification, K L1L1 LnLn … L IDES I(  ) Languages L(  ) composition decomposition Decomposition   : L(  )  I(  ): L  (P  (L ),C  (L)) Composition B  : I(  )  L(  ): (L,K)  || L i  K Extended operations

Abstract Architectural Specifications Architectural specifications usually address each component as a whole rather than its internal details Layouts are special languages that can be used to describe architectural specifications. An event in a layout represent a set of events shared exactly by the same set of components Many standard operations can be represented by layouts K L1L1 LnLn x  1 -  2 1  21  2 uv x uv x x u v uv uv v u,v,x Sync productRefinementCatenationInterleaving  2 -  1

Multilevel Interaction Specifications Practical systems usually organized in a hierarchical scheme A multilevel process space can be formally represented by a set of alphabet impeded into a tree A multilevel IDES can then be defined where the interaction specification is distributed over a multilevel process space K 11 L1L1 L2L2 L3L3 K 21 K 12 L1L1 L2L2 L3L3 K A multilevel interaction specification can be converted to flat interaction specification. A flat interaction specification can be converted to a multilevel matching a given multilevel process space Two way conversion

Abstractions in Process Space Abstraction provides a simpler representation of the system that preserves its behaviour In IDES, the interaction spec. is an abstraction of the system An abstraction L` of a system L should retain enough information such that for a given property P L`  P  L  P If L` does not satisfy P it is then refined until a proper abstraction is found to confirm the test To be useful, it is necessary to compute abstraction efficiently An association between the abstraction and the system behaviour is required to compute the refinements Direct the system components are composed then abstracted Inefficient Association is direct Indirect abstraction of the system components are computed first and then composed usually more efficient association are difficult to preserve Direct and Indirect abstractions abstraction composition initial system final abstraction indirect direct

Automaton and Language Abstractions given as a state partition for each component can be represented as a homomorphism mapping between finite state structures mappings between the components and their abstractions directly translate to a map between the system and its abstraction components partitions translate to a system partition given as language morphisms that satisfy (    ) {  }  G(  )  ([  ]  ) * prefix preserving by definition can be represented by transducers (extension of mealy machines) The abstract mapping G is preserved under indirect computation if every shared event is mapped to itself Language-based abstractionsAutomaton-based abstractions a/{a,b} + b/{a,b} + x/{x} a b c d a,b c d xa/{a,b} + a,b

b2b2 a1a1 b2b2 a1a1 y z x b 1,z a1a1 y x 01,2 z x 0,12 b2b2 a2a2 y || y x a1a1 b2b z z a2a2 b2b y h1h1 h2h2 x b1b1 a1a1 a2a2 y z a1a1 a1a1 b1b1 b1b1 a2a2 a2a2 b2b2 b2b2 b2b2 x h 1 x h 2 A1A1 A2A2 B1B1 B2B2 B 1 || B 2 A 1 || A 2 Automaton-based Abstractions - Example

Deadlock Detection in Multiprocess Systems Deadlocks a deadlock state is a state in the composite system where no events are enabled deadlock originates from the nature of the synchronization mechanism Detect-first approach a deadlock state in the composite system corresponds to a set of local states with all eligible events are shared the sets of eligible events at local states are disjoint potential deadlock states can be identified locally once identified potential deadlock states are checked for reachability x o,y o aoao bobo bobo coco coco x1x1 x1x1 y2y2 y2y x 1,y 1 a1a1 b1b1 b1b1 c1c1 c1c1 x2x2 x2x2 yoyo yoyo x 2,y 2 a2a2 b2b2 b2b2 c2c2 c2c2 xoxo xoxo y1y1 y1y1 Potential blocking states (q 00, q 10, q 20 ) (q 03, q 13, q 23 ) Both unreachable System is deadlock free Reachability cost: 2 3 System size: 7 3 Milner scheduler (3 cyclers) c0c0 c1c1 c2c2

Livelock Detection in Multiprocess Systems Livelock a deadlock state is a state that is not deadlocked but cannot reach a terminal states livelock states must exist in a clique that does not contain a terminal state Detect-first approach a livelock clique in the composite system corresponds to a set of local clique that when composed - remains a clique - is reachable - has no terminal state a potential livelock clique set is a one satisfying any of these conditions potential livelock cliques can be identified locally only maximal local cliques need to be considered x y z a1a1 a1a1 b1b1 b1b x y z a2a2 a2a2 b2b2 b2b2 L1L1 L2L2 Potential blocking states (q 00, q 14 ), (q 04, q 10 ) Both unreachable - System is deadlock-free Reachability cost: 2 global states Potential livelock clique sets C 1 = {(q 00, q 01 ), (q 10, q 11 )} - terminal C 2 = {(q 00, q 01 ), Q 2 } - terminal C 3 = {Q 1,(q 10,q 11 )} – terminal C4 = {Q1,Q2} - terminal System is livelock-free Testing complexity: depends on testing order

Verification of Interacting Discrete Event Systems IDES verification problem given an IDES L = ( L, K) and a specification S, test if B  ( L )  S The specification S can be converted to an IDES S = ( S, R) and the problem will be to test if B  ( L )  B  ( S ) without computing the composition Modular solution In general, L  S  B  ( L )  B  ( S ) However, the other direction does not hold in general Therefore, if local testing fails the verification check cannot be confirmed Iterative verification if the local test fails, refine K and check again A solution is guaranteed when K reaches its minimal limit namely B  ( L ) if the number of possible refinements is finite, the iterative procedure is guaranteed to terminate Initial abstraction Local Testing interaction refinement terminate failure Analysis success fail genuine failure over approximation

Iterative Verification – Example xoxo aoao bobo bobo coco coco x1x1 x1x1 c0c x1x1 a1a1 b1b1 b1b1 c1c1 c1c1 x2x2 x2x2 c1c x2x2 a2a2 b2b2 b2b2 c2c2 c2c2 xoxo xoxo c2c2 K =  * IDES Specification aoao a1a1 a2a2 Initial abstraction K o = K =  * Local verification: fail Failure report: ( ,a1), ( ,a2) First refinement K 1 Local verification: fail Failure report: (,a1), (,a2)  Fourth refinement K 4 Local verification: OK … x1x1 x2x2 a1a1 a2a2 a1a1 a2a2 x1x1 x2x2 aoao xoxo

Supervisory Control of Multiprocess DES Multiprocess DES supervision given a multiprocess DES L and a specification S, design a supervision P such that B  ( L )  P  S Synthesis the supervisor without computing the composition B  ( L ) Forward synchronization a supremal non-blocking supervisor can be obtained by exploring only the behaviour common with S while synchronizing L and S a state (q, x ) in Q(L)  Q(s) is marked bad if 1. an uncontrollable event is eligible for q but not for x 2. (q, x ) cannot reach a terminal state 3. (q, x ) leads uncontrollably to bad state bad state identification is repeated until there no more bad states usually efficient for restrictive spec. Detect first approach the idea to isolate and then remove bad states a potential bad states is defined by conditions 1,3 control information can be suplied for a bad state without testing its reachability a bad state is tested for reachability only if it influences the status of another state can be efficient for permissive specifications

x y z a1a1 a1a1 b1b1 b1b b1b1 b2b2 b3b3 ’’ 0,0,01,1,11,2,12,1,22,2,24,2,2 3,1,12,1,12,2,1 1,1,21,2,2 4,1,14,2,1 3,2,1 4,1,2 3,1,23,2,2 4,4,44,4,2 a1a1 a2a2 a3a3 a1a1 a2a2 a3a3 a2a2 a2a2 b1b1 b2b2 b3b3 z x y a3a3 a1a1 a3a3 a1a1 b1b1 b1b1 b1b1 b1b1 b1b1 b1b1 L1L1 Supervisory Control of MDES - Example System Specification x y z a2a2 a2a2 b2b2 b2b2 L1L x y z a2a2 a2a2 b2b2 b2b2 L1L1 b1b1 Supervisor Red states are bad Forward sync. explores only 19 out of 65 global states Optimal supervisor is obtained in one iteration

Supervisory Control of Interacting DES IDES supervision problem given an IDES L = ( L, K) and an IDES specification S = ( S, R), design and IDES supervisor V = ( V, T) such that || (Vi/Li)  (K/T)  B  ( S ) synthesis the supervisor without computing the composition Modular solution we assume every language is prefix closed (no blocking) IDES supervision is always valid (will restrict the system to the spec) IDES supervision is optimal if: - every shared event is controllable - K is controllable w.r.t. B  ( L ) (can be guaranteed in some cases without computing B  ( L ) ) - R  K is controllable w.r.t K L1L1 L2L2 L3L3 V1V1 V1V1 V2V2 V3V3 K T IDES supervision structure

x fa1 x fa2 ma r1ar2a op1aop2a op3a op4a r3a r4a Process A fb1 x fb2 mb r1br2b op1bop2b op3b op4b r3br4b Process B  r2a op1a Spec A op2a Spec B op1a C  (S) r2a op1a op2a System Supervisory Control of IDES - Example Specification Sub A r2a r1a op1a op2a fa1 fa 2 ma r3a r4a op3a op4a x x r2br1b op2b op1b x x Sub B C o  (S) IDES Supervisor

Conclusion Investigated the relation between the behaviour and structure of interacting discrete event systems: exploring the laws of architecture Proposed a general paradigm for interacting DES, that integrates the interaction specification in the modeling and analysis process Proposed several approaches for verification of multiprocess DES based on the IDES setting Proposed several approaches for verification of multiprocess DES based on the IDES setting All proposed procedures avoid the computation of the synch product of the system components; a major bottleneck in the analysis of IDES Extensions for real-time systems Extending the analysis procedures for multi-level systems Further investigation of the blocking problem, particularly for the IDES supervision problem Contributions Future Research