Emilia Villani, Paulo E. Miyagi and Robert Valette
Modelling and Analysis of Hybrid Supervisory Systems A Petri Net Approach
123
Emilia Villani, PhD Instituto Tecnológico de Aeronáutica Divisão de Engenharia MecânicaAeronáutica 12228-900 São José dos Campos (SP) Brazil
Paulo E. Miyagi, DrEng, LDoc University of São Paulo Escola Politécnica 05508-030 São Paulo (SP) Brazil
Robert Valette, PhD Laboratoire Analyse et Architecture des Systèmes (LAAS) CNRS 31077 Toulouse Cedex 4 France
British Library Cataloguing in Publication Data Villani, Emilia Modelling and analysis of hybrid supervisory systems : a petri net approach. - (Advances in industrial control) 1. Automatic control 2. Automatic control - Mathematical models 3. System analysis 4. Automatic control - Case studies 5. Petri nets I. Title II. Miyagi, Paulo Eigi III. Valette, Robert 629.8’0151135 ISBN-13: 9781846286506 Library of Congress Control Number: 2006938338 Advances in Industrial Control series ISSN 1430-9491 ISBN 978-1-84628-650-6 e-ISBN 978-1-84628-651-3
Printed on acid-free paper
© Springer-Verlag London Limited 2007 Apart from any fair dealing for the purposes of research or private study, or criticism or review, as permitted under the Copyright, Designs and Patents Act 1988, this publication may only be reproduced, stored or transmitted, in any form or by any means, with the prior permission in writing of the publishers, or in the case of reprographic reproduction in accordance with the terms of licences issued by the Copyright Licensing Agency. Enquiries concerning reproduction outside those terms should be sent to the publishers. The use of registered names, trademarks, etc. in this publication does not imply, even in the absence of a specific statement, that such names are exempt from the relevant laws and regulations and therefore free for general use. The publisher makes no representation, express or implied, with regard to the accuracy of the information contained in this book and cannot accept any legal responsibility or liability for any errors or omissions that may be made. 9 87654 321 Springer Science+Business Media springer.com
Advances in Industrial Control Series Editors Professor Michael J. Grimble, Professor of Industrial Systems and Director Professor Michael A. Johnson, Professor (Emeritus) of Control Systems and Deputy Director Industrial Control Centre Department of Electronic and Electrical Engineering University of Strathclyde Graham Hills Building 50 George Street Glasgow G1 1QE United Kingdom
Series Advisory Board Professor E.F. Camacho Escuela Superior de Ingenieros Universidad de Sevilla Camino de los Descobrimientos s/n 41092 Sevilla Spain Professor S. Engell Lehrstuhl für Anlagensteuerungstechnik Fachbereich Chemietechnik Universität Dortmund 44221 Dortmund Germany Professor G. Goodwin Department of Electrical and Computer Engineering The University of Newcastle Callaghan NSW 2308 Australia Professor T.J. Harris Department of Chemical Engineering Queen’s University Kingston, Ontario K7L 3N6 Canada Professor T.H. Lee Department of Electrical Engineering National University of Singapore 4 Engineering Drive 3 Singapore 117576
Professor Emeritus O.P. Malik Department of Electrical and Computer Engineering University of Calgary 2500, University Drive, NW Calgary Alberta T2N 1N4 Canada Professor K.-F. Man Electronic Engineering Department City University of Hong Kong Tat Chee Avenue Kowloon Hong Kong Professor G. Olsson Department of Industrial Electrical Engineering and Automation Lund Institute of Technology Box 118 S-221 00 Lund Sweden Professor A. Ray Pennsylvania State University Department of Mechanical Engineering 0329 Reber Building University Park PA 16802 USA Professor D.E. Seborg Chemical Engineering 3335 Engineering II University of California Santa Barbara Santa Barbara CA 93106 USA Doctor K.K. Tan Department of Electrical Engineering National University of Singapore 4 Engineering Drive 3 Singapore 117576 Professor Ikuo Yamamoto Kyushu University Graduate School Marine Technology Research and Development Program MARITEC, Headquarters, JAMSTEC 2-15 Natsushima Yokosuka Kanagawa 237-0061 Japan
Series Editors’ Foreword
The series Advances in Industrial Control aims to report and encourage technology transfer in control engineering. The rapid development of control technology has an impact on all areas of the control discipline. New theory, new controllers, actuators, sensors, new industrial processes, computer methods, new applications, new philosophies}, new challenges. Much of this development work resides in industrial reports, feasibility study papers and the reports of advanced collaborative projects. The series offers an opportunity for researchers to present an extended exposition of such new work in all aspects of industrial control for wider and rapid dissemination. The existence of a “gap between theory and practice” is often discussed in control engineering presentations and papers. Actually, this gap goes back a long way as it was definitely a topic of discussion at control conferences in the early 1970s! However, the “gap” refers to the difference between the results of (some) theoretical methods and procedures and the actual progress made by engineered plant, products, devices and control systems. This gap is often illustrated by an example like “the lowest order of a µ-controller for a sixth-order plant model that could be achieved by order-reduction was 27”; clearly implementing a 27th-order controller could pose some practical problems, hence the theoryípractice gap. To retain a balanced perspective, it should be recognised that there has been a widespread adoption of some advanced control techniques, for example the use of model predictive control (MPC) methods in the process industries. It is also essential that a wide range of new methods is explored since we are never quite sure which method may make a significant contribution to tomorrow’s industrial control engineering paradigm. One of the key fascinations of industrial systems is that they can be very complex, comprised as they often are, of continuous-time processes, discrete-event systems, time- and process-dependent decision rules, information systems, control systems, external operational interfaces and operator interventions. It is a massive challenge for the control engineer to model this system complexity and then devise techniques to analyse the system and its supervisory control. Since the late 1980s, as a response to this complexity, the study of hybrid systems has emerged. In their simplest form, hybrid systems comprise continuous-time dynamics, discrete-event
viii
Series Editors’ Foreword
processes and the interaction between the two; however, in this volume in the Advances in Industrial Control monograph series, Dr. Emilia Villani seeks a much closer correspondence to industrial systems. Dr. Villani considers the industrial system to be a self-contained object or process controlled by a hybrid supervisory system or controller. This productive system structure is sufficiently general to accommodate internal discrete decision rules, external user interfaces and information system links. For this new conceptual framework of a productive system, Dr. Villani then proceeds to construct a modelling formalism based on Petri-net and differential-equation systems for the respective discrete-event and continuous-time-process aspects and uses the object-oriented paradigm to incorporate system complexity. The resulting hybrid-system-modelling tool, known as the object-oriented differential predicate transition (OO-DPT) net, is described in Chapter 2, and put to work in Chapter 3 to model an industrial process supervisor as a hybrid system. The strength of any new modelling tool is always tested when it is used to create new system models and analyse their properties. Thus, in Chapter 4 of Dr. Villani’s monograph, the model formalism is used to verify system reachability and safety properties. For this, a new analysis method comprising seven activity steps is presented and demonstrated. After four chapters of preparation, Dr. Villani then presents three fully worked-out industrial examples, a heating, ventilation and air conditioning (HVAC) system (Chapter 5), an aircraft landing system (Chapter 6) and a cane-sugar factory (Chapter 7). These carefully chosen examples represent a range of industrial processes having different combinations of continuous-time and discrete event features. For example, the aircraft landing system is discreteevent dominated. A chapter on possible future developments of this new modelling and analysis technique closes the monograph. To conclude, one way to narrow the theory-practice gap is to have better and more realistic industrial system representations that support useful synthesis and analysis tools. Dr. Villani’s monograph Modelling and Analysis of Hybrid Supervisory Systems makes a valuable contribution to this search as can be seen from the applications í three demanding technological systems being presented. The volume should be of considerable interest to industrial engineers and academic researchers alike and is a very welcome addition to the Advances in Industrial Control series. M.J. Grimble and M.A. Johnson Glasgow, Scotland, U.K.
Preface
This book presents a new approach for the development of hybrid supervisory systems. Application areas include process and basic industries, manufacturing industries, service industries, healthcare, telecommunication, transportation and logistics, among others. The term ‘hybrid’ refers to the dynamic behaviour of the supervisory system, which includes characteristics from both discrete event dynamic systems and continuous dynamic systems. The development of supervisory systems has been extensively treated in the literature. However, it has always been considered as a problem of the discrete event dynamic system domain exclusively. The main motivation for the study of hybrid supervisory system is the need for integrating and exchanging information among controllers and subsystems of different nature (discrete and continuous). From the hardware point of view, the rapid progress of information processing power and its commercial availability have allowed the development of complex supervisory systems. Among the characteristics of these systems is the need to integrate a large number of industrial and service processes, continuously monitor a number of variables and react to asynchronous events generated either by the controlled plant or by commands of users and upper level systems. Many barriers that restrained the evolution of supervisory system in the past were removed by the recent popularisation of the open system paradigm, which allows the connection of devices, technologies and communication networks of different suppliers. On the other hand, the software has not followed the hardware evolution. Nowadays, most solutions are proposed in an ad hoc way. Both the industrial and scientific community have pointed out the need for a generic approach that guides the development of hybrid supervisory systems. The research about hybrid systems is relatively new when compared with discrete event dynamic systems and continuous dynamic systems. With the exception of a few isolated works, hybrid systems began to be studied in the 1990s. Although many proposals have already been made, there is no consolidated approach for the systematic modelling and analysis of complex hybrid systems, which is the case of supervisory systems.
x
Preface
This book presents an approach to fill in this gap. The first chapter of the book is dedicated to describe this purpose in detail. It defines what hybrid supervisory systems are and presents the main phases of their development. Basically, the first phase of the supervisory system design is to elaborate a proposal and describe it using a mathematical formalism. For these purposes, this book introduces a formalism that merges Petri net, differential equation systems and the object-oriented paradigm. The use of Petri net and differential equations ensures flexibility to model both discrete and continuous dynamics. The objectoriented paradigm copes with the system complexity. This formalism is described in Chapter 2. However, due to the complexity of the problem, the elaboration of this proposal is not usually straightforward. In order to guide the designer and conduct the hybrid modelling, Chapter 3 describes a method that starts from the supervisory system requirements and results in a model of both the supervisory system and the controlled plant using the formalism presented in Chapter 2. The method is mainly based on UML (unified modelling language) diagrams, which is a well-known tool for both the academic and industrial community. Once the model of the supervisory system and the controlled plant has been elaborated, the next phase is the supervisory system validation. The main purpose of validation is to ensure that the controlled plant will behave as expected under any circumstances of the supervisory system operation. For this purpose, Chapter 4 presents a validation procedure that allows verifying the formal properties of the hybrid model. The approach introduced in Chapters 2, 3 and 4 is then applied to three examples. The first example is the HVAC (heating ventilation and airconditioning) management system of a hospital. This is described in Chapter 5. The second example is the supervisory landing system of a military aircraft currently used by several air forces. This is described in Chapter 6. The third and more complex example is the supervisory system of a cane sugar factory that was updated to improve its productivity. This is described in Chapter 7. The last chapter of this book, Chapter 8, presents the main limitations of the approach and describes the points that can be expanded or improved in future work. The book is directed to researchers, students, academic and industrial professionals that are interested in industrial automation, design of supervisory system, modelling and analysis of hybrid systems. The book aims at building a bridge between what is developed by academic researchers and what is available to the industrial professionals. From one point of view, it introduces a design procedure for supervisory systems based on formal techniques, allowing the verification of behavioural properties. The book also presents an approach that establishes a connection with UML, which is a standard in the industrial world. Finally, it is important to highlight that a particular emphasis is placed on applications and a large portion of the book is dedicated to describe the three real-world examples that illustrate different aspects of the presented approach.
Acknowledgements
The authors would like to thank the Laboratoire d’Analyse et d’Architecture de Systèmes of the Centre National de la Recherche Scientifique at Toulouse, France and the Escola Politecnica of University of São Paulo at São Paulo, Brazil, where this work has been developed. We also thank the Hospital das Clínicas da Faculdade de Medicina da Universidade de São Paulo (Clinical Hospital of the Medicine School of the University of São Paulo), Dassault Aviation and the Cruz Alta Cane Sugar Factory, from Açucar Guarani Company. They provide access to the information necessary for the development of the examples presented in this book. This research received financial support of the following Brazilian governmental agencies: Fundação de Amparo à Pesquisa do Estado de São Paulo (FAPESP), Coordenação de Aperfeiçoamento de Pessoal de Nível Superior (CAPES), and Conselho Nacional de Desenvolvimento Científico e Tecnológico (CNPq). Finally we would like to thank Mrs. Maria Cristina Vidal Borba and Mrs. Priscila Mayumi Hayama for English review, and Mr. Oliver Jackson from Springer-Verlag London Ltd at Guildford, UK, for editorial assistance.
Contents
Notation ................................................................................................................ xix 1 Introduction....................................................................................................... 1 1.1 Hybrid Systems.......................................................................................... 1 1.2 Productive Systems.................................................................................... 5 1.3 The Hierarchical Control of Productive Systems....................................... 8 1.4 The Development of Hybrid Supervisory Systems.................................. 10 2 Modelling of Hybrid Systems......................................................................... 13 2.1 The Choice of a Formalism...................................................................... 14 2.2 Introduction to the Petri Net .................................................................... 15 2.3 From the Petri Net to the Differential Predicate Transition Net .............. 18 2.4 Petri Nets and the Object-oriented Paradigm........................................... 21 2.5 The Object-oriented Differential Predicate Transition Net...................... 23 2.5.1 Modelling Classes and Objects..................................................... 23 2.5.2 Communication between Objects ................................................. 30 2.5.3 Communication with External Environment ................................ 35 2.5.4 Unfolding the OO-DPT net .......................................................... 36 2.6 Final Remarks.......................................................................................... 40 3 Development of the Supervisory System....................................................... 43 3.1 The UML Diagrams and the OO-DPT net............................................... 44 3.1.1 Step 1: Modelling the Flows of Material ...................................... 47 3.1.2 Step 2: Specification of the Use Case........................................... 49 3.1.3 Step 3: Building the Activity Diagrams........................................ 50 3.1.4 Step 4: Specification of Classes and Objects................................ 50 3.1.5 Step 5: Building Sequence and/or Collaboration Diagrams ......... 53 3.1.6 Step 6: Building the OO-DPT Net of the Classes and the Class Diagrams............................................................................. 55 3.1.7 Step 7: Verification of Consistency among Models ..................... 63 3.1.7.1 OO-DPT Net and Sequence (or Collaboration) Diagram .......................................................................... 63
xiv
Contents
3.2
3.3 3.4
3.1.7.2 OO-DPT Net and Activity Diagrams ............................. 64 OO Relationships Applied to OO-DPT net.............................................. 68 3.2.1 Composition/Decomposition Relationship ................................... 68 3.2.2 Generalisation/Specialisation Relationship .................................. 70 (Local Control System + Plant) versus Controlled Plant ......................... 71 Final Remarks.......................................................................................... 72
4 Hybrid System Analysis ................................................................................. 75 4.1 Formal Verification of Properties in Hybrid Systems.............................. 76 4.2 Petri Nets and Linear Logic ..................................................................... 77 4.2.1 Linear Logic versus Classical Logic............................................. 77 4.2.2 Reachability in Petri Nets and the Proof of Sequents in Linear Logic ................................................................................. 79 4.2.2.1 Forward Reasoning......................................................... 79 4.2.2.2 Backward Reasoning ...................................................... 80 4.2.3 Linear Logic for the Search of Scenarios in Petri Nets................. 82 4.2.4 Linear Logic and the Object-oriented Paradigm........................... 84 4.3 Analysis Method for OO-DPT Nets ........................................................ 86 4.3.1 Main Features of the Method........................................................ 87 4.3.1.1 Decomposition of the Analysis Process ......................... 87 4.3.1.2 Introduction of Hypothesis ............................................. 87 4.3.1.3 Use of Linear Logic........................................................ 87 4.3.2 Overview of the Analysis Method................................................ 88 4.3.3 Reachability Property ................................................................... 90 4.3.3.1 Step 1: Specification of the Property Statement ............. 90 4.3.3.2 Step 2: Specification of the Set of Restrictions .............. 92 4.3.3.3 Step 3: Building the Static Collaboration Diagrams....... 93 4.3.3.4 Step 4: Analysis of the First Object................................ 93 4.3.3.5 Step 4.1: Analysis of the Discrete Dynamics ................. 93 4.3.3.6 Step 4.2: Elaboration of Hypotheses .............................. 97 4.3.3.7 Step 4.3: Analysis of the Continuous Dynamics ............ 98 4.3.3.8 Step 5: Analysis of Other Objects ................................ 100 4.3.3.9 Step 5.1: Analysis of the Discrete Dynamics ............... 100 4.3.3.10 Steps 5.2 and 5.3: Elaboration of Hypotheses and Analysis of the Continuous Dynamics .......................... 102 4.3.3.11 Step 6: Building the Global Sequents........................... 103 4.3.3.12 Step 7: Verification of Hypotheses............................... 104 4.3.4 Safety Properties......................................................................... 104 4.3.4.1 Step 1: Specification of the Property Statement ........... 104 4.3.4.2 Step 2: Specification of the Set of Restrictions ............ 104 4.3.4.3 Step 3: Building the Static Collaboration Diagrams..... 105 4.3.4.4 Step 4: Analysis of the First Object.............................. 105 4.3.4.5 Step 4.1: Analysis of the Discrete Dynamics ............... 105 4.3.4.6 Steps 4.2 and 4.3: Elaboration of Hypotheses and Analysis of the Continuous Dynamics ......................... 107 4.3.4.7 Step 5: Analysis of Other Objects ................................ 109 4.3.4.8 Step 5.1: Analysis of the Discrete Dynamics ............... 109
Contents
4.4
xv
4.3.4.9 Steps 5.2 and 5.3: Elaboration of Hypotheses and Analysis of the Continuous Dynamics ......................... 110 4.3.4.10 Step 6: Building the Global Sequents........................... 111 4.3.4.11 Step 7: Verification of Hypotheses............................... 111 Final Remarks........................................................................................ 111
5 Application 1: HVAC System ...................................................................... 113 5.1 Description of the HVAC Systems ........................................................ 114 5.1.1 Controlled Object ....................................................................... 114 5.1.2 The Management System Requirements .................................... 114 5.2 Modelling the Supervisory System and the Controlled Object.............. 115 5.2.1 Step 1: Modelling the Flows of Material .................................... 115 5.2.2 Step 2: Specification of the Use Cases ....................................... 116 5.2.3 Step 3: Building the Activity Diagrams...................................... 116 5.2.4 Step 4: Specification of Classes and Objects.............................. 117 5.2.5 Step 5: Building Sequence and/or Collaboration Diagrams ....... 118 5.2.6 Step 6: Building the OO-DPT Net of the Classes and the Class Diagrams........................................................................... 119 5.2.7 Step 7: Verification of Consistency among Models ................... 131 5.2.7.1 OO-DPT Net and Sequence (or Collaboration) Diagram ........................................................................ 131 5.2.7.2 OO-DPT Net and Activity Diagrams ........................... 131 5.3 Analysis of the OO-DPT Net................................................................. 131 5.3.1 Property 1 ................................................................................... 132 5.3.1.1 Step 1: Specification of the Property Statement ........... 132 5.3.1.2 Step 2: Specification of the Set of Restrictions ............ 132 5.3.1.3 Step 3: Building the Static Collaboration Diagrams..... 133 5.3.1.4 Step 4.1: Analysis of the Discrete Dynamics (O1.20 - User Interface A)............................................... 133 5.3.1.5 Step 4.2: Elaboration of Hypotheses (O1.20 - User Interface A) ................................................................... 134 5.3.1.6 Step 4.3: Analysis of the Continuous Dynamics (O1.20 - User Interface A)............................................... 134 5.3.1.7 Step 5.1: Analysis of the Discrete Dynamics (O2.12 - Controller Interface A)....................................... 134 5.3.1.8 Step 5.2: Elaboration of Hypotheses (O2.12 - Controller Interface A)....................................... 134 5.3.1.9 Step 5.3: Analysis of the Continuous Dynamics (O2.12 - Controller Interface A)....................................... 135 5.3.1.10 Step 5.1: Analysis of the Discrete Dynamics (O1.7 - On/Off Controller A)............................................ 135 5.3.1.11 Step 6: Building the Global Sequents........................... 136 5.3.1.12 Step 7: Verification of Hypotheses............................... 136 5.3.2 Property 2 ................................................................................... 136 5.3.2.1 Steps 1 and 2: Specification of the Property Statement and of the Set of Restrictions........................................ 136 5.3.2.2 Step 3: Building the Static Collaboration Diagrams..... 137
xvi
Contents
5.4
5.3.2.3 Step 4.1: Analysis of the Discrete Dynamics (O1.20 - User Interface A)............................................... 138 5.3.2.4 Step 4.2: Elaboration of Hypotheses (O1.20 - User Interface A)............................................... 138 5.3.2.5 Step 4.3: Analysis of the Continuous Dynamics (O1.20 - User Interface A)............................................... 138 5.3.2.6 Step 5: Analysis of Object O2.12 – Controller Interface A..................................................................... 138 5.3.2.7 Step 5.1: Analysis of the Discrete Dynamics (O1.7 - On/Off Controller A)............................................ 138 5.3.2.8 Step 5.2: Elaboration of Hypotheses (O1.7 - On/Off Controller A)............................................ 138 5.3.2.9 Step 5.3: Analysis of the Continuous Dynamics (O1.7 - On/Off Controller A)............................................ 139 5.3.2.10 Step 5.1: Analysis of the Discrete Dynamics (O1.5 - Cooling Coil A) .................................................... 139 5.3.2.11 Step 5.2: Elaboration of Hypotheses (O1.5 - Cooling Coil A)............................................................................ 139 5.3.2.12 Step 5.3: Analysis of the Continuous Dynamics (O1.5 - Cooling Coil A) .................................................... 139 5.3.2.13 Step 5.1: Analysis of the Discrete Dynamics (O1.9 - Zone A) ............................................................... 140 5.3.2.14 Step 5.2: Elaboration of Hypotheses (O1.9 - Zone A)..... 141 5.3.2.15 Step 5.3: Analysis of the Continuous Dynamics (O1.9 - Zone A) ............................................................... 141 5.3.2.16 Step 6: Building the Global Sequents............................ 141 5.3.2.17 Step 7: Verification of Hypotheses ............................... 142 Final Remarks........................................................................................ 142
6 Application 2: Landing System.................................................................... 143 6.1 Description of the Landing System........................................................ 143 6.1.1 Controlled Object ....................................................................... 143 6.1.2 Requirements of the Supervisory System................................... 145 6.2 Modelling of the Supervisory System and the Controlled Object.......... 148 6.2.1 Classes and Objects .................................................................... 148 6.3 Analysis of the OO-DPT Net Models .................................................... 154 6.3.1 Property 1 ................................................................................... 154 6.3.1.1 Step 1: Specification of the Property Statement ........... 154 6.3.1.2 Step 2: Specification of the Set of Restrictions ............ 154 6.3.1.3 Step 3: Building the Static Collaboration Diagrams..... 154 6.3.1.4 Step 4.1: Analysis of the Discrete Dynamics (O1.9 – Door HC) ........................................................... 155 6.3.1.5 Step 4.2: Elaboration of Hypotheses (O1.9 – Door HC). 156 6.3.1.6 Step 4.3: Analysis of the Continuous Dynamics (O1.9 – Door HC) ........................................................... 156 6.3.1.7 Step 5.1: Analysis of the Discrete Dynamics (O1.8 – Close Door EV).................................................. 156
Contents xvii
6.4
6.3.1.8 Step 5.2: Elaboration of Hypotheses (O1.8 – Close Door EV) ....................................................................... 157 6.3.1.9 Step 5.3: Analysis of the Continuous Dynamics (O1.8 – Close Door EV).................................................. 158 6.3.1.10 Step 5.1: Analysis of the Discrete Dynamics (O1.7 – Open Door EV)................................................... 158 6.3.1.11 Step 5.2: Elaboration of Hypotheses (O1.7 – Open Door EV)........................................................................ 158 6.3.1.12 Step 5.3: Analysis of the Continuous Dynamics (O1.7 – Open Door EV)................................................... 159 6.3.1.13 Step 5.1: Analysis of the Discrete Dynamics (O2.12 – Close Door EC)................................................. 159 6.3.1.14 Step 5.2: Elaboration of Hypotheses (O2.12 – Close Door EC) ....................................................................... 160 6.3.1.15 Step 5.3: Analysis of the Continuous Dynamics (O2.12 – Close Door EC)................................................. 160 6.3.1.16 Step 5.1: Analysis of the Discrete Dynamics (O1.12 – Open Door EC) ................................................. 161 6.3.1.17 Step 5.2: Elaboration of Hypotheses (O1.12 – Open Door EC) ....................................................................... 161 6.3.1.18 Step 5.3: Analysis of the Continuous Dynamics (O1.12 – Open Door EC) ................................................. 161 6.3.1.19 Step 5.1: Analysis of the Discrete Dynamics (O1.19 – Door EV Interface) ............................................ 162 6.3.1.20 Step 5.2: Elaboration of Hypotheses (O1.19 – Door EV Interface).................................................................. 166 6.3.1.21 Step 5.3: Analysis of the Continuous Dynamics (O1.19 – Door EV Interface) ............................................ 166 6.3.1.22 Step 7: Verification of Hypotheses............................... 168 Final Remarks........................................................................................ 168
7 Application 3: Cane Sugar Factory............................................................. 171 7.1 Description of the Cane Sugar Factory .................................................. 171 7.1.1 Controlled Object ....................................................................... 171 7.1.2 Requirements of the Supervisory System................................... 172 7.2 Modelling of the Supervisory System and the Controlled Object.......... 174 7.2.1 Activity 1: Modelling the Flows of Material .............................. 174 7.2.1.1 Refinement of [Reception] ............................................ 174 7.2.1.2 Refinement of [Preparation] ......................................... 175 7.2.1.3 Refinement of [Extraction] ............................................ 176 7.2.1.4 Refinement of [Sulphitation] ......................................... 176 7.2.1.5 Refinement of [Lime Addition] ...................................... 178 7.2.1.6 Refinement of [Heating] ................................................ 178 7.2.1.7 Refinement of [Clarification] ......................................... 179 7.2.1.8 Refinement of [Evaporation] ......................................... 181 7.2.1.9 Refinement of [Crystallisation and Centrifugation] ........ 182 7.2.1.10 Refinement of [Drying and Packing] ............................. 183
xviii Contents
7.3
7.4
7.2.2 Examples of Classes and Objects ............................................... 185 Analysis of the OO-DPT Net Models .................................................... 190 7.3.1 Property 1 ................................................................................... 190 7.3.1.1 Step 1: Specification of the Property Statement ........... 190 7.3.1.2 Step 2: Specification of the Set of Restrictions ............ 190 7.3.1.3 Step 3: Building the Static Collaboration Diagrams..... 190 7.3.1.4 Step 4.1: Analysis of the Discrete Dynamics (O1.13 – Conveyor 1 - Chopper)..................................... 191 7.3.1.5 Step 4.2: Elaboration of Hypotheses (O1.13 – Conveyor 1 - Chopper)..................................................................... 191 7.3.1.6 Step 4.3: Analysis of the Continuous Dynamics (O1.13 – Conveyor 1 - Chopper)..................................... 191 7.3.1.7 Step 5.1: Analysis of the Discrete Dynamics (O1.76 – Chopper Interface) ........................................... 192 7.3.1.8 Step 5.2: Elaboration of Hypotheses (O1.76 – Chopper Interface)....................................................................... 193 7.3.1.9 Step 5.3 – Analysis of the Continuous Dynamics (O1.76 – Chopper Interface) ........................................... 194 7.3.1.10 Step 5.1: Analysis of the Discrete Dynamics (O1.74 – Table Interface)................................................. 194 7.3.1.11 Step 5.2: Elaboration of Hypotheses (O1.74 – Table Interface) ....................................................................... 195 7.3.1.12 Step 5.3: Analysis of the Continuous Dynamics (O1.74 – Table Interface)................................................. 195 7.3.1.13 Step 5.1: Analysis of the Discrete Dynamics (O1.7 – Table 1 and O2.7 – Table 2) ................................ 195 7.3.1.14 Step 5.2: Elaboration of Hypotheses (O1.7 – Table 1 and O2.7 – Table 2) ........................................................ 196 7.3.1.15 Step 5.3: Analysis of the Continuous Dynamics (O1.7 – Table 1 and O2.7 – Table 2) ................................ 196 7.3.1.16 Step 7: Verification of Hypotheses............................... 196 Final Remarks........................................................................................ 197
8 Conclusion and Research Topics................................................................. 199 A Complementary Data about Application 2: Landing System ................... 201 References ........................................................................................................... 213 Index .................................................................................................................... 217
Notation
The purpose of this preliminary section is to summarize the notation used in this book and acts as a reference for the reader throughout the chapters. General: x
Variables and equations are printed in Arial type. Examples are v, q, M = M0 – Pre.s + Pos.s.
x
The variable T models the time.
Petri net notation: x
x x
The following words are printed in Arial type when referring to Petri net elements: place, transition, token, arc and marking. This notation is also valid for predicate transition nets, differential predicate transition nets and other formalisms derived from Petri net. The name of transitions, places and other Petri net elements are also printed in Arial type. For Petri nets, predicate transition nets and differential predicate transition nets, the name of places and transitions are tx and px, respectively, where x is a integer number. Examples are p1, p2, t6 and t4.
OO-DPT net notation: x
The names of classes are printed in Arial type and in italics. The classes that compose the model of a system are also identified as Ci, where i is a integer number. Examples are C1 – Class A, C2 – Class B, C3 – Class C.
x
The names of objects are printed in Arial type and underlined. The objects that compose the model of a system are also identified as Ox.i, where x is a integer number and i indicates the class Ci that the object belongs to. Examples are: O1.1 – Object A, O2.1 – Object B and O1.3 – Object C.
xx
Notation
x x
x
Places and transitions are identified as tv_i and pw_i, respectively, where v and w are integer numbers, and i indicates the class Ci that the place or transition belongs to. Examples are p1_4, p2_1, t6_2 and t4_3. Junction functions, enabling functions and equation systems are identified as jv_x, ew_x and fz_x, respectively, where v, w and z are integer numbers, and i indicates the class Ci that the junction function, enabling function or equation system belongs to. The set of variables of a class Ci is named Xi, where i is an integer number. It is composed of the following sets of variables:
x
x x
x
Constant parameters of class Ci: Xco_i Internal variables of class Ci: Xint_i Public variables of class Ci: Xpb_i Image variables of class Ci: Xim_i External variables of class Ci: Xext_i
Each variable of Xim_i of a class Ci is associated with a variable of Xi called In, where i and n are integer numbers. In specifies the object from which the value of the variable must be read. The variable of Xim_i is called MIn.y, where y is an integer number that identifies the original class Cy of the variable and M is the name of the variable in Cy. The instance of the set of variables of a class Ci for an object Ox.i is named Xx.i. Similarly, the marking of an object Ox.i is named mx.i. Method calls between two objects are identified as tv_i o tw_In.y. It means that transition tv_i of class Ci calls a method provided by class Cy and associated to transition tw_y. In is a variable of Ci and indicates the identity of the object of class Ci that receives the method call. In the unfolded version of an OO-DPT net, transitions named as tv_x.i/w_z.y, where v, x, i, w, z and y are integer number, indicates the transition resulted from the fusion of transition tv_i of object Ox.i with transition tw_y of object Oz.y.
PFS (Production Flow Schema) notation: x x
The following words are printed in Arial type when referring to PFS (Production Flow Schema) elements: activity and arc. The names of the PFS activities are printed in Arial type and in square brackets. Examples are: [Activity 1], [Activity 2].
Analysis method notation: x x x
The abbreviation PRi, where i is an integer number, indicates a statement for specifiying reachability properties. The abbreviation PSi, where i is an integer number, indicates a statement for specifiying safety properties. The abbreviation Ri, where i is an integer number, indicates a statement for specifiying restrictions.
Notation
x x x
x
xxi
Properties are identified by integer numbers and are typed in Black. Examples: Property 1, Property 2. Restrictions are identified by a letter preceded by the integer number of the corresponding property. Example: Restriction 1A, Restriction 1B, Restriction 2A. Scenarios are identified by integer numbers and are typed in Black. Examples: Scenario 1, Scenario 2. When a scenario is decomposed into two or more scenarios, the new scenarios are named Scenario 1-i, where i is an integer number. This rule can be applied recursively. Examples: Scenario 1-2-1, Scenario 2-2-2. In the verification of safety properties, the name of scenarios may be followed by the letter c or p. The letter c indicates it is a concurrent scenario, while the letter p indicates it is a forbidden scenario. Examples: Scenario 1p, Scenario 1-2c, Scenario 2c.
1 Introduction
On December 11, 1999, the Brazilian satellite launch vehicle (VLS-1) was launched from Alcântara Launching Centre, Brazil. The VLS-1 was a four-stage rocket. The launching was divided into a sequence of four phases and the VLS-1 was programmed to release a set of motors and components (a stage) after the conclusion of each phase. The rocket was carrying the SACI-2 satellite and successfully completed its first flight phase. However, after 55.9 seconds, an explosion caused the irregular separation of the first stage motors and the premature release of the second stage. The remaining of VLS-1 continued to fly, but it followed an uncontrollable ballistic trajectory. After 189 seconds, the ground controllers commanded the destruction of VLS-1 and SACI-2 because they were entering a non-security area. The loss was of many million dollars. The VLS-1 accident illustrates the importance of a systematic design and system validation, particularly for complex systems. The main problem is how to specify and build a system that will behave as expected under any condition it might operate. This book investigates how this problem can be solved for a particular class of systems, the hybrid supervisory systems, which is for example the case of the VLS-1. The terms ‘hybrid’ and ‘supervisory’ have been used in the literature with different meanings. In order to clarify what the core of this book is and what kind of system is being treated, this chapter is dedicated to detailing the problem domain. We begin by describing what hybrid systems are. Next, the supervisory systems are described based on the definition of productive systems, information systems and control systems. Finally, the development of hybrid supervisory systems is introduced.
1.1 Hybrid Systems When designing a new system, it is advisable to build mathematical models that help understand the behaviour of the system before the system is actually built.
2
Modelling and Analysis of Hybrid Supervisory Systems
This book considers the case when these behavioural models are classified as hybrid. The term ‘hybrid’ refers to heterogeneity or, in other words, a heterogeneous nature. In this book, it refers to the heterogeneous nature of the variables that compose the behavioural models of the system. In the case of VLS-1, the model may comprehend the VLS-1 on-board control system, actuators and sensors, and the vehicle aerodynamics. Examples of variables are the VLS-1 attitude, deflection of actuators and flight phase. The variables of a model can be classified as either discrete or continuous (Alla and David, 2004). The discrete variables have their possible values taken from an enumerable set of values (e.g. integer numbers, Booleans, etc.). An example is the VLS-1 flight phase, which could be 1, 2, 3 or 4. Opposite them are the continuous variables. Their possible values form an interval of real numbers. An example is the VLS-1 attitude (position, orientation and velocity). As a result of this dichotomy, systems can be classified into continuous dynamic systems or discrete event dynamic systems (Ho, 1987). In continuous dynamic systems, the set of variables that models the system state changes continuously through time. They are therefore described as timedriven. This is a feature typical of systems that have their behaviour determined by physical laws such as Ohm law, Newton laws, etc. Continuous dynamic systems are usually modelled by differential equations. On the other hand, discrete event dynamic systems have state variables that are modified in a discrete way by the occurrence of instantaneous events. The time interval from the beginning to the end of an event is not relevant for the system dynamics when compared to the time intervals between events. Another important feature is the evolution of the state variables. They are constant between events and are modified in a discontinuous way by the occurrence of events. They therefore describe discrete event-driven states (Cassandras, 1993). Systems that behave according to rules and procedures defined by man (the socalled ‘man-made systems’) are usually classified as discrete event dynamic systems. Examples are manufacturing systems, communication networks, and transportation systems. Examples of instantaneous events are to switch on or off a machine or the arrival of a message. Examples of discrete states are ‘machine idle’ or ‘communication channel occupied’. In this context, hybrid systems are defined as those that have state variables of both discrete and continuous nature. The system behaviour is a function of time and discrete events. It is both event-driven and time-driven. In a hybrid system, subsystems that belong to the two classes presented before coexist simultaneously and interact. Fig. 1.1 illustrates the behaviour of state variables from a discrete event dynamic system, a continuous dynamic system and a hybrid system. The VLS-1 is an example of a hybrid system. In each phase, the VLS-1 aerodynamics is modelled by differential equation systems and is time-driven. On the other hand, the behaviour of the VLS-1 is also characterized by discrete events, such as the release of a stage and switching on the motors of the next stage. Examples of discrete states are the flight phases.
1 Introduction Instantaneous events
3
Discrete states
Value of the variable Continuous evolution with time
Time
Legend: Variable of a discrete event dynamic system Variable of a continuous dynamic system Variable of a hybrid system
Fig. 1.1. Behaviour of state variables of different nature
In a hybrid system, the discrete and continuous dynamics interact and influence each other. Examples of interaction are when: x
x x
Different continuous dynamics (different sets of differential equation systems), are associated with each discrete state (each possible value of a discrete variable). For the VLS-1, there is a different set of aerodynamic equations for each flight phase. A discrete event is triggered by continuous variables reaching some thresholds. In the VLS-1, the motors of a stage are released when the VLS1 reaches a certain altitude. A discrete event introduces discontinuities in continuous variables. In the VLS-1, the release of motors generates a discontinuity in the weight of the vehicle.
The research on hybrid systems has two origins that eventually converged to the same point: studies about continuous dynamic systems that started to incorporate discrete events and studies about discrete event dynamic systems that started to incorporate continuous variables (Alur et al., 2000), (Antsaklis et al., 2003). From the continuous dynamic systems point of view, hybrid systems began with the employment of computers in the control of continuous processes. One of the main motivations is the need to incorporate discontinuities into the continuous process models. In this case, the model must be composed of continuous variables and differential equation systems, but the value of the variables or equations may be modified in an abrupt way. The main sources of discontinuities are (Lennartson et al., 1996):
4
Modelling and Analysis of Hybrid Supervisory Systems
x
Discontinuities in the plant behaviour. An example of discontinuity in the plant is illustrated in Fig. 1.2. This is a fuel tank simplified model. When the level of the tank reaches the height of h1, the equation that models its level as a function of time is modified. Another example is when a nonlinear model is approximated by the switching of various linear models.
Equation system for hdh1 Fuel Tank
h2
S.D2.h °° Vol 12 ® dVol ° qout °¯ dt
Equation system for h>h1
D h1 qout
S.D2.h1 SD2 . h h1 °° Vol 12 4 ® ° dVol q out °¯ dt
Fig. 1.2. Example of discontinuity in the plant
x
x
x
Discontinuities in the plant output (measured variables). This kind of discontinuity is mainly caused by discrete sensors (micro switches, limit switches, reed switches, etc.) and discrete monitoring devices (light indicators, LED displays, bells, etc.). These discrete devices indicate thresholds and behavioural restrictions that must be considered by the process controller. Discontinuities in the plant inputs (command and actuator signals). This kind of discontinuity is the result of the action of discrete actuators (on/off valves, contactors, pumps, etc.) and discrete command devices (pushbottom buttons, selection keys, etc.). Discontinuities in the controller. This kind of discontinuity originates the division of the process into phases and the use of adaptive control strategies, which switch among a set of different continuous control laws. Each phase is considered as a discrete state and the switching among control laws is a discrete event.
At the same time as discontinuities were introduced into continuous models, processes that were conventionally classified as driven by discrete events required the modelling of time intervals associated with the duration of activities and permanence in discrete states. In some cases, the time interval can be modelled as a constant number. However, in other cases, it must be modelled as a function of system parameters and variables. An example is when the time for processing a batch in a chemical industry depends on the amount of product of the batch. In this case, the model must include a continuous variable that describes the amount of product of each batch and may also include equations to describe how the batch size varies during the process.
1 Introduction
5
As a result, continuous dynamics described by differential equation systems have been integrated into discrete event dynamic systems models, also converging to hybrid systems. Hybrid systems theory has been used for a number of applications. Among them, there are building management systems, industrial systems (particularly in the case of batch processes), energy supply systems, transportation systems, aerospace systems, and many others (Lemmon et al., 1999), (Champagnat et al., 2001), (Engell et al., 2004) . It is important to highlight that the classification as hybrid system, discrete event dynamic system or continuous dynamic system always refers to an abstraction of the real-world system. The same real-world system may be classified and modelled as belonging to more than one class. An example is a room with an on/off air conditioning unit. It can be modelled as a set of cause-effect rules such as ‘when the air conditioning unit is turned on, the room gets cool’ and ‘when the air conditioning unit is turned off, the room gets hot’, and in this case it is classified as a discrete event dynamic system. It can also be modelled as a set of differential equations that represent the temperature behaviour according to the heat exchanged through walls and windows when the air-conditioning unit is on, and in this case it is a continuous dynamic system. Finally, another model of the same real-world system may be composed of sets of equations that describe the temperature evolution for each state of the air-conditioning unit together with decision-making rules such as the automatic on or off switching of the air-conditioning unit according to the room temperature. In this case, it is a hybrid system. The choice of modelling a real-world system as hybrid, discrete or continuous depends on the objective of the modelling. It is basically related to the kind of questions that should be answered by analysing or simulating the models.
1.2 Productive Systems While the previous section presented a classification of systems based on the nature of the state variables modelling their behaviour, this section introduces another possible way of classifying systems, which is based on the nature, either abstract or concrete, of the entities manipulated by the system. In this context, a productive system is defined as a system that processes physical entities in order to produce goods or services. Examples of productive systems are not only manufacturing systems, but also building systems, transportation systems, among others. Opposite them, are the information systems, which only manipulate computational data and abstract information. Examples are communication networks and database systems. With the evolution of the technology and the increasing availability of computational resources, information systems began to be used in the monitoring and control of productive systems in order to guarantee efficiency requirements and system integrity. As a result, productive systems are composed of physical devices, machines and entities that exchange data with an information system. However, in this case, unlike in the case of other information systems, the data
6
Modelling and Analysis of Hybrid Supervisory Systems
exchanged are only an intermediary step, used as a means for achieving the final purpose of the productive system. It results in modifications in the state of the physical entities of the productive system. In order to distinguish the information systems that are part of productive systems from other information systems, they are simply called control systems. The physical entities, devices and machines manipulated by a control system are called the controlled object. From this point on, the term information systems only refers to the conventional information systems and does not include the particular class of information systems called control systems. Fig. 1.3 illustrates the concepts of information systems and productive systems. Fig. 1.4 classifies the interactions of the control system inside a productive system. Productive System Control System
Information System Data, abstract entities
Data exchange
Data, abstract entities Physical entities
Controlled Object
Physical entities
Fig. 1.3. Information systems and productive systems
Productive System
External systems, users
Command
Monitoring
Control System
Actuation
Controlled Object
Physical entities
Detection
Fig. 1.4. Interactions of the control system in a productive system
The VLS-1 is an example of productive system. The service produced by the system is the releasing of SACI-2 satellite in the desired orbit. The control system of the VLS-1 determines the deflection of the booster actuators according to the signals from IMU (inertial measurement unit) sensors. It also sends position information to the ground station and receives commands, such as the autodestruction command. The controlled object is the VLS-1 components. They interact with the external atmosphere. The distinction between information systems, productive systems and control systems is particularly important in the context of this book because the development of hybrid supervisory systems, a sub-set of control systems, is closely related to the development of information systems. Many concepts and techniques
1 Introduction
7
proposed by software engineering for the development of information systems can be used in the development of control systems. However, there are some differences between control systems and conventional information system that result in the need for adapting and considering new paradigms different from those adopted for conventional information systems. Some of the most important differences are:
x
x
As control systems may result in the modification of the state of physical entities, some operations cannot be simply undone, as it is usual in information systems, because the modification in the physical entity is generally not reversible. An example of irreversible task is the releasing of a stage of VLS-1. Once the stage is disconnected from VLS-1, it cannot be recovered. Furthermore, possible damages generated by a system failure may be catastrophic and eventually imply the loss of human lives. As a result, the validation of the behaviour of a productive system is a very critical point. Unlike data in an information system, the controlled object has its own dynamic behaviour, which usually includes controllable and uncontrollable events. The physical entities interact among themselves and may occasionally result in unanticipated situations. As a result, unlike the case of information system design, the behaviour of the controlled object must be taken into account during the design of control systems in order to avoid failures and dangerous states. In the example of VLS-1, it implies the modelling of actuators, sensors, VLS-1 aerodynamics and atmosphere characteristics. Without their dynamic models, it is impossible to guarantee the performance of the control system.
These differences emphasize the importance of breaking down the development of a control system into three phases. Briefly, in the first phase, the requirements of the control system and the specification of controlled object are used as the starting point for the proposal of a logical and conceptual structure of the control system. A validation model is then built describing the behaviour of both the control system proposal and the controlled object. The second phase is the validation of the control system proposal. Basically, validation means to ensure that the system requirements are effectively fulfilled. The approach used for the validation mainly depends on the language chosen for describing the productive system model. In the case of formal languages, validation can be carried out by formally verifying model properties related to the system requirements. In the third phase, the validated control system model is used as a basis for the refinement, coding and implementation of the control system, which will then interact with the real physical entities of the controlled object. The organization of the development of a control system into three phases is illustrated in Fig. 1.5.
8
Modelling and Analysis of Hybrid Supervisory Systems
Requirements of the Control System
Information about the Controlled Object
Phase 1 – Modelling
Model of the Control System
Model of the Controlled Object
Phase 2 – Analysis
Phase 3 VALIDATED Implementation Model of the Control System
Model of the Controlled Object
Control System
Real Entities of the Controlled Object
Fig. 1.5. Phases of the development of control systems
1.3 The Hierarchical Control of Productive Systems Productive systems generally include decision-making problems of different complexity and variety. The complexity of the decision-making is associated with its time horizon. It covers a whole set of levels from long-term strategic decisions to real-time operational ones. In the long-term strategic level, examples of decisions are the selection of products and equipment. These decisions affect the design or extensive modification of the plant, i.e., the physical entities of the productive system. They are taken under some assumptions on the long-term evolution of the market and considering the particular strategy of the company. In the medium term, the part types for immediate processing and their relative ratio, lot sizing, allocation of resources, etc. must be fixed to respond to market changes. In the short term, real-time decisions are related to commands that are sent to actuators according to the inputs received from sensors and to the scheduling specified at the upper level. As a consequence of the organization of decision-making into levels, the control of productive systems also has a hierarchical architecture composed of a set of layers. Each control layer has as inputs the outputs of its upper layer, produces a reference for its lower layer and has a characterized dynamic behaviour. A typical architecture is illustrated in Fig.1.6. It is composed of the following layers: local control, supervision, scheduling and planning (Silva et al., 1998). The pyramidal shape is related to the number of controllers used in each layer and the frequency of decision-makings. Briefly, the local control layer interacts directly with the physical entities of the plant through actuators and sensors. It is mainly composed of PLC (programmable logic controllers) and continuous controllers that implement control laws such as PID (proportional integral derivative) control. The supervision layer has two main purposes:
x x
It acts upon the local control devices in order to perform a set of tasks previously defined by the upper layer (scheduling). It monitors the behaviour of the plant in order to detect, diagnose and treat failures and faults.
1 Introduction
9
Planning Scheduling Supervision Local Control
Physical Plant
Fig. 1.6. Control layers in productive systems
In the case of the VLS-1, the local control system determines the VLS-1 attitude. The supervisory system sets the operational phases, monitors the VLS-1 components and sub-systems, handles possible faults and interfaces with the ground station. According to a predefined strategy, the scheduling layer determines the tasks of the productive system for a mid-term time horizon. Particularly, it is in charge of resource allocation. The planning layer makes decisions for a long-term horizon, and is also called tactical layer. As a general rule, local control and supervision layers can be classified as realtime systems while the scheduling layer is reactive and the planning layer is non reactive. In non-reactive systems, decisions are made at predefined moments of each time-horizon and their output is the production plan elaborated for the timehorizon. Data received from the lower layer usually do not result in immediate decision-making and will only be considered in the next production plan. In reactive systems, some decisions are made at predefined moments of each time-horizon but others are taken as a reaction to events from the lower layer. However, there may be a significant time interval between the event and the corresponding reactive decision. Information processing and decision-making are time consuming activities. In real-time systems, decision-making is synchronized with the arrival of information (event occurrences) from the lower layer. The time delay for the system reaction must be small when compared with the Plant dynamics. It is important to observe that the hierarchical structure presented in Fig. 1.6 is flexible in the sense that a productive system may include additional layers, or may not have one or more layers. It has also been adapted according to the evolution of industrial systems. New trends in industrial and service automation include the migration of typical functions of local controllers to sensors and actuators (the socalled smart sensors and actuators), lined with the migration of functions from the
10
Modelling and Analysis of Hybrid Supervisory Systems
supervision layer to the local control layer and from the scheduling layer to the supervision layer. The control system definition (Fig. 1.4) can be applied to the hierarchical organization of a productive system in a number of ways. In the most comprehensive view, the set of layers is a control system. Similarly, each layer can also be considered a control system, as well as the sub-systems within a layer. If the control system definition is applied to the local control layer, the controlled object is composed of the plant, and the upper layers are classified as external elements and not included as part of the productive system. On the other hand, when the supervision layer is regarded as the control system, the controlled object is composed of the plant and the local control layer. The same approach can be applied to other layers.
1.4 The Development of Hybrid Supervisory Systems In this book, a supervisory system is considered. It is the control system that performs the activities related to the supervision layer of a productive system (Fig. 1.7). Productive System
Upper layers, users
Command
Monitoring
Supervisory System (Control System)
Actuation
Detection
Local Controllers + Plant
Physical entities
(Controlled Object)
Fig. 1.7. Supervisory system as a control system
If the control system development phases of Fig. 1.5 are applied to the development of a supervisory system, a dynamic model of the productive system must be built including the supervisory system, the local controllers and the plant. This model is used to validate the supervisory system proposal. From the dynamics point of view, a supervisory system is classified either as a discrete event dynamic system or a hybrid system. It is usually not a continuous dynamic system because it stores discrete data about the local control subsystems such as whether or not the local controller is active, whether or not it is under failure. Discrete supervisory systems have been extensively treated in the literature (Ramadge and Wonham, 1987), (Moody and Antsaklis, 1998) (Silva et al., 1998). On the other hand, the development of hybrid supervisory systems is a relatively new problem. It is mainly motivated by the need of integrating and exchanging information of different nature among local control and plant subsystems.
1 Introduction
11
This book is therefore dedicated to describe a new approach for the development of hybrid supervisory systems, i.e., supervisory systems that require the elaboration of a hybrid model and its validation. The focus is on the first two phases of the development process: (1) how to elaborate a proposal for the supervisory system taking as a starting point the system requirements and (2) how to validate this proposal by verifying properties of the productive system hybrid model.
2 Modelling of Hybrid Systems
The purpose of this chapter is to discuss the modelling of hybrid systems and introduce a new modelling formalism called object-oriented differential predicate transition net, or simply OO-DPT net. This formalism is used in the modelling method presented in Chapter 3 and analysis method presented in Chapter 4. The modelling activity has a crucial role in the development of supervisory systems. The modelling formalism influences the way a problem is approached and how the solution is shaped. Once the modelling formalism has been chosen, it limits the available methods for analysis and fault detection. The new formalism presented in this chapter for the modelling of hybrid systems results from the application of the object-oriented (OO) paradigm to the differential predicate transition net. A differential predicate transition net defines an interface between differential equation systems and Petri nets. The former models the continuous dynamics of the hybrid system and the latter the discrete event-driven dynamics. The definition of differential predicate transition nets is based on predicate transition nets, which are high-level Petri nets. Both predicate transition nets and Petri nets are formalisms for discrete event dynamic system modelling. This chapter begins by justifying why differential predicate transition net was chosen as the starting point for the approach proposed here and why the OO paradigm is needed. Then, a brief introduction to Petri nets, predicate transition nets and differential predicate transition nets is presented. The idea of merging OO and Petri nets is not new. Many previous works have proposed the incorporation of OO paradigm into formalisms based on Petri nets. These works are briefly discussed. Their advantages and disadvantages are taken into consideration for the new hybrid system modelling formalism, the OO-DPT net (object-oriented differential predicate transition net).
14
Modelling and Analysis of Hybrid Supervisory Systems
2.1 The Choice of a Formalism Hybrid systems have been studied for more than a decade. In this time interval, a large number of hybrid system modelling formalisms have been proposed. A detailed review of all these formalisms is not presented. The references at the end of the book can be used for this purpose (Antsaklis and Koutsoukos, 2003), (Gueguen and Lefebvre, 2001), (Champagnat, 1998). Briefly, hybrid system modelling formalisms can be grouped into three classes. The first one comprises the extensions of continuous formalisms by the introduction of discrete variables, such as ordinary differential equations with Boolean variables. The second class comprehends discrete formalisms where new elements are introduced for representing the continuous dynamic, such as hybrid Petri net (Alla and David, 2004). It incorporates continuous places and transitions in order to model the dynamics of continuous flows. The third class of formalisms combine a continuous formalism, described by differential equation systems, with discrete ones, such as Petri nets or automata. Examples are hybrid automata and differential predicate transition nets. In both cases, an interface is defined for representing the interaction between continuous and discrete formalisms. Extensions of discrete formalisms tend to restrict the flexibility to model continuous dynamics. The opposite can also be stated about extensions of continuous formalisms. On the other hand, proposals that combine a continuous and a discrete formalism usually present a broader modelling power and flexibility, as compared to the first two classes (Gueguen and Lefebvre, 2001). Therefore, these are the only proposals considered for the purpose of this book. Among the approaches of this group, the formalisms derived from Petri nets are particularly considered because of their well-known advantages for representing process features such as concurrency, conflict, synchronisation and asynchronous behaviour. Basically, there are two proposals in the third class that adopt Petri nets to model the discrete dynamics, mixed Petri nets (Valentin-Roubinet, 2000) and differential predicate transition nets (Champagnat, 1998). However, neither formalism provides means for system decomposition or for a progressive modelling, making it difficult, if not impracticable, to model large complex systems. A possible solution to this problem is the introduction of OO paradigm into the one of the formalisms. The OO paradigm is presented and discussed in the beginning of Section 2.4. Basically, its main purpose is to structure the system decomposition and handle its complexity. Furthermore, the direct correspondence between the objects of the model and the real entities of the problem results in a great facility to modify, revise and maintain the models, improving model reuse. For this purpose, the differential predicate transition net is more suitable than the mixed Petri net, as it does not have global variables and the Petri net place capacity is not constrained to one token. In the next section, a brief introduction to Petri nets is presented. It is then followed by the description of predicate transition nets and differential predicate transition nets.
2 Modelling of Hybrid Systems
15
2.2 Introduction to the Petri Net The Petri net (Murata, 1989) is a modelling formalism proposed by Carl Adam Petri in 1962 for modelling distributed systems. It was rapidly recognized as a promising formalism, due to its adequacy to represent a number of features of discrete event dynamic system behaviour. A Petri net is a directed, weighted, bipartite graph with two kinds of nodes: places1 and transitions. The arcs of a Petri net can either connect a place to a transition or a transition to a place. They can never connect two places or two transitions. The places of Petri net contain a positive integer number of tokens. The distribution of tokens over the Petri net places is called marking. When the behaviour of a system is modelled as a Petri net, the marking indicates the state of the system. An example of a Petri net is presented in Fig. 2.1. It models the behaviour of a manufacturing process. The system is composed of two buffers (Buffer 1 and Buffer 2) and one machine (Machine 1). Each place is associated with a local state of the system. The tokens in place p1 represent the parts in Buffer 1. Similarly, the tokens in p3 represent parts in Buffer 2. Places p2 and p4 model the state of Machine 1. If there is a token in p2, the machine is processing one part. However, when Machine 1 is idle, there is a token in p4. The marking illustrated in Fig. 2.1 indicates that the system is currently with three parts in Buffer 1, one in Buffer 2 and one being processed by Machine 1. t1 p1
Parts in Buffer 1
t2 Machine 1 processing one part
p2
Machine 1 idle p4
t3 p3
Parts in Buffer 2 4
t4
Fig. 2.1. Petri net of a manufacturing system
Each transition of a Petri net is associated with an event of the system. In the case of the Petri net in Fig. 2.1, t1 represents the arrival of a new part in Buffer 1. Transition t2 is associated with the event of removing a part from Buffer 1 and beginning the process in Machine 1. Similarly, t3 models the moving from Machine
1
In this text, structural elements of Petri nets are printed in Arial type, such as place,
transition, token and arc.
16
Modelling and Analysis of Hybrid Supervisory Systems
1 to Buffer 2. Transition t4 dispatches a batch of 4 parts from the manufacturing system. The system behaviour is simulated by the firing of transitions. A transition firing corresponds to the occurrence of an event. In the same way as an event affects the system state, when a transition fires, it modifies the Petri net marking. A transition fires only if it is enabled. The enabling of a transition depends on the number of tokens in its input places and the weight of the corresponding input arcs. An input arc is an arc that starts in a place (an input place) and finishes in a transition. Similarly, an output arc is an arc that starts in a transition and finishes in a place (an output place). The weight of the arc is the number written beside it. Usually, when the weight is omitted from the graphical view, it is unitary. In Fig. 2.1, all the arcs weights are 1, with the exception of the arc from p3 to t4, which weighs 4. A transition is enabled if each input place has at least n tokens, where n is the weight of the corresponding input arc. If the transition is enabled, it may fire. When it fires, it removes tokens from the input places, and adds tokens to the output places. The number of tokens removed or added to each place is the weight of the arc that connects it to the transition. In the Petri net of Fig. 2.2 a) transition t1 and t3 are enabled. If transition t3 fires the new marking presented in Fig. 2.2 b) is reached and transition t1 and t2 are enabled. Other transitions may fire, simulating the system evolution. If the sequence t2, t3, t1, t2, t3 is fired, the marking of Fig. 2.2 c) is reached. As p4 has now 4 tokens, transition t4 is enabled and may fire, leading to the marking of Fig. 2.2 d). t1
t1
t1
t1
p1
p1
p1
p1
t2
t2
p2 p4
p2 p4
t4
a)
t3
p3 4
t4
b)
p4
t3
p3 4
p2 p4
t3
p3
t2 Firing of t4
p2
t3
4
t2
Firing of t2, t1, t3, t2, t3
Firing of t3
p3 4
t4
c)
t4
d)
Fig. 2.2. Petri net evolution
The formal definition of Petri net is: Definition – A Petri net is a pair N=<S, M0>, where: x
S is the Petri net structure defined by the 4-tuple
, where:
-
P = {p1, p2, p3, …, pm} is a finite set of places. T = {t1, t2, t3, …, tn} is a finite set of transitions. P T Ø, P T z Ø.
2 Modelling of Hybrid Systems
x
17
Pre: P x T o N defines the input arcs of transitions (N is the set of natural numbers). Pos: T x P o N defines the output arcs of transitions.
M0: P o N is the initial marking of the net.
Pre and Pos can be represented as matrices where lines correspond to places and columns to transitions. The value of one element of the matrix is the weight of the arc that connects the corresponding place and transition. If it is zero, there is no arc. An example is presented in Fig. 2.3. t1
Pr e
ª0 « «0 «0 « ¬«0
1 0 0º » 0 1 0» 0 0 4» » 1 0 0 ¼»
P os
ª1 «0 « «0 « «¬0
0 0 0º 1 0 0 »» 0 1 0» » 0 1 0 »¼
p1
t2 p2 p4 t3 p3 4 t4
Fig. 2.3. Pre and Pos matrices of a Petri net
The evolution of a Petri net can be computed by Petri net state equation: M = M0 – Pre.s + Pos.s M0 is the initial marking. s is a vector of dimension n, where n is the number of transitions in the Petri net. The value of s[i] is the number of firings of transition ti. M is the final marking. Fig. 2.4 applies the state equation to compute the final marking for the net of Fig 2.2 a) and the sequence of firings t3, t2, t1, t3, t2, t3, t4. M0 Pr e.s P os.s
M ª2º «0 » « » «0 » « » ¬« 1¼»
ª3 º ª0 « 1» « 0 « »« « 1» « 0 « » « ¬«0 ¼» ¬«0
1 0 0 1
0 1 0 0
0 º ª 1º ª 1 0 »» ««2»» ««0 . 4 » «3 » «0 » « » « 0 ¼» ¬« 1¼» ¬«0
0 1 0 0
0 0 1 1
Fig. 2.4. Petri net state equation
0 º ª 1º 0 »» ««2»» . 0 » «3 » » « » 0 ¼» ¬« 1¼»
18
Modelling and Analysis of Hybrid Supervisory Systems
2.3 From the Petri Net to the Differential Predicate Transition Net Petri nets have been successfully applied to a number of real world problems in many domains. However, two main disadvantages have restricted their application for large, complex systems. The first one is that Petri net is not adequate to model data manipulation. Even for simple problems, the net structure becomes too complex, such as a net for comparing two integer numbers. The second disadvantage is that there is no hierarchy in Petri net and it is not possible to build the model of a large system as a composition of sub-models. Looking for a solution to these problems, many researchers proposed extensions of the Petri net formalisms. These extensions are known as high-level Petri nets. Among them are the coloured Petri net and the predicate transition net. In coloured Petri nets, the description power is enhanced by associating colours to tokens, places and transitions. Each token has a colour that makes it possible to distinguish it from tokens that have other colours. Each place has a set of colours that determines the colours of the tokens allowed in the place. Each transition has a set of colours that are different ways of firing the transition. Each element of the Pre and Pos matrices is no longer an integer number, but becomes a matrix itself. This matrix determines the colours of the tokens removed and added by the transition for each transition colour (way of firing the transition). In coloured Petri nets (Jensen, 1997), transitions can be considered rules of a propositional logic system, which is a logic system without variables. predicate transition net (Genrich, 1987) introduces the concept of variable. Each transition has additional enabling conditions specified as logical formulas with variables. Transitions are rules of a first order logic system, which is a logic system with variables. A simplified definition of the predicate transition net is presented here. Definition – A predicate transition net is a 3-tuple NPT = <S, A, M0>, where: x x
S is the Petri net structure defined by the 4-tuple . A is the annotation of the NPT, defined by the 4-tuple A=<X, Ax, Ac, Aa>,
where: -
x
X is a set of variables. Ax associates a vector of X variables to each arc (as a simplification it is considered that the maximum arc weight is one). Ac associates an enabling condition to each transition. The enabling condition uses the Ax variables of the transition input arcs. Aa associates an action to each transition. The action defines the value of the Ax variables of the transition output arcs using the Ax variables of the transition input arcs.
M0 is the initial marking of the net. Each token is a vector of variables similar to the arc vectors. The initial marking defines the value of the token variables.
2 Modelling of Hybrid Systems
19
In a predicate transition net, a transition is enabled (or not) for a specific set of tokens in its input places. If the arc variables are replaced by the values of the token variables and the enabling condition is true, then the transition is enabled. When enabled, a transition may fire. The transition action defines the values of the variables of the output arcs. These are the same values of the tokens generated in the output places by the transition firing. An example is presented in Fig. 2.5. The predicate transition net models the process of selecting a new piece to be stored in a box. The pieces available have different sizes, as well as the boxes. When the box arrives at the beginning of the process it already contains a piece. The new piece must be stored in the remaining space. The boxes available are represented by tokens in p2.The variable d is the size of the box, while r is the size of the piece that is already in the box at the beginning of the process. By firing transition t1, the box receives a new piece. The pieces available are modelled as tokens in p1, while the variable v is the size of the piece. The variable q is the space available in the box after receiving the new piece. The variables of the predicate transition net are, therefore, X = {r, v, d, q}, the arc vectors are Ax(p1,t1) = , Ax(p2,t1) = , Ax(t1,p3) = . The condition of t1 is Ac(t1): v+r = <2> and = <3, 6>, but is not enabled for = <5> and = <3, 6> because the enabling condition is not true. Enabling condition: Ac(t1): v+r
<2> <5> p1
<5>
< 3, 6 >
p1
p2 < r, d >
p2 < r, d >
Firing of t1 t1
t1 < q, d > p3
< 1, 6 >
< q, d > p3
Fig. 2.5. Example of predicate transition net
The use of variables in the predicate transition net motivates its application for hybrid system modelling, resulting in the definition of the differential predicate transition net. On a predicate transition net, the token variables can be modified only by the firing of a transition. On the other hand, token variables of a differential predicate transition net can be continuously modified. The basic idea of the differential predicate transition net is that each place models a different system configuration. It is associated with a set of differential equation systems that describes the continuous evolution of the token variables while the token is in that place. The continuous evolution is a function of the time (T).
20
Modelling and Analysis of Hybrid Supervisory Systems
As for the predicate transition net, differential predicate transition net also has enabling conditions, called enabling functions. When a transition is enabled, it fires immediately. The firing of an enabled transition has priority over time evolution. Another element of the differential predicate transition net is the junction function. Junction functions are used to introduce discontinuities in the continuous variables and are similar to the actions of predicate transition net. The definition of differential predicate transition net is presented here. Definition – A differential predicate transition net is a 3-tuple NPT = <S, A, M0>, where: x x
S is the Petri net structure defined by the 4-tuple and the maximum arc weight of 1. A is the annotation of the NPT, defined by the 4-tuple A=<X, Ap, Ae, Aj, Af>, where:
-
-
x
X is a set of variables. Ap associates a vector Xpi of the X variables with each place pi. Ae associates an enabling function ei with each transition ti. The enabling function uses the variables of Ap of the transition input places. Aj associates a junction function ji with each transition ti. Af associates a differential equation system fi with each place pi. The variables of the differential equation system are the Ap variables of place pi.
M0 is the initial marking of the net. Each token is a vector of variables similar to the place vectors. The initial marking defines the value of the token variables at the time T=0.
An example of a differential predicate transition net is presented in Fig. 2.6. It models the process of filling bottles with water. The tokens in p1 model the bottles that are being filled. Each bottle must be filled with a specific amount of water, represented by the variable m. The variable v is the current weight of the bottle, which includes the glass weight (5) and the water weight (v-5). The rate of filling (1) is fixed and is the same for all bottles. The differential equation associated to p1 models the variation of the bottle weight. The tokens in p2 model the available taps for closing the bottles. The firing of transition t1 represents the closing of a bottle that has been filled with the correct amount of water (m). The weight of the bottle after the firing of t1 includes also the weight of the tap (2). If there is no tap available when the bottle reaches the specified amount of water, then transition t2 fires instead of t1.
2 Modelling of Hybrid Systems
< 5, 10 > < 7, 20 > Place variables: Xp1: Xp3: Equation systems: f1: dv/dt = 1 Enabling function: e1: m = v-5 e2: v>m+5 Junction function: j1: v = v+2
p1
< 15, 10 > < 17, 20 > p1
p2
21
< 17, 20 > p1
p2
Time(T) evolution
p2
Transition firing
t1
t2
t1
t2
p3
p4
p3
p4
t1
t2
p3
p4
< 17 >
a) T= 0
b) T= 10-
c) T= 10+
Fig. 2.6. Example of transition firing in a differential predicate transition net
A desired feature for the differential predicate transition net is to use the value of a variable as an input parameter for the equation system of another place. This feature implies the introduction of additional elements because there can be more than one token in each place. An example would be to use the variable v of p1 as an input parameter for the equation system of p2, such as f2: dr/dt=v, where r is the variable associated to p2. In this case, the token in p2 must specify which token in p1 is being considered for solving f2. As a consequence, each token must have an identity. Another desirable feature for the differential predicate transition net is modularity. In order to model large systems, it must be possible to build a model by composing a set of sub-nets with well defined interfaces and interaction mechanisms. These problems lead to the introduction of the OO paradigm to the differential predicate transition net. However, there are many possible ways of combining OO and differential predicate transition net. In order to analyse the advantages and disadvantages of each option, the next section presents the main concepts of the OO paradigm and discusses previous works that merge Petri nets and OO.
2.4 Petri Nets and the Object-oriented Paradigm The origins of the object-oriented paradigm dates back to the 60s’ when the concept of encapsulation was introduced, grouping data and operations into a single entity called object. Initially, the OO paradigm was used exclusively as a way of organizing and structuring computer programs. Lately in the 80s’, it begins to be used also for the conception and design of systems. The object-oriented paradigm states that a system is composed of a set of objects, which interact among themselves. An object is an entity that has attributes, behaviour, memory and identity (Booch, 1994), (Rumbaugh et al., 2004). The attributes represents the system data. The behaviour is composed of operations or methods. The memory, or state retention, means that the state of the object is not reinitialized each time it is accessed. The identity distinguishes an object from any other object of the system, even when they have the same attributes and behaviour.
22
Modelling and Analysis of Hybrid Supervisory Systems
Additionally to the concept of object, the pillars of the object-oriented paradigm include the concepts of encapsulation, classification and inheritance. Encapsulation states that an object is composed of a body (internal implementation) and an interface (represented by methods that allow other objects to act on its behaviour). The interface determines how the object may interact with other objects. The internal structure is hidden and guarantees that the external view of the object is independent from the internal implementation. The interface contains all the necessary information for starting a communication with the object. It is not necessary to know the details of internal implementation. The objects of a system are organized into classes. The classification groups objects that share the same attributes, operations, relationships and semantics into a single class. The objects of a class have the same behaviour and data structure. A class works as a model for the creation of new objects, which is called instantiation. Finally, inheritance provides the means for defining a class (frequently called child) starting from the definition of another class (frequently called parent). The child class automatically inherits all the methods and attributes of the parent class. The reuse provided by the inheritance is one of the main advantages of the object oriented paradigm. The combination of object-oriented paradigm and Petri nets is an extensively discussed issue in the literature. The works on this subject can be organized into three groups: x
x
x
‘Objects inside Petri nets’. The Petri net models a system from a global point of view. A token in the Petri net is an object. It is the instance of a class defined in an object-oriented programming language, such as C++, and has attributes and methods. When a transition fires, it executes a method of an object and changes the values of its attributes. It can also create new objects and destroy old ones. The HyNet (hybrid high-level Petri net) (Wieting, 1996) is an approach of this group that models hybrid systems. It is an extension of the THORN (timed hierarchical objectrelated net) (Köster et al., 2001), a high level Petri net for discrete event dynamic systems. ‘Petri net inside objects’. A system is composed of a collection of objects. A Petri net models the behaviour of each object. The Petri net marking shows the current state of the object. The methods provided by the object are associated with places. They compose the object interface and can be accessed by other objects. Following the OO paradigm, other places and transitions model the internal behaviour of the object and are encapsulated. If the object calls are statically defined, it is possible to build a global model of the system by merging all the object nets. The hybrid object net (Drath, 1998) is an example of this group for hybrid systems. An example for discrete event dynamic systems is the G-CPN (g-coloured Petri net) (Guerrero et al., 2001), which combines the coloured Petri net and the gnet. Mixed approaches. The third group combines the ideas of the first two. It creates a hierarchical structure inside the Petri net. The approaches in this
2 Modelling of Hybrid Systems
23
group aim at a complete integration of the object-oriented paradigm with Petri net, including features such as inheritance and polymorphism. From a global point of view, a system is modelled by the system net. A token in a system net is an object. The object behaviour is detailed in an object net. An example of object attribute is the marking of a place of the object net. The tokens in an object net can also be objects, and so on, creating a hierarchical organization. In this case, an object net is the system net from the point of view of its token (Valk, 1998). An approach that belongs to this group is the OPN (object Petri nets) (Lakos, 1995). The analysis of works in the three groups resulted in some important remarks that should be taken into account in the approach presented here concerning a new formalism merging OO and differential predicate transition nets. The first one regards the possibility of building a global model of the system. This is considered an important feature for simulation and analysis. When an inconsistency is detected during the model simulation, the visualisation of the global system behaviour helps the diagnosis. The second remark is about encapsulation. The definition of a formalism based on the OO paradigm should provide a clear definition of the object interfaces. Objects interact only through their interfaces, ensuring the integrity of the internal data and behaviour. Another important point is the definition of hierarchical structures. The use of sophisticated hierarchical mechanisms and rules, such as those used in the third group, may compromise the graphical meaning of the Petri net. They must be avoided unless their advantages compensate this strong drawback.
2.5 The Object-oriented Differential Predicate Transition Net The remarks presented at the end of the previous section were the starting point for incorporating OO into differential predicate transition net. The resulting modelling tool is called object-oriented differential predicate transition net, or, shortly, OODPT net. 2.5.1 Modelling Classes and Objects The class and object concepts are the basis of the object-oriented paradigm. Therefore, they are the starting point for the definition of the OO-DPT net. A system is modelled by an OO-DPT net, which is composed of a set of OO-DPT sub-nets. Each OO-DPT sub-net is associated with a class and models the behaviour of the objects of that class. The marking of the OO-DPT sub-net indicates the current state of the objects of that class. Definition 1: An OO-DPT net is composed of a set of OO-DPT sub-nets: NOO-DPT = {C1, C2, …, Cn}. The subscript n is the number of the classes that composes the system model.
24
Modelling and Analysis of Hybrid Supervisory Systems
Example – Mixing System: The system of Fig. 2.7 is used to illustrate the OO-DPT net. Basically, the system mixes two substances S1 and S2 in tank Tk1. The on/off valves V1 and V2 regulate the amount of S1 and S2 that is discharged into the tank. The controller L1 executes the following sequence of steps: fill tank Tk1 with S1 and S2, mix S1 and S2, and empty Tk1. The OO-DPT of this system is composed of three classes2: C1 – Valve, C2 – Tank and C3 – Controller. Each class is an OO-DPT sub-net. V2
V1 S1
S2
Tank Tk1
Controller L1
Fig. 2.7. Example of a mixing system
The definition of an OO-DPT sub-net is based on the definition of the differential predicate transition net. The variables of a class Ci models the class attributes. Definition 2: Each OO-DPT sub-net is composed of a 3-tuple, Ci = , where: x
Ni is a Petri net defined by the 4-tuple , where the arcs have unitary weight:
x
Ai is the annotation of Ci, Ai=<Xi, Api, Aei, Aji, AFi>:
-
-
2
Pi={p1_i, p2_i, p3_i, …, pm_i} is a finite set of places. Ti={t1_i, t2_i, t3_i, …, tn_i} is a finite set of transitions. Pi Ti Ø, Pi Ti z Ø. Prei: Pi x Ti o (0,1). Posi: Pi x Ti o (0,1).
Xi is a set of variables (see Definition 5). Api associates a sub-set Xpk_i of variables of Xi with each place pk_i
(see Definition 4). Aci associates an enabling function ek_i with each transition tk_i. The enabling function is a Boolean expression that has the variables of Xi as input parameters. Aji associates a junction function jk_i with each transition tk_i. The junction function determines the values of the variables of Xi after the transition firing, Xi(T+) = jk_i(Xi(T-)) (T+, T- are time instants immediately before and after the firing of transition tk_i).
Class names are written in italic and object names are underlined.
2 Modelling of Hybrid Systems
-
x
25
Afi associates with each place pk_i an equation system fk_i composed of a set of differential and/or algebraic equations. The variables of fk_i are the elements of Xpk_i, and the input parameters are the elements of Xi.
M0_i is the initial marking of the OO-DPT sub-net (see Definition 3).
Example – mixing system: Fig. 2.8, Fig. 2.9 and Fig. 2.10 present the sub-nets of classes C1, C2 and C3 of the mixing system (Fig.2.7). Class C1 – Valve has two discrete states: open and closed. The variable q models the valve flow. Class C2 – Tank has three discrete states: stand-by, mixing and emptying. The variables Vol, qI1.1 and qI2.1 model the volume in tank and the incoming flows of S1 and S2. I1 and I2 are related to the class interface and are explained latter on. Class C3 – Controller models the sequence of activities for processing a batch. ME1 is the total amount of product in a batch. VolS1 and VolS2 are the volume of substances S1 and S2 in the tank. KTM is the time the batch must be mixed and TM is the time it has been mixed. pcE2 is the percentage of substance S1 in the mixture. Variables qI2.1, qI3.1 and VolI1.2 are the incoming flows of S1 and S2 and the volume of product in the tank. E1, E2, I1, I2 and I3 are related to the C3 interface.
C1 - Valve t1_1 p1_1
p2_1 Open
Closed t2_1
Class variables: X1 = {q}; Place variables: Xp1_1 = ; Xp2_1 = ; Enabling functions: e1_1, e2_1: ; Junction functions: j1_1: q = 10; j2_1: q = 0; Equation systems: f1_1, f2_1: ;
Fig. 2.8. Model of class C1 – Valve
C2 - Tank t3_2 t4_2
t1_2 p1_2
p2_2
Stand-by
Mixing
t5_2
p3_2
Emptying
Class variables: X2 = {Vol, I1, I2, qI1.1, qI2.1}; Place variables: Xp1_2 = Vol; Xp2_2 = Vol; Xp3_2 = Vol; Enabling functions: e1_2, e2_2, e4_2, e5_2: ; e3_2: Vol = 0; Junction functions: j1_2, j2_2, j3_2, j4_2, j5_2: ; Equation systems: f1_2, f2_2: dVol/dt= qI1.1+ qI2.1 f3_2: dVol/dt= qI1.1+ qI2.1 - 20
t2_2
Fig. 2.9. Model of class C2 – Tank
26
Modelling and Analysis of Hybrid Supervisory Systems
C3 - Controller Class variables: Junction functions: X3 = {TM, KTM, VolS1, VolS2, E1, E2, I1, I2, I3, j1_3, j4_3, j5_3, j7_3, j8_3: ; ME1, pc E2, VolI1.2, qI2.1, qI3.1}; j2_3: VolS1 = 0; Place variables: j3_3: VolS2 = 0; Xp1_3 = Xp2_3 = Xp3_3 = Xp6_3 = Xp7_3 = Xp9_3 =; j6_3: TM = 0; Equation systems: Xp4_3 = VolS1; Xp5_3 = VolS2; Xp8_3 = TM; f 1_3, f 2_3, f 3_3, f 6_3, f 7_3, f 9_3: ; Enabling functions: f 4_3: dVolS1/dT= qI2.1 e1_3, e2_3, e4_3, e5_3: ; e4_3: VolS1 = ME1*pc E2; f 5_3: dVolS2/dT= qI3.1 e5_3: VolS2 = ME1*(1-pc E2); f 8_3: dTM/dT= 1 e7_3: TM = KTM; e8_3: VolI1.2 = 0; Filling with S1 p2_3
t2_3
p4_3
t4_3
p6_3
Stand-by p1_3
t6_3
t1_3
p3_3
Filling with S2 t3_3 p5_3 t5_3
Mixing p8_3
t7_3
Emptying t8_3 p9_3
p7_3
Fig. 2.10. Model of class C3 – Controller
Once the classes and OO-DPT subnets have been specified, the next step is to define the set of objects of each class and their initial states. The objects of a class Ci are named O1.i, O2.i, …, On.i, where n is the number of objects of class Ci in the system. From the discrete point of view, the state of an object Ow.i is represented by one or more tokens in the sub-net of its class (mw.i). From the continuous point of view, it is modelled by an instantiation Xw.i of the variables Xi. The marking of the OO-DPT sub-net of a class is therefore the composition of the sub-markings that model the state of each object of that class. Definition 3: The marking of an OO-DPT sub-net is composed of a set of submarkings, Mi = {O1.i, O2.i, ..., On.i} that models the state of the objects of the class Ci: x
Ow.i is composed of a 2-tuple Ow.i = <Xw.i, mw.i>, where:
-
Xw.i is an instance of the set of variables Xi of the sub-net. mw.i: P o (0,1) defines the tokens in the sub-net that models the
state of the object from a discrete point of view3. It is important to highlight that Definition 3 imposes that a place contains at most one token of each object. An object cannot have two tokens in the same place.
3
The marking of a place can be addressed in one of the following ways: a) Specifying the number of tokens of all the places in the net, such as: m1.3 = {0,0,0,0,1,1,0,0,0}. b) Specifying the places that have one token: m1.3 = {p5_3,p6_3}. c) Specifying the number of token in a place: p5_3 = 1; p6_3 = 1.
2 Modelling of Hybrid Systems
27
Example – mixing system: The mixing system of Fig. 2.7 is composed of objects O1.1 – V1 and O2.1 – V2 of class C1 – Valve, O1.2 – Tk1 of class C2 – Tank and O1.3 – L1 of class C3 – Controller. A possible marking for these objects is presented in Fig. 2.11. From the discrete point of view, the class markings are illustrated in Fig. 2.12.
O1.1 – V1 Instance of Variables: X1.1: q=0; Petri net marking: m1.1 = {1,0}; O2.1 – V2 Instance of Variables: X2.1: q=10; Petri net marking: m2.1 = {0,1}; O1.2 – Tk1 Instance of Variables: X1.2: Vol=20; I1 = 1; I2 = 2; qI1.1=0; qI2.1=10; Petri net marking: m1.2 = {1,0,0}; O1.3 – L1 Instance of Variables: X1.3: KTM=10; TM=0; VolS1=10; VolS2=10; E1=1; E2=2; I1=1; I2=1; I3=2; ME1=40; pcE2=0.25; VolI1.2=20; qI2.1=0; qI3.1=10; Petri net marking: m1.3 = {0,0,0,0,1,1,0,0,0};
Fig. 2.11. Sub-markings of the objects of the mixing system
C1 – Valve
t3_2
C2 – Tank
O1.1 – V1
t4_2
t1_1 p1_1
p2_1
O1.2 – Tk1
Open
Closed
t1_2
p1_2
p2_2
t5_2
p3_2
t2_1 O2.1 – V2 C3 – Controller p2_3
Mixing
Stand-by
Filling with S1 t2_3 t4_3 p4_3
p6_3 Mixing
Stand-by p1_3
Emptying
t2_2
t6_3
t1_3
p3_3
Filling with S2 t3_3 p5_3 t5_3
p8_3
Emptying t7_3
p9_3
t8_3
p7_3 O1.3 – L1
Fig. 2.12. Sub-markings of the objects of the mixing system
For each object Ow.i, only one place at a time defines the value of a variable of Xw.i. The initial sub-marking of Ow.i must be so that all the reachable sub-markings mw.i of Ow.i obeys the following restriction about the variables Xpk_i associated with each place pk of the class Ci.
28
Modelling and Analysis of Hybrid Supervisory Systems
Definition 4: If mw.i is a reachable sub-marking of an object Ow.i and {pa_i, pb_i} mw.i, then Xpa_i Xpb_i = . Example – mixing system: The possible sub-markings mw.i for the objects of the mixing system are illustrated in Fig. 2.13. All the sub-markings fulfil Definition 4. An example of inconsistent sub-marking for an object O2.2 of C2 would be m2.2 = {1, 1, 0}. This marking does not comply with Definition 4 because Xp1_2 Xp2_1 = {Vol}.
Objects O1.2
Objects O1.1 and O2.1
t4_2
t1_1 {1,0}
t1_2
{0,1} {1,0,0}
t2_1
{0,1,0}
t5_2
{0,0,1}
t2_2 t3_2
Object O1.3 t1_3 {1,0,0,0,0,0,0,0,0}
{0,1,1,0,0,0,0,0,0} t3_3
t4_3
{0,0,1,0,0,1,0,0,0}
t2_3
t3_3
{0,0,1,1,0,0,0,0,0} t4_3
t3_3 t2_3
t5_3 {0,0,0,0,0,1,1,0,0}
t5_3
{0,1,0,0,1,0,0,0,0}
{0,0,0,1,0,0,1,0,0} t5_3
{0,0,0,0,0,0,0,1,0}
{0,0,0,0,1,1,0,0,0}
{0,0,0,1,1,0,0,0,0}
t7_3
{0,1,0,0,0,0,1,0,0}
{0,0,0,0,0,0,0,0,1}
t4_3
t6_3
t2_3
t9_3
Fig. 2.13. Reachable markings for the objects of the mixing system
The set of variables of a class is composed of constant parameters (Xco_i), internal variables (Xint_i), public variables (Xpb_i), image variables (Xim_i) and external variables (Xext_i). The value of constant parameters does not vary during the object life-time. However, two objects of the same class can have different values for the same constant parameter. External variables have their value defined by entities not modelled in the OO-DPT net. They are input signals of the model and are discussed in Section 2.5.3. The difference among internal, public and image variables are related to the communication between objects. Two objects can exchange data by sharing variables. Basically, the instances of internal variables (Xint_w.i) of an object Ow.i can only be read and written by the object itself. On the other hand, instances of public variables (Xpb_w.i) can be read but not written by other objects. If a second object Ov.z reads the value of a variable M of Xpb_w.i, then M will be part of Xim_v.z (image variables of Ov.z). It means that M must be specified in the set Xpb_i of class Ci as well as in the set Xim_z of class Cz.
2 Modelling of Hybrid Systems
29
However, the specification of Xpb_i and Xim_z is not sufficient for implementing variable sharing. It is necessary to specify the identity of the object that has the instantiation of the variable to be read. In other words, the object Ov.z must store the information that M must be read from Ow.i and not from any other object of class Ci. This information is recorded in a variable of Xz, such as In and when the variable M is listed in Xim_z, it is named as MIn.i. Definitions 5, 6 and 7 are the result of the previous discussion. Definition 5: The set of variables Xi of a class is composed of Xi = Xco_i Xint_i Xpb_i Xim_i Xext_i, where (Xext_i Xco_i) (Xext_i Xint_i) (Xext_i Xpb_i) (Xext_i Xim_i) (Xco_i Xint_i) (Xco_i Xpb_i) (Xco_i Xim_i) (Xint_i Xpb_i) (Xint_i Xim_i) (Xpb_i Xim_i) = .
Definition 6: Each image variable of Xim_z of a class Cz is associated with a public variable of Xpb_i of a class Ci (i z or izz): x x x
Each variable of Xim_z is associated with a variable of Xz called In, where n is an integer number. In specifies the object from which the value of the variable must be read. The variable of Xim_z is called MIn.i, where M is the name of the variable in its original class (Ci).
Definition 7: The set of variables Xpk_i of each place must be defined over Xint_i Xpb_i. Example – mixing system: Fig. 2.14 presents the set of variables Xco_i, Xint_i, Xpb_i, Xim_i and Xext_i for each class of the mixing system. Considering the variable values defined in Fig. 2.11 for O1.1 – V1, O2.1 – V2, O1.2 – Tk1 and O1.3 – L1, Fig. 2.15 illustrates the sharing of variables among objects. C1 - Valve Xco_1 = ; Xint_1 = ; Xpb_1 = {q}; Xim_1 = ; Xext_1 = ; C2 - Tank Xco_2 = {I1, I2}; Xint_2 = ; Xpb_2 = {Vol}; Xim_2 = {qI1.1, qI2.1}; Xext_2 = ; C3 - Controller Xco_3 = {KTM, E1, E2, I1, I2, I3}; Xint_3 = {TM, VolS1, VolS2}; Xpb_3 = ; Xim_3 = {VolI1.2, qI2.1, qI3.1}; Xext_3 = {ME1, pcE2};
Fig. 2.14. Constant parameters, internal, public, image and external variables O1.1 - V2 q
O1.2 - Tk1 Vol qI1.1 qI2.1
O2.1 - V1 q
O1.3 - L1 VolI10.2 qI2.1 qI3.1
Fig. 2.15. Variable sharing for the mixing system
30
Modelling and Analysis of Hybrid Supervisory Systems
2.5.2 Communication between Objects In the OO-DPT nets, two kinds of communication are possible among objects. The first one is the sharing of variables, which has already been presented. This kind of communication is considered ‘continuous’ because one object is continuously reading the value of a public variable of another object and updating the value of its own image variable. The second kind of communication is through method calls. It is considered a discrete interaction and it is modelled by the dynamic fusion of transitions. The discrete interface of an object is composed of two sets of transitions: the methods provided by the class and the methods used by the class. In case an Ov.z calls a method of another object Ow.i, the two objects communicate through the fusion of two transitions. One of them is a transition ta_i from the provided interface of class Ci. The other is a transition tb_z from the used interface of class Cz. Definition 8: The interface provided by a class Ci is composed of: x x
A set of public variables Xpb_i (Definition 5). A set of transitions Tp_i, where Tp_i Ti.
Definition 9: The interface used by a class Ci is composed of: x x
A set of image variables Xim_i (Definitions 5 and 6). A set of transitions Tu_i, where Tu_i Ti and Tu_i Tp_i = .
As for the case of variable sharing, if an object Ov.z of class Cz calls the method ta_i of the class Ci, it must know which object of Ci will perform the method. A variable In of Cz stores this information and is associated with the method call. When both ta_i and tb_z are enabled, they fire as a single transition. Definition 10: Each transition of Tu_z of a class Cz is associated with a transition of Tp_i of a class Ci (i z or izz). x x
Each transition of Tu_z is associated with a variable of Xz called In, where n is an integer number. In specifies the object of class Ci that will perform the method requested.
The graphical view of OO-DPT net differentiates transitions of Tu_i and Tp_i from internal transitions. Transitions of Tu_i (methods used by the class) are represented as black-filled bars, while transitions of Tp_i (methods provided by the class) are white-filled bars. Example – mixing system: Fig. 2.16, Fig. 2.17 and Fig. 2.18 present the interface of class C1, C2 and C3 of the mixing system (other elements such as equation systems, enabling functions and junction functions are omitted from the figures). The first step of the batch process is to fill the tank with the two substances S1 and S2. For
2 Modelling of Hybrid Systems
31
this purpose, class C3 must call the method t1_1 - Open valve provided by class C1 for two different valves (identified by I2 and I3). These method calls are performed by t2_3 o t1_I2.1 and t3_3 o t1_I3.1. After filling the tank with the appropriated volume of S1 or S2, the two valves are closed by the method calls t4_3 o t2_I2.1 and t5_3 o t2_I3.1. The next step of the batch process is to turn on the mixer by calling method t6_3 o t1_I1.2. After the appropriate time, the mixer is turned off and the tank is emptied (method call t7_3 o t5_I1.2). C1 - Valve t1_1 p1_1
Interface variables: Xpb_1 = {q}; Xim_1 = ; Methods provided by the class: Tp_1 = {t1_1; t2_1}; t1_1 – Open valve t2_1 – Close valve Methods used by the class: Tu_1 = ;
p2_1
Closed
Open t2_1
Fig. 2.16. Interface of class C1 – Valve
C2 - Tank
t3_2 t4_2
t1_2 p1_2
t5_2
p2_2
p3_2
t2_2 Stand-by
Mixing
Emptying
Interface variables: Xpb_2 = {Vol}; Xim_2 = {qI1.1, qI2.1}; Methods provided by the class: Tp_2 = {t1_2; t2_2; t4_2; t5_2}; t1_2 – Start mixing t2_2 – Stop mixing t4_2 – Start emptying t5_2 – Stop mixing and start emptying Methods used by the class: Tu_2 = ;
Fig. 2.17. Interface of class C2 – Tank
C3 - Controller Interface variables: Methods used by the class: Xpb_3 = ; Tu_3 = {t2_3; t3_3; t4_3; t5_3; t6_3}; Xim_3 = {VolI1.2, qI2.1, qI3.1}; t2_3 o t1_I2.1– Open valve Methods provided by the class: t3_3 o t1_I3.1 – Open valve Tp_3 = ; t4_3 o t2_I2.1 – Close valve t5_3 o t2_I3.1 – Close valve t6_3 o t1_I1.2 – Start mixing t7_3 o t5_I1.2 – Stop mixing and start emptying Filling with S1 t2_3 t4_3 p2_3 p4_3 p6_3 Stand-by p1_3 t1_3
t6_3
p3_3
Filling with S2 t3_3 t5_3 p5_3
Mixing p8_3
p7_3
Fig. 2.18. Interface of class C3 – Controller
Emptying t7_3 p9_3
t8_3
32
Modelling and Analysis of Hybrid Supervisory Systems
A method call tb_z o ta_In.i is performed when both transitions are enabled for a pair of objects. Considering two objects Ov.z and Ow.i, tb_z is enabled in Cz if for Ov.z , mv.z contains the input places of tb_z and the enabling function of tb_z is true for Xv.z. Similarly, ta_i is enabled in Ci if mw.i contains the input places of ta_i and the enabling function of ta_i is true for Xw.i. An additional condition for the firing is that the value of In in Xv.z must be In = w. Example – mixing system: The mixing system is in the state indicated in Fig. 2.19 and Fig. 2.20, with the two valves opened (O1.1 – V1 and O2.1 – V2) and the controller (O1.3 – L1) indicating that the tank is being filled by S1 and S2. In this case, transition t2_1 is enabled for O1.1 and O2.1 in class C1. In class C2, t5_3 is not enabled because e5_3 is false for the values of VolS2, ME1 and pcE2 of O1.3. On the other hand, t4_3 is enabled because e4_3 is true. Variable I2 defines which object must perform the method t4_3 o t2_I2.1. In this case, I2=1, implying that t2_1 must fire using O1.1. As the additional condition for the method call is satisfied, both transitions t4_3 and t2_1 fire simultaneously as a single transition. The new state of the system is illustrated in Fig. 2.21 and Fig. 2.22. C1 - Valve t1_1
Closed p1_1
Open p2_1
t2_1
O1.1 – V1 q=10;
O2.1 – V2 q=10;
Class variables: Xpb_1 = {q}; Junction functions: j1_1: q = 10; j2_1: q = 0; Methods provided by the class: t1_1 – Open valve t2_1 – Close valve
Fig. 2.19. Mixing system before a method call – class C1
If the execution of the method can be considered a single discrete event, then it is modelled by a fusion of two transitions as illustrated before. However, a method may be composed of a sequence of events or continuous activities. In this case, it is modelled by two fusions of two pairs of transitions. The first fusion is the method call (or request). The second fusion is the answer (or the confirmation that the method has been completed). What happens between the two fusions is the method implementation and is not available to the other objects. A method composed of two fusions is performed in the same way that two independent method calls. An example is presented in Fig. 2.23. The only distinction between a method of two fusions and two independent methods is that, in the first case, the object that calls the method (O1.z) must wait for its answer without imposing any other condition for the second transition fusion. It means that transition t2_z is not in conflict with other transition and has no enabling function. This restriction simplifies the analysis procedures.
2 Modelling of Hybrid Systems
C3 - Controller Class variables: Xco_3 = {KTM, E1, E2, I1, I2, I3}; Xint_3 = {TM, VolS1, VolS2}; Xim_3 = {VolI1.2, qI2.1, qI3.1}; Xext_3 = {ME1, pcE2}; Place variables: Xp4_3 = VolS1; Xp5_3 = VolS2; Xp8_3 = TM; Enabling functions: e4_3: VolS1 = ME1*pcE2; e5_3: VolS2 = ME1*(1-pcE2); e7_3: TM = KTM; e8_3: VolI1.2 = 0; Junction functions: j2_3: VolS1 = 0; j3_3: VolS2 = 0; j6_3: TM = 0;
p2_3
Filling with S1 t2_3 t4_3 p4_3
Equation systems: f4_3: dVolS1/dT= qI2.1 f5_3: dVolS2/dT= qI3.1 f8_3: dTM/dT= 1 Methods used by the class: t2_3 o t1_I2.1– Open valve t3_3 o t1_I3.1 – Open valve t4_3 o t2_I2.1 – Close valve t5_3 o t2_I3.1 – Close valve t6_3 o t1_I1.2 – Start mixing t7_3 o t5_I1.2 – Stop mixing and start emptying
p6_3
Stand-by p1_3 t1_3
t6_3
p3_3
Filling with S2 t3_3 t5_3 p5_3
33
Mixing p8_3
Emptying t7_3 p9_3
t8_3
p7_3
O1.3 – L1 KTM=10; TM=0; VolS1=10; VolS2=10; E1=1; E2=2; I1=1; I2=1; I3=2; ME1=40; pcE2=0.25; VolI1.2=20; qI1.1=10; qI2.1=10;
Fig. 2.20. Mixing system before a method call – class C2
C1 - Valve t1_1
Closed p1_1
Open p2_1
t2_1 O1.1 – V1 q=0;
O2.1 – V2 q=10;
Class variables: Xpb_1 = {q}; Junction functions: j1_1: q = 10; j2_1: q = 0; Methods provided by the class: t1_1 – Open valve t2_1 – Close valve
Fig. 2.21. Mixing system after a method call – class C1
Another important point about method calls is the possibility of transmitting data. Following the previous definitions, an object accesses data of another object by sharing a variable in a continuous communication. However, when this shared variable is only used in a junction function, there is no need to constantly read its value. The value of the variable must be known only when the transition fires. In order to avoid unnecessary continuous communication, it is possible to transmit the value of a variable in a method call. When an object Ov.z calls a method of Ow.i, it can send the value of one or more public variables. The number of values to be transmitted is defined in the method signature.
34
Modelling and Analysis of Hybrid Supervisory Systems
C3 - Controller Class variables: Xco_3 = {KTM, E1, E2, I1, I2, I3}; Xint_3 = {TM, VolS1, VolS2}; Xim_3 = {VolI1.2, qI2.1, qI3.1}; Xext_3 = {ME1, pcE2}; Place variables: Xp4_3 = VolS1; Xp5_3 = VolS2; Xp8_3 = TM; Enabling functions: e4_3: VolS1 = ME1*pcE2; e5_3: VolS2 = ME1*(1-pcE2); e7_3: TM = KTM; e8_3: VolI1.2 = 0; Junction functions: j2_3: VolS1 = 0; j3_3: VolS2 = 0; j6_3: TM = 0;
p2_3
Equation systems: f4_3: dVolS1/dT= qI2.1 f5_3: dVolS2/dT= qI3.1 f8_3: dTM/dT= 1 Methods used by the class: t2_3 o t1_I2.1– Open valve t3_3 o t1_I3.1 – Open valve t4_3 o t2_I2.1 – Close valve t5_3 o t2_I3.1 – Close valve t6_3 o t1_I1.2 – Start mixing t7_3 o t5_I1.2 – Stop mixing and start emptying
Filling with S1 t2_3 t4_3 p4_3
p6_3
Stand-by p1_3 t1_3
t6_3
p3_3
Filling with S2 t3_3 t5_3 p5_3
Mixing p8_3
Emptying t7_3 p9_3
t8_3
p7_3
O1.3 – L1 KTM=10; TM=0; VolS1=10; VolS2=10; E1=1; E2=2; I1=1; I2=1; I3=1; ME1=40; pcE2=0.25; VolI1.2=20; qI1.1=0; qI2.1=10;
Fig. 2.22. Mixing system after a method call – class C2
Class Ci Methods provided by the class: t1_i – Example (call) t2_i – Example (answer) O1.i t1_i
p1_i
p2_i
t2_i
p3_i
t3_i
p4_i
t4_i
Class Cz Class variables: Xco_z = {I1};
p1_z
t1_z
Methods used by the class: t1_z o t1_I1.i– Example (call) t2_z o t4_I1.i – Example (answer) p2_z
t2_z
p3_z
t3_z
O1.z I1=1;
Fig. 2.23. Example of method call with two transition fusions
Definition 11: A signature is defined for each transition tb_z of Tu_z of a class Cz, it contains a sub-set of variables Xpb_z that are transmitted in the method call.
2 Modelling of Hybrid Systems
35
Definition 12: A signature is defined for each transition ta_i of Tp_i of a class Ci, it contains a sub-set of variables Xi that will receive the values transmitted in the method call. An example of method call with the data transmission is presented in Fig. 2.24. When the method provided by t1_i is called, the value of w is used to calculate the new value of variables x and y. Class Ci O1.i x =3; y=5 p1_i
t1_i
p2_i
O1.i x =2; y=4
Class Ci t2_i
t1_i
p1_i
p2_i
t2_i
Class variables: Xint_i = {x, y}; Methods provided by the class: t1_i {x, y} – Method 1
Class variables: Xint_i = {x, y}; Methods provided by the class: t1_i {x, y} – Method 1
Class C z
Class C z
p1_z
O1.z I1=1; w=2; t1_z
p2_z
t3_z
Class variables: Xco_z = {I1}; Xpb_z = {w}; Methods used by the class: t1_z o t1_I1.i {w, w+2} – Method 1
a) Before the firing of t1_z o t1_I1.i
p1_z
O1.z I1=1; w=2; t1_z
p2_z
t3_z
Class variables: Xco_z = {I1}; Xpb_z = {w}; Methods used by the class: t1_z o t1_I1.i {w, w+2} – Method 1
b) After the firing of t1_z o t1_I1.i
Fig. 2.24. Example of method call with the transmission of parameters
2.5.3 Communication with External Environment Differential predicate transition nets, as well as ordinary Petri nets and predicate transition nets, cannot represent the interaction among the modelled system and its environment. Anything that interferes in the system behaviour should be modelled as part of the Petri net – and therefore becomes part of the modelled system. However, when designing control systems, the explicit definition of the interface with external entities is a key issue. The external interface specifies the input signals that the control system receives from external entities. They make explicit how external entities interfere in the system behaviour. A typical example of external entity is the user of a system. The behaviour of a user is not known and therefore cannot be modelled. In the OO-DPT net, the interface with external entities is specified in a way similar to the interface with other objects. The value of a class variable may be set by an external entity and methods may be called by external entities. Definition 13: The interface of a class Ci with the external environment is composed of: x
A set of external variables Xext_i (Definitions 5 and 6).
36
Modelling and Analysis of Hybrid Supervisory Systems
x x
Each variable of Xext_i is associated with a variable of Xi called En, where n is an integer number. En specifies the input signal that sets the value of the variable. The variable of Xext_i is called MEn, where M is a generic name. A set of transitions Text_i that models the methods provided by the class to the external environment. Text_i Ti and (Text_i Tp_i) (Text_i Tu_i) = .
When simulating the OO-DPT net, the evolution of the external variables and the external methods calls must be defined. The simulation is performed considering a specific behaviour of the external environment. However, the same restriction is not imposed for the formal verification of behaviour properties. Some properties do not depend on the behaviour of external entities. Typically, safety properties cannot depend on the behaviour of the environment. The system has to be safe in any case. Example – mixing system: The objects of class C3 – Controller are the only ones that interact with external entities (Fig. 2.25). As for the methods provided by a class to another class, the transitions of Text_i are represented by white-filled bars. External entities determine the size of a batch (ME1) and the percentage of S1 in the mixture (pcE2). Furthermore, the class makes available an external method for starting the production of a batch. C3 - Controller Interface variables: External methods provided by the class: Text_3 = {t1_3}; Xext_3 = {ME1, pc E2}; t1_3 – Start a new batch Filling with S1 t2_3 t4_3 p2_3 p4_3 p6_3 Stand-by t1_3 p1_3
t6_3
p3_3
Filling with S2 t3_3 t5_3 p5_3
Mixing p8_3
Emptying t7_3 p9_3
t8_3
p7_3
Fig. 2.25. External interface of class C3 – Controller
2.5.4 Unfolding the OO-DPT net The fusion of transitions presented in the previous section is dynamic. As a consequence, the structure of the underlying global Petri net changes in time. The method provided by a class Ci can be called by more than one class. In this case, the transition of Ci will be fused with different transitions of different classes, though not at the same time. An example is transition t1_1 of C1 – Valve of the mixing system. This transition merges with both transitions t2_3 and t3_3 of C3 – Controller. A dynamic structure is a significant disadvantage because the Petri net analysis techniques cannot be used to analyse the discrete behaviour of OO-DPT nets. This problem can be avoided by building an unfolded version of the OO-DPT net that
2 Modelling of Hybrid Systems
37
has a static structure. The unfolding of an OO-DPT net depends on the set of objects that compose the system. If the number of objects in a class varies, the structure of the unfolded OO-DPT will also change. As a consequence, the number of objects in the system must not change in time. The underlying Petri net of each class must be bounded, i.e., the number of tokens in each place must not exceed a finite number in any reachable marking of the net. The unfolding of the OO-DPT net is organized in 4 steps. Step 1: The sub-net of a class Ci must be duplicated the number of times equal to the number of the object instances of Ci. The sub-marking of each object defines that of each sub-net. The transitions tk_i and places pk_i of the sub-net of an object Ow.i are renamed tk_w.i and pk_w.i. Example – mixing system: The only class in the mixing system that has more than one object is class C1 – Valve. The sub-net of this class is duplicated and the submarking of each object defines that of the corresponding sub-net (Fig. 2.26). All the sub-nets have their place and transition names changed in order to include the object name (Fig. 2.27 and Fig. 2.28). O1.1 – V1 q=0;
O2.1 – V2 q=10;
t1_1.1
p1_1.1 t2_1.1 Closed
t1_2.1
p1_2.1
p2_1.1
p2_2.1 t2_2.1
Closed
Open
Open
Fig. 2.26. Step 1 – Unfolding procedure – O1.1 and O2.1
O1.2 – Tk1 Vol=20; I1 = 1; I2 = 2; qI1.1=0; qI2.1=10; t3_1.2 t4_1.2
t1_1.2 p1_1.2
p2_1.2
t5_1.2
p3_1.2
t2_1.2 Stand-by
Mixing
Emptying
Fig. 2.27. Step 1 – Unfolding procedure – O1.2
38
Modelling and Analysis of Hybrid Supervisory Systems
O1.3 – L1 KTM=10; TM=0; VolS1=10; VolS2=10; E1=1; E2=2; I1=1; I2=1; I3=2; ME1=40; pcE2=0.25; VolI1.2=20; qI1.1=0; qI2.1=10; p2_1.3 Stand-by p1_1.3 t1_1.3
t2_1.3
t4_1.3
p4_1.3
p6_1.3 t6_1.3
Filling with S1 p3_1.3
Filling with S2 t3_1.3 p5_1.3 t5_1.3
Mixing p8_1.3
Emptying t7_1.3 p9_1.3
t8_1.3
p7_1.3
Fig. 2.28. Step 1 – Unfolding procedure – O1.3
Step 2: In the net of an object Ov.z, a transition tb_v.z associated with a method call (tb_v.z o ta_In.i) is duplicated the number of times of the objects that provide the method (number of objects of class Ci). Each transition is named tb_v.z/a_w.i, where ta_v.z is the transition of an object Ov.z that provides the method. Each transition tb_v.z/a_w.i has an enabling function In = w. In is the variable of Ov.z that carries the identity of the object that must perform the method. Example – mixing system: The only object in the mixing system that calls methods is O1.3 – L1. The net of this object is presented in Fig. 2.29.
O1.3 – L1 KTM=10; TM=0; VolS1=10; VolS2=10; E1=1; E2=2; I1=1; I2=1; I3=2; ME1=40; pcE2=0.25; VolI1.2=20; qI1.1=0; qI2.1=10;
p2_1.3
Stand by p1_1.3 t1_1.3 p3_1.3
t2_1.3/1_1.1 t4_1.3/2_1.1 Filling with S1 p4_1.3 p6_1.3
t2_1.3/1_2.1
t4_1.3/2_2.1
t3_1.3/1_1.1
t5_1.3/2_1.1 p5_1.3
Mixing p8_1.3
p7_1.3
t6_1.3/1_1.2
Emptying p9_1.3 t8_1.3 t7_1.3/5_1.2
Filling with S2 t3_1.3/1_2.1 t5_1.3/2_2.1
Fig. 2.29. Step 2 – Unfolding procedure – O1.3
Step 3: In the net of an object Ow.i, a transition ta_w.i associated with a method provided by the object is duplicated the number of times of the transitions of other objects that call the method. Each transition is named tb_v.z/a_w.i, where tb_v.z is the transition of an object Ov.z that calls the method. Methods that are not called by any object in the system are eliminated from the object sub-net. The model resulting
2 Modelling of Hybrid Systems
39
from this step has a static structure and the global net is obtained by fusing pair of transitions that have the same name. Example – mixing system: The objects that provide methods are O1.1 – V1, O2.1 – V2 and O1.2 – Tk1. The net of these objects are presented in Fig. 2.30 and Fig. 2.31. Transitions t2_1.2 and t4_1.2 are eliminated because no object calls the methods provided by them. O1.1 – V1 q=0;
O2.1 – V1 q=10;
t2_1.3/1_1.1
t2_1.3/1_2.1
t3_1.3/1_1.1 p1_1.1 Closed
t3_1.3/1_2.1 p1_2.1
p2_1.1 Open
p2_2.1 Open
Closed
t4_1.3/2_1.1
t4_1.3/2_2.1
t5_1.3/2_1.1
t5_1.3/2_2.1
Fig. 2.30. Step 3 – Unfolding procedure – O1.1 and O2.1 O1.2 – Tk1 Vol=20; I1 = 1; I2 = 2; qI1.1=0; qI2.1=10; t3_1.2 t4_1.2
t6_1.3/1_1.2 p1_1.2
p2_1.2
t7_1.3/5_1.2
p3_1.2
t2_1.2 Stand-by
Mixing
Emptying
Fig. 2.31. Step 3 – Unfolding procedure – O1.2
Step 4: The last step is a simplification of the model resulting from Step 3 for the cases where the variables In associated with the method calls are constant parameters with known values. Supposing that the original transition tb_v.z of an object Ov.z was duplicated in Step 2, resulting in transitions tb_v.z/a_w.i and tb_v.z/a_m.i. If the variable In associated with the method call is a constant parameter with initial value In=m, then transition tb_v.z/a_w.i is never enabled, and therefore can be eliminated from both Ov.z and Ow.i. The same happens if In=w; in this case, tb_v.z/a_w.i is eliminated. Example – mixing system: The variables I1, I2 and I3 of O1.3 are constant parameters. Their initial values are I1=1, I2=1 and I3=2. As a consequence, transitions t2_1.3/1_2.1, t4_1.3/2_2.1, t3_1.3/1_1.1 and t5_1.3/2_1.1 may be eliminated because their enabling function will never be true (e2_1.3/1_2.1, e4_1.3/2_2.1: I2=2; e3_1.3/1_1.1, e5_1.3/2_1.1: I3=1). The final models of O1.1, O2.1 and O1.3 are presented in Fig 2.32 and Fig. 2.33. The sub-net of O1.2 is not modified in Step 4.
40
Modelling and Analysis of Hybrid Supervisory Systems
O1.1 – V1 q=0; p1_1.1 Closed
t2_1.3/1_1.1
O2.1 – V2 q=10;
p2_1.1
p1_2.1
Open
Closed
t4_1.3/2_1.1
t3_1.3/1_2.1 p2_2.1 Open t5_1.3/2_2.1
Fig. 2.32. Step 4 – Unfolding procedure – O1.1 and O2.1 O1.3 – L1 KTM=10; TM=0; VolS1=10; VolS2=10; E1=1; E2=2; I1=1; I2=1; I3=2; ME1=40; pcE2=0.25; VolI1.2=20; qI1.1=0; qI2.1=10; p2_1.3 t2_1.3/1_1.1 p4_1.3 t4_1.3/2_1.1 p6_1.3 Stand-by p1_1.3 t1_1.3
Filling with S1
Mixing Emptying t6_1.3/1_1.2 p8_1.3 t7_1.3/5_1.2 p9_1.3
t8_1.3
Filling with S2 p3_1.3 t3_1.3/1_2.1 p5_1.3 t5_1.3/2_2.1 p7_1.3
Fig. 2.33. Step 4 – Unfolding procedure – O1.3
An important advantage of the simplification introduced in Step 4 is that if all the variables associated with method calls are constant parameters, then the dynamics of the system from a discrete point of view can be modelled by an ordinary Petri net (the underlying Petri net of the unfolded OO-DPT net). This feature is particularly interesting for analysis, as will be seen in Chapter 4.
2.6 Final Remarks This chapter introduced the OO-DPT net, which is the result of incorporating the OO paradigm into the differential predicate transition net. The OO-DPT net has a modular structure and provides flexibility to model complex discrete and continuous dynamics. The OO-DPT net of a large-scale system is easily built by decomposing it into classes and objects. When the number of objects in the system is constant and known, the OO-DPT net can be unfolded into a net with fixed structure. The resulting net is safe (1bounded, which means that a place has at most one token). In this case, it is possible to use formal techniques of ordinary Petri net for the system analysis. Although this is a desirable feature for an OO-DPT net, it is not mandatory. When required, an OO-DPT net may incorporate the dynamic instantiation of objects (creation of objects during simulation). The choice between having a constant number of objects and using dynamic instantiation is up to the person that is building the model. If dynamic instantiation is chosen, the OO-DPT net cannot be unfolded and the only way of analysing the system behaviour is by simulation.
2 Modelling of Hybrid Systems
41
When the OO-DPT net is used for modelling productive systems, all the signals exchanged between the control system and the controlled object are specified, defining the interface of the control software. Moreover, the organization of the OO-DPT into classes and objects defines the architecture of the control software.
3 Development of the Supervisory System
The purpose of this chapter is to present a systematic method for building a model of the supervisory system and its controlled object with the formalism described in Chapter 2, the OO-DPT net. According to the discussion presented in Chapter 1, hybrid supervisory systems are a special class of information systems and therefore their development is closely related to the design of general purpose software. Many concepts, methods and techniques of software engineering can be applied to the development of hybrid supervisory systems. However they should be adapted to the particular needs of hybrid supervisory systems. Among the problems to be tackled are specific topics of control engineering, such as how to understand and model the system that must be supervised, using the appropriate formalism, and how to define a control system that imposes the desired behaviour on the controlled object, taking as a starting point this model. In software engineering, many approaches have been proposed for the development process of information systems. Among the most significant ones are the incremental model (such as the rational unified process – RUP) (Jacobson et al., 1999) and the cascade model. These approaches can be applied to supervisory system development according to the complexity of the problem. According to Chapter 1, this book divides the development process in three phases. The purpose of the first phase is to obtain a model for validation of the supervisory system and its controlled object in an adequate formalism (in the case of this book the OODPT net). Then, in the second phase this model is validated by verifying behavioural properties and in the third phase it is implemented by translating the supervisory system model into a programming language and defining the hardware architecture. The focus of this chapter is on the first phase. The method presented in this chapter for building the OO-DPT net model of the hybrid supervisory system and its controlled object is based on the unified modelling language (UML) diagrams (Rumbaugh et al., 2004). The UML diagrams aim to support and document the gradual and systematic definition of the OO-DPT model. They focus on different
44
Modelling and Analysis of Hybrid Supervisory Systems
views of the system architecture, emphasizing the structural organization of the model into classes and objects, its functionalities or its dynamic behaviour. The next section details the method for obtaining the OO-DPT net model using the UML diagrams. Then Section 3.3 introduces the use of OO relationships, such as composition/decomposition and generalisation/specialisation, for building OODPT nets. Section 3.4 focuses on the interaction between the design of the supervisory system and the design of local control systems, as a way of increasing the productive system performance.
3.1 The UML Diagrams and the OO-DPT net Among the languages proposed to model object-oriented systems, UML has established itself as a standard not only among scientists and researchers but also in the industry. UML is the result of the combined efforts of many specialists in the object-oriented (OO) paradigm. Among the most important, there are Grady Booch (Booch method), Jim Rumbaugh (object modeling technique – OMT), Ivar Jacobson (object-oriented software engineering – OOSE) and David Harel (statecharts). Generally, UML can be described as a language that, starting with a set of basic elements and the possible kinds of relationship among these elements, defines a set of diagrams that has as a purpose the representation of different views of the same system. The basic elements are structural elements such as classes, interfaces and components, and elements related to the system behaviour, such as states, activities and interactions. The UML defines nine kinds of diagrams: class diagram, object diagram, use case diagram, interaction diagrams (collaboration diagram and sequence diagram), statechart diagram, activity diagram, component diagram and deployment diagram. Among them, the ones used in the modelling method presented in this chapter are: x
Use case diagram: it illustrates the interactions among the system under development and external actors for each possible use of the system. The use case diagram is particularly important as a first step in the organization and documentation of the system behaviour. Fig. 3.1 presents an example of use case diagram. Production Operator
external actors
Start yogurt production use cases Set off alarm
Maintenance Operator Clean yogurt machine
Fig. 3.1. Example of UML use case diagram
3 Development of the Supervisory System
x
45
Interaction diagrams: they indicate the interactions, i.e. the messages exchanged, among a set of objects for a specific scenario. A scenario is a sequence of activities and operations performed by the system as part of a use case. The interaction diagrams present a dynamic view of the system and can be divided in sequence diagram and collaboration diagram. The first one emphasizes the temporal order of the messages exchanged, and the second one emphasizes the messages sent and received by each object. An example of sequence diagrams is presented in Fig. 3.2. External actor Sequence of interactions among objects
Object 1
1: Request serv ice
Object 2
2:Request operation
Object 3
3: Request operation
4: Operation perf ormed
Fig. 3.2. Example of UML sequence diagram
x
Activity diagram: it describes the sequence of activities that can be performed by an object (or a set of objects). Differently from the statechart diagram, the activity diagram combines features from the Petri nets in order to specify behaviours such as concurrence, parallelism and synchronism. The activity diagram is illustrated in Fig. 3.3. Initial state Activity 1
Activity 2
OR connection: either Activity 2 OR Activity 3 is performed
Activity 3
AND connection: Activity 5 AND Activity 6 are performed
Activity 4 Activity 5
Activity 6 Synchronism: Activity 7 starts only after Activity 5 AND Activity 6 are finished
Activity 7 Final state
Fig. 3.3. Example of UML activity diagram
x
Class diagram: it shows the set of classes that composes the system and the relationship among these classes. It presents a static view of the system structure. The relationship used in this book are generalisation/
46
Modelling and Analysis of Hybrid Supervisory Systems
specialisation (described in Section 3.2.2), composition/decomposition (described in Section 3.2.1) and are illustrated in Fig. 3.4. Class 1 Generalisation/specialisation relationship
Class 2
Composition/decomposition relationship
Class 3
Class 4
Class 5
Fig. 3.4. Steps of the modelling method
For a detailed review about UML and its diagrams refer to the references at the end of the book (Rumbaugh et al., 2004), (Douglass, 2004). The modelling method of the first phase of the hybrid supervisory system development is organised into a set of steps. Some of the steps consist of building UML diagrams. Modifications are introduced into the UML diagrams in order to better model the continuous dynamics of the system behaviour. The steps of the proposed modelling method are presented in Fig. 3.5. It is important to highlight that although the steps are illustrated as a sequence, the modelling method is an interactive process, where the results obtained during a step may lead to the revision of the previous steps and so on until a satisfactory model of the system is obtained. The modelling method begins with the specification of the system that must be supervised (the controlled object). This is done by building a production flow schema (PFS) that illustrates the flows of material or physical entities through the system. The next step is to build the UML use case diagram, which specifies the supervisory system functionalities. Next, each use case is detailed into a UML activity diagram. Concurrently, the classes and objects that compose the supervisory system and the controlled object are defined. The UML sequence diagram and/or the UML collaboration diagram are built in order to explicit the communication among each object for each use case. Based on these diagrams, the set of class attributes and methods is determined. Each class is then modelled as an OO-DPT sub-net. Classes are organized in a UML class diagram. Restrictions about the initial state of the system objects must be specified. Finally, the last step is the verification of the consistency between the OO-DPT sub-nets and the UML diagrams. The steps of the modelling method are detailed and illustrated using the example of a production system.
3 Development of the Supervisory System
47
Step 1: Modelling the flows of material
Step 2: Specification of the use cases
Step 3: Building the activity diagrams
Step 4: Specification of classes and objects
Step 5: Building the sequence and/or collaboration diagrams
Step 6: Building the OO-DPT net of the classes and the class diagrams
Step 7: Verification of consistence between models
Fig. 3.5. Steps of the modelling method
Example: The system that must be supervised is composed of a production line that makes two products (P1 and P2). The products result from the mixing of a common base (B) with one of two colouring additives (C1 or C2). In order to produce P1, B is mixed with C1, and to produce P2, B is mixed with C2. The layout of the production line is presented in Fig. 3.6. It is composed of a set of tanks (T1, T2, T3), valves (VT2-1, VT2-2, VT3-2, VT3-2, VM1-1, VM1-2, VM2-1, VM2-2), two mixers (M1 and M2) and two local controllers (CM1, CM2). The outputs of the steps of the modelling method are presented in the next sections. 3.1.1 Step 1: Modelling the Flows of Material Step 1 specifies the boundaries of the controlled object by modelling the flow of materials through the productive system in production flow schemas (PFS).
48
Modelling and Analysis of Hybrid Supervisory Systems
Tank T1 (Base – B)
Tank T3 (Additive C2)
Tank T2 (Additive C1)
VT2-1
VM1-1
VM1-2
VT2-2
VT3-1
VM2-1
VT3-2
VM2-2
Mixer M1
Mixer M2
Controller CM1
Controller CM2
Fig. 3.6. Production system used as example
The PFS is a modelling technique for describing the processes of a productive system. It has originally been proposed for discrete event dynamic systems (Miyagi, 1988) and later extended to hybrid systems (Villani, 2000). Basically a PFS is composed of three elements: activities, inter-activities and arcs (Fig. 3.7). Activities are actions (steps of a process) performed on the flow of material. They can be either related with transformation of material or simply its transportation. Inter-activities do not transform or modify the flow of material, but can be used to model mixing and distribution points. They are a mandatory element between two activities. Arcs connect the activities and inter-activities indicating the flow of material through the system. Arc Inter-activity Activity 1 Activity 3 Activity 2
Fig. 3.7. PFS elements
The PFS allows the progressive refinement of its elements in order to support the modelling of complex systems. Each activity or inter-activity can be decomposed into a new PFS (Fig. 3.8). In addition to giving an abstract view of the material processing in the controlled object, the PFS also highlights closed loop dependences among the inputs and outputs of the activities. An example of closed loop would be when the input of Activity 1 is the output of Activity 2 and the input of Activity 2 is the output of Activity 1. This kind of dependence among the steps of a process may result in the closed loop sharing of continuous variables, which may turn the verification of behavioural properties difficult.
3 Development of the Supervisory System
49
Activity A
Activity A.2 Activity A.1 Activity A.3
Fig. 3.8. Progressive refinement of a PFS activity
Example: The PFS of the production line of Fig. 3.6 is presented in Fig. 3.9.
Storage of B in Tank T1
Storage of C1 in Tank T2
Mixing with C1 in M1
Mixing with C1 in M2 Storage of C2 in Tank T3
Emptying M1
Mixing with C2 in M1
Emptying M2
Mixing with C2 in M2
Fig. 3.9. PFS of the production line example
3.1.2 Step 2: Specification of the Use Case Step 2 consists of building the UML use case diagrams for the system (supervisory system + controlled object). The use case diagram presents an overview of the system functionalities by specifying the use cases and their actors. Actors are external elements, such as users, operators, a high-level control system, etc., that interact with the system in a use case. Example: In the production line of Fig. 3.6, the main functionality of the supervisory system is to manage the production of P1 and P2, taking as a starting point a production plan defined by a human operator. A production plan consists of making a certain number of batches of products P1 and P2. The use case diagram of the production line is presented in Fig. 3.10. It is important to observe that in the proposed modelling method the controlled object is part of the system that is being defined, not an actor or an external entity, as it is common practice in software engineering. The main motivation is that the purpose of the modelling method is not only to obtain a model of the supervisory system but also a model of the controlled object. Without the model of the controlled object it not possible to validate the supervisory system.
50
Modelling and Analysis of Hybrid Supervisory Systems
Operator
Supervisory System + Controlled Object Perform the production plan uses Make P1 uses Make P2
Fig. 3.10. Use case diagram of the production line example
3.1.3 Step 3: Building the Activity Diagrams Step 3 consists of building the UML activity diagrams for each of the use cases specified in Step 2. The activity diagram shows the sequence of activities performed by the system in order to accomplish a use case. It illustrates the parallelism, synchronism and concurrency among the use case activities. In this book a continuous activity is illustrated by a dashed-line rectangle, while a discrete one is illustrated by a solid-line rectangle. Example: In the production line of Fig. 3.6, the use case ‘Make P1’ is detailed by the activity diagram of Fig. 3.11. In order to make a batch of P1, the appropriate mixer (M1 or M2) is filled with base and additive by opening the correct valves. When the mixer has been filled, base and additive are mixed for a certain time and after that the mixer is emptied.
3.1.4 Step 4: Specification of Classes and Objects Step 4 consists of specifying the set of objects that composes the supervisory system and the controlled object. These objects are then organized into classes. As a general rule, when specifying the objects of the controlled object, the main candidates are the resources, components and equipment of the system. In the case of the supervisory system, some objects may be related to the objects of the controlled object. They perform the interface between the supervisory system and the controlled object, and store in the supervisory system the relevant data about resources, components and equipment of the system. They are particularly important when the same resource, component or equipment is shared among different processes of the productive system. Other candidates are objects related to the system functionalities, such as objects that perform production plans or supervise processes. They are particularly important when the functionality implies the interaction with more than one resource, component or equipment.
3 Development of the Supervisory System
51
Receive a request for producing P1
Open V T2-1 Production of a batch of P1 in M2 (similar to M 1)
Open VM1-2
Open VM1-2
Filling with Base Filling with Additive Close VM1-2
Close VM1-2
Close VT2-1
Mixing in M1
Emptying M1
Fig. 3.11. Activity diagram of ‘Make P1’ for the production line example
Another criterion that can be used for the specification of objects is their degree of interaction. Each object must have a strong internal cohesion and a weak connection with the other objects (Paludetto, 1991). In order to obtain a set of objects with an adequate level of interaction, three decomposition rules may be applied. The rules have a decreasing restriction degree. Each rule limits the kind of interaction that can exist among the objects. Initially the 1st rule is imposed and the set of the objects is specified. If these objects are too complex for modelling, then the 1st rule is replaced by the 2nd rule and some of the objects may be decomposed into two or more objects. If the complexity of the objects resulted from the 2nd rule is still great, the 3rd rule is applied. Next, the three decomposition rules are presented and applied to the production line example. x
1st Decomposition rule – The objects resulting from the decomposition of the system can have only discrete interaction among themselves, which means that the OO-DPT sub-nets will not share continuous variables.
Example: Considering the controlled object of the production line, all the system components (tanks, valves and mixers) have continuous interactions with other components, as they share the continuous flow of base or additive. The controllers
52
Modelling and Analysis of Hybrid Supervisory Systems
also interact in a continuous way with the valves. As a result no decomposition at all is possible for the controlled object if the 1st rule is applied. Grouping all the components in a single object would result in a too complex object. Therefore the 2nd rule must be applied. In the case of the supervisory system, the candidates are the objects that interface in a discrete way with the components of the controlled object: Interface VT2-1, Interface VT2-2, Interface VT3-1 and Interface VT3-2 (these valves are directly controlled by the supervisory system, while the others are controlled by CM1 and CM2), Interface CM1 and Interface CM2. Moreover, two objects can be associated with the production receipt of products P1 and P2: Receipt P1 and Receipt P2. Finally, the supervisory system must have objects to store and manage the execution of production orders. In the case of the production line, the maximum number of production orders in the system is 4, resulting in the following objects: Production Order 1, Production Order 2, Production Order 3 and Production Order 4. x
2nd Decomposition rule – The objects resulting from the decomposition can have continuous interactions among them but restricted to a limited time interval (a typical feature of batch systems) and not in closed loop.
Example: After applying the 2nd rule to the controlled object, the new candidates to object are the controllers CM1 and CM2, the mixers M1 and M2, and the tank T1. Controllers and mixers interact only during the filling and emptying activities. Tank T1 interacts with the valves VT1-1 and VT1-2 only during the activity of filling one of the mixers with the base. The other two tanks and the valves do not have an interaction limited to a time interval, as they may be open during an unlimited time interval, resulting in a continuous interaction among them and the corresponding tank. In order to decompose the remaining of the controlled object, the 3rd rule is applied. x
3rd Decomposition rule – The objects resulting from the decomposition can have continuous interactions not limited to a time interval, but cannot share continuous variables in closed loops of dependence.
The restriction imposed by the 3rd rule assures the minimum independence to an object. When a set of objects shares variables in a closed loop of dependence, it means that the equations that define the dynamics of each object of the loop must be merged with the equations of the other objects and the set of equations is solved as a single equation system. The evolutions of the objects are so closely related that no decomposing is possible. The sharing of variables among objects and its implications to the analysis of the OO-DPT net is discussed in Chapter 4. Example: After applying the 3rd rule to the remaining components of the controlled object, the following objects are specified: the tanks T2, T3, the mixers M1 and M2, and the valves VT2-1, VT2-2, VM1-1 and VM2-1. All the objects must be organized into classes. Objects with similar behaviour are in the same class.
3 Development of the Supervisory System
53
Example: The objects of the controlled object of the production line are organized in the following classes: C1 – Tank (objects T1, T2 and T3), C2 – Valve A (objects VT2-1, VT2-2, VT3-1, VT3-2, VM1-1 and VM2-1), C3 – Valve B (objects VM1-2 and VM2-2), C4 – Mixer (objects M1 and M2), C5 – Mixer Controller (objects CM1 and CM2). For the supervisory system the objects are organized in the following classes: C6 – Interface CM (objects Interface CM1 and Interface CM2), C7 – Interface Valve A (objects Interface VT2-1, Interface VT2-2, Interface VT3-1 and Interface VT3-2), C8 – Receipt (objects Receipt P1 and Receipt P2), C9 – Production Order (objects Production Order 1, Production Order 2, Production Order 3 and Production Order 4). 3.1.5 Step 5: Building Sequence and/or Collaboration Diagrams The activity diagram built in Step 3 models the system dynamics without indicating which object must perform each activity. Once the objects and classes of the system are known, the next step is to specify what interactions between objects are necessary to perform the activities of a use case. Two UML diagrams can be used for this purpose, the sequence diagram and the collaboration diagram. The first one focuses on the chronological order of the method calls among objects, while the second one highlights the method calls of each object. It is important to stress that each diagram only shows one scenario, i.e., one of the possible evolutions for the system. In the case of concurrency, more than one diagram must be generated for each use case in order to represent all the possible evolutions. The UML defines a solid-line arrow to indicate a discrete interaction (method call). In this book a dashed-line arrow is used to indicate continuous interactions (sharing of variables). Letters B and E indicate if the arrow refers to the beginning or end of the continuous interaction. This notation is used in both sequence and collaboration diagrams. Example: Fig. 3.12 shows a possible sequence diagram for the use case ‘Make P1’ of the production line. It considers the case of a production order that is composed of a single batch of P1 to be processed in M1. The equivalent collaboration diagram is presented in Fig. 3.13. Once the sequence and/or collaboration diagrams have been built and the communications among objects have been identified, the methods and attributes of the classes must be specified. Eventually, new methods and attributes will be added to the list when the OO-DPT sub-net of each class is built. Example: The classes of the production line have the following methods and attributes (Fig. 3.14):
54
Modelling and Analysis of Hybrid Supervisory Systems
Production Order 1
Receipt P1
1:
Interface CM1 2:
Interface VT2-1
CM1
VT2-1
VM1-1
VM1-2
T1
T2
M1
3:
4:
5:
6:
7:
8(B)
9(B)
10(B)
11(B)
12(B)
13(B)
15:
16:
17:
14(B)
18: 19:
20(E11)
21(E12)
22(E13)
23(E14) 24: 26(E9)
25(E8) 27(E10)
28: 29: 30(B) 31(E30)
32:
33:
Discrete Communication 1: Production Order 1 asks Receipt P1 to make a batch of P1 2: Receipt P1 requests M1 to Interface C M1 3: Interface C M1 requests M1 to the controller CM1 4: Receipt P1 sends a request of opening VT2-1 to Interface VT2-1 5: Interface VT2-1 opens VT2-1 6: CM1 opens VM1-1 7: CM1 opens VM1-2 15: CM1 interrupts the loading of additive in M1 by closing VM1-2 16: CM1 informs the end of the loading to Interface C M1 17: Interface C M1 informs end of the loading to Receipt P1 18: Receipt P1 sends a request of closing VT2-1 to Interface VT2-1 19: Interface VT2-1 closes VT2-1 24: CM1 interrupts the loading of base by closing VM1-1 28: CM1 starts mixing 29: CM1 stops mixing and starts emptying 32: CM1 informs the end of the batch production to Interface CM1 33: Interface C M1 informs the end of the batch production to Receipt P1
Continuous Communication 8: T 1 uses the flow of VM1-1 to determine its volume 9: CM1 uses the flow of VM1-1 to determine the additive volume 10: M1 uses the flow of VM1-1 to determine its volume 11: VM1-2 uses the flow of VT2-1 to determine its own flow. 12: T 2 uses the flow of VT2-1 to determine its volume 13: CM1 uses the flow of VM1-2 to determine the base volume 14: M1 uses the flow of VM1-1 to determine its volume 30: CM1 uses the volume of M1 to determine the end of the emptying process
Fig. 3.12. Sequence diagram for the use case ‘Make P1’
9(B) 6 13 2 10 17
Production Order 1
1
Interface CM1
3 9 16
7 8 14
Receipt P1
15 11(B) 4
11
CM1
Interface VT2-1
5 12
26(E9)
VM1-1
VM1-2
8(B) 25(E8)
T1
12(B) 21(E12)
T2
14(B)
23(E10)
M1
20(E11)
VT2-1
Fig. 3.13. Collaboration diagram for the use case ‘Make P1’
10(B) 27(E10)
3 Development of the Supervisory System
C1 – TanK Vol, I1, I2 qI1.C2, qI2.C2, qin
C2 – Valve A q Inform flow interruption Open valve Close valve C3 – Valve B I1, I2 q qI1.C2, qI2.C2 Inform flow interruption Open valve Close valve
C4 – Mixer I1, I2 Vol qI1.C2, qI2.C3 Start mixing Stop mixing Start emptying Stop mixing and start emptying C7 – Interface Valve A Open valve Close valve C9 – Production Order I1, I2 NP1, NP2 Receive an order
55
C5 – Mixer Controller M, KTM, TM, pc, VolP1, VolP2, I1, I2, I3 VolI1.C4, qI2.C2, qI3.C3 Begin a batch Inform the end of additive loading Inform end of the batch C6 – Interface CM I1 Begin a batch Inform the end of additive loading Inform end of the batch C8 – Receipt N, I1, I2; I3, I4 Begin production Inform end of production
Fig. 3.14. Methods and attributes of the classes of the production line example
Once the methods are defined, the activity diagram can be detailed in order to include the activities related to the communication between objects and highlight concurrencies, synchronisms and conflicts in the control thread. Example: The activity diagram of Fig. 3.11 (use case ‘Make P1’) is detailed in Fig. 3.15. 3.1.6 Step 6: Building the OO-DPT Net of the Classes and the Class Diagrams The OO-DPT net of the classes must be consistent with the diagrams built in Steps 1-5. For this purpose the following directives must be considered: x
x
x
Each activity of the PFS model is performed by an object of the controlled object. The continuous activities correspond to places of the OO-DPT subnet while the discrete ones correspond to transitions. The flows of discrete items through the system correspond to method calls between classes while the continuous flows of material are modelled as continuous variable sharing. The continuous activities of the activity diagrams correspond to places, while the discrete activities are modelled as transitions of the OO-DPT subnet. They may belong to classes of the supervisory system or the controlled object. The communications of the sequence or collaboration diagrams correspond to method calls in the case of discrete communications, or continuous variable sharing in the case of continuous communications.
56
Modelling and Analysis of Hybrid Supervisory Systems
Production Order 1 asks Receipt P1 to produce P1
Receipt P1 requests M1 to Interface C M1
Production of a batch of P1 in M2 (similar to M 1) Receipt P1 asks Interface VT2—1 to open VT2-1
Interface CM1 requests M1 to controller CM1
Interface VT2-1 opens VT2-1 CM1 opens V M1-1
CM1 opens V M1-2
Filling with base
Filling with additive
CM1 closes VM1-1
CM1 closes VM1-2
CM1 informs end of additive loading to Interface C M1
Interface CM1 informs end of additive loading to Receipt P1 CM1 starts mixing in M1
Mixing in M1
CM1 stops mixing and starts emptying M1
Receipt P1 requests Interface VT2--1 to close VT2-1
Emptying M1
CM1 detects M1 empty
CM1 informs end of batch to Interface CM1
Interface CM1 informs end of batch to Receipt P1
Fig. 3.15. Detailed activity diagram for the use-case ‘Make P1’
Interface VT2 closes VT2
3 Development of the Supervisory System
57
Example: The OO-DPT net of the class C1 is presented in Fig. 3.16. The tank is initially not empty (place p1_1). While in p1_1, the tank is receiving a certain amount of incoming flow (qin) and providing a certain amount of product that is set by the objects of class C2, indicated in I1 and I2 (qI1.2 and qI2.2). The current volume in the tank (Vol) is calculated by f1_1. When the tank runs out of product it informs the two valves connected to it by calling the method associated with transitions t2_1 and t3_1. In order to make it easy to understand, the OO-DPT sub-nets are presented with possible initial markings for the objects of the system.
C1 – Tank
p1_1
p2_1
t2_1
p4_1
p3_1
t3_1
p5_1
t1_1
t4_1
Not empty
p6_1 Empty
Variables: Xint_1 = {Vol}; Xco_1 = {I1, I2}; Xext_1 = {qin}; Xim_1 = {qI1.2, qI2.2}; Enabling function: e1_1: Vol < 0; Equation systems: f1_1: dVol/dT= qin - qI1.2 - qI2.2 Methods used by the class: t2_1 o t2_I1.2 – Inform end of flow t3_1 o t2_I2.2 – Inform end of flow
Fig. 3.16. OO-DPT sub-net of class C1 – Tank
Example: The OO-DPT sub-net of class C2 – Valve A is presented in Fig. 3.17. The valve can switch between the states ‘open’ (p5_2) and ‘closed’ (p2_2) by calling the methods associated with transitions t3_2 and t4_2. When open, the flow through the valve (q) is constant and equal to 10. If eventually the tank connected to the valve runs out, the method associated with t2_2 is called and makes q=0.
C2 – Valve A Closed p2_2
t3_2
Open p5_2
t4_2 t1_2
t5_2 p3_2 Without flow
p1_2
Variables: Xpb_2 = {q}; Junction functions: j1_2, j4_2, j5_2: q = 0; j3_2: q = 10; Methods provided by the class: t2_2 – Inform flow interruption t3_2 – Open valve t4_2 – Close valve
t2_2 p4_2
Fig. 3.17. OO-DPT sub-net of class C2 – Valve A
Example: The OO-DPT sub-net of class C3 – Valve B is presented in Fig. 3.18. This class is similar to class C2 – Valve A, but in this case the flow through the valve is the result of the sum of the flow through the two corresponding valves of class C2, identified by I1 (qI1.2) and I2 (qI2.2).
58
Modelling and Analysis of Hybrid Supervisory Systems
C3 – Valve B Closed p2_3
t3_3
Open p5_3
t4_3 t1_3
t5_3 p3_3 Without flow
p1_3
t2_3
Variables: Xco_3 = {I1, I2}; Xpb_3 = {q}; Xim_3 = {qI1.2, qI2.2}; Junction functions: j1_3, j4_3, j5_3: q = 0; Equation system: f5_3: q = qI1.2 + qI2.2; Methods provided by the class: t2_3 – Inform flow interruption t3_3 – Open valve t4_3 – Close valve
p4_3
Fig. 3.18. OO-DPT sub-net of class C3 – Valve B
Example: The OO-DPT sub-net of class C4 – Mixer is presented in Fig. 3.19. When in the states ‘idle’ (p1_4) or ‘mixing’ (p2_4), the mixer receives the flow from the valves indicated by I1 (qI1.2) and I2 (qI2.3). When emptying (p3_4), the output flow is constant and equal to 20. After being completely emptied the mixer goes automatically to the state ‘idle’ (firing of t3_4).
C4 – Mixer t3_4 t4_4
t1_4 p1_4
p2_4
t5_4
p3_4
t2_4 Idle
Mixing
Emptying
Variables: Xco_4 = {I1, I2}; Xpb_4 = {Vol}; Xim_4 = {qI1.2, qI2.3}; Enabling function: e3_4: Vol = 0; Equation systems: f1_4, f2_4: dVol/dT= qI1.2+ qI2.3 f3_4: dVol/dT = qI1.2+ qI2.3 – 20 Methods provided by the class: t1_4 – Start mixing t2_4 – Stop mixing t4_4 – Start emptying t5_4 – Stop mixing and start emptying
Fig. 3.19. OO-DPT sub-net of class C4 – Mixer
Example: The OO-DPT sub-net of class C5 – Mixer Controller is presented in Fig. 3.20. It controls the execution of a batch by filling the mixer with base and additive, mixing them for a fixed time interval (KTM), and then emptying the mixer. The amount of mixture to be produced in a batch is M, and is fixed. The percentage of base in the mixture is pc. VolP1 and VolP2 indicate the current amount of base and additive in the mixer by monitoring the input flow from the valves identified by I2 (qI2.2) and I3 (qI3.3). The valve that controls the admission of base is open and closed by the controller. On the other hand, the supervisory system must close the output valve of the additive tank. For this purpose, the method associated with t6_5 is used to inform the supervisory system of the end of additive loading.
3 Development of the Supervisory System
59
C5 – Mixer Controller p2_5
Filling with base t2_5 t4_5 p4_5
p6_5 Mixing
Idle p1_5
t7_5
t1_5
p3_5
Filling with additive t3_5 t5_5 p5_5
p7_5
t6_5
p9_5
t8_5
Emptying p10_5 t10_5
p8_5 t9_5
Variables: Xco_5 = {M, KTM, pc, I1, I2, I3}; Xint_5 = {TM, VolP1, VolP2, I1, I2, I3}; Xim_5 = {VolI1.4, qI2.2, qI3.3}; Enabling functions: e4_5: VolP1 = M*pc; e5_5: VolP2 = M*(1-pc); e8_5: TM = KTM; e10_5: VolI1.4 = 0; Junction functions: j2_5: VolP1 = 0; j3_5: VolP2 = 0; j7_5: TM = 0; Equation systems: f4_5: dVolP1/dT = qI2.2 f5_5: dVolP2/dT = qI3.3 f9_5: dTM/dT = 1
p11_5
Methods provided by the class: t1_5 – Begin a batch t6_5 – Inform end of additive loading t8_5 – Inform end of the batch Methods used by the class: t2_5 o t3_I2.2 – Open valve t3_5 o t3_I3.3 – Open valve t4_5 o t4_I2.2 – Close valve t5_5 o t4_I3.3 – Close valve t7_5 o t1_I1.4 – Start mixing t8_5 o t5_I1.4 – Stop mixing and start emptying
Fig. 3.20. OO-DPT sub-net of class C5 – Mixer Controller
Example: The OO-DPT sub-net of class C6 – Interface CM is presented in Fig. 3.21. This is a class of the supervisory system that basically makes the interface with the mixer controller (objects of class C5).
C6 – Interface CM Available t1_6 p1_6
p2_6
t2_6
p3_6
t3_6
p4_6
t4_6
p5_6
t5_6
p6_6
t6_6
Processing the batch
Variables: Xco_6 = {I1}; Methods provided by the class: t1_6 – Begin a batch t4_6 – Inform the end of additive loading t6_6 – End the batch
Methods used by the class: t2_6 o t1_I1.5 – Begin a batch t3_6 o t6_I1.5 – Inform end of additive loading t5_6 o t9_I1.5 – Inform end of the batch
Fig. 3.21. OO-DPT sub-net of class C6 – Interface CM
Example: The OO-DPT sub-net of class C7 – Interface Valve A is presented in Fig. 3.22. This is a class of the supervisory system that basically makes the interface with the valves of class C2. The valves of class C3 are not controlled by the supervisory system.
60
Modelling and Analysis of Hybrid Supervisory Systems
C7 – Interface Valve A t1_7
p2_7
t3_7
t2_7
p3_7
t4_7
Closed p1_7
Open p4_7
Variable: Xco_7 = {I1}; Methods provided by the class: t1_7 – Open valve t4_7 – Close valve Methods used by the class: t2_7 o t3_I1.2 – Close valve t3_7 o t4_I1.2 – Open valve
Fig. 3.22. OO-DPT sub-net of class C7 – Interface Valve A
Example: The OO-DPT sub-net of class C8 – Receipt is presented in Fig. 3.23. It is a class of the supervisory system and it executes receipts, which consists of making a number N of batches of a product.
C8 – Receipt Using M1
p2_8
t2_8
p4_8
t5_8
p7_8
t8_8
p9_8
t10_8
p11_8
t12_8
t3_8
p5_8
t6_8
p8_8
t9_8
p10_8
t11_8
p12_8
t13_8
Using M2 p1_8
t1_8
p3_8
t4_8
Making P Variables: Xpb_8 = {N}; Xco_8 = {I1, I2; I3, I4}; Enabling functions: e4_8: N = 0; e2_8, e3_8: N > 0; Junction functions: j2_8, j3_8: N = N-1; Methods provided by the class: t1_8 – {N} – Begin production t7_8 – Inform end of production
p6_8
t7_8 Methods used by the class: t2_8 o t1_I1.6 – Begin a batch t3_8 o t1_I2,6 – Begin a batch t5_8 o t1_I3.7 – Open valve t6_8 o t1_I4.7 – Open valve t8_8 o t4_I1.6 – Inform end of additive loading t9_8 o t4_I1.6 – Inform end of additive loading t10_8 o t4_I3.7 – Close valve t11_8 o t4_I4.7 – Close valve t12_8 o t6_I1.6 – Inform end of the batch t13_8 o t6_I2.6 – Inform end of the batch
Fig. 3.23. OO-DPT sub-net of class C8 – Receipt
Example: The OO-DPT sub-net of class C9 – Production Order is presented in Fig. 3.24. It is a class of the supervisory system and it executes production orders. A production order consists of making a certain number of batches of P1 (NP1) and P2 (NP2). The definition of the OO-DPT sub-nets is concomitant with the building of the UML class diagram, where the structural relationships among the classes are illustrated. The two most important relationships of the OO paradigm are generalisation/specialisation and composition/decomposition. The use of OO relationships for defining the OO-DPT sub-net is introduced in Section 3.2.
3 Development of the Supervisory System
C9 – Production Order
p1_9
p2_9
t2_9
p3_9
t3_9
Making P1 t4_9 p2_9
p4_9
t5_9
p5_9
t1_9
t6_9 p3_9
61
Variables: Xco_9 = {I1, I2}; Xpb_9 = {NP1, NP2}; External methods provided by the class: t1_9 {NP1, NP2} – Receive order Methods used by the class: t2_9 o t1_I1.8 {NP1} – Begin production t3_9 o t1_I2.8 {NP2} – Begin production t4_9 o t1_I1.8 – Inform end of production t5_9 o t1_I2.8 – Inform end of production
Making P2
Fig. 3.24. OO-DPT sub-net of class C9 – Production order
Once the OO-DPT sub-net has been built, the initial state of the system must be specified (or the set of possible initial states) in order to ensure the consistency of the model. The initial state of each object is composed of the Petri net marking (mj.i of object Oj.i) and the initial values of the object variables (instance Xj.i of object Oj.i). The values of the image (Xim_i) and external (Xext_i) variables are not specified. Example: For the objects of the production line, an example of consistency is to ensure that if the valve VT2-1 (of the controlled object) is closed, the flow (q) must be zero and the object Interface_VT2-1 (of the supervisory system) must also be closed. As an example, the following initial state is specified for the production line: x
O1.1 – T1 X1.1: Vol = 20; I1 = VM1-1; I2 = VM2-1; m1.1 = {p1_1};
x
O2.1 – T2 X2.1: Vol = 20; I1 = VT2-1; I2 = VT2-2; m2.1 = {p1_1};
x
O3.1 – T3 X3.1: Vol = 20; I1 = VT3-1; I2 = VT3-2; m3.1 = {p1_1};
x
O1.2 – VT2-1 X1.2: q = 0; m1.2 = {p1_2, p2_2};
x
O2.2 – VT2-2 X2.2: q = 0; m2.2 = {p1_2, p2_2};
x
O3.2 – VT3-1; X3.2: q = 0; m3.2 = {p1_2, p2_2};
x
O4.2 – VT3-2; X4.2: q = 0; m4.2 = {p1_2, p2_2};
62
Modelling and Analysis of Hybrid Supervisory Systems
x
O5.2 – VM1-1 X5.2: q = 0; m5.2 = {p1_2, p2_2};
x
O6.2 – VM2-1 X6.2: q = 0; m6.2 = {p1_2, p2_2};
x
O1.3 – VM1-2 X1.3: q = 0; I1 = VT2-1; I2 = VT3-1; m1.3 = {p1_3, p2_3};
x
O2.3 – VM2-2 X2.3: q = 0; I1 = VT2-2; I2 = VT3-2; m2.3 = {p1_3, p2_3};
x
O1.4 – M1 X1.4: Vol = 0; I1 = VM1-1; I2 = VM1-2; m1.4 = {p1_4};
x
O2.4 – M2 X2.4: Vol = 0; I1 = VM2-1; I2 = VM2-2; m2.4 = {p1_4};
x
O1.5 – CM1 X1.5: M = 5; KTM = 4; TM = 0; pc = 0.5; VolP1 = 0; VolP2 = 0; I1 = M1; I1 = VM1-1; I2 = VM1-2; m1.5 = {p1_5};
x
O2.5 – CM2 X2.5: M = 5; KTM = 5; TM = 0; pc = 0.3, VolP1 = 0, VolP2 = 0, I1 = M1, I1 = VM2-1, I2 = VM2-2}; m2.5 = {p1_5};
x
O1.6 – Interface CM1 X1.6: I1 = CM1; m1.6 = {p1_6};
x
O2.6 – Interface CM2 X2.6: I1 = CM2; m2.6 = {p1_6};
x
O1.7 – Interface VT2-1 X1.7: I1 = VT2-1; m1.7 = {p1_7};
x
O2.7 – Interface VT2-2 X2.7: I1 = VT2-2; m2.7 = {p1_7};
x
O3.7 – Interface VT3-1 X3.7: I1 = VT3-1; m3.7 = {p1_7};
3 Development of the Supervisory System
63
x
O4.7 – Interface VT3-2 X4.7: I1 = VT3-2; m4.7 = {p1_7};
x
O1.8 – Receipt P1 X1.8: N = 0; I1 = Interface CM1; I2 = Interface CM2; I3 = Interface VT2-1; I4 = Interface VT2-2; m1.8 = {p1_8};
x
O2.8 – Receipt P2 X2.8: N = 0; I1 = Interface CM1; I2 = Interface CM2; I3 = Interface VT3-1; I4 = Interface VT3-2; m2.8 = {p1_8};
x
O1.9 – Production Order 1 X1.9: NP1 = 1; NP2 = 0; I1 = Receipt P1; I2 = Receipt P2; m1.9 = {p1_9};
x
O2.9 – Production Order 2 X2.9: NP1 = 2; NP2 = 4; I1 = Receipt P1; I2 = Receipt P2; m2.9 = {p1_9};
x
O3.9 – Production Order 3 X3.9: NP1 = 6; NP2 = 3; I1 = Receipt P1; I2 = Receipt P2; m3.9 = {p1_9};
x
O4.9 – Production Order 4 X4.9: NP1 = 2; NP2 = 2; I1 = Receipt P1; I2 = Receipt P2; m4.9 = {p1_9};
3.1.7 Step 7 – Verification of Consistency among Models 3.1.7.1 OO-DPT Net and Sequence (or Collaboration) Diagram For the OO-DPT net and the sequence (or collaboration) diagrams to be consistent, the following statements must be true: x x
Each discrete communication must correspond to a method call associated with a transition. Each continuous communication must correspond to a variable shared between the objects.
Example: For the production line, the correspondence between the sequence diagram of Fig. 3.12 and the transitions and variables of the OO-DPT net is presented in Fig. 3.25.
64
Modelling and Analysis of Hybrid Supervisory Systems
Production Order 1
Receipt P1
1: t2_9ot1_8
Interface CM1
2: t2_8ot1_6 4: t5_8ot1_7
Interface VT2-1
CM1
VT2-1
VM1-1
VM1-2
T1
T2
M1
3: t2_6ot1_5 5: t2_6ot1_5
6: t2_5ot3_2 7: t3_5ot3_3
8(I): q
9(I): q
10(I): q
11(I): q
12(I): q
13(I): q
14(I): q
17: t8_8ot4_6
15: t5_5ot4_3
16: t3_6ot6_5 18: t10_8ot4_7
19: t3_6ot6_5
20(F11): q
22(F13): q
21(F12): q 23(F14): q
24: t4_5ot4_2
25(F8): q
26(F9): q
27(F10): q
28: t7_5ot1_4 29: t8_5ot5_4 30(I): Vol 31(F30): Vol
33: t12_8ot6_6 32: t5_6ot9_5
Fig. 3.25. Correspondence between the sequence diagram and the OO-DPT net
3.1.7.2 OO-DPT Net and Activity Diagrams In order to verify the consistency between the activity diagrams and the OO-DPT net, the activity diagram must be converted into a Petri net model. The purpose of the conversion is to identify which places and transitions of the OO-DPT net perform the activities of the activity diagram, and therefore ensure that they are consistent. The conversion is made by applying the following rules: x
Each discrete activity corresponds to a transition. A place is introduced between two transitions (Fig. 3.26). t1
Activity 1
Activity 1 p1 Activity 2 t2
Activity 2
Fig. 3.26. Conversion of activity diagram into Petri net – discrete activities
x
Each continuous activity is converted into a place. A transition is introduced between two places. (Fig. 3.27).
3 Development of the Supervisory System
Activity 1
t1
Activity 1
p1
Activity (continuous) 2
65
Activity 2 t2 Activity 3
Activity 4
p2
Activity (continuous) 3
t3
Activity 4
Fig. 3.27. Conversion of activity diagram into Petri net – continuous activities
x
Each synchronisation bar of the activity diagram is converted into a transition. Places are introduced between the transitions corresponding to the discrete activities before the synchronisation bar and the transition
corresponding to the bar. The same is also done for the discrete activities after the synchronisation bar. No place is introduced in the case of continuous activities. (Fig. 3.28). t1 Activity 1
Activity 2
Activity 3
Activity 1
t2 Activity 2 p2
p1
Activity 3
p3
t3 Activity 4
Activity 5
Activity 6
p4
p5
p6
Activity 5 t3
Activity 4
t3
Activity 6
Fig. 3.28. Conversion of activity diagram into Petri net – synchronisation bar
x
Each activity followed by a decision point with N possible outputs is represented by a place with N output transitions. When there is a discrete activity after the decision point, a place is introduced between the transition corresponding to the output of the decision point and the transition corresponding to the discrete activity. No place is introduced in the case of continuous activities (Fig. 3.29).
x
Once the Petri net model has been built, it can be simplified. A sequence of a place and a transition (or a transition and a place) can be deleted in the case when (1) it does not correspond to any activity of the activity diagram and (2) it corresponds to one of the following cases: -
The sequence has only one input arc and one output arc (Fig. 3.30).
-
The place of the sequence has one input arc and one output arc, while the transition has one input arc and more than one output arc (Fig. 3.31).
66
Modelling and Analysis of Hybrid Supervisory Systems
-
The place of the sequence has one input arc and one output arc, while the transition has one output arc and more than one input arc (Fig. 3.32). Activity 1
p1 Activity 1 t1
t2
p2
p3
Activity 2 Activity 2
Activity 3
t3
Activity 3
p4 Activity 4
Activity 5
t4
t5
p5
p6
Activity 4 t6
Activity 5
Fig. 3.29. Conversion of activity diagram into Petri net – decision point
Activity 1 Activity 1
Activity 2
Activity 1
p1
Activity 3
p1
t1
t2
p2
p3
t1
t2
Activity 3
p2
Activity 2
Activity 2 t3
Activity 3
Fig. 3.30. Conversion of activity diagram into Petri net – simplification (1)
Activity 1
t1 Activity 1
p1
t1 t2
Activity 2
Activity 3
p2 t3 Activity 2
p3 t4
p2 t3 Activity 2
Activity 1 p3 t3 Activity 3
Activity 3
Fig. 3.31. Conversion of activity diagram into Petri net – simplification (2)
Once the activity diagram has been converted into a Petri net model, a correspondence must be established between the places and transitions of the Petri net model and the places and transitions of the OO-DPT net. The Petri net model is part of the unfolded version of the OO-DPT net. Example: For the production line, Fig. 3.33 presents the converted version of the activity diagram of Fig. 3.15.
3 Development of the Supervisory System Activity 1 t1 Activity 1
Activity 2 t2 Activity 1 t1
Activity 2 p1
p2
Activity 2 t2
p1
t2
p2
Activity 3
t3 Activity 3
p3 t3
Activity 3
Fig. 3.32. Conversion of activity diagram into Petri net – simplification (3)
t2_9ot1_8
Production Order 1 asks Receipt P1 to produce P1
p2_8
t3_8ot1_6
t2_8ot1_6
p2_6
p4_8 Production of a batch of P1 in M2 t5_8ot1_7 (similar to M1)
Receipt P1 asks Interface VT2—1 to open VT2-1
p4_7
p3_5
p2_5
p2_7 t3_7ot4_2
t2_6ot1_5 Interface CM1 requests M1 to controller CM1
Interface VT2-1 t2_5ot3_2 opens VT2-1 Valve open
p4_5 t4_5ot4_2
CM1 opens t3_5ot3_3 VM1-1
CM1 opens VM1-2
Filling with base
Filling with additive
p5_5
CM1 closes t5_5ot4_3 VM1-1
p6_5
CM1 closes VM1-2
p7_5 CM1 informs end of additive loading to Interface C M1
t3_6ot6_5
p4_6 CM1 starts t ot 7_5 1_4 mixing in M1
p4_6
Mixing in M1 p9_5 CM1 stops mixing and t ot 8_5 5_4 starts emptying M1 Emptying M1 p10_5 CM1 detects M1 t10_5 empty
Interface CM1 informs end of additive loading to Receipt P1
t8_8ot4_6
p9_8 Receipt P1 requests Interface VT2--1 to close VT2-1
t10_8ot4_
p11_8
p3_7 t2_7ot3_2
Interface VT2 closes VT2
p11_5 CM1 informs end of t ot 5_6 9_5 batch to Interface CM1
p11_5 End of production of P1
t4_8
Interface CM1 informs end t ot of batch to Receipt P1 12_8 6_
Fig. 3.33. Conversion of activity diagram into Petri net - example
67
68
Modelling and Analysis of Hybrid Supervisory Systems
3.2 OO Relationships Applied to OO-DPT net Two relationships among classes are particularly important for the system design and reuse: composition/decomposition and specialisation/generalisation (Booch, 1994). 3.2.1 Composition/Decomposition Relationship In the composition/decomposition relationship an object from one class is part of an object of another class. In the OO-DPT nets, the composition is achieved by permanently fusing transitions that correspond to method calls between the classes. On the other hand, decomposition can be done by identifying place invariants and dividing the sub-net. Example: For the production line, one option is to define a class that is responsible for providing the additive (C10 – Additive Station). This class is the result of the composition of class C1 – Tank with class C2 – Valve A. Each object of C10 is composed of one object of C1 and two objects of C2. This relationship is presented in the class diagram of Fig. 3.34. The OO-DPT sub-net resulting from the composition is presented in Fig. 3.35. C10 – Additive Station
Decomposition/composition relationship
2
C1 – Tank
C2 – Valve A
Fig. 3.34. Class diagram for the composition of class C10 – Additive Station Closed p9_10
t6_10
Open p10_10
t7_10 t5_10
t8_10 p11_10
Without flow
p7_10
p8_10
p1_10
p2_10
t2_10
p4_10
p3_10
t3_10
p5_10
t1_10
t4_10
Not empty
C10 – Additive Station Variables: Xpb_10 = {q1}; Junction function: j5_10, j7_10, j8_10: q1 = 0; j6_10: q1 = 10; Methods provided by the class: t6_10 – Open valve 1 t7_10 – Close valve 1
Variables: Xint_1 = {Vol}; Xext_1 = {qin}; p6_10 Enabling function: e1_10: Vol = 0; Equation systems: Empty f1_10: dVol/dT= qin - q1 - q2
p13_10
Variables: Xpb_10 = {q2}; Without flow p14_10 Junction function: j9_10, j10_10, j12_10: q2 = 0; t10_10 t9_10 t12_10 j11_10: q2 = 10; Methods provided by the class: t10_10 – Open valve 2 Open Closed t11_10 t11_10 – Close valve 2 p15_10 p16_10 p12_10
Fig. 3.35. OO-DPT sub-net of class C10 – Additive station
3 Development of the Supervisory System
69
The model resulting from the composition may be simplified in order to eliminate redundant information. A technique that can be used to check if two sets of places are equivalent is to determine if they compose a place invariant. If they do compose a place invariant and there is no continuous dynamics associated with them, and one of them can be eliminated without interfering in the class behaviour. Other techniques proposed for the reduction of Petri nets can also be applied. Example: In the model of Fig. 3.35, places p7_10 and p12_10 contain redundant information. They indicate that the tank has not yet run out of flow. However, this information can be obtained directly from the net of the tank (p1_10 to p6_10). Considering the initial marking of the system (m1.10 = {1,0,0,0,0,0,1,0,1,0,0,1, 0,0,1}), the following place invariants are associated with p7_10 and p12_10: ‘m(p7_10) = m(p1_10) + m(p2_10)’ and ‘m(p12_10) = m(p1_10) + m(p3_10)’. As a consequence both places can be eliminated without interfering in the system dynamics. Moreover, when the tank is empty both valves enter the state ‘without flow’. If there is no interest in explicitly representing the states ‘valve 1 without flow’, ‘valve 2 without flow’, ‘tank empty’, then places p4_10, p5_10 and p6_10 can also be eliminated (place invariant ‘m(p4_10) + m(p5_10) + 2*m(p6_10) = m(p8_10) + m(p11_10) + m(p13_10) + m(p14_10)’). Once p4_10, p5_10, p6_10, p7_10 and p12_10 have been eliminated, the sequences of place-transition p2_10-t2_10 and p3_10-t3_10 have only one input arc and one output arc. They do not represent any relevant information. Therefore, according to the reduction rules of Petri nets, they can also be eliminated. The OODPT sub-net resulting from the simplifications is presented in Fig. 3.36. C10 – Additive Station t6_10
Closed p9_10
Open p10_10
t7_10 t5_10
t8_10 p11_10
Without flow p8_10
t1_10
p1_10
Empty
Not empty p13_10 p12_10 p14_10 t9_10 Closed
Without flow t10_10
t11_10 p15_10
t12_10 Open p16_10
Variables: Xpb_10 = {q1}; Junction function: j5_10, j7_10, j8_10: q1 = 0; j6_10: q1 = 10; Methods provided by the class: t6_10 – Open valve 1 t7_10 – Close valve 1 Variables: Xint_1 = {Vol}; Xext_1 = {qin}; Enabling function: e1_10: Vol = 0; Equation systems: f1_10: dVol/dT= qin - q1 - q2 Variables: Xpb_10 = {q2}; Junction function: j9_10, j10_10, j12_10: q2 = 0; j11_10: q2 = 10; Methods provided by the class: t10_10 – Open valve 2 t11_10 – Close valve 2
Fig. 3.36. Simplification of the OO-DPT sub-net of class C10 – Additive station
70
Modelling and Analysis of Hybrid Supervisory Systems
In the same way C10 is the result of the composition of C2 and C1, C1 and C2 can be obtained by decomposing C10. The decomposition of a class is carried out by identifying the place invariants corresponding to different components. Example: Starting from C10 (OO-DPT sub-net of Fig. 3.36), the following place invariants can be identified: ‘m(p9_10) + m(p10_10) + m(p11_10) = 1’ and ‘m(p14_10) + m(p15_10) + m(p16_10) = 1’. They correspond to the state of the valves. A simple decomposition is obtained by associating method calls with t5_10, t8_10, t9_10, t12_10. If it is desired that only one method is associated with both t5_10 and t8_10 (or t9_10, t12_10) then the net should be further detailed, resulting in the models of classes C1 and C2 presented in Fig. 3.16 and Fig. 3.17. The composition/decomposition relationship is useful for the definition of classes with an adequate level of detail. It is also important for specifying complex classes that cannot be divided because of closed loop of variable sharing. A typical example is when a continuous material flow cycles through a set of machines. Each machine cannot be associated with a class because it would result in a closed loop sharing of variables. However, the class containing all the machines can be specified as a composition of a set of ‘intermediate’ classes, each one associated with a machine. These intermediate classes can be modelled separately or can be reused from a class library. Many examples are presented in Chapters 5, 6 and 7. 3.2.2 Generalisation/Specialisation Relationship Another way in which two classes can be related is in a generalisation/ specialisation hierarchy, in which one class is a special case of another. This kind of relationship between classes is referred to as an ‘is-a’ or ‘kind-of’ relationship, and is also known as inheritance. It shows common structures and behaviours among classes. The ‘child class’ inherits the methods and attributes of the ‘parent class’, and has also additional methods and/or attributes. In software engineering, the main purpose of the generalisation/specialisation relationship is to provide code reuse. When a ‘child class’ is created, it is not necessary to copy all the attributes and methods of the ‘parent class’. Many approaches have already defined the inheritance relationship for Petri nets. They propose inheritance as a way of reusing models (Lakos, 1995). The model of the parent net is not included in the child net. However, in the context of this work, this definition is considered not appropriate because it affects the visual comprehension of the OO-DPT sub-nets. The sub-net of a ‘child’ class would have little graphical meaning without the sub-net of the ‘parent’ class. Even if there is no interest in the inheritance relationship for modelling purposes, it can still be used in Phase 3 of control system design, when the OODPT net of the classes is converted into software code. In this context, the identification of common attributes and methods can result in code reuse. Therefore, the OO-DPT sub-net of a class is considered the specialisation of another class if it has the same elements (places, transitions, variables, enabling functions, etc.) plus additional elements.
3 Development of the Supervisory System
71
Example: In the case of the production line, classes C2 – Valve A and C3 – Valve B can be defined as the specialisation of a common class C11 – Valve. This relationship is illustrated in the class diagram of Fig. 3.37. The model of class C11 is presented in Fig. 3.38. Class C2 (Fig. 3.17) has the junction function associated with t3_2 as additional element. On the other hand, class C3 (Fig. 3.18) has the variables Xco_3 and Xim_3, and the equation system f5_3 as additional elements. C11 – Valve
Generalisation/Specialisation relationship
C2 – Valve A
C3 – Valve B
Fig. 3.37. Class diagram for the specialisation of class C11 – Valve
C11 – Valve t3_11
Closed p2_11
Open p5_11
t4_11 t1_11
t5_11 p3_11
p1_11 t2_11
Without flow
Variables: Xpb_11 = {q}; Junction function: j1_11, j4_11, j5_11: q = 0; Methods provided by the class: t2_11 – Inform flow interruption t3_11 – Open valve t4_11 – Close valve
p4_11
Fig. 3.38. OO-DPT sub-net of class C11 – Valve
3.3 (Local Control System + Plant) versus Controlled Plant The level of detail and the precision of the controlled object model depend on the functionalities associated with the supervisory system. A particular important point to be considered is whether to distinguish or not the model of the local control system from that of the plant. The behaviour of the local control system can be modelled independently of the behaviour of the plant or not. In the second case, it is assumed that whenever the local control system emits a command to the plant, this command is immediately executed. The model built in this case is that of a controlled plant. Example: In the production line, the model that has been presented for class C2 – Valve A (Fig. 3.17) considers that the output flow from tank T1 is constant when the valve is open. This is the model of a controlled valve. As the volume of tank T1 varies, the pressure in the valve ports also varies. In order to maintain a constant output, the valve position should be continuously modified by a local control system. In this case a possible model for a local control system and a corresponding plant is presented in Fig. 3.39. Class C12 – Uncontrolled Valve A + PID is defined as the result of the composition of two classes (PID Controller and Proportional Valve). They share variables in a closed loop. The flow of the valve
72
Modelling and Analysis of Hybrid Supervisory Systems
(q) is proportional to the valve position (P) and to the maximum flow (qmax). The maximum flow is determined as a function of the tank volume. Kp is the proportional constant. P is determined by a local PID controller (constants K0, K1, K2 and K3) as a function of the error (E) obtained by comparing q with a setpoint (qsp = 10). The use of the C2 model with a constant flow (Fig. 3.17) indicates that the error (E) is considered not relevant for the modelling process. C12 – Uncontrolled Valve A + PID PID Controller Off p1_12
t1_12
On p2_12
t2_12
Proportional Valve p3_12
t3_12
p4_12
Without flow
Variables: Xint_12 = {P, E}, Xco_12 = {qteor, K0, K1, K2, K3}; Junction function: j2_12: q = 0; E=0; Equation system: f2_12: E = q – qsp; P = K0 + K1* E + K2* ³E + K3*dE/dt; Methods provided by the class: t1_12 – Open valve t2_12 – Close valve Variables: Xpb_12 = {q}; Xco_12 = {qmax, K p, I1}; Xim_12 = {VolI1.1} Junction function: j3_12: q = 0; Equation systems: f3_12: qmax = f(VolI1.C1); q = Kp*P*qmax Methods provided by the class: t3_12 – Inform flow interruption
Fig. 3.39. OO-DPT sub-net of class C13 – Uncontrolled Valve A + PID
3.4 Final Remarks This chapter presented a method for obtaining the validation model of the supervisory system and the controlled object. This method is decomposed into steps. Each step corresponds to a set of diagrams. The diagrams document and help the specification of a validation model consistent with the supervisory system requirements. The steps of the method are related in the following way: x x x x
Step 1 – Modelling of the flows of material (in PFS): this step defines the boundaries of the system to be supervised. It also supports the identification of the communication among candidates to objects in Step 4. Step 2 – Specification of the use cases: this step models the system functionalities in use case diagrams. It specifies the external elements (actors) that interact with the system in each use case. Step 3 – Building the activity diagram: this step details each use case of Step 2. Step 4 – Specification of class and objects: this step proposes a set of classes and objects to perform the activities described in the diagrams of Step 3. The system decomposition is based on the communication among the object candidates.
3 Development of the Supervisory System
x x
x
73
Step 5 – Building the sequence and/or collaboration diagram: this step models the communications among the objects (specified in Step 4) for each use case of the system (specified in Step 2). Step 6 – Building the OO-DPT net of the classes and the class diagram: this step uses the information of the diagrams of Steps 1, 3 and 5 for obtaining a OO-DPT sub-net for each class specified in Step 4. The model generated in this step is the validation model of the supervisory system and the controlled object. Step 7 – Verification of consistency between models: this step confronts the OO-DPT net of Step 6 with the diagrams of Steps 3 and 5 in order to verify their consistency.
The PFS and UML diagrams support the modelling of productive systems in which equipment and processes are complex. They focus on different and complementary views of the system behaviour and structure. They enable a gradual definition of the supervisory system. On the other hand, the OO-DPT net establishes a link between the diagrams, ensuring their consistency. The advantages of merging UML and Petri nets have already been highlighted by a number of works for the case of discrete event dynamic systems (Baresi and Pezzè, 2001), (Delatour, 2003), (Elkoutbi and Keller, 2000), (Giese et al. 1999). Concerning the hybrid nature of the models, UML and OO-DPT net complement each other. While the OO-DPT net explicitly shows the states of an object that are associated with a continuous dynamics, the UML collaboration diagram focuses on the continuous interaction among objects. These diagrams are important for the system analysis and will be discussed in Chapter 4. This chapter also approached the use of OO relationships of composition/decomposition and generalisation/specialisation. The first one is important for specifying the OO-DPT net of a system in a progressive way, using bottom-up and top-down strategies. The second one is mainly used in the 3rd Phase of hybrid supervisory system development (Chapter 1). Finally, the question of modelling the local control system independently of the plant has been discussed. It is particularly interesting when the local control system is being designed simultaneously with the supervisory system. In this case, once the model of plant, local control system and supervisory system has been built, it can be used to detect events that may cause disturbance and decrease the performance of the local control system. These events may be monitored by the supervisory system, which interferes in the local control system (e.g. switching controller or changing parameters) in order to deal with the disturbance. The integration enabled by the supervisory system is a key issue for improving the system performance.
4 Hybrid System Analysis
The purpose of this chapter is to discuss the analysis of hybrid systems and presents a systematic method for verifying behavioural properties using the modelling formalism presented in Chapter 2, the OO-DPT nets. In the scientific literature, the word ‘analysis’ has been used with many different meanings. In this chapter, this word refers to the analysis of the productive system behaviour. It is performed using the OO-DPT net model. In the context of discrete event dynamic systems, it is used to differentiate between two different approaches for analysing the behaviour of a system: simulation and formal methods. This dichotomy can also be applied to hybrid systems. Simulation shows the evolution of a model from the initial state, for a limited time or a limited number of simulation steps. It is automatically performed by software tools and depends on the resources and facilities made available by the tool. Generally, it presents some advantages when compared to formal methods, such as it is easily applied to complex and large systems, it requires less computational power and it allows the user to detect a number of modelling problems and mistakes quickly and efficiently. However, if the behaviour of the system depends on interactions with the external environment that are not completely known, if the purpose of the analysis is not limited to a time window, or if there is more than one possible evolution as in the case of conflicts, then simulation cannot be an effective approach to validate the system behaviour. The main limitation of simulation is that it shows one of the possible evolutions for the system. It does not give any information about what would happen if a different choice had been made in the case of a conflict. As a consequence, it cannot ensure the absence of errors. On the other hand, formal methods perform the mathematical verification (proof) of model properties. Differently from the simulation, these properties may not be restricted to a limited time interval, or to a specific interaction with the external environment, or to a particular choice in the case of conflicts. The requirements regarding the system behaviour must be translated into properties of the OO-DPT net. Unlike simulation, the verification of the properties may ensure
76
Modelling and Analysis of Hybrid Supervisory Systems
the absence of error in the system behaviour under any circumstance the system can operate in. This chapter addresses the problem of verifying properties of hybrid systems that are modelled using the OO-DPT nets. The purpose is to validate the supervisory system under design. The chapter begins by discussing one of the main problems related to the verification of properties in hybrid system: the non-decidability. In Section 4.2, what has already been proposed for the analysis of hybrid systems using other modelling formalisms is reviewed. The desired features of an analysis approach based on OO-DPT net are then identified. Among these features is the decomposition of the analysis problem. For these purposes, the association between Petri net and linear logic (Girault et al., 1997) is explored in Section 4.3. This association is the basis of the analysis method introduced in Section 4.4 for the formal verification of properties in OO-DPT nets.
4.1 Formal Verification of Properties in Hybrid Systems The techniques for verifying properties in hybrid systems have not undergone the same evolution as the modelling techniques. While numerous solutions have been proposed for modelling different kinds of hybrid systems, the same has not happened with analysis. The approaches for verifying properties can be classified into two groups: model checking and theorem proving (Clarke and Wing, 1996). The approaches in the first group are based on the enumeration of all the reachable states of a model. In the second group, the property is inferred (or contradicted) by reasoning with a set of rules of a formal logic. The main advantage of the latter group is that it is not restricted to systems with a finite number of states. On the other hand, not many properties can be verified in an automatic way by theorem proving. In the context of hybrid systems, the main problem of model checking techniques is the non-decidability. This means that there is no guarantee that the hybrid system can be described by a finite number of states (or state regions). This problem has been initially discussed regarding discrete event dynamic systems with time-dense clocks, i.e. clocks modelled by continuous variables with a constant derivative equal to one. It has been proved for finite timed automata that the models are decidable and can be analysed by building the equivalent region graph (Alur and Dill, 1994). In the region graph, each node (region) is associated with a discrete state and a set of intervals for the values of the model clocks (continuous variables). The set of reachable regions is finite and allows the verification of properties. On the other hand, it has also been proved that when continuous variables with different but constant growing rates (derivatives) are introduced into the model, then the number of regions may become infinite. Similarly, the decidability of hybrid system models cannot be guaranteed because the derivatives of continuous variables can not only be different among themselves, but also vary in time. Once the model decidability cannot be ensured, the development of an automatic verification procedure based on the enumeration of all possible
4 Hybrid System Analysis
77
reachable regions has no guarantee of convergence. The number of interactions necessary to build the corresponding region graph may be infinite. Another problem that limits the application of analysis approaches based on the region graph is the problem of explosion of the number of regions (Alur et al., 1995), (Gueguen and Zaytoon, 2001). Because of these problems, many of the works proposed in this area are restricted to a specific class of hybrid system and most of them concern the analysis of hybrid automata. Software tools have been developed in order to automate the model checking procedure. Among them are UPPAAL (for timed automata) (Pettersson and Larsen, 2000), HyTech (for linear hybrid automata) (Henzinger et al., 1997), CheckMate (Silva et al., 2000) and Verdict (Stursberg et al., 1998). However, owing to the computational complexity of the analysis problem, these tools can be applied only to small size models with few variables (Silva et al., 2001). The limitations described in this section encouraged the study of new analysis methods that are not based on the region graph. The verification procedure proposed for OO-DPT net explores the model organization into classes and objects to decompose the analysis problem. It follows the ‘divide-to-conquer’ maxim and divides a complex problem into a set of simpler problems. Instead of considering the OO-DPT net as a whole, each sub-net (or a few sub-nets) is analysed separately from the remaining of the model. The verification of a property is based on the search for scenarios. Each scenario is a possible evolution of the OO-DPT net. However, only events and states that are important to the verification of the property are included in the scenario. The focus on the behaviour that is relevant for the property is achieved because linear logic is used in the analysis of the discrete dynamics. The next section presents how linear logic and Petri nets are related. It describes the procedures based on linear logic for verifying reachable markings and deriving scenarios in Petri net models.
4.2 Petri Nets and Linear Logic 4.2.1 Linear Logic versus Classical Logic The idea of relating logic and Petri nets for the reachability analysis was initially studied considering the classical logic. However, classical logic has some features that make it inappropriate for relating it to Petri nets. One of these features is monotonicity. This means that the proof of a theorem does not change when new propositions are added to the hypotheses, as far as no inconsistency is introduced (weakening proof-rule). In addition, if a proposition is true, it remains true whatever use is made of it. On the other hand, Petri nets model resources which are dynamically consumed, allocated or released. As a result, any proposition about the system state has its veracity changed with system evolution. Another problem of classical logic is the contraction proof-rule and the related idempotence of the logical connector ‘AND’. If a resource modelled by a token in a Petri net is represented as a proposition ‘P’, then in classical logic ‘P AND P’ is equivalent to
78
Modelling and Analysis of Hybrid Supervisory Systems
‘P’, which means that it is not possible to distinguish between one, two or more resources. Owing to these problems, linear logic was chosen to be associated with Petri nets instead of classical logic. The fundamental idea of linear logic is to consider logical propositions as resources (Girard, 1987). It controls the use of propositions in a proof by abandoning contraction and weakening proof-rules. The propositions are not eternal truths. They can be ‘consumed’ by rules and ‘counted’ as resources. As a consequence, the 3 connectors: ‘AND’, ‘OR’ and ‘IMPLY’ are redefined. The reasoning in linear logic is based on the proof of a sequent (sequent calculus). A sequent is composed of: a list of premises (the hypotheses), the metaconnector ‘|––’ and a list of conclusions. The meta-connector ‘,’ is used to separate the elements of each list. As an example, the sequent ‘X1, X2 |–– Y1, Y2’ means that from hypothesis X1 and X2 conclusions Y1 or Y2’ can be deduced (the metaconnector ‘,’ does not have the same meaning on both sides, right and left, of the meta-connector ‘|––’). The proof of a sequent is made by applying a syntactic approach, i.e., by verifying if the sequent is correctly written (syntactically correct). The proof is done by applying a set of rules until only axiom sequents are obtained. Axiom sequents are true by definition. Each rule is divided into upper and lower sections (Fig. 4.1). The lower section is composed of a single sequent (Sequent 1), while the upper section is composed of one or two sequents (Sequent 2 and 3). The meaning of a rule is that if the upper section is true, the lower section is also true. As a consequence, in order to prove that the sequent in the lower section is true, it is enough to prove that the sequents in the upper section are true. upper section: lower section:
Sequent 2 Sequent 3 Sequent 1
Fig. 4.1. Graphical representation of a rule
The linear logic rules used in this book are presented in Fig. 4.2. They consider that: x x
x
A, B and C are atomic propositions of linear logic. F, G and H are formulas. A formula is composed of one or more
propositions separated by connectors. The connectors used in this book are:
(multiplicative conjunction), (multiplicative disjunction) and —o (imply). Examples of formulas are ‘F = A
B’, ‘G = A
B —o C’. ī, ī1, ī2, ǻ, ǻ1 and ǻ2 are blocs of formulas. A bloc is composed of a list (possibly empty) of formulas separated by the meta-connector ‘,’. One example of a bloc of formulas is ‘ī = F, G’.
The rule ‘Identity’ sets that an axiom sequent is true by definition. The rule ‘Cut’ allows the use of an intermediate lemma to make a proof. The intermediate lemma is formula ‘F’ and it cannot be deduced from the original sequent (‘*1, *2 ¸ '’). The sequent on the left side (‘*1¸ F’) is the proof of the intermediate lemma, while the sequent on the right side (‘*2, F ¸ '’) represents the use of the lemma in the proof of the original sequent (‘*1, *2 ¸ '’). The rules ‘Exchange L’ and
4 Hybrid System Analysis
79
‘Exchange R’ correspond to the fact that the meta connector ‘,’ is commutative in the linear logic used in this book. *1 , F, G, * 2¸ ' Exchange L *1 , G, F, * 2¸ '
*, F, G ¸ '
L *, F
G ¸ '
*, F ¸ G, ' —o R * ¸ F —o G, '
'¸ *1, F, G, *2 Exchange R ' ¸ *1 , G, F, * 2
* ¸ F, G,' R * ¸ F G, '
*1 ¸ F, ' 1 *2, G ¸ '2 —o L *1, *2, F —o G ¸ ' 1, '2
*1¸ F, ' 1 *2¸ G, '2
R * 1, *2¸ F
G, '1, ' 2
Identity A ¸ A
*1¸ F * 2, F ¸ ' Cut *1, *2¸ '
*1, F¸ ' 1 *2 , G¸ '2 L * 1, *2, F G¸ ' 1, '2
Fig. 4.2. Linear logic rules used in this book
The next section illustrates how these rules are used in the context of Petri nets. 4.2.2 Reachability in Petri Nets and the Proof of Sequents in Linear Logic The first proposal relating Petri net and linear logic was based on the association of a new axiom sequent to each transition of a Petri net. This approach has the disadvantage that the ‘Cut’ rule must be used in order to make a reachability analysis. In order to overcome this disadvantage, a new approach was proposed associating the firing of a transition to an imply formula (Girault et al., 1997). It has the advantages of not extending the set of axioms of linear logic and avoiding the use of the ‘Cut’ rule. Furthermore, the Petri net marking is explicit in the sequent proof, as well as parallelism behaviour and partial order of events. This second proposal is therefore used in this chapter for the analysis of the discrete aspects of hybrid systems. Two strategies can be used to verify the reachability of a marking in a Petri net using linear logic (Khalfaoui, 2003). In the forward reasoning, transitions are fired from the initial marking until the final marking is reached. In the backward reasoning, one starts from the final marking and transitions are fired ‘backward’ until the initial marking is obtained. These two strategies cannot be mixed in the proof of a sequent. 4.2.2.1 Forward Reasoning In forward reasoning, the proof of the reachability of a Petri net marking is made considering that: x x x
An atom ‘p’ is associated with each place ‘p’ of the Petri net. A monomial using the connector
is associated with each marking that is the pre or post-condition of a transition. An imply formula is defined for each transition ‘t’ of the Petri net:
80
Modelling and Analysis of Hybrid Supervisory Systems
t:
pi (i Pre (pi,t)) —o
pj (j Post (pj,t))
Example: Fig. 4.3 presents an example of a Petri net and the definition of imply formulas for its transitions. p2 t1 p1
t2 p3 p4
p5
Definition of transitions: t1: p 1 —o p 2
p 3 t2: p 3
p 4 —o p 5
Fig. 4.3. Definition of transitions in the forward reasoning
The verification of the reachability of a final marking from an initial marking is made by proving the sequent ‘M0, t1, t2, ..., tn |–– Mf’. M0 is the initial marking, Mf is the final marking, and t1, t2, ..., tn is the set of transition firings that brings to Mf from M0. The proof of the sequent is performed by successively applying the rules ‘
L’, ‘
R’ and ‘—o L’ until only identity sequents such as ‘A |–– A’ are obtained. The set of sequents resulting from the application of this method composes the proof tree, which is read bottom-up. In order to not overcharge the proof true, ‘Exchange L’ and ‘Exchange R’ are omitted. Example: Fig. 4.4 presents the proof tree that verifies the reachability of marking {p2, p5} from marking {p1, p4} by firing transitions t1 and t2 and using the forward reasoning. The proof tree starts by applying the rule ‘
L’ to the initial sequent. The interpretation of this rule from the Petri net point of view is that if the final marking is reachable when there is simultaneously a token in p1 and a token in p4 (formula ‘p1
p4’), then it is also reachable if p1 and p4 are consumed independently of each other (formula ‘p1, p4’). The second rule that is applied is ‘—o L’. From the Petri net point of view, it means the firing of transition t1, and it results in the marking ‘p4, p2
p3’. Next, the second application of rule ‘
L’ changes ‘p2
p3’ in ‘p2, p3’ and the second application of rule ‘—o L’ corresponds to the firing of t2. The last rule of the proof is ‘
R’ - it indicates that if two sequents are true independently of each other, they are also true when combined. The application of rule ‘
R’ results only in identity sequents, which are true by definition. As a consequence, the proof is complete and it can be stated that the initial sequent is true, i.e., the final marking is reachable from the initial marking. 4.2.2.2 Backward Reasoning In the backward reasoning, the connector
is replaced by the connector . The proof corresponds to firing the transition in the backward direction, i.e., the marking before the transition firing is obtained from the marking after the transition firing.
4 Hybrid System Analysis
81
Id Id Id Id p3 ¸ p3 p2 ¸ p2 p5 ¸ p5 p4 ¸ p4
R
R p2, p5¸ p2
p5 p4, p3 ¸ p3
p4 —o L (t2) p4, p2, p3, p3
p4 —o p5¸ p2
p5 Id
L p4, p2
p3, p3
p4 —o p5¸ p2
p5 p1 ¸ p1 —o L (t1) p1, p4, p1 —o p2
p3, p3
p4 —o p5¸ p2
p5
L p1
p4, p1 —o p2
p3, p3
p4 —o p5¸ p2
p5 M0
t1, t2
Mf
Fig. 4.4. Example of proof using the forward reasoning
The proof of the reachability of a Petri net marking is made considering that: x x x
An atom ‘p’ is associated with each place ‘p’ of the Petri net. A monomial using the connector is associated with each marking that is the pre or post-condition of a transition. An imply formula is defined for each transition ‘t’ of the Petri net: t: pi (i Pre (pi,t)) —o pj (j Post (pj,t))
Example: Fig. 4.5 presents the transitions of the Petri net of Fig. 4.3 according to the backward reasoning. p2 t1 p1
Definition of transitions: t1: p1 —o p2 p3 t2: p3 p4 —o p5
t2 p3 p4
p5
Fig. 4.5. Definition of transitions in the backward reasoning
The reachability proof in the backward reasoning is similar to the proof in the forward reasoning but using the rules ‘ R’, ‘ L’ and ‘—o L’. Example: Fig. 4.6 presents the proof tree for the same problem of Fig. 4.3, but now using the backward reasoning. In this case, the first rule applied in the initial sequent is ‘ R’. It is equivalent to the rule ‘
L’ of the backward reasoning, as both connectors behave in a similar way when on opposite sides of the sequent. The application of rule ‘ R’ means that the tokens in p2 and p5 do not need to be produced simultaneously. Similarly, the rule ‘ L’ corresponds to the ‘
R’.
82
Modelling and Analysis of Hybrid Supervisory Systems
Id Id Id Id p2 ¸ p2 p3 ¸ p3 p1 ¸ p1 p4 ¸ p4 L L p2 p3 ¸ p2, p3 p1 p4 ¸ p1, p4 —o L (t1) p1 p4, p1 —o p2 p3 ¸ p2, p3, p4 Id R p5 ¸ p5 p1 p4, p1 —o p2 p3 ¸ p2, p3 p4 —o L (t2) p1 p4, p1 —o p2 p3, p3 p4 —o p5¸ p2, p5 R p1 p4, p1 —o p2 p3, p3 p4 —o p5¸ p2 p5 M0
t1, t2
Mf
Fig. 4.6. Example of proof using the backward reasoning
4.2.3 Linear Logic for the Search of Scenarios in Petri Nets In the previous section, the linear logic is used for proving the reachability of a final marking when the initial marking and the set of transitions that must be fired are known. In other words, the truth of the sequent is proved for a specific scenario. However, in many problems, this information is only partially known. An example is when the set of events that leads to the final marking is partially defined (it is known that some events are in the scenario, but not all the events of the scenario are known) or completely unknown. Another example is when the initial (or final) marking are partially defined. The number of tokens in some places of the Petri net (e.g. the state of some machines of the system) is known, but not all the tokens of the initial or final marking are known. When the markings and transition firings are only partially known, the purpose of building the proof tree of the corresponding linear logic sequent is to find all the scenarios that ‘fit’ this partial definition. These scenarios indicate the possible causality between the partial initial and final markings. When using linear logic to search for scenarios, the sequent is written in the following ways: x x
Forward reasoning: ‘*0, M0, !t1, ..., !tn |–– Mf
*f’ Backward reasoning: ‘*0 M0, !t1, ..., !tn |–– Mf, *f’
The sequent components have the following meaning: x x x
!ti indicates an unknown number of firings of transition ti. It means that the scenarios taking from M0 to Mf can have zero or infinite firings of ti. *0 indicates an unknown set of tokens that, additionally to M0, are necessary to reach Mf. In the forward reasoning, the tokens are connected by ‘,’ and, in the backward reasoning, they are connected by ‘’. *f indicates an unknown set of tokens that, additionally to Mf, are generated from *0 and M0. In the forward reasoning, the tokens are connected by ‘
’ and, in the backward reasoning, they are connected by ‘,’.
4 Hybrid System Analysis
83
The search for scenarios is performed by building the proof tree. In this case, whenever two transitions are enabled, two proof trees are generated, corresponding to two possible scenarios. In the forward reasoning, each building of the proof tree is interrupted when marking Mf is reached. In the backward reasoning, it is interrupted when M0 is reached. Example: For the Petri net of Fig. 4.7, the aim is to find all the scenarios that lead from an initial marking containing p2 to a final marking containing p6: M0 = p2 and Mf = p6. The set of transition firings is unknown and no restriction is made. p1
p4 t1
p3
t3
p2
p5
t4
p6
t2
Fig. 4.7. Example
Example – Forward reasoning: The sequent to be analysed is: ‘*0, p2, !t1, ..., !t5 |–– p6
*f’. The proof trees resulting from this sequent are presented in Fig. 4.8. They correspond to the scenarios that lead from ‘*0, p2,’ to ‘p6
*f’. From the partial initial marking p2, two transitions can be fired (t2 and t1), resulting in two possible scenarios. These are the transitions that have p2 as pre-condition. In the case of t1, the pre-condition is ‘p1
p2’. As a consequence, a scenario starting with the firing of t1 is possible only if *0 contains a token in p1. The unknown initial marking *0 is therefore replaced by ‘*0’, p1’. For each scenario, once the marking on the left side of the sequent contains the known final marking (p6), the solution is obtained by making ‘*0i = ’ and attributing to *f all the other tokens on the left side of the sequent other than that of Mf. Scenario 2 Events: t1, t3, t4 *0 = *0’, p1 *0 = p1 *0’ = *f = p4
p5¸ p5 *0’, p4, p6, !t1, !t2, !t3, !t4¸ *f
p6 —o L (t4) *0’, p4, p5, !t1, !t2, !t3, !t4¸ *f
p6 Scenario 1 Events: t2, t4
L *0 = *f = p3¸ p3 *0’, p4
p5, !t1, !t2, !t3, !t4¸ *f
p6 —o L (t3) p1,p2¸ p1
p2 *0’, p3, !t1, !t2, !t3, !t4¸ *f
p6 p5¸p5 *0, p6, !t1, !t2, !t3, !t4¸ *f
p6 —o L (t4) —o L (t1) *0’, p1, p2, !t1, !t2, !t3, !t4¸ *f
p6 p2¸p2 *0, p5, !t1, !t2, !t3, !t4¸ *f
p6 —o L (t2)
Firing of t2
Firing of t1
*0, p2, !t1, !t2, !t3, !t4 *f
p6
Fig. 4.8. Search for scenarios – example of forward reasoning
84
Modelling and Analysis of Hybrid Supervisory Systems
Example – Backward reasoning: The sequent to be analysed is: ‘*0 p2, !t1, ..., !t5 |–– p5, *f’. The proof trees resulting from this sequent are presented in Fig. 4.9. From the partial final marking p6, transition t4 is fired, resulting in the partial marking p5. Then, two transitions can be fired (t2 or t3), resulting in two possible scenarios. In the case of t3, the post-condition is ‘p4 p5’; therefore, the scenario is possible only if *f contains a token in p4. This means that *f must be replaced by ‘*f’, p4’. Once the marking on the right side of the sequent contains the known initial marking (p2), the proof tree is interrupted. The final solution is obtained by making ‘*fi = ’ and attributing to *0 the tokens on the right side of the sequent other than that of M0. Scenario 2 Events: t1, t3, t4 *f = *f’, p4 *f = p4 *f’ = *0 = p1 Scenario 1 Events: t2, t4 *0 = *f =
p3¸ p3 *0 p2, !t1, !t2, !t3, !t4¸ *f’, p1p2 —o L (t1) *0 p2, !t1, !t2, !t3, !t4¸ *f’, p3 p4 p5¸ p4,p5 —o L (t3) p6 p6 *0 p2, !t1, !t2, !t3, !t4 *f, p2 *0 p2, !t1, !t2, !t3, !t4¸ *f’, p4, p5 —o L (t2)
Firing of t2
Firing of t3
p6¸ p6 *0 p2, !t1, !t2, !t3, !t4¸ *f, p5 —o L (t4) *0 p2, !t1, !t2, !t3, !t4¸ *f, p6
Fig. 4.9. Search for scenarios – example of backward reasoning
Up to this point, it has been shown how linear logic and Petri net can be combined in order to make reachability proofs and derive scenarios. The Petri net used in both cases is an ordinary Petri net. The next section discusses the advantages of using linear logic when the object-oriented paradigm is incorporated into the Petri net formalism, which is the case of OO-DPT net. 4.2.4 Linear Logic and the Object-oriented Paradigm The use of the object-oriented paradigm when building the OO-DPT models ensures modularity and well-defined interfaces. Owing to these features, the use of linear logic for analysing the discrete part of the OO-DPT net presents two important advantages: it allows the use of local approach that does not need to include the state and events of the whole system, and it explores the partial order of events instead of a totally ordered sequence. The local approach means that a property can be verified by only analysing part of the system, independently of the transition firings and markings of the remaining part of the OO-DPT net. In object-oriented models, it means that the internal evolution of an object between two interactions with other objects is completely independent of the internal evolution of other objects. In the same way, the
4 Hybrid System Analysis
85
evolution of a set of objects is independent of the evolution of the other objects as long as there is no interaction between them. Example: The sequent ‘p1_1.O1, p2_1.O1, t1_1.O1, t2_1.O1, t3_1.O1|–– p5_1.O1
p6_1.O1’ represents the reachability between two states of object O1.1. None of the transitions t1_1.O1, t2_1.O1, t3_1.O1 belongs to the object interface. If this sequence is true, then the following sequent is also true ‘īA, p1_1.O1, p2_1.O1, t1_1.O1, t2_1.O1, t3_1.O1|–– p5_1.O1
p6_1.O1
īB’. *A is any set of propositions that correspond to tokens and transition firings in other objects of the system, *B is a monoid in
(set of tokens) and *A |–– *B represents a scenario occurring concurrently in the other objects. For example, if a second sequent, ‘p7_2.O1, t4_2.O1, t5_2.O1|–– p9_2.O1’, modelling the evolution of another object is also true, then both sequents can be combined using the rule ‘
R’. This means that proving the two sequents separately is equivalent to making the proof of a global sequent including states and events of the two objects (Fig. 4.10): p 1_1.O1, p2_1.O1, t1_1.O1, t2_1.O1, t3_1.O1|–– p 5_1.O1
p 6_1.O1 p7_2.O1, t4_2.O1, t5_2.O1|–– p 9_2.O1
R p 1_1.O1, p2_1.O1, p7_2.O1, t1_1.O1, t2_1.O1, t3_1.O1, t4_2.O1, t5_2.O1|–– p 5_1.O1
p 6_1.O1
p 9_2.O1
Fig. 4.10. The local focus of linear logic
On the other hand, if instead of using linear logic, one decides to use another analysis method such as the graph of reachable markings (Murata, 1989) then the results of local analysis cannot be combined directly. The graph for the evolution of two objects does not result from the direct association of the graphs of each object. Instead, it shows all the possible states of the system from a global point of view. Example: Fig. 4.11 presents the graph of the reachable markings resulting from the analysis of O1.1 and O1.2 separately and combined into a single object. In this case, the number of states is increased from 7 local states to 20 global states. O1.1 + O1.2 {p1_1.O1, p2_1.O1, p7_2.O1}
O1.2
O1.1 {p1_1.O1, p2_1.O1} t1_1.O1
t4_2.O1
{p3_1.O1} t2_1.O1
{p8_2.O1} t5_2.O1
{p4_1.O1} t3_1.O1
{p9_2.O1}
{p5_1.O1, p6_1.O1}
t4_2.O1
t1_1.O1
{p7_2.O1}
{p3_1.O1, p7_2.O1}
{p4_1.O1, p7_2.O1} t3_1.O1
t1_1.O1
{p1_1.O1, p2_1.O1, p9_2.O1}
{p3_1.O1, p8_2.O1} t4_2.O1
t2_1.O1
{p5_1.O1, p6_1.O1, p7_2.O1} t4_2.O1
{p1_1.O1, p2_1.O1, p8_2.O1} t5_2.O1
t4_2.O1
t2_1.O1
{p4_1.O1, p8_2.O1} t3_1.O1
{p5_1.O1, p6_1.O1, p8_2.O1} t5_2.O1
t1_1.O1
t5_2.O1
t5_2.O1
{p3_1.O1, p9_2.O1} t2_1.O1
{p4_1.O1, p9_2.O1} t3_1.O1
{p5_1.O1, p6_1.O1, p9_2.O1}
Fig. 4.11. Analysis using the graph of reachable markings
86
Modelling and Analysis of Hybrid Supervisory Systems
Another important advantage of using linear logic is that the scenarios are defined considering the partial order of events (transition firings), i.e., the causality among them, and not their temporal sequence. Example: For objects O1.3 and O1.4 of Fig. 4.12, the system evolution from the initial state {p1_3.O1, p1_4.O1} to the final state {p5_3.O1, p5_4.O1} is represented by the proof tree of the sequent ‘p1_3.O1, p1_4.O1, t1_3.O1/1_4.O1, t2_3.O1, t3_3.O1, t4_3.O1, t2_4.O1, t3_4.O1, t4_4.O1, t5_3.O1/5_4.O1 |–– p6_3.O1
p6_4.O1’. This proof tree is equivalent to a single partial order of events, i.e., a single scenario (illustrated in Fig. 4.13). The partial order shows that the firing of t2_3.O1 must occur between the firing of t1_3.O1/1_4.O1 and that of t5_3.O1/5_4.O1. However, it does not specify if the firing of t2_3.O1 happens before or after the firings of transitions t2_4.O1, t3_4.O1 and t4_4.O1. Only the causality between the events is considered when specifying the scenarios based on the partial order of events. On the other hand, if the graph of reachable markings is built, an excessive number of states will be found and 20 possible temporal sequences of events, i.e., 20 transition firing sequences. The analysis of these 20 completely ordered sequences will bring no more information than the analysis of the single scenario based on the partial order of events. Object O1.3 p1_3.O1
p2_3.O1 t2_3.O1 p3_3.O1 t3_3.O1 p4_3.O1 t4_3.O1 p5_3.O1 t1_3.O1/1_4.O1
p6_3.O1
t5_3.O1/5_4.O1
Object O1.4 t1_4.O1/1_3.O1 p1_4.O1
t5_4.O1/5_3.O1
p2_4.O1 t2_4.O1 p3_4.O1 t3_4.O1 p4_4.O1 t4_4.O1 p5_4.O1
p6_3.O1
Fig. 4.12. OO-DPT net of objects O1.3 and O1.4
t2_3.O1
t3_3.O1
t4_3.O1
t5_4.O1/5_3.O1 t1_4.O1/1_3.O1 t2_4.O1
t3_4.O1
t4_4.O1
Fig. 4.13. Partial order of events for the objects O1.3 and O1.4
4.3 Analysis Method for OO-DPT Nets This section presents a method based on linear logic for proving properties in OODPT nets.
4 Hybrid System Analysis
87
4.3.1 Main Features of the Method 4.3.1.1 Decomposition of the Analysis Process One of the main features of the method developed for analysing OO-DPT nets is the decomposition of the analysis process. In order to determine the possible scenarios for the system evolution, the evolution of each object is considered separately from the evolution of the remaining objects. During the specification of scenarios, whenever a communication between the object under analysis and the remaining objects is possible, an obligation of analysis is generated. An obligation of analysis means that the veracity of a property verified in a certain object depends on the behaviour of other objects that interact with it. These objects must therefore be analysed. The new analysis may result in a new set of obligations. The process goes on until all the obligations of analysis have been performed (Fig. 4.14). Obligation of analysis
Analysis of Object 1
Analysis of Object 2 Analysis of Object 4
Analysis of Object 5
Analysis of Object 3 Analysis of Object 6
Fig. 4.14. Decomposition of the analysis process
4.3.1.2 Introduction of Hypothesis When an object is being analysed, it may be convenient to make hypotheses about its behaviour and its interaction with other objects. A hypothesis is an assumption that may simplify the analysis process. It is considered true temporarily and must be proven at the end of the analysis process. The hypotheses are made by the person who is performing the analysis process and are based on the person’s knowledge about the system under analysis. The veracity of a property is conditional to the veracity of the hypotheses. All the hypotheses must be true in order to verify the property. A hypothesis is like an intermediate lemma in a mathematical proof. The hypothesis is not necessary for proving the property, but it decomposes and may significantly simplify the proof. 4.3.1.3 Use of Linear Logic An important feature of the OO-DPT analysis approach is that it separates the analysis of the discrete dynamics from the analysis of the continuous one. The association of Petri nets and linear logic is used for the discrete dynamics. It is important to highlight that this association does not distinguish one token in a place from another token in the same place. All the tokens in a place are represented by identical propositions. As a consequence, it is necessary to analyse the unfolded version of the OO-DPT net (Section 2.5.3), where the state of each object of a class is represented in a different net. The analysis approach is therefore restricted to the problems where the number of objects of the system is fixed and known.
88
Modelling and Analysis of Hybrid Supervisory Systems
4.3.2 Overview of the Analysis Method The method for validating the supervisory system through the OO-DPT net can be organized into a set of steps, according to Fig. 4.15. For each property: Step 1: Specification of the property statement
Step 2: Specification of the set of restrictions
Step 3: Building the static collaboration diagram
For each property: Step 4: Analysis of the first object: Step 4.1: Analysis of the discrete dynamics – search for scenarios
Step 4.2: Elaboration of hypotheses
Step 4.3: Analysis of the continuous dynamics – evolution of the continuous variables and calculation of the transition firings dates
Step 5: Analysis of the other objects: For each object that must be analysed: Step 5.1: Analysis of the discrete dynamics – search for scenarios
Step 5.2: Elaboration of hypotheses
Step 5.3: Analysis of the continuous dynamics – evolution of the continuous variables and calculation of the transition firings dates
Step 6: Building the global sequents (only for the reachability properties)
Step 7: Verification of hypotheses
Fig. 4.15. Steps for the validation of hybrid supervisory systems
The analysis begins by establishing a set of properties to be verified. This set of properties must ensure a correct behaviour of the system under the control of the supervisory system. It is based on the system requirements. Particularly, in this book, two different kinds of properties are considered: reachability properties and safety properties. The reachability properties ensure that a certain state is always
4 Hybrid System Analysis
89
reached under some specific circumstances. A typical example is the guarantee that a request made by a user of the system is always performed successfully under normal operation conditions. In the case of the elevator system of a building, it can be the guarantee that the elevator will always stop in the floor selected by the occupants unless there is a fire in the building. The safety properties ensure that states considered dangerous or forbidden will never be reached, no matter what happens in the system. For the elevator system of a building, it can be the guarantee that, in the case of a fire, the elevator will never be blocked with the doors closed because this state may put the life of the occupants in danger. Safety properties can also be analysed under specific circumstances. A property is composed of two parts: the statement to be proven (defined in Step 1) and the restrictions (defined in Step 2). Not all the properties have restrictions. In this book, two kinds of statement (PR1 and PR2) are specified for the reachability properties, and one (PS1) for the safety properties. The restrictions delimit the conditions under which the property is expected to be true. They can regard the system states or the occurrence of events. In this book, 6 possible kinds of restrictions (R1 to R6) are considered. Once the set of properties is specified, Step 3 consists of building the static collaboration diagrams. They illustrate all the possible interactions among objects and, therefore, the obligation of analysis that may be generated when verifying a property. For each property, the verification starts with the analysis of the first object (Step 4). The analysis of this object may result in the obligation of analysis for other objects and so on – this is Step 5. In both Steps 4 and 5, the analysis of an object is divided into 3 main activities: x
x
x
Step 4.1/5.1 – Analysis of the discrete dynamics – search for scenarios: this step consists of determining the set of scenarios that illustrate the evolution of the object under the circumstance imposed by the property. It uses the procedure described in 4.3.3. The search is made without considering the interaction of the object with other objects (interface transitions are treated in the same way as internal transitions). Step 4.2/5.2 – Elaboration of hypotheses: the hypotheses are made about the internal behaviour of the object under analysis, or the interaction of the object with other objects of the model. These hypotheses limit the set of possible scenarios found in Step 4.1/5.1, the set of possible intervals for the date of transition firings, or the behaviour of the continuous variables. Step 4.3/5.3 – Analysis of the continuous dynamics – evolution of the continuous variables and calculation of the transition firings dates: the analysis of an object is concluded by determining the possible intervals for the date of transition firings and the values of the continuous variables, considering the junction functions, the enabling functions and the equation systems of the object model.
The analysis of the objects results in a set of scenarios that may or not obey the property. In the first case, the property is considered true if the hypotheses are also proven. In the second case, no conclusion is obtained: the property could either be
90
Modelling and Analysis of Hybrid Supervisory Systems
false or the hypotheses imposed during the analysis process may be unnecessary restrictions that prevent the verification of the property. For the reachability properties, in case the scenarios satisfy the property, Step 6 consists of building a global sequent for each scenario. This sequent results from the composition of the sequents of Steps 4.1 and 5.1. By building the proof tree of the global sequence, the consistency of the composition of the single object analyses is ensured. Finally, Step 7 is the verification of the hypotheses. Although the sequence of steps is the same for reachability and safety properties, the way each step is detailed is different. Section 4.3.3 details each step for the reachability properties while Section 4.3.4 deals with the safety properties. In order to illustrate the analysis method, a packing system is used as an example. Example: Fig. 4.16 presents the packing module of a yogurt production system. The yogurt is poured into packages of 4 units. The packing module is composed of two machines: Machine 1, which puts the plastic package in the correct position, and Machine_2, which pours the yogurt. The model of the system is composed of two objects: O1.1 – Machine 1 and O1.2 – Machine 2. Variables VR and VC (of O1.2) model the volume of yogurt in the tank of Machine 2 and in the unit that is being filled, respectively. The flow of yogurt entering the tank of Machine 2 is given by the external variable q. The variable N (of O1.1) indicates the number of units in a package that have already been filled. A fault occurs when the tank is empty (firing of t3_1.2). This is an example of safety property: the state tank empty (place p4_1.2) should never be reached. An example of reachability property to be verified is if the initial conditions allow the complete production of a package, i.e., there is a possible sequence of firings that results in the firing of t5_1.1. The initial state of the system is: x
O1.1 – Machine 1 X1.1: N = 0; Taux = 0; I1 = Machine 2; m1.1 = {p1_1};
x
O1.2 – Machine 2 X1.2: VR = undefined; VC = 0; m1.2 = {p1_2};
4.3.3 Reachability Property 4.3.3.1 Step 1: Specification of the Property Statement The following statements specify the reachability properties treated in this book: x x
PR1: Once an event e0 occurred, another event ef always occurs in a time interval of 'Tmax. PR2: Once an event e0 occurred, another event ei always occurs in a time interval of 'Tmax. The occurrence of ei results in a state that is maintained until the occurrence of another event ef.
4 Hybrid System Analysis
Machine 2
91
O1.2 – Machine 2 Variables: Xint_1.2 = {VC, VR}; Xext_1.2 = {q}; Enabling functions: e2_1.2: VC = 20; e3_1.2: VR = 0; Junction function: j1_1.2: VC = 0; Equation systems: f1_1.2, f3_1.2: dVR/dT= q; f2_1.2: dVC/dT = 10; dVR/dT = q -10
Filling t1_1.2 Package with 4 units
p2_1.2 t2_1.2
p3_1.2
t3_1.2
p4_1.2
t4_1.2
p1_1.2 Idle
Fault Methods provided by the class: t1_1.2 – Fill a new unit t3_1.2 – Confirm unit filled
Machine 1
Empty tank
O1.1 – Machine 1
t1_1.1
p1_1.1
p2_1.1 t2_1.1
p3_1.1
t3_1.1
Filling p4_1.1 t4_1.1
t5_1.1 p5_1.1
Withdraw the package
t6_1.1 Idle
Put a new package
Variable: Xint_1.1 = {I1, N, Taux}; External methods provided by the class: t1_1.1 – Fill a new package Methods used by the class: t3_1.1 o t1_I1.2 – Fill a new unit t4_1.1 o t4_I1.2 – Confirm unit filled
Turn the package Enabling functions: e5_1.1: N = 4; Taux = 2; e6_1.1: N < 4; Taux = 1; e2_1.1: Taux = 2; Junction functions: j2_1.1: N = 1; Taux = 0; j4_1.1: Taux = 0; j6_1.1: N =N+1; Equation systems: f2_1.1, f5_1.1: dTaux/dT = 1
Fig. 4.16. Packaging system and the OO-DPT net model
The events e0, ei and ef are specified in one of the following ways: x
As the firing of an internal transition tx_w.y or of an interface transition tx_w.y/z_v.u of an object Ow.y.
x x
As the reaching of a state specified as a marking mw.y of an object Ow.y (mw.y may define the number of tokens in all or just some places of Ow.y). As the reaching of a state specified as a function of the values of the variables Xw.y of an object Ow.y.
It is important to observe that the reachability property does not impose that e0 occurs at the initial state of the system (T(e0)t0). The current state when event e0 occurs is not known. It could be any state reachable from the initial state of the system as long as event e0 is enabled in that state. Example: The packing system of Fig. 4.16 must verify the following reachability property: x
Property 1 (statement PR1): When a request for filling a package with yogurt arrives, Machine 1 must reach the state ‘Idle’ in 20 seconds. This is the maximum expected time for producing a package and affects all the production plans of the industry. In the case of Property 1:
-
Event e0 is the arrival of a request for filling a package with yogurt: e0 = firing of t1_1.1.
92
Modelling and Analysis of Hybrid Supervisory Systems
-
Event ef occurs when Machine 1 reaches the state ‘Idle’: ef = reaching of m1.1 = {p1_1.1}. The time interval is 'T= 20 seconds.
4.3.3.2 Step 2: Specification of the Set of Restrictions The specification of properties may contain restrictions. They limit the cases where the property is expected to be true. This book considers the following ways of specifying a restriction: x
An event occurs in a certain time interval: -
x
An event does not occur during a certain time interval: -
x
R1: An internal transition ta_c.b or an interface transition ta_c.b/d_f.e of an object Oc.b fires in TgdTdTh.
R2: An internal transition ta_c.b or an interface transition ta_c.b/d_f.e of an object Oc.b does not fire in TgdTdTh. R3: A state specified by the marking mc.b of an object Oc.b is not reached in TgdTdTh (mc.b may define the number of tokens in all or just some places of Oc.b). R4: A Boolean function of the variables Xc.b of an object Oc.b is true in TgdTdTh.
An object Oc.b is in a certain state during a certain time interval: -
R5: The marking of an object Oc.b is mc.b in TgdTdTh (mc.b may define the number of tokens in all or just some places of Oc.b). R6: The value of a variable of Xc.b of Oc.b is specified for TgdTdTh. The specification may be a fixed value, a set of possible values, or a value given by a mathematical expression.
It is important to observe that the limits of the time interval (Tg and Th) may be specified by an absolute value, such as Tg=0 (the restriction is valid from the initial state), or relative to the occurrence of an event, such as the firing of a transition ti_k.j (Tg=Ti_k.j). Example: Property 1 of the packing system of Fig. 4.16 is subjected to the following restriction: x
Restriction 1A1 (restriction statement R2): The filling process is not interrupted by a fault in Machine 2: -
1
t3_1.2 (= ta_c.b) does not fire in d T d f (Tg=0 and Th=f).
The book adopts the following rules to name properties and restrictions: properties are identified by integer numbers (e.g.: Property 1, Property 2). Restrictions are identified by a letter preceded by the integer number of the corresponding properties (e.g.: Restriction 1A, Restriction 1B, Restriction 2A).
4 Hybrid System Analysis
93
4.3.3.3 Step 3: Building the Static Collaboration Diagrams After the definition of the set of properties that must be verified, the next step is building the static collaboration diagrams. They differ from the UML collaboration diagrams of the modelling phase (Chapter 3) because, instead of containing the sequence of interactions for a specific scenario, the static collaboration diagram contains all the possible interactions among objects without specifying a chronological order. The static collaboration diagram illustrates the possible obligations of analysis generated when an object is analysed. Example: Fig. 4.17 presents the static collaboration diagram for the packing system of Fig. 4.16: External entity
External entity
o t1_1 O1.1 – M1
q t3_1 o t1_2
O1.2 – M2
t4_1 o t4_2
Fig. 4.17. Static collaboration diagram for the packing system
The next steps (Steps 4 to 6) consist in determining what the possible scenarios from the occurrence of event e0 are and if all these scenarios result in the occurrence of ef, therefore obeying the property. Initially, in Steps 4 and 5, the objects are analysed without considering the interactions with other objects. Using the forward reasoning, the scenarios for the object evolution in the time interval specified in the property statement ('Tmax) are determined. Next, in Step 6, the information obtained in the previous steps is used to verify the consistency of the local scenarios from a discrete point of view. This is done by building the proof tree of a global sequent that contains the initial states and transition firings of all the objects analysed. 4.3.3.4 Step 4: Analysis of the First Object The first object to be analysed is the one where event e0 occurs. The OO-DPT subnet of the object contains the transition, marking or variable related to the specification of e0. 4.3.3.5 Step 4.1: Analysis of the Discrete Dynamics The purpose of the search for scenarios is to determine what can happen in the first object analysed after the occurrence of event e0, from a discrete point of view. Each possible evolution, i.e., each sequence of transition firings, is a different scenario. The search for scenarios is performed using the forward reasoning (described in Section 4.2.3). The interface transitions are treated as internal transitions. When analysing an object Ow.y, the imply formulas of an interface transition tx_w.y/z_v.u (with the pre and post conditions of Ow.y and Ov.u) are replaced by the imply formula of a transition tx_w.y with only the pre and post conditions of object Ow.y.
94
Modelling and Analysis of Hybrid Supervisory Systems
The definition of the sequents to be analysed depends on the fact that ei and/or ef may or may not occur in the same object of e0 (generically called Ow.y). The following situations are possible (Fig. 4.18): x
Case 1: only e0 occurs in Ow.y – only one search is performed: -
x
Case 2: e0 and ei occurs in Ow.y – two searches are performed. The set of possible scenarios are the combination of the results of the two searches: -
x
Search 1: Evolution from e0 up to ei; Search 2: Evolution from ei;
Case 3: e0 and ef occurs in Ow.y– only one search is performed: -
x
Search 1: Evolution from e0;
Search 1: Evolution from e0 up to ef;
Case 4: e0, ei and ef occurs in Ow.y – two searches are performed. The set of possible scenarios are the combination of the results of the two searches: -
Search 1: Evolution from e0 up to ei; Search 2: Evolution from ei up to ef. undefined endpoint of the search
Search 1 e0 Case 1: time Search 1 e0
undefined endpoint of the search
Search 2 ei
Case 2: time Search 1 e0
ef
Case 3: time Search 1 e0
Search 2 ei
ef
Case 4: time
Fig. 4.18. Search for scenarios in the first object analysed – reachability properties
In Cases 2 and 4, the scenarios are the results of all the possible combinations of one scenario obtained in Search 1 with one scenario of Search 2. In Case 4, for example, if there are two possible sequence of events from e0 to ei, and three sequences from ei to ef, then there are 6 possible scenarios for the evolution of the analysed object.
4 Hybrid System Analysis
95
The sequent used in the search is composed of: *0, M0, !t1_w.y, ..., !tn_w.y, ti_w.y ¸ Mf
*f. The markings M0, Mf, the transition firing ti_w.y and the transition firings ‘!t1_w.y, ..., !tn_w.y’ are specified by the following rules: x x x
x x x x x x
Rule 1: If e0 is defined as the reaching of a marking mw.y, then M0 = mw.y in the sequent of Search 1. The same is valid for ei and the sequent of Search 2 (Cases 2 and 4). Rule 2: If e0 is defined as the firing of a transition tx_w.y (or tx_w,y/z_v.u), then M0 = post-condition of tx_w.y in the sequent of Search 1. The same is valid for ei and the sequent of Search 2 (Cases 2 and 4). Rule 3: If e0 is defined as a Boolean function of the variables of Xw.y, no information is given about the discrete state of the object from the discrete point of view. Search 1 must be decomposed into ‘n’ searches, where n is the number of reachable markings of the object. In each search, M0 is a different marking and *0 = . Rule 4: If ei is defined as the reaching of a marking mw.y, then Mf = mw.y and the firing of ti_w.y is eliminated from the sequent of Search 1 (Cases 2 and 4). Rule 5: If ei is defined as the firing of a transition tx_w.y (or tx_w.y/z_v.u), then ti_w.y = tx_w.y and Mf = post-condition of tx_w.y in the sequent of Search 1 (Cases 2 and 4). Rule 6: If ef is defined as the reaching of a marking mw.y, then Mf = mw.y and the firing of ti_w.y is eliminated from the sequent of Search 1 (Case 3) or Search 2 (Case 4). Rule 7: If ef is defined as the firing of a transition tx_w.y (or tx_w.y/z_v.u), then ti_w.y = tx_w.y and Mf = post-condition of tx_w.y in the sequent of Search 1 (Case 3) or Search 2 (Case 4). Rule 8: The set of firings ‘!t1_w.y, ..., !tn_w.y’ contains all the transitions of object Ow.y with the exception of ti_w.y and any transition firing limited by eventual restrictions of the property. Rule 9: In the sequent of Search 1 (Case 1) and Search 2 (Case 2), Mf = .
For Search 1 of Case 1 and Search 2 of Case 2, the search for scenarios is performed until the proof trees result in one of the following situations: x
x x
The sequent resulting from the application of the last rules is the same as a previous sequent found in the proof tree. It means that from that marking it is possible to execute a sequence of transition firings that will return to the same marking. As a consequence, this sequence can be performed any number of times. The sequent resulting from the application of the last rule corresponds to a state where no other transition is enabled. The number of firings of the proof tree is limited to a number arbitrarily defined. When the proof tree reaches this number, the search is interrupted. It is supposed that the number of transitions firings is large enough to allow for the verification of the property, i.e., for event ef to occur. In case it is not, the object analysis must be extended in order to include more events.
96
Modelling and Analysis of Hybrid Supervisory Systems
For the other cases, the search for scenarios is performed until the proof trees result in one of the following situations: x x x
The sequent resulting from the application of the last rule is the same as a previous sequent found in the proof tree. The proof tree results in the firing of ti_w.y or reaches marking Mf. The sequent resulting from the application of the last rule corresponds to a state where no other firing is enabled. In this case, for the property to be true, this scenario must be impossible.
Example: Property 1 of the packing system is an example of Case 3 of Fig. 4.18. The first object to be analysed is O1.1. The discrete dynamics analysis consists of determining all the scenarios from the emission of a request for filling a new package untill the system becomes idle (Search 1). x
Search 1 – Sequent specification - *0, M0, !t1_w.y, ..., !tn_w.y, ti_w.y ¸ Mf
*f:
x
According to Rule 2: M0 = post-condition of t1_1.1 = p2_1.1. According to Rule 6: ti_w.y is eliminated and Mf = p1_1.1. According to Rule 8: !t1_w.y, ..., !tn_w.y = !t1_1.1, !t2_1.1, !t3_1.1, !t4_1.1, !t5_1.1, !t6_1.1.
Search 1 – Building the sequent proof tree – After the firing of t4_1.1, the proof tree is divided into two, corresponding to the firing of t5_1.1 and t6_1.1. After the firing of t5_1.1, the search is interrupted because Mf is reached. After the firing of t6_1.1, the search is interrupted because the resulting sequent is the same as the one obtained after the firing of t2_1.1:
p5_1.1¸ p5_1.1 *0, p3_1.1, !t1_1.1, !t2_1.1, !t3_1.1, !t4_1.1, !t5_1.1, !t6_1.1¸ p1_1.1
*f —o L (t6_1.1)
p5_1.1¸ p5_1.1 *0, p1_1.1, !t1_1.1, !t2_1.1, !t3_1.1, !t4_1.1, !t5_1.1, !t6_1.1¸ p1_1.1
*f —o L (t5_1.1) Firing of t6_1.1
Firing of t5_1.1
p4_1.1¸ p4_1.1 *0, p5_1.1, !t1_1.1, !t2_1.1, !t3_1.1, !t4_1.1, !t5_1.1, !t6_1.1¸ p1_1.1
*f —o L (t4_1.1) p3_1.1¸ p3_1.1 *0, p4_1.1, !t1_1.1, !t2_1.1, !t3_1.1, !t4_1.1, !t5_1.1, !t6_1.1¸ p1_1.1
*f —o L (t3_1.1) p2_1.1¸ p2_1.1 *0, p3_1.1, !t1_1.1, !t2_1.1, !t3_1.1, !t4_1.1, !t5_1.1, !t6_1.1¸ p1_1.1
*f —o L (t2_1.1) *0, p2_1.1, !t1_1.1, !t2_1.1, !t3_1.1, !t4_1.1, !t5_1.1, !t6_1.1¸ p1_1.1
*f
x
Definition of the scenarios – Each scenario corresponds to a sequence of choices when the sequent tree is divided. Starting at p2_1.1, Scenario 1 corresponds to the case of firing t5_1.1 after the first firing of t4_1.1, i.e., the package is delivered after filling one unit of yogurt. Scenario 2 corresponds to firing t5_1.1 only after the second firing of t4_1.1, i.e., filling two units of yogurt. From the discrete point of view, as one can have any number of firings of t5_1.1 before reaching p1_1.1, there is an infinite number of scenarios. Each ‘Scenario i’ (1didf) corresponds to the case where the
4 Hybrid System Analysis
97
packaging system fills ‘i’ units of yogurt before delivering the package. In all the scenarios *0 = *f = . The firing order in each case is shown below and illustrated in Fig. 4.19 for Scenarios 1 to 4. When a scenario has more than one firing of the same transition, they are identified by a number in brackets: ... -
Scenario 1: t2_1.1; t3_1.1/1_1.2; t4_1.1/4_1.2; t5_1.1 Scenario 2: t2_1.1; t3_1.1/1_1.2(1); t4_1.1/4_1.2(1); t6_1.1; t3_1.1/1_1.2(2);
(2) t4_1.1/4_1.2 ; t5_1.1 Scenario 3: t2_1.1; t3_1.1/1_1.2(1); t4_1.1/4_1.2(1); t6_1.1(1); t3_1.1/1_1.2(2); (2) (2) (3) (3) t4_1.1/4_1.2 ; t6_1.1 ; t3_1.1/1_1.2 ; t4_1.1/1_1.2 ; t5_1.1
Scenario i: t2_1.1; t3_1.1/1_1.2(1); i*(t4_1.1/4_1.2(); t6_1.1(); t3_1.1/1_1.2();)
(i) t4_1.1/4_1.2 ; t5_1.1
Internal firings of O1.1 Scenario 1
Scenario 2 t5_1.1
t2_1.1
t2_1.1
t6_1.1
t3_1.1/
t4_1.1/
t3_1.1/
1_1.2
4_1.2
(1) 1_1.2
t4_1.1/ (1) 4_1.2
t5_1.1 t3_1.1/ (2) 1_1.2
t4_1.1/ (2) 4_1.2
Interface firings of O1.1 and O1.2
Scenario 3 t2_1.1 t3_1.1/ (1) 1_1.2
t4_1.1/ (1) 4_1.2
Scenario 4 t2_1.1 t3_1.1/ (1) 1_1.2
t6_1.1(1)
t4_1.1/ (1) 4_1.2
t6_1.1(2) t3_1.1/ (2) 1_1.2
t4_1.1/ (2) 4_1.2
t6_1.1(1)
t5_1.1 t3_1.1/
t4_1.1/
(3) 1_1.2
(3) 4_1.2
t6_1.1(2) t3_1.1/ (2) 1_1.2
t4_1.1/ (2) 4_1.2
t6_1.1(3)
t5_1.1
t3_1.1/
t4_1.1/
t3_1.1/
t4_1.1/
(3) 1_1.2
(3) 4_1.2
(4) 1_1.2
(4) 4_1.2
Fig. 4.19. Firings of O1.1 for Scenarios 1 to 4 – Property 1
4.3.3.6 Step 4.2: Elaboration of Hypotheses Hypotheses are defined in the same way as restrictions are. Otherwise, differently of restrictions, hypotheses must be proved in order to be acceptable as true. In this book, 6 different ways of specifying hypotheses (H1 to H6) are considered, corresponding to restrictions R1 to R6. Example: In the analysis of O1.1 for Property 1 of the packaging system, the following hypothesis is created (numbering of hypotheses follows the same rule as the numbering of restrictions):
98
Modelling and Analysis of Hybrid Supervisory Systems
x
Hypothesis 1A (corresponding to specification H1): When requested by Machine 1, Machine 2 will always be available to start the filling of a new unit: t3_1.1/1_2.2 (= ta_c.b/d_f.e) fires as soon as t3_1.1/1_2.2 is enabled in O1.1.
4.3.3.7 Step 4.3: Analysis of the Continuous Dynamics The analysis of the continuous dynamics consists in determining the value of the continuous variables for each scenario. It also calculates the transition firing dates having as reference event e0, and verifies the viability of the scenarios under conflicting situations. The transition firing dates and the continuous variable values are interdependent: the enabling of transitions depends on the continuous variable values because of the enabling functions, and continuous variable values depend on the time of permanence in a given state and in the junction functions. Once the OO-DPT net does not impose restrictions on the type of differential equation systems or the expressions of the junction and enabling functions, it is not possible to specify an analytical procedure for determining the continuous dynamics of the objects. In many cases, the data needed to determine the dates of transition firing and the value of the variables for a specific scenario are not known. If this is the case, one must try to define intervals for the value of these variables, using the available information. Some common situations are: x
x
The object does not have enabling functions and public variables. Consequently, events e0, ei and ef are not related to the value of the variables. In this case, the evolution of the continuous variables does not influence the verification of the property and, therefore, is not calculated. The analysis of the scenario involves solving differential equation systems, enabling and/or junction functions that use image variables (variables from other objects). In this case, two approaches may be used: -
x
A hypothesis is made about the value of the image variable. The analysis of the current object is interrupted and the object that owns the image variable is analysed in order to determine its value.
The scenario includes firings of interface transitions. In this case, three approaches may be used: -
A hypothesis is made about the firing dates of the interface transitions.
-
-
The analysis of the current object is interrupted and the object that shares interface transitions is analysed in order to determine the firing dates. The property is proven for any date of transition firing.
The analysis of the continuous dynamics may reveal that some scenarios are impossible. An example is when the enabling function associated with one of the scenario transitions never becomes true. In this case, either the object has reached a deadlock (meaning that the property is not true), or another transition fires. The firing of a second transition corresponds to the execution of another scenario(s). In order to verify the property, one must analyse this scenario.
4 Hybrid System Analysis
99
Example: In the case of Property 1 of the packing system, the analysis of O1.1 shows that the only possible scenario is Scenario 4. All the other scenarios are impossible because the condition for delivering the yogurt package (firing of t5_1.1) is that 4 units have been filled (e5_1.1). For each scenario, the date of transition firings and the value of the variables are: x
Scenario 1:
-
x
T2_1.1 = T1_1.1 + 2 (from j1_1, f2_1 and e2_1); N=1 (from j2_1); T3_1.1/1_1.2 = T2_1.1 (from Hypothesis 1A); T4_1.1/4_1.2 t T3_1.1/1_1.2; e5_1.1: N=4 cannot be satisfied; therefore, Scenario 1 is impossible. Analysing the proof tree of O1.1, it can be seen that the firing of t5_1.1 is in conflict with the firing of t6_1.1. Once t5_1.1 cannot fire, then t6_1.1 may fire, leading to one of the other Scenarios i (i>1). As a consequence, for Property 1 to be true, one of the Scenarios i must be possible and must fulfil the property requirements.
Scenario 2:
-
T2_1.1 = T1_1.1 + 2 (from j1_1, f2_1 and e2_1); N=1 (from j2_1); T3_1.1/1_1.2(1) = T2_1.1 (from Hypothesis 1A); T4_1.1/4_1.2(1) t T3_1.1/1_1.2(1); T6_1.1 = T4_1.1/4_1.2(1) + 2 (from j4_1, f5_1 and e6_1); N=2 (from j6_1); T3_1.1/1_1.2(2) = T6_1.1 = T4_1.1/4_1.2(1) + 2 (from Hypothesis 1A); T4_1.1/4_1.2(2) t T3_1.1/1_1.2(2); e5_1.1: N=4 cannot be satisfied, therefore Scenario 2 is impossible. At least one of the Scenarios i (i>2) must be possible and must fulfil the property requirements.
x
Scenario 3: the analysis of this scenario is similar to the analysis of Scenarios 1 and 2. It also shows that Scenario 3 is impossible. At least one of the Scenarios i (i>3) must be possible and must fulfil the property requirements.
x
Scenario 4: -
T2_1.1 = T1_1.1 + 2; N=1; T3_1.1/1_1.2(1) = T2_1.1; T4_1.1/4_1.2(1) t T3_1.1/1_1.2(1) = T1_1.1 + 2; T6_1.1(1) = T4_1.1/4_1.2(1) + 1; N=2; T3_1.1/1_1.2(2) = T6_1.1(1) = T4_1.1/4_1.2(1) + 1; T4_1.1/4_1.2(2) t T3_1.1/1_1.2(2) = T4_1.1/4_1.2(1) + 1;ҏ T6_1.1(2) = T4_1.1/4_1.2(2) + 2; N=3; T3_1.1/1_1.2(3) = T6_1.1(2) = T4_1.1/4_1.2(2) + 1; T4_1.1/4_1.2(3) t T3_1.1/1_1.2(3) = T4_1.1/4_1.2(2) + 1; T6_1.1(3) = T4_1.1/4_1.2(3) + 2; N=4; T3_1.1/1_1.2(4) = T6_1.1(3) = T4_1.1/4_1.2(3) + 2;
100
Modelling and Analysis of Hybrid Supervisory Systems
-
-
x
T4_1.1/4_1.2(4) t T3_1.1/1_1.2(4) = T4_1.1/4_1.2(3) + 2; T5_1.1 = T4_1.1/4_1.2(4) + 2; N=1. In order to fulfil the property requirements, the following condition must be true: T5_1.1 - T1_1.1 < 20 T5_1.1 - T1_1.1 = [2 + (T4_1.1/4_1.2(1) - T3_1.1/1_1.2(1)) + 1 + (T4_1.1/4_1.2(2) T3_1.1/1_1.2(2)) + 1 + (T4_1.1/4_1.2(3) - T3_1.1/1_1.2(3)) + 1 + (T4_1.1/4_1.2(4) T3_1.1/1_1.2(4)) + 2] < 20.
Scenario i (for i>4): the analysis of these scenarios is similar to the analysis of Scenarios 1 and 2. For any value of i greater than 4, it results that Scenario i is impossible because the condition for firing t6_1.1(4) (e6_1: N<4) is never satisfied.
4.3.3.8 Step 5: Analysis of Other Objects Once the scenarios for the behaviour of the first object have been determined (Step 4), the next objects to be analysed are those sharing transitions and variables which are used in the scenarios. The analyses may result in new obligations of analysis and so on, until all the objects whose behaviour is relevant for the property are analysed. 4.3.3.9 Step 5.1: Analysis of the Discrete Dynamics The analysis of the second object is performed for each scenario resulting from the analysis of the first object. The analysis procedure is detailed as follows and illustrated in Fig. 4.20, where Ow.y is the first object analysed and the object under analysis is Ov.u. For each scenario, the analysis is divided into n+1 searches, where n is the number of interface transition firings between Ow.y and Ov.u in the scenario. In Fig. 4.20 these firings are named t1, t2, ..., tn. Each search determines the behaviour of Ov.u between two interface transition firings: Search 1 details the behaviour of Ov.u until the firing of t1, Search 2 between t1 and t2, and so on, until Search n, which details the behaviour of Ov.u after the firing of tn. Transitions of the interface between Ow.y and Ov.u
Events in Ow.y
e0
Searches in Ov.u Search 1
t1
t2
t1
t2 Search 2
t3
ef
t3 Search 3
Search 4
Fig. 4.20. Search for scenarios in the second analysed object – reachability properties
4 Hybrid System Analysis
101
The sequent used in the search is composed of: *0, M0, !t1_w.y, ..., !tn_w.y¸ Mf
*f. The markings M0, Mf and the transition firings ‘!t1_w.y, ..., !tn_w.y’ are specified by the following rules: x x x x
x x
Rule 10: For j = 1 to n, the sequent of Search j has Mf = pre-condition of tj. Rule 11: For j = 1 to n, the sequent of Search j+1 has M0 = post-condition of tj. Rule 12: The set of firings ‘!t1_u.Ov, ..., !tn_u.Ov’ has all the transitions of object Ov.u with the exception of the interface transitions between Ov.u and Ow.y, and any transition firing limited by the restrictions of the property. Rule 13: In the case of Search 1, if no information is given about the state of the object when e0 occurs, then Search 1 is decomposed into ‘m’ searches, where ‘m’ is the number of reachable markings of the object. In each search, M0 is a different marking and *0 = . Rule 14: In the case of Search n+1, if no information is given about the state of the object when the ef occurs, then Mf = . Rule 15: If n=0, M0 and Mf are defined according to Rules 13 and 14.
If the behaviour of Ov.u before the first interaction with Ow.y (firing of t1) and/or after the last interaction (firing of tn) is considered irrelevant for the property verification, then Search 1 and/or n+1 may not be performed. Search n+1 is performed until the proof trees result in one of the following situations: x x x
The sequent resulting from the application of the last rule is the same as a previous sequent found in the proof tree. The sequent resulting from the application of the last rule corresponds to a state where no other transition is enabled. The number of firings of the proof tree is limited to a number arbitrarily defined.
Searches 1 to n are performed until the proof trees result in one of the following situations: x x x
The sequent resulting from the application of the last rule is the same as a previous sequent found in the proof tree. The proof tree reaches the marking Mf; The sequent resulting from the application of the last rule corresponds to a state where no other firing is enabled. In this case, the property is true only if the scenario is impossible.
It is important to observe that a Scenario i, resulting from the analysis of the first object, may correspond to more than one possible behaviour in the second object which has been analysed. This means that, from a global view, there is more than one scenario but the behaviour of the first object is the same in all of them. These scenarios are named Scenario i-1, Scenario i-2, etc. Example: For Property 1 of the packaging system, the second object to be analysed is O1.2 – Machine 2. The only possible scenario resulting from the analysis
102
Modelling and Analysis of Hybrid Supervisory Systems
of O1.1 is Scenario 4, which has 8 interface transitions firing between O1.1 and O1.2. As a consequence, the analysis of O1.2 is divided into 9 searches: x x
Search 1 – This search is not performed because Hypothesis 1A imposes that t3_1.1/1_2.2 is immediately fired when enabled in O1.1. Searches 2, 4, 6 and 8 – The sequent is *0, p2_1.2, !t2_1.2¸ p3_1.2
*f (t3_1.2 is excluded because of Restriction 2A). The proof tree results in *0 = *f = and a single firing of t2_1.2: p2_1.2 p2_1.2 *0, p 3_1.2, !t2_1.2 p 3_1.2
*f —o L (t2_1.2) *0, p2_1.2, !t2_1.2¸ p3_1.2
*f
x
x x
Searches 3, 5 and 7 – The sequent is *0, p1_1.2, !t2_1.2¸ p1_1.2
*f. There is no need to build the proof tree because M0 = Mf. It means that *0 = *f = and there is no transition firings in these searches. Search 9 – The sequent is *0, p1_1.2, !t2_1.2¸ *f. There is no transition firing enabled. As a result, *0 = , *f = p1_1.2. Definition of the scenarios – The previous searches resulted in the following scenario for object O1.2 (Fig. 4.21):
-
Scenario 4: t3_1.1/1_1.2(1); t2_1.2(1); t4_1.1/4_1.2(1); t3_1.1/1_1.2(2); t2_1.2(2); t4_1.1/4_1.2(2); t3_1.1/1_1.2(3); t2_1.2(3); t4_1.1/4_1.2(3); t3_1.1/1_1.2(4); t2_1.2(4); t4_1.1/1_1.2(4). Scenario 4 Interface firings b etween O1.1 and O1.2
t3_1.1/
t4_1.1/ (1) 4_1.2
(1) 1_1.2
(1)
t3_1.1/
t4_1.1/ (2) 4_1.2
(2) 1_1.2
(2)
t2_1.2
t2_1.2
t3_1.1/
t4_1.1/ (3) 4_1.2
(3) 1_1.2
t3_1.1/
t4_1.1/ (4) 4_1.2
(4) 1_1.2
(3)
t2_1.2
(4)
t2_1.2
Internal firings of O1.2
Fig. 4.21. Firings of O1.2 for Scenario 4 – Property 1
4.3.3.10 Steps 5.2 and 5.3: Elaboration of Hypotheses and Analysis of the Continuous Dynamics These steps are performed in the same way as in Steps 4.2 and 4.3. Example: For Property 1 of the packaging system, no hypothesis is made when analysing O1.2. The analysis of the continuous dynamics results in: x
Scenario 4:
-
T2_1.2(1) = T3_1.1/1_1.2(1) + 2 (from j1_2, f2_2 and e2_2); T4_1.1/4_1.2(1) = T2_1.2(1) = T3_1.1/1_1.2(1) + 2 (the only restriction from the side of O1.1 is T4_1.1/4_1.2(1) t T3_1.1/1_1.2(1)); T4_1.1/4_1.2(2) = T2_1.2(2) = T3_1.1/1_1.2(2) + 2;
4 Hybrid System Analysis
103
T4_1.1/4_1.2(3) = T2_1.2(3) = T3_1.1/1_1.2(3) + 2; T4_1.1/4_1.2(4) = T2_1.2(4) = T3_1.1/1_1.2(4) + 2; At this point, it is possible to verify the condition imposed by the analysis of O1.1 for Property 1 to be true: T5_1.1 - T1_1.1 = [2 + 2 + 1
-
+ 2 + 1 + 2 + 1 + 2 + 2] = 15 < 20
x
As the analysis of O1.2 does not require the analysis of other objects, Step 5 is finished. The only possible evolution for the packing system from the occurrence of event e0 is Scenario 4. According to the previous results, this scenario fulfils Property 1 (if Hypothesis 1A is true).
4.3.3.11 Step 6: Building the Global Sequents The composition of the object analyses may be verified from a discrete point of view by building a global proof tree for each scenario. In this case, the global sequent contains all the events of all the analysed objects, from e0 to ef. If the previous steps have been performed correctly, the sequents are true. For each scenario, the global sequent is composed of M0_T, T¸ Mf_T, where: x
x
x
M0_T: set of formulas connected by ‘,’. Each formula contains the marking ‘M0, *0’ resulting from Search 1 of an analysed object (in case Search 1 has not been performed, then it is composed of *0 from Search 2 and M0=precondition of t1). Mf_T: formula resulting from the composition of a set of formulas using connector ‘
’. Each formula of this set is the marking ‘Mf
*f’ of Search n+1 of an analysed object. T: set of formulas connected by ‘,’. Each formula contains the transition firings of all the searches of an analysed object.
Example: The global sequent for Scenario 4 of Property 1 of the packaging system is defined according to the previous statements. The proof tree is easily built by applying the linear logic rule ‘—o’. The partial order of transition firings is illustrated in Fig. 4.22. It shows the causality among the events in object O1.1 and O1.2. M0 _T = p2 _1.1, p1_1.2 from O1.1 from O1.2
Mf _T = p1_1.1, p1 _1.2 from O1.1 from O1.2
T = t2_1.1, t3_1.1/1_1.2, t4_1.1/4_1.2, t6_1.1, t3_1.1/1_1.2, t4_1.1/4_1.2, t6_1.1, t3_1.1/1_1.2, t4_1.1/4_1.2, t6_1.1, t3_1.1/1_1.2, t4_1.1/4_1.2, t5_1.1, t2_1.2, t2_1.2, t2 _1.2, t2_1.2
from O1.1
from O1.2
x
Global sequent for Scenario 4: p2_1.O1, p1_2.O1, t2_1.O1, t3_1.O1/1_2.O1, t4_1.O1/4_2.O1, t6_1.O1, t3_1.O1/1_2.O1, t4_1.O1/4_2.O1, t6_1.O1, t3_1.O1/1_2.O1, t4_1.O1/4_2.O1, t6_1.O1, t3_1.O1/1_2.O1, t4_1.O1/1_2.O1, t5_1.O1, t2_2.O1, t2_2.O1, t2_2.O1, t2_2.O1¸ p1_1.O1
p1_2.O1
104
Modelling and Analysis of Hybrid Supervisory Systems
t1_1.O1
t2_1.O1 t3_1.O1 /1_2.O1
t6_1.O1
t6_1.O1 t4_1.O1/ t2_2.O1
4_2.O1
t3_1.O1 /1_2.O1
t4_1.O1/ t2_2.O1
4_2.O1
t6_1.O1
t3_1.O1 /1_2.O1
t4_1.O1/ t2_2.O1
4_2.O1
t5_1.O1
t3_1.O1 /1_2.O1
t4_1.O1/ t2_2.O1
4_2.O1
Fig. 4.22. Transition firings for Scenario 4 – Property 1
4.3.3.12 Step 7: Verification of Hypotheses The verification of a hypothesis can be made using the same approach as the one for verifying a property, i.e., by searching all the scenarios connecting the events and states of the hypothesis. Another alternative is to analyse the behaviour of the OO-DPT net resulting from the composition of the objects related to the hypothesis. In this case, the verification can also be performed by building the reachability tree of this net or using other Petri net analysis techniques, such as place invariants. Example: Hypothesis 1A is verified by fusing the sub-nets of objects O1.1 and O1.2. The resulting net obeys the place invariant ‘p5_1.O1 + p1_1.O1 + p2_1.O1 + p3_1.O1 – p1_2.O1’. Considering the initial marking of the system, the following expression is true ‘p5_1.O1 + p1_1.O1 + p2_1.O1 + p3_1.O1 = p1_2.O1’. It implies that ‘p3_1.O1 d p1_2.O1’ and therefore whenever t3_1.1/1_1.2 is enabled in O1.1 (p3_1.O1 = 1), it is also enabled in O1.2 (p2_1.O1 d 1). 4.3.4 Safety Properties 4.3.4.1 Step 1: Specification of the Property Statement The safety properties considered in this book are defined according to the following statement: x
PS1: A forbidden state, specified as the marking mw.y of an object Ow.y, is never reached.
Example: The packing system of Fig. 4.16 must verify the following safety property: x
Property 2 (statement PS1): The state ‘Tank empty’ is never reached: mw.y = m1.2 = {p4_2.O1}.
4.3.4.2 Step 2: Specification of the Set of Restrictions Similar to the reachability properties, the safety properties may contain restrictions about the conditions under which they must be true. The restrictions are specified in the same way as for the reachability properties. Example: Property 2 of the packing system is submitted to the following restrictions: x
Restriction 2A (restriction statement R6): The value of the yogurt input flow in Machine 2 is between 7 and 15:
4 Hybrid System Analysis
x
105
q(T) (variable of X1.2=Xc.b) [7, 15], for dTdf (Tg=0 and Th=f).
Restriction 2B (restriction statement R8): The initial volume of the tank is between 20 and 30 litres: - VR(T)(variable of X1.2=Xc.b) [20, 30], , for T = 0 (Tg=Th=0).
4.3.4.3 Step 3: Building the Static Collaboration Diagrams This step is performed in the same way as for the reachability properties. 4.3.4.4 Step 4: Analysis of the First Object The first object to be analysed (Ow.y) is the one with the forbidden state (mw.y). The verification of safety properties uses the backward reasoning for determining the possible scenarios that result in the forbidden state. One must then prove that all the scenarios are impossible. In other words, for each scenario, there must be a transition (generically called ti_w.y) that will never be enabled (either because of a lack of tokens or because of the enabling function attached to it). 4.3.4.5 Step 4.1: Analysis of the Discrete Dynamics In order to determine the scenarios that result in mw.y, we must build the proof tree (Search 1) of the sequent: *0, !t1_w.y, ..., !tn_w.y¸ Mf, *f, where: x x
Rule 16: Mf = mw.y Rule 17: ‘!t1_w.y, ..., !tn_w.y’ contains all the transitions of Ow.y other than the ones forbidden by the restrictions associated with the property.
The search for scenarios is performed until: x x x
The sequent resulting from the application of the last rule is the same as a previous sequent found in the proof tree. The sequent resulting from the application of the last rule corresponds to a state where no transition is enabled. The number of firings of the proof tree is limited to a number arbitrarily defined.
For each scenario, one must choose a transition firing ti_w.y that will never happen in order to verify the property. Similar to the hypotheses, the person who is performing the analysis makes this choice which is based on his/her knowledge of the system. In case the property is not proven for the chosen transition firing, the choice must be modified and the analysis procedure must be redone. The following situations may inhibit the firing of a transition ti_w.y. The cases are illustrated in Fig. 4.23: x x
x
Case 1: ti_w.y has an enabling function that never becomes true. Case 2: There is a transition tj_w.y in conflict with ti_w.y. The enabling function of tj_w.y always becomes true before 'T>0) the enabling function of ti_w.y. Therefore, tj_w.y always fires instead of ti_w.y. Case 3: There is a transition tj_w.y in potential conflict with ti_w.y. The other pre-conditions of ti_w.y are always satisfied after ('T>0) the pre-conditions of tj_w.y. Therefore, tj_w.y always fires instead of ti_w.y.
106
Modelling and Analysis of Hybrid Supervisory Systems
x
Case 4: There is a transition tj_w.y in potential conflict with ti_w.y. One of the pre-conditions for the firing of ti_w.y can only be generated by the firing of tj_w.y. It means that ti_w.y will never have all the pre-conditions simultaneously satisfied.
Case 1 j1: x=1
p1
t1
e2: x=1
p2 t2 f 2: dx/dT= -1
Forbidden state
p3
e2: x=10 Case 2 t2
j1: x=1 p1
t1
p2 f 2: dx/dT=1
The forbidden state p3 is never reached because the enabling function e2 of transition t2 is never true.
Forbidden state
p3
The forbidden state p3 is never reached because the enabling function e3 of transition t3 alw ays becomes true before ('T>0) e2, ensuring the firing of t3 instead of t2.
e3: x=6 t3 t4
f 2: dx/dT=1
Forbidden state
e2: x=10
Case 3 j1: x=1 p1
t1
t2
p2
p4
p6
f 3: dy/dT=1 e3: y=6 t3
p3
p5
t3
t1
p2 t2
p3
p5
The forbidden state p5 is never reached because the precondition p4 of t5 is alw ays generated after ('T>0) the precondition p5 de t6, ensuring the firing of t6 instead of t5.
t6
Case 4
p1
t5
Forbidden state The forbidden state p4 is never reached because the pre-condition p3 of t3 is p4 generated by the firing of t2, which consumes the other pre-condition of t3 (p3). As a consequence, there never are tokens in p2 and p3 simultaneously.
t4
Fig. 4.23. Examples of Cases 1 to 4, where the firing of ti_w.y is impossible
For Cases 2, 3 and 4 the scenarios with the firing of ti_w.y are called forbidden scenarios (Scenario ip), while the scenarios with the firing of tj_w.y are called concurrent scenarios (Scenario ic). Example: For Property 2 of the packing system, the first object to be analysed is O1.2. The analysis of the discrete behaviour consists of the following search: x
Search 1 – *0, !t1_1.2, !t2_1.2, !t3_1.2, !t4_1.2¸ p3_1.2, *f:
4 Hybrid System Analysis
107
p1_1.2 p1_1.2 *0, !t1_1.2, !t2_1.2, !t3_1.2, !t4_1.2, !t5_1.O1, !t6_1.O1 p2_1.2, *f —o L (t2_1.2) p1_1.2¸ p1_1.2 *0, !t1_1.2, !t2_1.2, !t3_1.2, !t4_1.2, !t5_1.O1, !t6_1.O1¸ p4_1.2, *f —o L (t4_1.2) p2_1.2¸ p2_1.2 *0, !t1_1.2, !t2_1.2, !t3_1.2, !t4_1.2, !t5_1.O1, !t6_1.O1¸ p1_1.2, *f —o L (t1_1.2) p4_1.2¸ p4_1.2 *0, !t1_1.2, !t2_1.2, !t3_1.2, !t4_1.2, !t5_1.O1, !t6_1.O1¸ p2_1.2, *f —o L (t3_1.2) *0, !t1_1.2, !t2_1.2, !t3_1.2, !t4_1.2, !t5_1.O1, !t6_1.O1¸ p4_1.2, *f
x
Definition of the forbidden scenarios – There are infinite scenarios that, starting from the initial state, lead to the forbidden state. Each Scenario ip (1didf) corresponds to the case where ‘i - 1’ units are filled with yogurt before the tank of Machine 2 becomes empty. For all the scenarios, *0 = *f = . The transition firings for each scenario is, in the reverse order:
... x
Scenario ip: t3_1.2; t1_1.2/3_1.1(i); i*(t4_1.2/4_1.1(); t2_1.2(); t1_1.2/3_1.1());
Definition of the concurrent scenarios – For all the scenarios, the transition chosen for proving the property (the transition that is never enabled) is t3_1.2. From the discrete point of view, this transition is in conflict with t2_1.2; therefore, the following concurrent scenarios are determined:
... x
Scenario 1p: t3_1.2; t1_1.2/3_1.1; Scenario 2p: t3_1.2; t1_1.2/3_1.1(2); t4_1.2/4_1.1; t2_1.2(1); t1_1.2/3_1.1(1);
Scenario 1c: t2_1.2; t1_1.2/3_1.1; Scenario 2c: t2_1.2(2); t1_1.2/3_1.1(2); t4_1.2/4_1.1; t2_1.2(1); t1_1.2/3_1.1(1); Scenario ic: t2_1.2(i); t1_1.2/3_1.1(i); i*(t4_1.2/4_1.1(); t2_1.2(); t1_1.2/3_1.1());
Condition for Property 2 – Once there is no other pre-condition for the firing of t2_1.2 or t3_1.2, Property 2 must be verified by proving that after the firing of t1_1.2/3_1. 1, e2_2 always becomes true before e3_1.2 (Case 2).
4.3.4.6 Steps 4.2 and 4.3: Elaboration of Hypotheses and Analysis of the Continuous Dynamics These steps are performed in the same way as for the reachability property. They result in that the set of conditions for the forbidden scenarios is impossible. Example: For each scenario of Property 2 of the packing system, the date of transition firings and the value of the variables are: x
Scenarios 1p and 1c: - Date of transition firing for Scenario 1c: T2_1.2 = T1_1.2/3_1.1 + 2 (from j1_2, f2_2 and e2_2); - Date of transition firing for Scenario 1p: T1_1.2/3_1.1 d T3_1.2; - Condition 1 for Scenario 1p to happen instead of Scenario 1c: - T3_1.2 d T1_1.2/3_1.1 + 2; Value of continuous variables for Scenario 1p:
108
Modelling and Analysis of Hybrid Supervisory Systems
T3 _1.2
- VR(T3_1.2) = VR(T1_1.2/3_1.1) +
³
(q 10).dT ;
T1_1.2 / 3 _1.1
- VR(T1_1.2/3_1.1) = VR(); -
Best case for Scenario 1p: minimum q and minimum VR(): - VR(T3_1.2) t min(VR()) + (min(q)-10) * (T3_1.2T1_1.2/3_1.1)
-
Condition 2 for Scenario 1p to happen instead of Scenario 1c (from e3_2): - VR(T3_1.2) t 10–3*(T3_1.2T1_1.2/3_1.1) < 0; Best case for Scenario 1p: maximum (T3_1.2T1_1.2/3_1.1)=2
x
-
Replacing in Condition 2:
-
min(VR(T3_1.2)) = 10–3*2 = 4 > 0 (Condition 2 is not satisfied!) There is no value of (T3_1.2T1_1.2/3_1.1) that satisfies both conditions Therefore Scenario 1 is impossible.
Scenarios 2p and 2c: - Date of transition firing for Scenario 2c: T2_1.2(2) = T1_1.2/3_1.1(2) + 2 (from j1_2, f2_2 and e2_2); - Date of transition firing for Scenario 2p: T1_1.2/3_1.1(2) d T3_1.2; - Condition 1 for Scenario 2p to happen instead of Scenario 2c: T3_1.2 d T1_1.2/3_1.1(2) + 2; Value of continuous variables for Scenario 2p: T3 _1.2
VR(T3_1.2) = VR(T1_1.2/3_1.1(2)) +
³
(q 10).dT ;
T1_1.2 / 3 _ 1.1
-
Best case for Scenario 2p: minimum q, minimum VR(T1_1.2/3_1.1(2)) and maximum (T3_1.2 - T1_1.2/3_1.1(2)): - T1_1.2/3_1.1(2) t T4_1.2/4_1.1; - VR(T1_1.2/3_1.1(2)) t VR(T4_1.2/4_1.1) + min(q)* (T1_1.2/3_1.1(2)-T4_1.2/4_1.1); (2) - T4_1.2/4_1.1 t T2_1.2; - VR(T4_1.2/4_1.1) t VR(T2_1.2) + min(q)*(T4_1.2/4_1.1 - T2_1.2); (1) - T2_1.2 = T1_1.2/3_1.1 + 2; - VR(T2_1.2) t VR(T1_1.2/3_1.1(1)) + [min(q) - 10] * (T2_1.2 -T1_1.2/3_1.1(1)); - VR(T2_1.2) t VR(T1_1.2/3_1.1(1)) + [min(q) - 10] * 2; - VR(T1_1.2/3_1.1(1)) = VR() - VR(T3_1.2) t 10 + min(q) * [(T4_1.2/4_1.1 - T2_1.2) + (T1_1.2/3_1.1(2) – T4_1.2/4_1.1)] + [min(q)-10] * [(T3_1.2T1_1.2/3_1.1(2)) + 2]; - VR(T3_1.2) t 10 + 7 * [(T4_1.2/4_1.1 - T2_1.2(1)) + (T1_1.2/3_1.1(2) - T4_1.2/4_1.1)] - 3*[(T3_1.2T1_1.2/3_1.1(2)) + 2]; - min(VR(T3_1.2)) = 10 + 7 * [(T4_1.2/4_1.1 - T2_1.2(1)) + (2) (T1_1.2/3_1.1 - T4_1.2/4_1.1)] - 3*4;
4 Hybrid System Analysis
-
x
109
Condition 2 for Scenario 2p to happen instead of Scenario 2c (from e3_2): VR(T3_1.2) < 0; 10 + 7 * [(T4_1.2/4_1.1 - T2_1.2(1)) + (T1_1.2/3_1.1(2) - T4_1.2/4_1.1)] < 12; Object O1.2 must be analysed in other to determine the time intervals and verify Property 2.
Scenarios ip or ic: following the same procedure, the condition for a Scenario i (i>2) to be possible is: -
10+ 7*
i 1
¦ ª¬(T j 1
(j) 4_2.O1/4_1.O1
-T2_2.O1(j) ) (T1_2.O1/3_1.O1(j 1) -T 4_2.O1/4_1.O1(j) )º¼ <6*i
4.3.4.7 Step 5: Analysis of Other Objects The next objects to be analysed are those that have transitions or variables in the forbidden and concurrent scenarios. The procedure is similar to the one adopted for the reachability properties. However, instead of using the forward reasoning, the backward reasoning is used. As for the reachability property, the analysis goes on until all the objects that are relevant for the property have been analysed. 4.3.4.8 Step 5.1: Analysis of the Discrete Dynamics The analysis of the second object (Ov.u) is performed for each Scenario ip and ic resulting from the analysis of the first object (Ow.y). For each Scenario ip and ic, the analysis is divided into n+1 searches, where n is the number of interface transition firings between Ow.y and Ov.u in the scenario. These firings are called t1, t2, ..., tn. The sequent used in the search is composed of: *0 M0, !t1_w.y, ..., !tn_w.y¸ Mf, *f. The markings M0, Mf and the transition firings ‘!t1_w.y, ..., !tn_w.y’ are specified by the following rules: x x x
x
x x
Rule 18: For j = 1 to n, the sequent of Search j has Mf = pre-condition of tj. Rule 19: For j = 1 to n, the sequent of Search j+1 has M0 = post-condition of tj. Rule 20: The set of firings ‘!t1_u.Ov, ..., !tn_u.Ov’ contains all the transitions of object Ov.u with the exception of the interface transitions between Ov.u and Ow.y, and of any transition firings forbidden by the restrictions associated with the property. Rule 21: In the case of Search n+1, if no information is given about the state of the object when the forbidden state is reached, then Search n+1 is decomposed into ‘m’ searches, where ‘m’ is the number of reachable markings of the object. In each search, Mf is a different marking and *f = . Rule 22: For Search 1, M0 = . Rule 23: If n=0, M0 and Mf are defined according to Rules 21 and 22.
If the behaviour of Ov.u before the first interaction with Ow.y (firing of t1) and/or after the last interaction (firing of tn) is considered irrelevant for the property verification, then Search 1 and/or n+1 may not be performed.
110
Modelling and Analysis of Hybrid Supervisory Systems
In the case of Scenarios ic, after each firing (in the reverse order) it is important to verify that no other transition can be fired from the reached state. In other words, one must be sure that no other scenario is possible other than Scenario ic and the corresponding Scenario ip. The verification of the property must ensure that Scenario 1c always occurs. Example: For Property 2 of the packaging system, the second object to be analysed is O1.1 – Machine 1. For each Scenario ip or ic, the analysis of the discrete dynamics is divided into (1+2*i) searches: x x
Search (1+2*i) – From the firing of t1_1.2/3_1.1(i): this search is omitted because it is not relevant for the verification of the property. For j=1 to i, Search 2*j – From the firing of t4_1.2/4_1.1(j) to the pre-condition of t1_1.2/3_1.1(j): *0 p5_1.1, !t1_1.1, !t2_1.1, !t5_1.1, !t6_1.1,¸ p3_1.1, *f – The search results in two possible scenarios. In both cases, *0 = *f = : p31_1.1¸ p1_1.1 *0 p5_1.1, !t1_1.1, !t2_1.1, !t5_1.1, !t6_1.1¸ p5_1.1, *f —o L (t5_1.1) p2_1.1¸ p2_1.1 *0 p5_1.1, !t1_1.1, !t2_1.1, !t5_1.1, !t6_1.1¸ p1_1.1, *f —o L (t1_1.1) p3_1.1¸ p3_1.1 *0 p5_1.1, !t1_1.1, !t2_1.1, !t5_1.1, !t6_1.1¸ p2_1.1, *f —o L (t2_1.1)
p3_1.1¸ p3_1.1 *0 p5_1.1, !t1_1.1, !t2_1.1, !t5_1.1, !t6_1.1¸ p5_1.1, *f —o L (t6_1.1) Firing of t2_1.1
Firing of t5_1.1
*0 p5_1.1, !t1_1.1, !t2_1.1, !t5_1.1, !t6_1.1¸ p3_1.1, *f
x
x x
For j=1 to i, Search 2*j-1 – From the firing of t1_1.2/3_1.1(j) to the precondition of t4_1.2/4_1.1(j): *0p4_1.1, !t1_1.1, !t2_1.1, !t5_1.1, !t6_1.1¸ p4_1.1, *f – There is no need to build the proof tree because M0 = Mf. It means that *0 = *f = and there is no transition firings in these searches. Search 1 – This search is not performed because the date of firing (1) t1_1.2/3_1.1 is not relevant for the verification of the property. Definition of the scenarios – The possible scenarios result from the combination of Search 2j (for j=1 to i). Each Scenario ip and ic from the analysis of O1.2 is decomposed into 2i scenarios, called Scenarios ip-1, ic1, ip-2, ic-2, …, ic-2i. As an example, for i=2 the scenarios are: -
Scenarios 2p and 2c-1: t1_1.2/3_1.1(2); t6_1.1; t4_1.2/4_1.1; t1_1.2/3_1.1(1); Scenarios 2p and 2c-2: t1_1.2/3_1.1(2); t2_1.1; t1_1.1; t5_1.1; t4_1.2/4_1.1; t1_1.2/3_1.1(1);
4.3.4.9 Steps 5.2 and 5.3: Elaboration of Hypotheses and Analysis of the Continuous Dynamics These steps are performed in the same way as Steps 4.2 and 4.3. Similar to the reachability property, Step 5 must be performed until all the objects that are relevant for the property have been analysed.
4 Hybrid System Analysis
111
Example: In the case of Property 2 of the packing system, the analysis of the continuous dynamics of O1.2 leads to the following statements, valid for all the possible scenarios: x x x x
In the cases that the firing of t1_2.O1/3_1.O1 happens before the firing of t6_1.O1: (T1_2.O1/3_1.O1(j) - T4_2.O1/4_1.O1(j)) = 1 In the cases that the firing of t1_2.O1/3_1.O1 happens before the firing of t2_1.O1: (T1_2.O1/3_1.O1(j) - T4_2.O1/4_1.O1(j)) = 2 In all the cases: (T4_2.O1/4_1.O1(j)-T2_2.O1(j)) = 0; The condition for a Scenario ip to happen instead of the corresponding Scenario ic is: i 1
-
10+7* ¦ ª¬(T4_2.O1/4_1.O1(j) -T2_2.O1(j) ) (T1_2.O1/3_1.O1(j 1) -T4_2.O1/4_1.O1(j) )º¼ < 6*i j 1
-
x
i 1
i 1
j 1
j 1
10+7* ¦ [...] t10+7*min( ¦[...] ) = 10+7*i < 6*i
The condition cannot be satisfied; therefore, all the Scenarios ip are impossible. Property 2 is true.
4.3.4.10 Step 6: Building the Global Sequents This step is not performed for safety properties. 4.3.4.11 Step 7: Verification of Hypotheses This step is performed in the same way as for the reachability properties.
4.4 Final Remarks This chapter approached the problem of validating the hybrid supervisory system. The validation is performed by formally verifying properties of the OO-DPT net of the supervisory system + controlled object. Two kinds of properties have been presented: reachability properties, which aim to prove that a state is always reached under certain conditions, and safety properties, which aim to prove that dangerous and forbidden states are never reached. The method used for verifying properties in the OO-DPT net is divided into 7 steps: x x
x
Steps 1 and 2 are the definition of the properties to be verified for validating the supervisory system. Step 3 consists in building the static collaboration diagram of the system, showing the discrete and continuous relationships among the objects. The static collaboration diagram indicates the sequences in which the objects are analysed. Step 4 analyses the first object.
112
Modelling and Analysis of Hybrid Supervisory Systems
x x x
Step 5 refers to the analysis of the other objects that are relevant for the verification of the property. Step 6 builds global sequents for verifying the consistency of the analyses of Steps 4 and 5. Step 7 is the verification of hypotheses made during the previous steps.
The main feature of the analysis method presented in this chapter is modularity. Each object is analysed separately from the other objects. The method explores the natural decomposition of the model, resulting from the object-oriented paradigm, in order to decompose the analysis process. Another important feature is that the designer of the supervisory system can interfere in the analysis procedure by making hypotheses with the purpose of simplifying the analysis process. The hypotheses are based on the designer knowledge about the system. Each hypothesis is a supposition that is probably true. The hypothesis simplifies the analysis of an object but is not explicit in the model (it is implicit). Once the elaboration of the hypotheses depends on the model interpretation, a computer program cannot automatically make it. This is a disadvantage of the method when compared with the tools described in Section 4.1. However, the purpose of the method is not to be faster or simpler than these tools, but to be an alternative for the cases where the current solutions cannot provide an answer (because of undecidability). Even if the analysis method cannot be totally automatic, some steps can be implemented in software. An example is the search for scenarios using the linear logic sequents. The evolution of this method is in the direction of a balanced automation, in which computer and designer collaborate in a synergetic way to solve the analysis problems. Once that method uses linear logic, it focuses on the partial order of events for defining the scenarios. In this way, it reduces the number of scenarios that must be analysed. Regarding the continuous dynamics, the OO-DPT net does not impose restrictions on the type of differential equation systems or enabling and junction functions. The drawback is that the analysis of the continuous dynamics is not structured. It is important to observe that the method does not provide any guarantee of solution. Besides the decidability problem discussed in Section 4.2, the success of the method depends on decisions made by the designer. If he/she makes bad choices, such as false hypotheses or hypotheses that do not simplify the analysis, the method may result in an extremely large number of scenarios, or it can be inconclusive (it cannot be said that the property is either true or false).
5 Application 1: HVAC System
The purpose of this chapter is to illustrate the application of the modelling method described in Chapter 3. It also illustrates the analysis method described in Chapter 4 for the verification of a reachability property. Particularly, this chapter aims at highlighting the following features of the modelling and analysis methods: x x x
How the PFS models of Step 1 of the modelling method can be used for identifying the sharing of variables in closed loop. How the decomposition/composition relationship can be used for obtaining the OO-DPT net when the classes share variables in closed loop. How the generalisation/specialisation relationship can provide the reuse of OO-DPT subnets when dealing with systems with common features and components.
The application presented in this chapter is the HVAC (heating ventilation and air-conditioning) management system of a hospital. The models refer to a single zone of the main building of the Hospital das Clínicas da Faculdade de Medicina da Universidade de São Paulo (Clinical Hospital of the Medicine School of the University of São Paulo). A zone is a set of rooms under the control of a single controller. This chapter presents two different configurations for the HVAC system of the zone. They are called HVAC System A and HVAC System B. The comparison of the models of the two configurations highlights some of the advantages and limits of the approach described in this book for modelling and analysis of hybrid supervisory system. Following, Section 5.1 presents a description of HVAC Systems A and B, and the management system requirements. Section 5.2 details Steps 1 to 7 for the HVAC System A and Steps 1, 4 and 6 for the HVAC System B (Steps 2, 3, 5 and 7 are similar for both systems and therefore are only presented for HVAC System A). The analysis method is illustrated in Section 5.3 in which some properties of HVAC System A are verified.
114
Modelling and Analysis of Hybrid Supervisory Systems
5.1 Description of the HVAC Systems 5.1.1 Controlled Object The HVAC Systems A and B are illustrated in Fig. 5.1 and Fig. 5.2. In both configurations, a fan imposes a continuous airflow between the HVAC system and the conditioned environment (the building rooms). In the case of HVAC System A, all the air that enters the HVAC system is from outside the building. This air is sent through the cooling coil (Cooling Coil A), where it exchanges heat with the cold water. It is then supplied to the zone. In the case of HVAC System B, the air that passes through the cooling coil (Cooling Coil B) derives from the mixing of return air (air from the conditioned zone) and outside air. The mixing occurs in the Mixing Box B. After being conditioned, the mixed air is supplied to the rooms. Both HVAC systems operate with a constant volume of air. The temperature control is done by varying the temperature of the air supplied to the zone, while the amount of air is maintained constant. The regulation is achieved by varying the amount of cold water that is provided to the cooling coil. For this purpose, both systems use a three-way valve that bypasses part of the water flow. Another difference between the two configurations is the controller of the valve that determines the cold-water flow through the cooling coil. The HVAC System A uses an on/off controller, while the HVAC System B uses a PID (Proportional Integral Derivative) controller. In both systems, the temperature in the zone depends not only on the temperature of the supplied air but also on the thermal load produced by people and equipment present in the zone. Conditioned environment Zone A
HVAC System A Outside air
Heat produced by equipment
Cooling Coil A Fan A Supplied air
On/Off Controller
Heat produced by people
Water valve A T
Temperature sensor
Fig. 5.1. HVAC System A
5 Application 1: HVAC System
HVAC System B Outside air
Conditioned Environment Zone B
Mixing Box B
Heat produced by equipment
Return air
Outside air
115
Cooling Coil B
Heat produced by people
Fan B Supplied air
PID Controller
T
Temperature sensor
Water Valve B
Fig. 5.2. HVAC System B
5.1.2 The Management System Requirements The management system of HVAC system must provide the following functionalities: x x x x
It must act on the HVAC components according to the operating mode selected by the user. Three operating modes are provided to the user: off, ventilation and cooling. It must allow the HVAC operator to select the set point of the zone temperature. It must supervise the cooling coil operation, identify leakages, and inform the HVAC operator. In the occurrence of a fire (communicated by the fire management system), it must modify the speed of the fan. In the case of HVAC System B, it must also modify the position of the mixing box to take 100% of outside air.
5.2 Modelling the Supervisory System and the Controlled Object 5.2.1 Step 1: Modelling the Flows of Material Fig. 5.3 and Fig. 5.4 present the PFS models of the air and water flows through the HVAC Systems A and B. The airflow corresponds to the solid arcs, while the dashed arcs are water flow. An important difference between the PFS of systems A and B is that in the case of HVAC System B, the activities for processing the air compose a closed loop. The PFS loop suggests a possible sharing of variables among the objects that will model the HVAC equipment that performs these activities. In the case of HVAC System A, there is no loop.
116
Modelling and Analysis of Hybrid Supervisory Systems
Imposing the air flow in Fan A
Outside air Cold w ater
Air cooling in Coil A
Conditioning of Zone A
Division of water flow in Valve A
Fig. 5.3. PFS of the HVAC System A
Outside air
Outside air
Air mixing in Mixing Box B
Cold water
Imposing airflow in Fan B
Air cooling in Coil B
Air conditioning in Zone B
Division of water flow in Valve B
Fig. 5.4. PFS of the HVAC System B
5.2.2 Step 2: Specification of the Use Cases Following the modelling method described in Chapter 3, Fig. 5.5 presents the UML use case diagram of the HVAC System A. Supervisory System + Controlled Object End alar m procedure User
Select cooling Select ventilation
Fire Management System
Begin alarm procedure Modify temperature
Operator
Turn off Inform of coil leakage
Fig. 5.5. UML use case diagram of the HVAC System A
5.2.3 Step 3: Building the Activity Diagrams This step corresponds to the refinement of each use case in UML activity diagram. The refinement is similar for all the use cases. As an example, Fig. 5.6 presents the activity diagram of the use case ‘Begin alarm procedure’ (HVAC System A).
5 Application 1: HVAC System
117
Begin alarm procedure
Select high speed for the fan
Turn on fan
Select high speed for the fan
Ventilating w ith high flow
Fig. 5.6. Activity diagram of use case ‘Begin alarm procedure’ – HVAC System A
5.2.4 Step 4: Specification of Classes and Objects The specification of the objects is performed according to the decomposition rules described in Chapter 3, Section 3.1.4. Considering the controlled object of HVAC System A, the candidates to objects are the components of the HVAC equipment. However, according to the PFS of Fig. 5.3 (Step 1), all the HVAC components interact with the continuous airflow. Once the properties of the airflow must be modelled, they probably share continuous variables. As a consequence, any decomposition is achieved only with the application of the 3rd decomposition rule. It results in the following candidates: Fan A, Cooling Coil A, On/Off Controller A and Zone A. For the supervisory system, the application of the 1st decomposition rule results in the following candidates: User Interface A, Fire Management Interface A and Fan Interface A. The application of the 2nd decomposition rule does not provide any additional decomposition. The 3rd decomposition rule results in the candidates: Set Point Regulator A and Controller Interface A. The object Set point Regulator A provides the set point chosen by the operator for the zone temperature. The Controller Interface A continuously monitors the temperature in the coil in order to detect leakage faults. In the case of HVAC System B, the system decomposition is possible only with the 3rd decomposition rule. But, according to the PFS of Fig. 5.4 (Step 1), the continuous airflow performs a cycle, as some of the return air is mixed with the outside air and sent back to the rooms. This cycle suggests that the variables will be shared in closed loop among the HVAC equipment. The air temperature along the HVAC system is determined according to a set of interactions. The temperature in the rooms depends on the supplied air temperature, among others. The supplied air temperature depends on the temperature of the airflow that leaves the mixing
118
Modelling and Analysis of Hybrid Supervisory Systems
box. Finally, closing the loop, the temperature of the air in the mixing box depends on the temperature of the return air, which is the room temperature. Another example of sharing variables in closed loop is the relationship among the room temperature, the temperature of the airflow that leaves the cooling coil, and the valve position, which is defined by the PID controller as a function of the room temperature. Both cases of closed loop impose the definition of a single object, called Air Cycle B, which is composed by the cooling coil, the mixing box, the conditioned environment and the PID controller. Although the fan also interacts with the airflow, the definition of an object Fan B is in accordance with the 3rd decomposition rule because this is the only equipment that acts on the amount of airflow. The amount of airflow does not depend on the state of the other objects or the value of the temperature along the system. The objects defined for the supervisory system of the HVAC System B are: Set Point Regulator B, User Interface B, Fire Management Interface B, Mixing Box Interface B, Fan Interface B and Controller Interface B. The objects are organized in the following classes: x x x x x x x x x x x x x
C1 – Fan: O1.1 – Fan A, O2.1 – Fan B; C5 – Cooling Coil A: O1.5 – Cooling Coil A; C7 – On/Off Controller: O1.7 – On/Off Controller A; C9 – Zone: O1.9 – Zone A; C10 – Air Cycle: O1.10 – Air Cycle B; C11 – Set Point Regulator: O1.11 – Set Point Regulator A, O2.11 – Set Point Regulator B; C12 – Controller Interface: O1.12 – Controller Inteface A, O2.12 – Controller Interface B; C14 – Fan Interface: O1.14 – Fan Interface A, O2.14 – Fan Interface B; C15 – Mixing Box Interface: O1.15 – Mixing Box Interface B; C16 – Fire Management Interface A: O1.16 – Fire Management Interface A; C17 – Fire Management Interface B: O1.17 – Fire Management Interface B; C19 – User Interface A: O1.19 – User Interface A; C20 – User Interface B: O1.20 – User Interface B;
The other classes (C2, C3, C4, C6, C8, C13 and C18) result from the decomposition/composition and generalisation/specialisation relationships (see Section 5.2.6). 5.2.5 Step 5: Building Sequence and/or Collaboration Diagrams As an example of Step 5, Fig. 5.7 presents the sequence diagram of the use case ‘Begin alarm procedure’. It considers that the HVAC System A is turned off when the procedure is activated by the fire management system.
5 Application 1: HVAC System
Fire Manag. System
Fire Manag. Interface A
Fan Interface A
Fan A
119
Zone A
1: 2: 3: 4: 5(B) Discrete Communication 1: Fire Management System (external actor) requests the alarm procedure to Fire Management Interface A 2: Fire Management Interface A requests fan at high speed to Fan Interface A 3: Fan Interface A turns on Fan A 4: Fan Interface A selects high speed for Fan A Continuous Communication 5: Zone A interacts with the airflow produced by Fan A
Fig. 5.7. Sequence diagram for the use case ‘Begin alarm procedure’ – HVAC System A
The activity and sequence diagrams provide the identification of the methods and attributes of each class, which are presented in Fig. 5.8 for HVAC System A. In this figure, the methods and attributes that are identified based on the activity diagram of Fig. 5.6 and the sequence diagram of Fig. 5.7 are in bold. C1 – Fan Kq_air_1, Kq_air_2
qair Turn on Turn off
Select high speed Select normal speed C14 – Fan Interface I1 Turn on fan Turn off fan
Select high speed for fan Return to previous state C12 – Controller Interface Tair_out_teor, E, KE, Kw, qw, ', H, K1, K2, K3, K4, K5, KW, I1, I2, I3 qair.I1.1,PV.I2.3,Tair_in.I2.3,Tair_out.I2.3 Turn on cooling Turn off cooling
C5 – Cooling Coil A qw, Tw, H, K1, K2, K3, K4, K5, Kw, KW, I1, I2 Tair_in, PV, Tair_out qair.I1.1; Text Begin water flow Stop water flow C9 – Zone Qac, Kac, Np, Kp, Kp_max, Neq, Keq, Keq_max, Volzn, Kzn, I1, I2 Tzn qair.I1.1, Tair_out.I2.3
C7 – On/Off Controller K', I1, I2, I3 Tzn.I1.9; Tsp.I2.11 Turn on controller Turn off controller
C11 – Set Point Regulator K Tsp Begin decreasing End decreasing Begin increasing End increasing
C20 – User Interface A I1 Start ventilation Stop ventilation Start cooling Stop cooling
C17 – Fire Manag. Interface A I1
Start alarm procedure Stop alarm procedure
Fig. 5.8. Methods and attributes of the classes of HVAC System A
Following the method described in Chapter 3, the activity diagram of Fig. 5.6 is then refined in order to include the activities regarding the communication among the objects. The new activity diagram is presented in Fig. 5.9. 5.2.6 Step 6: Building the OO-DPT Net of the Classes and the Class Diagrams Once the methods and attributes have been identified, the next step is the class modelling in OO-DPT net. In order to illustrate the reuse of models between HVAC System A and B, the classes of both systems are presented.
120
Modelling and Analysis of Hybrid Supervisory Systems
Begin alarm procedure in Fire Management Interface A
Fire Manag. Interface A requests high ventilation to Fan Interface A
Fan Interface A turn on Fan A
Fan Interface A select high speed for Fan A
Fan Interface A sets Fan A in high speed
Ventilating with high speed
Fig. 5.9. Refinement of the activity diagram of Fig. 5.6 – HVAC System A
The decomposition/composition relationship is used to define the class C10 – Air Cycle as the composition of the classes C2 – Mixing Box, C4 – Cooling Coil B, C8 – PID Controller and C9 – Zone. Each of these classes separately illustrates the behaviour of a component of the HVAC System B. The generalisation/specialisation relationship is used to define the class C3 – Cooling Coil, which contains the common behaviour of classes C4 – Cooling Coil A and C5 – Cooling Coil B. Similarly, C15 and C14 are specialisation of C13, C8 and C7 are specialisation of C6, and C19 and C20 are specialisation of C18. Fig. 5.10 presents the class diagram of HVAC System A and B. It illustrates the class relationships and how classes are related between the two systems. Below, the OO-DPT subnet of each class of Fig.5.10 is presented. C1 – Fan (Fig. 5.11) An object of class C1 – Fan may be off (p1_1) or on. When it is on, it may operate at two different speeds (p2_1 and p3_1). The airflow (qair) in each of these speeds is constant and equal to Kq_air_1 and Kq_air_2. C2 – Mixing Box (Fig. 5.12) The mixing box can impose 0% of air renewal (p1_2), which means that 100% of the supplied air comes from the zone and 0% from outside the building. It can also partially renew the air (p2_2 – the percentage of renewal is Kmbox) or provide 100% of renewal (p3_2). The temperature of air sent to the cooling coil (Tmbox) is determined according to the outside temperature (Text) and the temperature of the return air, i.e., the temperature in the zone (Tzn).
5 Application 1: HVAC System
C13 – Equipment Interface C15 – Mixing Box Interface
HVAC System A C14 – Fan Interface C17 – Fire Manag. Interface A
C12 – Controller Interface C16 – Fire Manag. Interface B
C11 – Set-point Regulator C9 – Zone
C10 – Air Cycle
C1 – Fan C7 – On/Off Controller
C8 – PID Controller C6 – Controller
C2 – Mixing Box
C4 – Cooling Coil B
C5 – Cooling Coil A C3 – Cooling Coil
C19 – User Interface B
C20 – User Interface A C18 – User Interface
HVAC System B
Fig. 5.10. Class diagram for HVAC Systems A and B
C1 – Fan t1_1
t3_1
p1_1
p2_1 t2_1
p3_1 t4_1 High speed
Normal speed
Off
Variables: Xint_1 = {Kq_air_1, Kq_air_2}; Xpb_2 = {qair}; Junction functions: j2_1: qair = 0; j1_1, j4_1: qair = Kq_air_1; j3_1: qair = Kq_ar_2; Methods provided by the class: t1_1 – Turn on t2_1 – Turn off t3_1 – Select high speed t4_1 – Select normal speed
Fig. 5.11. OO-DPT sub-net of class C1 – Fan
C2 – Mixing Box t1_2 p1_2
t3_2 p2_2
t2_2 O% of renew
p3_2 t4_2
Partial renew
100% of renewl
Variables: Xint_2 = {Kmbox, I1}; Xpb_2 = {Tmbox}; Xext_2 = {Text}; Xim_2 = {Tzn.I1.1} Equation systems: f 1_2: Tmbox = Tzn.I1.9; f 2_2: Tmbox = Kmbox*Text + (1- Kmbox)*Tzn.I1. 9 f 3_2: Tmbox = Text Methods provided by the class: t1_2 – Select partial renew t2_2 – Select 0% of renew t3_2 – Select 100% of renew t4_2 – Return to partial renew
Fig. 5.12. OO-DPT sub-net of class C2 – Mixing Box
121
122
Modelling and Analysis of Hybrid Supervisory Systems
C3 – Cooling Coil (Fig. 5.13) This class models the heat exchange in the cooling coil (Incropera and De Witt, 1990), (Salsbury, 1996). The temperature of the air that leaves the coil (Tair_out) is a function of the cold water valve position (PV), a set of constants (K1, ..., K5, Kw), the time lag (Kt), the temperature of the air that enters the coil (Tair_in), the temperature of the water (Tw) and the water flow (qw). The firing of t3_3 represents the occurrence of a leakage in the coil. It imposes in this example a reduction of 20% in the water flow. Variables: Xint_3 = {qw, Tw, H, K1, K2, K3, K4, K5, Kw, Kw_T , KW, I1}; Xpb_3 = {Tair_in, PV , Tair_out}; Xim_3 = {qair.I1.1} t1_3 Junction function: t3_3 j3_3: Kw = 0,80*Kw_T p1_3 p2_3 Equation systems: t2_3 f 1_3: Tair_out = Tair_in; Without With water Leakage f 2_3: qw = PV * Kw; water flow flow H = 1-exp((-K1*qair.I1.1K2 * K3*qwK4)/(K5*qw * (K1*qair.I1.1K2 + K3*qwK4)) dTair_out/dT = (Tair_in + H*(Tw-Tair_in) – Tair_out)/KW External methods provided by the class: t3_3 – Occurrence of leakage C3 – Cooling Coil
Fig. 5.13. OO-DPT sub-net of class C3 – Cooling Coil C4 – Cooling Coil B (Fig. 5.14) In the HVAC System B, the temperature of the air that enters the cooling coil (Tair_in) is the temperature of the air that leaves the mixing box (Tmbox.I4.2). A PID controller (PI3.8) determines the position of the valve. The elements that have been added to this class when compared to class C3 are in bold. Variables: Xint_4 = {qw, Tw, H, K1, K2, K3, K4, K5, Kw, Kw_T , KW, I1, I2, I3, I4}; Xpb_4 = {Tair_in, PV , Tair_out}; Xim_4 = {qair.I1.1, PI3.8, Tmbox.I4.2} t1_4 Junction function: t3_4 j3_4: Kw = 0,80*Kw_T p1_4 p2_4 Enabling functions: t2_4 e1_4: PV > 0; e2_4: PV = 0; Without With water Leakage Equation systems: water flow flow f 1_4: Tair_in = Tmbox.I4.2; Tair_out = Tair_in; f 2_4: Pv = PI3.8; Tair_in = Tmbox.I4.2; qw = PV * Kw; H = 1-exp((-K1*qair.I1.1K2 * K3*qwK4)/(K5*qw * (K1*qair.I1.1K2 + K3*qwK4)) dTair_out/dT = (Tair_in + H*(Tw-Tair_in) – Tair_out)/KW External methods provided by the class: t3_4 – Occurrence of leakage C4 – Cooling Coil B
Fig. 5.14. OO-DPT sub-net of class C4 – Cooling Coil B C5 – Cooling Coil A (Fig. 5.15) In the HVAC System A, the temperature of the air that enters the cooling coil (Tair_in) is the temperature of the outside air (Text). The valve position varies between 0 and 1, according to firings of t1_5 and t2_5, which are enabled by the On/Off controller.
5 Application 1: HVAC System
123
Variables: Xint_5 = {qw, Tw, H, K1, K2, K3, K4, K5, Kw, Kw_T , KW, I1}; Xpb_5 = {Tair_in, PV , Tair_out}; Xim_5 = {qair.I1.1}; Xext _5 = {Text} Junction function: j3_5: Kw = 0,80*Kw_T t3_5 p2_5 Equation systems: f 1_5: T ar_in = T ext; Tair_out = Tair_in; f 2_5: T ar_in = T ext; qw = PV * Kw; With water Leakage H = 1-exp((-K1*qair.I1.1K2 * K3*qwK4)/(K5*qw * (K1*qair.I1.1K2 + K3*qwK4)) flow dTair_out/dT = (Tair_in + H*(Tw-Tair_in) – Tair_out)/KW Methods provided by the class: t 1_5 – Begin water flow t 2_5 – Stop water flow External methods provided by the class: t3_5 – Occurrence of leakage
C5 – Cooling Coil A t1_5 p1_5 t2_5 Without water flow
Fig. 5.15. OO-DPT sub-net of class C5 – Cooling Coil A C6 – Controller (Fig. 5.16) This controller could be turned on (t1_6) or off (t4_6). When it is off, the water valve of the cooling coil is closed. When it is on, it opens and closes the valve. The control law used for this purpose is incorporated in the specialization of this class (classes C7 and C8). C6 – Controller On Off
t1_6
p2_6
t4_6
Valve closed p4_6
p1_6 t2_6
t5_6 Valve opened p5_6 t6_6
p3_6 t3_6
Variables: Xint_6 = {I1, I2}; Xim_6 = {Tzn.I1.9; Tsp.I2.11} Methods provided by the class: t1_6 – Turn on controller t4_6 – Turn off controller
Fig. 5.16. OO-DPT sub-net of class C6 – Controller C7 – On/Off Controller (Fig. 5.17) This class opens (t5_7) and closes (t6_7) the water valve of the cooling coil according to the temperature in the zone (Tzn.I1.9) and the set point temperature (Tsp.I2.11). C8 – PID Controller (Fig. 5.18) This class sets the position (P) of the water valve according to the equation of a PID (f5_8). If the resulting value is beyond the valve range (P<0 or P>1), then either the state p4_8 or p7_8 is reached.
124
Modelling and Analysis of Hybrid Supervisory Systems
C7 – Controle On/Off On Off
t1_7
p2_7
t4_7
Valve closed p4_7
p1_7 t2_7
t5_7
t6_7 p3_7 t3_7
Variables: Xint_7 = {K' , I1, I2, I3}; Xim_7 = {Tzn.I1.9; Tsp.I2.11} Valve Enabling functions: opened e5_7: Tzn.I1.9 > (Tsp.I2.11 + K' ); p5_7 e6_7: Tzn.I1.9 < (Tsp.I2.11 - K'); Methods provided by the class: t1_7 – Turn on controller t4_7 – Turn off controller Methods used by the class: t 3_7 o t2_I3.5 – Stop water flow t 5_7 o t1_I3.5 – Start w ater flow t 6_7 o t2_I3.5 – Stop water flow
Fig. 5.17. OO-DPT sub-net of class C7 – Controller On/Off
C8 – PID Controller On Off p1_8
t1_8
t2_8
t4_8
p2_8
Valve Valve opened Valve t5_8 opened t8_8 (partial) (complete) closed p4_8 p5_8 p7_8 t6_8
p3_8
t9_8
t3_8 t7_8
p6_8
Variables: Xint_8 = {Paux, K0, K1, K2, K3, I1, I2}; Xpb_8 = {P}; Xim_8 = {Tzn.I1.9; T sp.I2.10;} Enabling function: e5_8: Paux>0; e6_8: Pauxd0; e8_8: Pauxt1; e9_8: Paux<1; Equation systems: f4_8, f7_8: E = Tzn.I1.9 – T sp.I2.11; Paux = K0 + K1* E + K2* ³E + K3*dE/dT; f2.12: E = Tzn.I1.9 – Tsp.I2.10; Paux = K0 + K1* E + K2* ³E + K3*dE/dT; P = Paux; Methods provided by the class: t1_8 – Turn on controller t4_8 – Turn off controller
Fig. 5.18. OO-DPT sub-net of class C8 – PID Controller C9 – Zone (Fig. 5.19) The temperature in the zone (Tzn) is a function of the number of people in the rooms (Np), the amount of equipment on (Neq) and the thermal load removed by the HVAC system (Qac). The thermal load is a function of the airflow (qair.I1.1) and of the temperature of the air that leaves the cooling coil (Tair_out.I2.3). C10 – Air Cycle (Fig. 5.20) This class is the composition of classes C2, C4, C8 and C9. There is no transition fusion because there is no method call among the classes, only the sharing of variables. The closed loops of the variables shared among the classes are illustrated in Fig. 5.20.
Classes C1 to C10 model the controlled object. The next classes model the S supervisory system of the HVAC Systems A and B.
5 Application 1: HVAC System
125
C9 – Zone t1_9 Equipment is turned on
External methods provided by the class: t1_9 – Turn on equipment t2_9 – Turn off equipment t4_9 t3_9 – Person enters the zone Person leaves t4_9 – Person leaves the zone the zone
t3_9 p1_9
Person enters the zone
t2_9 Equipment is turned off Variables: Xint_9 = {Qac, Kac, Np, Kp, K p_max, Neq, Keq, Keq_max, Volzn, K zn, I1, I2}; Xpb_9 = {T zn}; Xim_9 = {qair.I1.1, Tair_out.I2.3} Junction function: e1_9: Neq=Neq+1; e2_9: Neq=Neq-1; e3_9: Np=N p+1; e4_9: N p=N p-1; Enabling function: j1_9: Neq0; j3_9: Np0; Equation systems: f1.9: Qac = qair.I1.C1*Kac*(Tair_out.I2.3 –T zn) dT zn/dT = (N p*Kp + Neq*Keq + Qac)/Volzn*K zn
Fig. 5.19. OO-DPT sub-net of class C9 – Zone
C10 – Air Cycle C2 – Mixing Box K mbox, I1 T mbox T zn.I1.9, Text Select partial renew Select 0% of renew Select 100% of renew Return to partial renew
C9 – Zone Qac, Kac, Np, Kp, Kp_max, Neq, Keq, Keq_max, Volzn, K zn, I1, I2 T zn qair.I1.1, Tair_out.I2.3
C4 – Cooling Coil A qw,Tw,H, K1, K2, K3, K4, K5, Kw, KW, I1, I2, I3, I4 Tair_in, PV, Tair_out qair.I1.1; PI3.8, Tmbox.I4.2
C8 – PID Controller K0, K1, K2, K3, I1, I2 P T zn.I1.9; Tsp.I2.11 Turn on controller Turn off controller
Fig. 5.20. Closed loops of the variables shared among classes C2, C4, C8 and C9 C11 – Set Point Regulator (Fig. 5.21)
This class provides methods for the HVAC operator to change the controller set point (Tsp), which is the temperature desired in the rooms. C11 – Set Point Regulator Decreasing p1_11
t1_11
t3_11 p2_11
t2_11
t4_11
Variables: Xint_11 = {K}; Xpb_11 = {Tsp} Equation systems: Increasing f : dT /dT = -K; f : dT /dT = K; 1_11 sp 3_11 sp p3_11 External methods provided by the class: t1_11 – Stop decreasing t2_11 – Start decreasing t3_11 – Start increasing t4_11 – Stop increasing
Fig. 5.21. OO-DPT sub-net of class C11 – Set Point Regulator
126
Modelling and Analysis of Hybrid Supervisory Systems
C12 – Controller Interface (Fig. 5.22)
This class makes the interface with the cooling coil controller (class C6) and monitors its behaviour. It estimates the temperature of the air that leaves the cooling coil (Tair_out_teor) and compares it with the real temperature (Tair_out.I2.3). When the difference between them (E) is greater than an allowed limit (KE), a fault is detected; the controller is turned off and blocked. The HVAC operator is notified by the firing of t6_12. C12 – Controller Interface Off p1_12
t1_12
p2_12
t3_12
t2_12
p3_12
t4_12
On p4_12
t5_12
Fault notification p5_12 t6_12
Blocked p5_12
Variables: Xint_12 = {Tair_out_teor, E, KE , Kw, qw, H, K1, K2, K3, K4, K5, KW, I1, I2, I3}; Xim_12 = {qair.I1.1; PV.I2.3; Tair_in.I2.3, Tair_out.I2.3}; Enabling function: e5_12: |E|> KE ; Equation systems: f 4_12: qw = PV.I2.I3 * Kw; H = 1-exp((-K1*qair.I1.1K2 * K3*qwK4)/(K5*qw * (K1*qair.I1.1K2 + K3*qwK4)); dTair_out_teor/dT = (Tair_in.I2.3 + H*(Tw-Tair_in.I2.3) – Tair_out_teor)/KW E = Tair_out.I2.3 - Tair_out_teor; Methods provided by the class: t1_12 – Turn on cooling t4_12 – Turn off cooling Methods used by class: t2_12 o t4_I3.6 – Turn off controller t3_12 o t1_I3.6 – Turn on controller t5_12 o t4_I3.6 – Turn off controller
Fig. 5.22. OO-DPT sub-net of class C12 – Interface Controller C13 – Equipment Interface (Fig. 5.23)
This class models the common behaviour between classes C14 and C15. The difference between the two classes is the discrete interface (method calls): C14 interfaces with class C1 – Fan, while C15 interfaces with class C2 – Mixing Box. C13 – Equipment Interface t1_13 p2_13 t5_13 p6_13 t2_13 p3_13
t6_13
Variable: Xint_13 = {I1};
t9_13 p8_13 t10_13
p9_13
t11_13 p11_13
p10_13
t12_13 p12_13
p1_13 t3_13 p4_13 t7_13 p7_13 t4_13 p5_13 t8_13
Fig. 5.23. OO-DPT sub-net of class C13 – Equipment Interface
5 Application 1: HVAC System
127
C14 – Fan Interface (Fig. 5.24)
This class turns on and off, and changes the speed of the fan, when requested by other classes of the supervisory system. It interacts with class C1 – Fan. When the fire management system requests to increase ventilation, this class emits the command. When the alarm situation ends, the HVAC system must return to the previous state. For this purpose, it must know if the fan was off (p7_14) or operating at normal speed (p6_14). C14 – Fan Interface t1_14
p2_14
t5_14 Normal speed p6_14
Normal speed t9_14 o High speed
t2_14
p3_14
t6_14
t10_14
p4_14
t7_14 Off o High speed p7_14
p5_14
t8_14
Off p1_14 t3_14
t4_14
Variables: Xint_14 = {I1}; Methods provided by the class: t1_14 – Turn on fan t6_14 – Turn off fan t11_14 – Select high speed to fan t12_14 – Return to previous state
p8_14 p9_14
t11_14
p11_14
p10_14
t12_14
p12_14
Methods used by the class: t2_14 o t2_I1.1 – Turn off fan t3_14 o t1_I1.1 – Turn on fan t4_14 o t2_I1.1 – Turn off fan t5_14 o t1_I1.1 – Turn on fan t7_14 o t3_I1.1 – Select high speed t8_14 o t4_I1.1 – Return to normal speed t9_14 o t3_I1.1 – Select high speed t10_14 o t4_I1.1 – Return to normal speed
Fig. 5.24. OO-DPT sub-net of class C14 – Fan Interface C15 – Mixing Box Interface (Fig. 5.25) This class interacts with class C2 – Mixing Box, when requested by the other objects
of the supervisory system. C16 – Fire Management Interface B (Fig. 5.26)
The fire management system of the building uses this class to change the speed of the fan and the percentage of renewed air in the case of fire or smoke in the zone. The fire procedure is started by t1_16 and interrupted by t8_16. C17 – Fire Management Interface A (Fig. 5.27) This class has the same function as class C16, but for HVAC System A. In this case,
only the fan speed is changed, as the HVAC System A does not have a mixing box.
128
Modelling and Analysis of Hybrid Supervisory Systems
C15 – Mixing Box Interface Partial t1_15 p2_15 t5_15 renew p6_15
t9_15 Partial o 100% of renew p8_15
t2_15
p3_15
t6_15
t3_15
p4_15
t7_15 0o 100% of renew p7_15
0% of renew p1_15
t4_15
p5_15
t10_15
p9_15
t11_15
p11_15
p10_15
t12_15
p12_15
t8_15
Methods used by the class: t2_15 o t2_I1.2 – Select 0% of renew t3_15 o t1_I1.2 – Select partial renew t4_15 o t2_I1.2 – Select 0% of renew t5_15 o t1_I1.2 – Select partial renew t7_15 o t3_I1.2 – Select 100% of renew t8_15 o t4_I1.2 – Return to partial renew t9_15 o t3_I1.2 – Select 100% of renew t10_15 o t4_I1.2 – Return to partial renew
Variables: Xint_15 = {I1}; Methods provided by the class: t1_15 – Start partial renew t6_15 – Start 0% of renew t11_15 – Start 100% of renew t12_15 – Return to previous state
Fig. 5.25. OO-DPT sub-net of class C15 – Mixing Box Interface
C16 – Fire Management Interface B t3_16 p6_16 p2_16 t1_16
t7_16 p3_16
t4_16
p7_16
p1_16
p10_16
Normal
p4_16
t5_16
Alarm
p8_16
t2_16
t8_16 p5_16
t6_16
p9_16
Variables: Xint_16 = {I1, I2};
Methods used by the class: t3_16 o t11_I1.14 – Select high speed to fan External methods provided by the class: t4_16 o t11_I2.15 – Start 100% of renew t5_16 o t12_I1.14 – Return to previous state t1_16 – Start alarm procedure t6_16 o t12_I2.15 – Return to previous state t8_16 – Stop alarm procedure
Fig. 5.26. OO-DPT sub-net of class C16 – Fire Management Interface B
C17 – Fire Management Interface A t3_17 t1_17 p2_17 p1_17 Normal
p4_17 t2_17
p3_17
t4_17
Alarm
Variables: Xint_17 = {I1}; External methods provided by the class: t1_17 – Start alarm procedure t4_17 – Stop alarm procedure Methods used by the class: t2_17 o t12_I1.14 – Return to previous state t3_17 o t11_I1.14 – Select high speed for fan
Fig. 5.27. OO-DPT sub-net of class C17 – Fire Management Interface A
5 Application 1: HVAC System
129
C18 – User Interface (Fig. 5.28) Through this class, the HVAC user can select one of the following operation modes: off (p1_18), ventilation (p2_18) and cooling (p3_18). According to the mode selected, the class actuates on the fan and cooling coil controller using their interfaces (classes C14 and C12). The class imposes a minimal time interval (H) between two consecutive user commands. C18 – User Interface t1_18
p2_18
t3_18
p3_18
t4_18
p1_18 Off
t2_18
Ventilation p4_18
t5_18
p5_18
t7_18
t6_18
p6_18
t8_18
p7_18 Cooling
External methods provided by the class: t1_18 – Start ventilation t4_18 – Stop ventilation t5_18 – Start cooling t8_18 – Stop cooling Methods used by the class: t2_18 o t6_I1.14 – Turn off fan t3_18 o t1_I1.14 – Turn on fan t6_18 o t4_I2.12 – Turn off cooling t7_18 o t1_I2.12 – Turn on cooling
Variables: Xint_18 = {Taux, H,I1, I2}; Enabling functions: e1_18, e4_18, e5_18, e8_18: Taux tH; Junction functions: j2_18, j3_18, j6_18, j7_18: Taux= 0 Equation systems: f1_18, f4_18, f7_18: dTaux/dT= 1
Fig. 5.28. OO-DPT sub-net of class C18 – User Interface C19 – User Interface B (Fig. 5.29)
This class is the specialisation of class C18 for the HVAC System B. It interacts with the fan and the mixing box through their interfaces in the supervisory system. C19 – Interface Usuário B
Off p1_19
t1_19
p8_19
t10_19
p11_19
p2_19
t3_19
p12_19 t12_19
t5_19
p5_19
t7_19
t6_19
p6_19
t8_19
p4_19 t9_19 p9_19
t2_19
p3_19
t4_19
Cooling p7_19
Ventilation p10_19
t11_19
p13_19 External methods provided by the class: t1_19 – Start ventilation t4_19 – Stop ventilation Variables: t5_19 – Start cooling Xint_19 = {Taux, H, I1, I2, I3}; t8_19 – Stop cooling Enabling functions: Methods used by the class: e1_19, e4_19, e5_19, e8_19: Taux tH; t2_19 o t6_I1.14 – Turn off fan Junction functions: t3_19 o t1_I1.14 – Turn on fan j2_19, j3_19, j6_19, j7_19: Taux= 0 t6_19 o t4_I2.12 – Turn off cooling Equation systems: t7_19 o t1_I2.12 – Turn on cooling f1_19, f4_19, f7_19: dTaux/dT= 1 t10_19 o t1_I3.15 – Start partial renew t11_19 o t6_I3.15 – Start 0% of renew
Fig. 5.29. OO-DPT sub-net of class C19 – User Interface B
130
Modelling and Analysis of Hybrid Supervisory Systems
C20 – User Interface A (Fig. 5.30)
This class is the specialisation of class C18 for the HVAC System A. C20 – User Interface A t1_20
p2_20
t3_20
t Ventilation 5_20 p4_20
p5_20
t7_20
t2_20
p3_20
t4_20
t6_20
p6_20
t8_20
p1_20 Off
Variables: Xint_20 = {Taux, H, I1, I2}; Enabling functions: e1_20, e4_20, e5_20, e8_20: Taux tH; Junction functions: j2_20, j3_20, j6_20, j7_20: Taux= 0 Equation systems: f1_20, f4_20, f7_20: dTaux/dT= 1
p7_20 Cooling
External methods provided by the class: t1_20 – Start ventilation t4_20 – Stop ventilation t5_20 – Start cooling t8_20 – Stop cooling Methods used by the class: t2_20 o t6_I1.14 – Turn off fan t3_20 o t1_I1.14 – Turn on fan t6_20 o t4_I2.12 – Turn off cooling t7_20 o t1_I2.12 – Turn on cooling
Fig. 5.30. OO-DPT sub-net of class C20 – User Interface A
The next step of the modelling process is the specification of the initial state. The initial state of the HVAC System A is presented as an example: x
O2.1 – Fan A X2.1: Kq_air_1 = 0.7; Kq_air_2 = 1.4; qair = 0; m2.1 = {p1_1};
x
O1.5 – Cooling Coil A X1.5: qw = 0; Tair_in = undefined; PV = 0; Tair_out = ind; Tw = 7; H = 0; K1 = 7 6 -4 6464; K2 = 0.8; K3 = 10 ; K4 = 0.8; K5 = 4.15*10 ; Kw = 6.8*10 ; KW = 300; I1 = Fan A; m1.5 = {p1_5};
x
O1.7 – On/Off Controller A X1.7: K' = 2; I1 = Zone A; I2 = Set Point Regulator A; I3 = Cooling Coil A; m1.7 = {p1_7};
x
O1.9 – Zone A 3 X1.9: Qac = undefined; Kac = 1.2987*10 ; Np = 0; Kp = 100; Kp_max = 5; 3 Neq = 0; Keq = 200; Keq_max = 5; Volzn = 500; Kzn = 1.2987*10 ; I1 = Fan A; I2 = Cooling Coil A; Tzn = undefined; m1.7 = {p1_9};
x
O2.11 – Set Point Regulator A X2.11: K = 1; Tsp = 23; m1.7 = {p2_11};
x
O2.12 – Controller Interface A X2.12: Tair_out_teor = undefined; E = undefined; KE = 3; qw = undefined; H = 7 6 undefined; K1 = 6464; K2 = 0.8; K3 = 10 ; K4 = 0.8; K5 = 4.15*10 ;
5 Application 1: HVAC System
131
Kw = 6.8*10-4; KW = 300; I1 = Fan A; I2 = Cooling Coil A; I3 = On/Off Controller A; m2.12 = {p1_12};
x
O2.14 – Fan Interface A X2.14: I1 = Fan A; m2.14 = {p1_14, p11_14};
x
O1.17 – Fire Management Interface A X1.17: I1 = Fan Interface A; m1.17 = {p1_17};
x
O1.20 – User Interface A X1.20: Taux = 0; H = 1; I1 = Fan Interface A; I2 = Controller Interface A; m1.20 = {p1_20};
5.2.7 Step 7: Verification of Consistency among Models 5.2.7.1 OO-DPT Net and Sequence (or Collaboration) Diagram The last step of the modelling method is the verification of consistency among the models. For the HVAC System A, Fig. 5.31 presents the relationship between the interactions of the sequence diagram of the use-case ‘Begin alarm procedure’ (Fig. 5.7) and the transitions of the OO-DPT net. Fire Management System
Fire Manag. Interface A
Fan Interface A
Fan A
Zone A
1: t1_17 2: t3_17ot11_14 3: t3_14ot1_1 4: t7_14ot3_1 5(I): q air
Fig. 5.31. The sequence diagram and the OO-DPT net – HVAC System A
5.2.7.2 OO-DPT Net and Activity Diagrams Each activity diagram is converted into a Petri net model. The places and transitions of this Petri net are related with the places and transitions of the OODPT net model. Fig. 5.32 presents this correspondence for the activity diagram of Fig. 5.9.
5.3 Analysis of the OO-DPT Net In the case of HVAC System B, the composition relationship is used to create the object O1.10 – Air Cycle B because of the sharing of continuous variables. This object O1.10 is complex and difficult to be analysed using the analysis method presented in Chapter 4. This is one of the limitations of the analysis method.
132
Modelling and Analysis of Hybrid Supervisory Systems Begin alarm procedure in Fire Management Interface A t1_17
p2_17 t3_17ot11_14
Fire Manag. Interface A requests fan at high speed to Fan Interface A
p9_14 t3_14ot1_1
Fan Interface A turns on Fan A
t7_14ot3_1
Fan Interface A sets Fan A at high speed
p4_14
t7_14ot3_1
Fan Interface A sets Fan A at high speed
p3_1 Fan at high speed
Fig. 5.32. Conversion of activity diagram into Petri net – HVAC System A
Conversely, the model of HVAC System A has an adequate level of decomposition. It is therefore used in this section to illustrate the analysis method. The two properties considered for the HVAC System A are related with the requirements of the use case ‘Select cooling’. Property 1 exemplifies the verification of a reachability property that depends almost exclusively on the discrete dynamics of the system. The continuous dynamics that must be taken into account is restricted to the determination of transition firing dates. On the other hand, the verification of Property 2 is strongly related with the continuous dynamics of HVAC System A. The verification of Property 2 exemplifies the reuse of results of the analysis method. 5.3.1 Property 1 5.3.1.1 Step 1: Specification of the Property Statement Property 1 is specified according to the statement PR2 (described in Chapter 4, Section 4.3.3.1): x
Property 1 – When a user selects the mode ‘cooling’ (event e0), the cooling coil controller must immediately be turned on (event ei) and continue in this state until another operation is selected (event ef): e0 = firing of t5_1.20; ei = reaching of m1.7 = {p2_1.7}; ef = firing of t8_1.20; 'T = 0.
5.3.1.2 Step 2: Specification of the Set of Restrictions Property 1 is submitted to a single restriction, defined according to the restriction statement R2 (described in Chapter 4, Section 4.3.3.2): x
Restriction 1A – No fault occurred or occurs in the cooling coil: t5_2.12/4_1.7 and t3_1.5 do not fire between 0dTdT8_1.20.
5 Application 1: HVAC System
133
5.3.1.3 Step 3: Building the Static Collaboration Diagrams The static collaboration diagram of HVAC System A is presented in Fig. 5.33. It highlights the interactions among objects that are relevant for the verification of Property 1. Fire Manag. System (external actor)
O1.17 – Fire Manag. Interface A
O2.14 – Fan Interface A
O2.1 – Fan A
O1.20 – User Interface A
O2.12 – Controller Interface A
O1.7 – On/Off Controller A
O1.5 – Cooling Coil A
User (external actor) O2.11 – Set Point Regulator A
Outside air (external actor)
O1.9 – Zone A
Operator (external actor)
Fig. 5.33. Relevant interactions for the verification of Property 1
According to Fig. 5.33, the objects O1.20 – User Interface A (where events e0 and ef occur) and O1.7 – On/Off Controller A (where ei occurs) interacts through object O2.12 – On/Off Controller A. As a consequence, the verification of this property must at least include these 3 objects. The analysis begins with the analysis of O1.20 – User Interface A. 5.3.1.4 Step 4.1: Analysis of the Discrete Dynamics (O1.20 – User Interface A) The event that characterises the beginning of the scenarios for Property 1 is the firing of t5_1.20. The end of the scenarios is determined by the firing of t8_1.20. The analysis of the discrete dynamics is performed by building the proof tree of a single sequent: x
Search 1 (from the firing of t5_1.20 up to the firing of t8_1.20): The sequent definition uses Rules 2 and 7, described in Section 4.3.3.5 of Chapter 4. It considers that p5_1.20 = post-condition of t5_1.20 and p6_1.20 = post-condition of t8_1.20. The sequent is *0, p5_1.20, !t1_1.20, !t2_1.20, !t3_1.20, !t4_1.20, !t5_1.20, !t6_1.20, !t7_1.20, t8_1.20¸ p6_1.20
*f: p7_1.20 p7_1.20 *0, p 6_1.20, !t1_1.20, ..., !t7_1.20 p6_1.20
*f —o L (t8_1.20) *0, p7_1.20, !t1_1.20, ..., !t7_1.20, t8_1.20 ¸ p6_1.20
*f p5_1.20¸ p5_1.20 —o L (t7_1.20) *0, p5_1.20, !t1_1.20, !t2_1.20, !t3_1.20, !t4_1.20, !t5_1.20, !t6_1.20, !t7_1.20, t8_1.20 ¸ p6_1.20
*f
x
Definition of the scenarios – The proof tree results in a single sequence of transition firings with *0 = *f = :
134
Modelling and Analysis of Hybrid Supervisory Systems
-
Scenario 1: t7_1.20/1_1.12; t8_1.20.
5.3.1.5 Step 4.2: Elaboration of Hypotheses (O1.20 – User Interface A) The following hypothesis is introduced in the verification of Property 1. It corresponds to the hypothesis statement H1 (described in Chapter 4, Section 4.3.3.6): x
Hypothesis 1A – The method calls performed by object O1.20 are immediately executed by O2.12: t7_1.20/1_2.12 fires in 'T = 0 after it is enabled in O1.20.
5.3.1.6 Step 4.3: Analysis of the Continuous Dynamics (O1.20 – User Interface A) Scenario 1 obeys the following restrictions about the date of transition firings: x x
T7_1.20/1_2.12 = T5_1.20 (from Hypothesis 1A). T8_20 t T5_1.20 + H (from j7_20, f7_20 and e8_20).
5.3.1.7 Step 5.1: Analysis of the Discrete Dynamics (O2.12 – Controller Interface A) There is a single firing of O2.12 and O1.20 interface transitions. Therefore, the analysis of this object is composed of two searches. In both searches, transition t5_2.12/4_1.7 is not included because of Restriction 1A. Transitions t7_1.20/1_2.12 and t6_1.20/4_2.12 are not included because they are from the interface between O1.20 and O2.12: x x
Search 1 (up to the firing of t7_1.20/1_2.12): Once the date of firing of t7_1.20/1_2.12 does not depend on O2.12 (according to Hypothesis 1A), this search is not performed. Search 2 (from the firing of t7_1.20/1_2.12): The sequent of Search 2 is defined according to Rules 11 and 14, described in Chapter 4, Section 4.3.3.9. It considers that p2_2.12 = post-condition of t7_1.20/1_2.12. The sequent is *0, p2_2.12, !t2_2.12, !t3_2.12, !t6_2.12¸ *f. The search is interrupted when no other transition can be fired. p2_2.12 p2_2.12 *0, p4_2.12,!t2_2.12, !t3_2.12, !t6_2.12 *f —o L (t3_2.12) *0, p2_2.12,!t2_2.12, !t3_2.12, !t6_2.12 ¸ *f
x
Definition of the scenarios – The proof tree results in a single transition firing: t3_2.12/1_1.7. Once this event is not a pre-condition for event ef, two scenarios must be defined, one with the firing of t3_2.12/1_1.7 and another without it. In the first case, *0 = and *f = p2_2.12, and in the second case *0 = and *f = p4_2.12: - Scenario 1 - 1: t7_1.20/1_2.12; t3_2.12/1_1.7. - Scenario 1 - 2: t7_1.20/1_2.12.
5.3.1.8 Step 5.2: Elaboration of Hypotheses (O2.12 – Interface Controller A) The following hypothesis is made about the behaviour of O2.12. It corresponds to the hypothesis statement H1 (described in Chapter 4, Section 4.3.3.10):
5 Application 1: HVAC System
x
135
Hypothesis 1B – The method calls performed by object O2.12 are immediately executed by object O1.7: t3_2.12/1_1.7 fires in 'T = 0 after it is enabled in O2.12.
5.3.1.9 Step 5.3: Analysis of the Continuous Dynamics (O2.12 – Interface Controller A) According to Hypothesis 1B, Scenario 1-2 is impossible because t3_2.12/1_1.7 always fires when enabled in O2.12. Scenario 1-1 obeys the following restriction about the date of transition firing: x
T3_2.12/1_1.7 = T7_1.20/1_2.12 = T5_1.20.
5.3.1.10 Step 5.1: Analysis of the Discrete Dynamics (O1.7 – On/Off Controller A) Similar to the analysis of O2.12, the analysis of this object is composed of two searches: x x
Search 1 (up to the firing of t3_2.12/1_1.7): Once the date of firing of t3_2.12/1_1.7 does not depend on O1.7 (according to Hypothesis 1B), this search is not performed. Search 2 (from the firing of t3_2.12/1_1.7): The sequent of this search is defined according to Rules 11 and 14. Transition t5_2.12/4_1.7 is not included because of Restriction 1A and transition t3_2.12/1_1.7 are not included because it is from the interface between O2.12 and O1.7: The sequent is *0, p2_1.7
p4_1.7, !t2_1.7, !t3_1.7, !t5_1.7, !t6_1.7¸ *f: p5_1.7 p5_1.7 *0, p 2_1.7, p4_1.7, !t2_1.7, !t3_1.7, !t5_1.7, !t6_1.7 *f —o L (t6_1.7) p4_1.7¸ p4_1.7 *0, p2_1.7, p5_1.7, !t2_1.7, !t3_1.7, !t5_1.7, !t6_1.7 ¸ *f —o L (t5_1.7) *0, p2_1.7, p4_1.7, !t2_1.7, !t3_1.7, !t5_1.7, !t6_1.7 ¸ *f
L *0, p2_1.7
p4_1.7, !t2_1.7, !t3_1.7, !t5_1.7, !t6_1.7 ¸ *f
x
Definition of the scenarios – The proof tree of Search 2 has a loop that results in infinite scenarios. The scenarios are defined according to the number of firings of t5_1.7/1_1.5 and t6_1.7/2_1.5. In the case the last transition firing of the scenario is t3_2.12/1_1.7 or t6_1.7/2_1.5, *f = p2_1.7
p4_1.7. Otherwise, in the case of t5_1.7/1_1.5, *f = p2_1.7
p5_1.7. For 1djdf, the following scenarios are possible from the discrete point of view: - Scenario 1-1-1: t3_2.12/1_1.7. - Scenario 1-1-2: t3_2.12/1_1.7; t5_1.7/1_1.5. - Scenario 1-1-3: t3_2.12/1_1.7; t5_1.7/1_1.5; t6_1.7/2_1.5. ... - Scenario 1-1-2*j: t3_2.12/1_1.7; (j-1)*(t5_1.7/1_1.5; t6_1.7/2_1.5;) t5_1.7/1_1.5. - Scenario 1-1-(2*j+1): t3_2.12/1_1.7; j*(t5_1.7/1_1.5; t6_1.7/2_1.5;).
For all the scenarios, independently of the continuous variable evolution and dates of transition firings, the state p2_1.7=1 is true from the firing of t3_2.12/1_1.7 (T3_2.12/1_1.7 = T ҏ 5_1.20) up to the firing of t8_1.20 (T8_1.20), therefore Property 1 is true if Hypotheses 1A and 1B are true.
136
Modelling and Analysis of Hybrid Supervisory Systems
5.3.1.11 Step 6: Building the Global Sequents The sequents that define the possible evolution of the HVAC System A from the firing of t5_1.20 to the firing of t8_1.20 are the following: x x x
Scenario 1-1-1: p4_1.20, p1_12.O1, p1_1.7, t5_1.20, t7_1.20/1_2.12, t8_1.20, t3_12.O1/1_1.7¸ p6_1.20
p4_12.O1
p2_1.7
p4_1.7. Scenario 1-1-2: p4_1.20, p1_12.O1, p1_1.7, p1_1.5, t5_1.20, t7_1.20/1_2.12, t8_1.20, t3_12.O1/1_1.7, t5_1.7/1_1.5 ¸ p6_1.20
p4_12.O1
p2_1.7
p5_1.7
p2_1.5. Scenario 1-1-3: p4_1.20, p1_12.O1, p1_1.7, p1_1.5, t5_1.20, t7_1.20/1_2.12, t8_1.20, t3_12.O1/1_1.7, t5_1.7/1_1.5, t6_1.7/2_1.5 ¸ p6_1.20
p4_12.O1
p2_1.7
p4_1.7
p1_1.5.
… The sequents of the other scenarios are similar but with a different number of firings of t5_1.7/1_1.5 and t6_1.7/2_1.5. It is important to observe that when the scenario includes the firings of t5_1.7/1_1.5 and t6_1.7/2_1.5, the initial and final marking of object O1.5 – Cooling Coil A must be included in the sequent. Fig. 5.34 illustrates the partial order of transition firings obtained by building the proof tree of the global sequent for Scenario 1-1-3. t8_1.20
t5_1.20 t7_1.20/1_2.12
t3_1.12/1_1.7 t5_1.7/1_1. 5
t6_1.7/2_1. 5
Fig. 5.34 Partial order of firings for Scenario 1-1-3 – Property 1
The verification of Property 1 is conditioned by the verification of Hypotheses 1A and 1B. 5.3.1.12 Step 7: Verification of Hypotheses The verification of Hypothesis 1B is achieved through the composition of objects O1.7 and O2.12 in a single object. Considering the initial marking of this object and Restriction 1A, Hypothesis 1B is verified by place invariants or by building the reachability tree. Similarly, Hypothesis 1A is verified by the composition of objects O2.12 and O1.20 into a single object. 5.3.2 Property 2 5.3.2.1 Steps 1 and 2: Specification of the Property Statement and of the Set of Restrictions This property has the following statement and restrictions: x
Property 2 (statement PR1) – When the user select the mode ‘cooling’ (event e0), the temperature in the zone must reach the set point (event ef) in a maximum time of KT = 30min: e0 = firing of t5_1.20; ef = reaching of Tzn=Tsp; 'T d 30 min.
5 Application 1: HVAC System
-
137
Restriction 2A (restriction statement R2) – No fault occurred or occurs in the cooling coil: t5_2.12/4_1.7 and t3_1.5 do not fire between 0dTd(T5_1.20 + 30 min). Restriction 2B (restriction statement R2) – The user does not modify the operation mode of HVAC System A in this time interval: t1_1.20, t4_1.20 and t8_1.20 do not fire in T5_1.20 d T d (T5_1.20 + 30 min). Restriction 2C (restriction statement R6) – The operator does not modify the set point of the temperature in this time interval: dTsp/dT = 0 in T5_1.20 d T d (T5_1.20 + 30 min). Restriction 2D (restriction statement R6) – When the cooling mode is selected, the set point of the temperature is between 18 and 25ºC: Tsp(T) [18, 25], in T T5_1.20. Restriction 2E (restriction statement R6) – When the cooling mode is selected, the zone temperature is between 26 and 35ºC: Tzn(T) [26, 35], in T T5_1.20. Restriction 2F (restriction statement R6) – The outside temperature is constant in this time interval: dText/dT = 0 in T5_1.20 d T d (T5_1.20 + 30 min). Restriction 2G (restriction statement R6) – The outside temperature is between 26 and 35ºC in this time interval: Text(T) [26, 35], in T5_1.20 d T d (T5_1.20 + 30 min).
-
-
-
-
-
-
5.3.2.2 Step 3: Building the Static Collaboration Diagrams Fig. 5.35 presents the static collaboration diagram of HVAC System A and highlights the relevant interactions for the verification of Property 2. Fire Manag. System (external actor) O1.17 – Fire Manag. Interface A
O2.14 – Fan Interface A
O2.1 – Fan A
O1.20 – User Interface A
O2.12 – Controller Interface A
O1.7 – On/Off Controller A
User (external actor) O2.11 – Set-point Regulator A
O1.5 – Cooling Coil A
Outside air (external actor)
O1.9 – Zone A
Operator (external actor)
Fig. 5.35. Relevant interactions for the verification of Property 2
138
Modelling and Analysis of Hybrid Supervisory Systems
According to Fig. 5.35, the objects O1.20 – User Interface A (where events e0 occurs) and O1.9 – Zone A (where ef occurs) interact through objects O2.14 –Fan Interface A, O2.12 – Controller Interface A, O2.1 – Fan A, O1.7 – On/Off Controller A and O1.5 – Cooling Coil A. The analysis of Property 2 may include these objects. 5.3.2.3 Step 4.1: Analysis of the Discrete Dynamics (O1.20 – User Interface A) The event that characterises the beginning of the scenarios for Property 2 is the firing of t5_1.20. The end of the scenarios is not specified for O1.20. The analysis of the discrete dynamics is performed by a single search: x
Search 1 (from the firing of t5_1.20): The sequent definition uses Rules 2 and 9 (Chapter 4, Section 4.3.3.5). The firings of t1_1.20, t4_1.20 and t8_1.20 are not included in the sequent of this search because of Restriction 2B. The sequent is: *0, p5_1.20, !t2_1.20, !t3_1.20, !t5_1.20, !t6_1.20, !t7_1.20¸ *f. The search is interrupted when no other transition is enabled. p5_1.20 p5_1.20 *0, p7_1.20, !t2_1.20, !t3_1.20, !t6_1.20, !t7_1.20 *f —o L (t7_1.20) *0, p5_1.20, !t2_1.20, !t3_1.20, !t6_1.20, !t7_1.20 ¸ *f
x
Definition of scenarios – The proof tree results in a single transition firing: t7_1.20/1_2.12. Once this event is not a pre-condition for event ef, two scenarios must be defined, one with the firing of t7_1.20/1_2.12 and another without it. In the first case, *0 = and *f = p7_1.20, and in the second one *0 = and *f = p5_1.20: -
Scenario 1: t7_1.20/1_2.12. Scenario 2: there is no transition firing.
5.3.2.4 Step 4.2: Elaboration of Hypotheses (O1.20 – User Interface A) Hypothesis 2A is similar to Hypothesis 1A of Property 1 (Section 5.3.1.5). 5.3.2.5 Step 4.3: Analysis of the Continuous Dynamics (O1.20 – User Interface A) According to Hypothesis 2A, Scenario 2 is impossible. Scenario 1 obeys the following restrictions: x
T7_1.20/1_2.12 = T5_1.20 (from Hypothesis 2A).
5.3.2.6 Step 5: Analysis of Object O2.12 – Controller Interface A The analysis of this object for Property 2 is similar to the analysis performed for Property 1. The next object to be analysed is O1.7 – On/Off Controller A. 5.3.2.7 Step 5.1: Analysis of the Discrete Dynamics (O1.7 – On/Off Controller A) The analysis of the discrete dynamics of this object is similar to the analysis performed for Property 1. 5.3.2.8 Step 5.2: Elaboration of Hypotheses (O1.7 – On/Off Controller A) The following hypothesis is made about the behaviour of this object:
5 Application 1: HVAC System
x
139
Hypothesis 2C (hypothesis statement H1) – The method calls performed by object O1.7 are immediately executed by object O1.5: t5_1.7/1_1.5 and t6_1.7/2_1.5 fires in 'T = 0 after they are enabled in O1.7.
5.3.2.9 Step 5.3: Analysis of the Continuous Dynamics (O1.7 – On/Off Controller A) The continuous dynamics of this object is restricted by two enabling functions – e5.7: Tzn.I1.9 < (Tsp.I2.11 - K'); e6.7: Tzn.I1.9 > (Tsp.I2.11 + K'). The following considerations are made about the scenarios: x
x x
Scenarios 1-1-1 (t3_2.12/1_1.7): From Restrictions 2D and 2F, e5.7(T5_1.20) and e5.7(T3_2.12/1_1.7) are true, enabling the firings. From Hypothesis 2C, t5_1.7/1_1.5 always fires when enabled. Therefore Scenario 1-1-1 is impossible - (at least one of the Scenarios 1-1-i (i>1) must be true). Scenario 1-1-2 (t3_2.12/1_1.7; t5_1.7/1_1.5): - T5_1.7/1_1.5 = T3_2.12/1_1.7; Scenarios 1-1-i (i>2): the condition that establishes the end of the scenarios for this property is Tzn = Tsp, which means that e6.7 is false in the time interval of Property 2. Therefore Scenarios 1-1-i are impossible (Scenario 1-1-2 must be true).
5.3.2.10 Step 5.1: Analysis of the Discrete Dynamics (O1.5 – Cooling Coil A) There is a single transition firing of the interface between O1.7 and O1.5. Therefore the analysis of the discrete dynamics of this object is divided into two searches: x x
x
Search 1 (up to the firing of t5_1.7/1_1.5): Once the date of firing of t5_1.7/1_1.5 does not depend on O1.7 (according to Hypothesis 2C), this search is not performed. Search 2 (from the firing of t5_1.7/1_1.5): Transition t3_1.5 is not included in the sequent because of Restriction 2A. Transitions t5_1.7/1_1.5 and t6_1.7/2_1.5 are not included because they are from the interface between O1.7 and O1.5. The sequent is defined according to Rules 11 and 14 (Chapter 4, Section 4.3.3.9). The sequent is *0, p2_1.5 ¸ *f. No transition can be fired. Definition of the scenarios – As no transition is fired, *0 = e *f = p2_1.5: - Scenario 1-1-2: t5_1.7/1_1.5.
5.3.2.11 Step 5.2: Elaboration of Hypotheses (O1.5 – Cooling Coil A) From the continuous point of view, the evolution of the continuous variables of O1.5 depends of the image variable qair.I1.1 from O2.1 – Fan A. The following hypothesis is made about this variable: x
Hypothesis 2D (hypothesis statement H6): qair.I1.1 [0.5; 1.5] for T5_1.20dTdT(Tzn=Tsp).
5.3.2.12 Step 5.3: Analysis of the Continuous Dynamics (O1.5 – Cooling Coil A) Scenario 1-1-2 obeys the following restrictions: x
PV = 1 (imposed by j1_5).
140
Modelling and Analysis of Hybrid Supervisory Systems
x x x x x
Tair_in = Text [26, 35] (from Restriction 2F). qw, Tw, K1, K2, K3, K4, K5, Kw, KW are constant.
Considering Hypothesis 2D, the equation system of place p2_5 is solved algebraically, resulting in: H(T) [0,6893; 0,9119] in T5_1.20 d T d T(Tzn=Tsp). Tair_out is limited to the set of values illustrated in Fig. 5.36.
5.3.2.13 Step 5.1: Analysis of the Discrete Dynamics (O1.9 – Zone A) No information is given about the state of O1.9 in the beginning of the time interval of Property 2. However, the only possible marking for this object is p1_1.9=1. Starting from this marking, the possible scenarios for this object is given by the following search: x
Search 1 – (from T5_1.20): The sequent is defined by Rule 15 (Section 4.3.3.9, Chapter 4): p1_1.9, !t1_1.9, !t1_1.9, !t3_1.9, !t4_1.9 ¸ *f. 35
30
Tair out (ºC)
25
20
15
10
5
0
200
400
600
800 1000 Time (s)
1200
1400
1600
1800
Fig. 5.36. Possible values for Tair_out
p1_1.9 p1_1.9 p1_1.9,!t1_1.9,...!t4_1.9 *f —o L (t2_1.9)
Firing of t2_1.9 p1_1.9 p1_1.9 p1_1.9,!t1_1.9,...!t4_1.9 *f —o L (t1_1.9)
Firing of t1_1.9
p1_1.9 p1_1.9 p1_1.9,!t1_1.9,...!t4_1.9 *f —o L (t3_1.9)
Firing of t3_1.9 p1_1.9 p1_1.9 p1_1.9,!t1_1.9,...!t4_1.9 *f —o L (t4_1.9)
Firing of t4_1.9 p1_1.9, !t1_1.9, !t2_1.9, !t3_1.9, !t4_1.9 *f
x
Definition of the scenarios – All the transitions can be fired returning to the initial marking. As a consequence, there are infinite scenarios combining
5 Application 1: HVAC System
141
any number of firings of t1_1.9, t2_1.9, t3_1.9 and t4_1.9. In any case, *f = p1_1.9. Some examples of scenarios are: - Scenario 1-1-2-1: no firing. - Scenario 1-1-2-2: t3_1.9. - Scenario 1-1-2-3: t1_1.9; t2_1.9. 5.3.2.14 Step 5.2: Elaboration of Hypotheses (O1.9 – Zone A) No hypothesis is made about the behaviour of this object. 5.3.2.15 Step 5.3: Analysis of the Continuous Dynamics (O1.9 – Zone A) From e1_9, e2_9, e3_9, e4_9, j1_9, j2_9, j3_9 and j4_9, it is possible to conclude that Neq [0, 20] and Np [0, 20]. The variables Qac, Kac, Np, Kp, Kp_max, Neq, Keq, Keq_max, Volzn, Kzn are constant and their values have been defined at the end of Section 5.2.6. As a result, the equation system f1_9 can be solved numerically. The possible values for Tzn are presented in Fig. 5.37. In any situation, Tzn reaches Tsp in Td1800s (=30min).
36
34
Possible values for Tzn (ºC) Temperature (ºC)
32
30
28
Possible values for Tsp (ºC) 26
24
22
0
200
400
600
800 1000 Time (s)
1200
1400
1600
1800
Fig. 5.37. Possible values for Tzn
x
Property 2 is true if Hypotheses 2A, 2B, 2C and 2D are true.
5.3.2.16 Step 6: Building the Global Sequents The global sequents of the scenarios differ among themselves in the number of firings of transitions t1_1.9, t2_1.9, t3_1.9 and t4_1.9. Some examples are: x
Scenario 1-1-2-1: p4_1.20, p1_12.O1, p1_1.7, p1_1.5, p1_1.9, t5_1.20, t7_1.20/1_2.12, t3_12.O1/1_1.7, t5_1.7/1_1.5 ¸ p6_1.20
p4_12.O1
p2_1.7
p5_1.7
p2_1.5
p1_1.9.
142
Modelling and Analysis of Hybrid Supervisory Systems
x
Scenario 1-1-2-2: p4_1.20, p1_12.O1, p1_1.7, p1_1.5, p1_1.9, t5_1.20, t7_1.20/1_2.12, t3_12.O1/1_1.7, t5_1.7/1_1.5, t3_1.9¸ p6_1.20
p4_12.O1
p2_1.7
p5_1.7
p2_1.5
p1_1.9.
The partial order of transition firings of Scenario 1-1-2-2 is illustrated in Fig. 5.38. From the discrete point of view, the firing of t3_1.9 (one person enters the zone) is not related to the other firings of the scenario. t8_1.20
t5_1.20 t7_1.20/1_2.12
t3_12.O1/1_1.7 t5_1.7/1_1.5
t6_1.7/2_1.5
t3_1.9
Fig. 5.38. Partial order of firings for Scenario 1-1-2-2 – Property 2
5.3.2.17 Step 7: Verification of Hypotheses The verification of hypotheses 2A and 2B is similar to the verification of Hypotheses 1A and 1B for Property 1. Hypothesis 2C is verified by composing objects O1.7 and O1.5, while Hypothesis 2D is verified by composing objects O2.1, O2.14 and O1.20.
5.4 Final Remarks This chapter presents two applications (HVAC Systems A and B) where the processing of material (in this case the air) is continuous and most of control variables are discrete. The modelling and analysis of HVAC System A illustrates the advantages of the methods described in Chapters 3 and 4. In the analysis of an object, only the features that are relevant for the property are considered. An example is the verification of Property 1. In this case, neither the modification of the number of people in the zone nor the temperature set point act on the state of the on/off controller and therefore they are not taken into account by the analysis method. HVAC System B illustrates how a closed loop in the material processing can prevent the system decomposition because of the resulting sharing of variables in closed loops. This fact does not significantly limit the modelling activity because the OO-DPT sub-nets can be defined using the composition/decomposition relationship and combining the models of all its components. An example is object O1.10 – Air Cycle B. However, the analysis of the model is made difficult because it is necessary to analyse a complex object such as O1.10 – Air Cycle B. The search for scenarios must include all the events and the analysis of the continuous dynamics must solve the equation system resulting from all its components as a single one. It is not possible to deduce the analysis of the object from the analysis of single components.
6 Application 2: Landing System
The purpose of this chapter is to illustrate and discuss the application of the analysis method of Chapter 4 to systems that are mostly complex in the discrete dynamics. These systems are particularly critical because the decomposition of the system into objects and classes is performed based on the continuous communication among them (according to the decomposition rules of Chapter 3, Section 3.1.4). The application presented in this chapter is an aircraft landing system. It is based on the landing system of the military aircraft Rafale, made by Dassault Aviation (Dassault, 1995), (Dassault, 1996). This application has been adopted as a case study by the French research group StrQdS (Système Temp-réel Qualité de Service1) of GdR-CNRS ARP (Architecture, Réseaux et systèmes, Parallélisme2). The purpose of the case study is to analyse, test and compare different techniques, tools and approaches for the verification of behavioural properties in dynamic systems. Some results obtained by this group are discussed in Section 6.4 Section 6.1 presents a description of the landing system and the requirements of the supervisory system. Section 6.2 presents the OO-DPT classes, while Section 6.3 describes the verification of a safety property.
6.1 Description of the Landing System 6.1.1 Controlled Object The landing system is composed of 3 landing sets. Each set is composed of a door and a landing-gear. A simplified schema is presented in Fig. 6.1.
1 2
http://www.laas.fr/strqds/ http://www.arp.cnrs.fr/
144
Modelling and Analysis of Hybrid Supervisory Systems
landing-gear box landing-gear retracted
door
landing-gear extended
Fig. 6.1. Landing set
The following sequence must be performed for landing (Fig. 6.2): open the doors; extend the landing-gears; close the doors. After taking off, the sequence performed is: open the doors; retract the landing-gears, close the doors.
a) Doors closed and landing-gears retracted
b) Doors open and landing-gears retracted
c) Doors open and landing-gears extended
d) Doors closed and landing-gears extended
Fig. 6.2. Landing sequence
The pilot controls the landing system using an up-down handle, which performs the landing (down) and taking-off (up) sequences. The landing system provides the pilot with information about the system state and the occurrence of faults. A physical schema about the landing system components is presented in Fig. 6.3. The WOW (weight on the wheels) system indicates if the aircraft is landed or not. This information is used to perform the UP sequence – the landing system cannot be retracted while the aircraft is landed. The movement of doors and landing-gear is performed by a set of hydraulic actuators. The pressure on the hydraulic circuit is determined by a set of electrovalves. On/off discrete sensors inform the state of the landing system components to the controller. There is also an analogical relay which isolates the controller from the electro-valves. The relay is closed when the up/down handle is moved. It opens automatically after a certain time from the last handle movement.
6 Application 2: Landing System
Input/output to/from the pilot panel
145
Signal from the WOW system
Controller
Signal from up/down handle Analogical relay
Output to electro-valves Input from sensors
Discrete sensor (with/ without pressure)
General electro-valve
P
Electro-valve (close the doors)
Electro-valve (open the doors)
Electro-valve (retract the landing-gears)
Electro-valve (extend the landing-gears)
General hydraulic circuit
Nose door actuator
Right door actuator
Left door actuator
Discrete sensors (door open – door not open)
Nose landinggear and uplock actuator
Right landinggear actuator
Right up-lock actuator
Left landinggear actuator
Left uplock actuator
Discrete sensors (landing-gear extended – landing-gear not extended) Discrete sensors (landing-gear retracted – landing-gear not retracted) Discrete sensors (door closed – door not closed)
Fig. 6.3. Landing system components
6.1.2 Requirements of the Supervisory System The monitoring of the landing system state is one of the main functionalities of the supervisory system. For this purpose, it must verify the state of the discrete sensors with a time interval of KT (KT = 40 ms) and detect inconsistencies. The system considers three different levels of inconsistencies. Level 1 analyses the consistency of the signals from the two sensors of a door (door closed/door open) or a landinggear (landing-gear extended/landing-gear retracted). Level 2 considers the consistency of the state of a door with the state of the corresponding landing-gear. Level 3 verifies the consistency among the states of the 3 landing sets.
146
Modelling and Analysis of Hybrid Supervisory Systems
Level 1: Consistency among the sensors of door or landing-gear The state of each door is defined according to the signals from the sensors (Table 6.1). Table 6.1. States of a door Door state Door closed Door moving Door open INCONSISTENT
Door closed sensor ON OFF OFF ON
Door open sensor OFF OFF ON ON
Similarly, the state of a landing-gear is defined according to Table 6.2. Table 6.2. States of a landing-gear Landing-gear state Landing-gear retracted Landing-gear moving Landing-gear extended INCONSISTENT
Landing-gear retracted sensor ON OFF OFF ON
Landing-gear extended sensor OFF OFF ON ON
Level 2: Consistency between the state of a door and the state of the corresponding landing-gear The output of Level 1 indicates the state of the doors and landing-gears. For a given landing set, the door and landing-gear states are combined in order to provide the state of the landing set, according to Table 6.3. The seven possible states are organized into 3 groups: 1 – Landing-gear retracted, 2 – Door open, 3 – Landing-gear extended. Table 6.3. States of a landing set State of the set State 1 State 2 State 3 State 4 State 5 State 6 State 7 INCONSISTENT INCONSISTENT
Door Closed Moving Open Open Open Moving Closed Moving Closed
Landing-gear Retracted Retracted Retracted Moving Extended Extended Extended Moving Moving
Group 1 1 1 and 2 2 2 and 3 3 3 -
Level 3: Consistency among the state of the 3 landing sets The state of the 3 landing sets are consistent if they belong to the same group, otherwise an inconsistency is detected.
6 Application 2: Landing System
147
Another main function of the supervisory system is to perform the down (landing) and up (taking-off) sequences within a maximum time of KT_down and KT_up, respectively. The steps of the down sequence are: 1. 2. 3. 4. 5. 6. 7. 8.
Open the general electro-valve. Open the electro-valve for opening the doors. Close the electro-valve for opening the doors. Open the electro-valve for extending the landing-gears. Close the electro-valve for extending the landing-gears. Open the electro-valve for closing the doors. Close the electro-valve for closing the doors. Close the general electro-valve.
The steps of the up sequence are: 1. 2. 3. 4. 5. 6. 7. 8.
Open the general electro-valve. Open the electro-valve for opening the doors. Close the electro-valve for opening the doors. Open the electro-valve for retracting the landing-gears. Close the electro-valve for retracting the landing-gears. Open the electro-valve for closing the doors. Close the electro-valve for closing the doors. Close the general electro-valve.
Another functionality of the supervisory system is the detection of the following faults: x x
x
The doors must be completely open (or closed) in a time interval of KT1, starting from the moment a command to open (close) the doors is emitted by the supervisory system, otherwise a fault is detected. Similarly, the landing-gears must be completely extended (or retracted) in a time interval of KT1, starting from the moment a command to extend (retract) the landing-gears is emitted by the supervisory system, otherwise a fault is detected. The pressure sensor must detect pressure in the hydraulic circuit in a time interval of KT1, starting from the moment a command to pressurize the circuit is emitted by the supervisory system, otherwise a fault is detected.
It is important to highlight that, although the detection of faults is included in this application, the diagnosis and treatment of faults are not. The diagnosis and treatment are performed in collaboration with a back-up supervisory system and involves the use of another two redundant sets of discrete sensors.
148
Modelling and Analysis of Hybrid Supervisory Systems
6.2 Modelling of the Supervisory System and its Controlled Object This section presents the OO-DPT subnets for the classes of the landing system related to the doors’ movement and control. The OO-DPT subnets of the classes not presented here can be found in Appendix A. Once the modelling method has already been illustrated by the application of Chapter 5, this chapter goes directly to the OO-DPT net. 6.2.1 Classes and Objects The set of objects and classes that models the doors’ movement and control is composed of: Controlled Object x x x x x
C1 – Single Actuator Equipment: O1.1 – Nose Door, O2.1 – Right Door, O3.1 – Left Door; C7 – Positive Pressure Electro-valve: O1.7 – Open Door EV; C8 – Negative Pressure Electro-valve: O1.8 – Close Door EV; C9 – Dedicated Hydraulic Circuit: O1.9 – Door HC; C12 – Dedicated Electric Circuit: O1.12 – Open Door EC, O2.12 – Close Door EC;
Supervisory System x
C19 – Dedicated EV Interface: O1.19 – Door EV Interface.
The OO-DPT subnets of these classes are presented in the following. C1 – Single Actuator Equipment (Fig. 6.5) This class models the equipment that is moved by a single actuator: the three doors and the nose landing-gear. The position of the actuator depends on the pressure of the corresponding hydraulic circuit, according to Fig. 6.4. When the door is closed or the nose landing-gear is retracted, and the pressure in the actuator pI1.9 is greater than Kp, the actuator is extended with a constant speed of Kv. The position of the equipment is represented by the variable x. If the pressure goes below a minimal value (threshold Kp), the movement is interrupted and the door remains partially open or, in the case of the nose landing-gear, partially extended.
6 Application 2: Landing System
Door opening movement
Door closing movement
p = pB – pA t Kp pA
149
p = pB – pA t -Kp pB
pA
pB
x Kx
Fig. 6.4. Door opening and closing
C1 – Single Actuator Equipment Opening / extending t1_1 Door closed/Landing -gear retracted
t5_1
p2_1
t2_1
t6_1
Intermediate position p1_1
p3_1
t3_1
t4_1
p5_1 t7_1
p4_1
Variables: Xint_1 = {x, Kp, Kv, Kx, I1, I2, I3}; Xim_1 = {pI1.9} Enabling functions: e1_1, e6_1: pI1.9 t Kp; e2_1: pI1.9 < Kp; e8_1, e7_1: pI1.9 d - Kp_d; e3_1: pI1.9 > Kp_d e4_1: x = 0; e5_1: x = Kx Door open/ Equation systems: Landing-gear f2_1: dx/dT= Kv; f4_1: dx/dT = - Kv extended Methods used by the class: t1_1 o t2_I2.4 – Set sensor ‘Off’ t4_1 o t1_I3.4 – Set sensor ‘On’ t5_1 o t1_I2.4 – Set sensor ‘On’ t8_1 o t2_I3.4 – Set sensor ‘Off’
t8_1
Closing / retracting
Fig. 6.5. OO-DPT sub-net of class C1 – Single Actuator Equipment
The portion of the hydraulic circuit that moves the door actuators (or landing-gear actuators) is called dedicated hydraulic circuit and is modelled by class C9. Two electro-valves control the pressure in each dedicated hydraulic circuit (Fig. 6.6). They are called positive pressure electro-valve (modelled by C7) and negative pressure electro-valve (modelled by C8). There are 3 different discrete states for the pressure in the hydraulic circuit: positive pressure, negative pressure and blocked. The current state is determined by the position (open/closed) of the electro-valves, according to Fig. 6.6. If both valves are open, the pressure in the hydraulic circuit and actuator chambers is the return pressure (pressure of the aircraft hydraulic reservoir). This means that the supervisory system has no control over the actuator position. Therefore, this situation should never occur – it is a forbidden state.
150
Modelling and Analysis of Hybrid Supervisory Systems
Negative Pressure Negative pressure electro-valve (open) pg p=0
Positive Pressure Negative pressure electrovalve (closed) pg p=0
Actuator movement
Positive pressure electro-valve (closed) p=0 pg
Actuator movement
Positive pressure electro-valve (open) p=0 pg
Negative pressure electrovalve (closed) pg p=0
Blocked
Blocked position
Positive pressure electro-valve (closed) p=0 pg
Fig. 6.6. Dedicated hydraulic circuit and electro-valves
Both classes C7 – Positive Pressure Electro-valve and C8 – Negative Pressure Electro-valve are specialisations of class C6 – Dedicated Electro-valve. C6 – Dedicated Electro-valve (Fig. 6.7) The electro-valve has two main discrete states: closed (p1_6) and open (p4_6). It interacts with the dedicated hydraulic circuit through transitions t2_6, t3_6, t4_6 and t5_6, which are redefined as interface transitions in the specialised classes C7 and C8. C6 – Dedicated Electro-valve t3_6 p2_6 t 1_6
t4_6 p4_6
p1_6 Valve closed
t2_6
p3_6
t5_6
Variables: Xint_6 = {I1}; Methods provided by the class: t1_6 – Open electro-valve t5_6 – Close electro-valve
Valve open
Fig. 6.7. OO-DPT sub-net of class C6 – Dedicated Electro-valve C7 – Positive Pressure Electro-valve
In the case of C7, the following interfaces are specified for transitions t2_6, t3_6, t4_6 and t5_6: x x x
t2_7 o t3_I1.9 – Block positive pressure t3_7 o t4_I1.9 – Set positive pressure t4_7 o t5_I1.9 – Cancel positive pressure
6 Application 2: Landing System
151
C8 – Negative Pressure Electro-valve In the case of C8, the following interfaces are specified for transitions t2_6, t3_6, t4_6 and t5_6:
x x x
t2_8 o t2_I1.9 – Block negative pressure t3_8 o t1_I1.9 – Set negative pressure t4_8 o t6_I1.9 – Cancel negative pressure
C9 – Dedicated Hydraulic Circuit (Fig. 6.8)
The pressure on the dedicated hydraulic circuit varies according to the state of the positive and negative electro-valve, and the pressure on the general hydraulic circuit (pg.I1.5). C9 – Dedicated Hydraulic Circuit t3_9 Blocked Positive pressure p1_9
p3_9 t4_9
t1_9
t2_9
t6_9
t5_9 p2_9 Negative pressure
Variables: Xint_9 = {I1}; Xpb_9 = {p}; Xim_9 = {pg.I1.5}; Junction functions: j7_9, j6_9: p = 0; j3_9, j2_9: p = 0.9*p; Equation systems: f 1_9: p = pg.I1.5; f2_9: p = - pg.I1.5 Methods provided by the class: t1_9 – Set negativ e pressure t2_9 – Block negativ e pressure t3_9 – Block positive pressure t4_9 – Set positive pressure t5_9 – Cancel negativ e pressure t6_9 – Cancel positive pressure
p4_9 Without pressure
Fig. 6.8. OO-DPT sub-net of class C9 – Dedicated Hydraulic Circuit
An electric circuit opens and closes the electro-valves that affect the dedicated hydraulic circuit. It is modelled as an object of class C12 – Dedicated Electric Circuit, which is a specialisation of class C10 – General Hydraulic Circuit. C10 – General Hydraulic Circuit (Fig. 6.9). The state of the electric circuits depends not only on the control signals sent by the supervisory system, but also on the state of the analogical relay (Fig. 6.3). Basically, the electro-valve connected to the electric circuit is open (firing of t1_10) when the circuit is energized (firing of t4_10) by the supervisory system. The energization is possible only if the analogical relay is not isolating the electric circuit (firing of t7_10). Transitions t1_10, t5_10 and t6_10 perform the interface with the positive and negative pressure electro-valve. The method calls are specified in classes C11 and C12.
152
Modelling and Analysis of Hybrid Supervisory Systems
C10 – General Electric Circuit t1_10
p3_10
t4_10
t7_10
Isolated
Energized p2_10
p6_10
p7_10
p1_10
Not isolated
t2_10
p4_10
t5_10
Not energized t8_10
t6_10 t3_10
p5_10
Variables: Xint_10 = {I1}; Methods provided by the class: t2_10 – Not energize the electric circuit t3_10 – Isolate the electric circuit t4_10 – Energize the electric circuit t7_10 – Not isolate the electric circuit
Fig. 6.9. OO-DPT sub-net of class C10 – General Electric Circuit C12 – Dedicated Electric Circuit In the case of C12, the following interfaces are specified for transitions t1_10, t5_10 and t6_10:
x x x
t1_12 o t1_I1.6 – Open dedicated electro-valve t5_12 o t5_I1.6 – Close dedicated electro-valve t6_12 o t5_I1.6 – Close dedicated electro-valve
The object of the supervisory system that interacts with the dedicated electric circuits is from class C19 – Dedicated EV Interface. C19 – Dedicated EV Interface (Fig. 6.10)
This class determines the control signals to be sent to a pair of electro-valves of contrary action: positive pressure (I2) and negative pressure (I1) electro-valves. A light in the pilot panel is turned on when the door and landing-gear actuators are not retracted.
6 Application 2: Landing System
C19 – Dedicated EV Interface Variables: Xint_19 = {Taux, KT1, KT2, I1, I2, I3, I4, I5, I6, I7, I8}; Enabling functions: e7_19, e14_19: T= KT1; e2_19, e17_19: T= KT2; Junction functions: j1_19, j6_19, j16_19, j18_19: T = 0; Equation systems: f1_19, f6_19, f21_19, f24_19: dTaux/dT= 1; Retracted actuators
p1_19
t2_19
p3_19 t4_19
p2_19 t3_19
p4_19
t7_19 p14_19
Open valve
t5_19
Set alarm
p6_19
p5_19 t6_19
Turn on light
153
p7_19
t8_19
p15_19
p8_19
t9_19
p16_19
t15_19
p9_19
t10_19
p17_19
Close valve
p10_19
t11_19
p18_19
p11_19
t12_19
p19_19
t16_19
Confirm doors open/ landing-gears extended
p22_19
p23_19
t17_19
t18_19
p24_19
t1_19 Close Turn off Open Extended valve p12_19 t13_19 p20_19 light valve actuators Methods used by the class: t5_19 o t2_I1.12 – Not energize electric circuit t6_19 o t4_I2.12 – Energize electric circuit Confirm doors closed/ t8_19 o t4_I3.4 – Confirm sensor on p13_19 t14_19 p21_19 landing-gears retracted Set t9_19 o t4_I4.4 – Confirm sensor on alarm t10_19 o t4_I5.4 – Confirm sensor on t11_19 o t4_I6.4 – Confirm sensor on Methods provided by the class: t12_19 o t4_I7.4 – Confirm sensor on t1_19 – Confirm actuators retracted t13_19 o t4_I8.4 – Confirm sensor on t2_19 – Extend actuators t15_19 o t2_I2.12 – Not energize electric circuit t17_19 – Retract actuators t16_19 o t4_I1.12 – Energize electric circuit t18_19 – Confirm actuators extended
Fig. 6.10. OO-DPT sub-net of class C12 – Dedicated EV Interface
The initial state of the landing system is when it is completely extended (down position), i.e., when the aircraft is landed. It corresponds to the following initial marking: x
O1.1 – Nose Door X1.1: x = 0; Kp = 10; Kv = 1; Kx = 0.5; I1 = Door HC; I2 = Closed Nose Door; I3 = Open Nose Door; m1.1 = {p1_1};
x
O2.1 – Right Door X2.1: x = 0; Kp = 10; Kv = 1; Kx = 0.5; I1 = Door HC; I2 = Closed Right Door; I3 = Open Right Door; m2.1 = {p1_1};
x
O3.1 – Left Door; X3.1: x = 0; Kp = 10; Kv = 1; Kx = 0.5; I1 = Door HC; I2 = Closed Left Door; I3 = Open Left Door; m3.1 = {p1_1};
x
O1.7 – Open Door EV; X1.7: I1 = Door HC; m1.7 = {p1_7};
154
Modelling and Analysis of Hybrid Supervisory Systems
x
O1.8 – Close Door EV; X1.8: I1 = Door HC; m1.8 = {p1_8};
x
O1.9 – Door HC; X1.9: p = - 9.6; I1 = General EV/HC; m1.9 = {p1_9};
x
O1.12 – Open Door EC; X1.12: I1 = Open Door EV; m1.12 = {p7_12};
x
O2.12 – Close Door EC; X2.12: I1 = Close Door EV; m2.12 = {p7_12};
x
O1.19 – Door EV Interface X1.19: Taux = 0; KT1 = 2; KT2 = 1; I1 = Close Door EC; I2 = Open Door EC; I3 = Open Nose Door; I4 = Open Right Door; I5 = Open Left Door; I6 = Closed Nose Door; I7 = Closed Right Door, I8 = Closed Left Door; m1.19 = {p1_19};
6.3 Analysis of the OO-DPT Net Models The validation of the landing system requires the verification of a number of safety and reachability properties. In order to illustrate the validation approach, this section presents the verification of a safety property using the method described in Chapter 4. 6.3.1 Property 1 6.3.1.1 Step 1: Specification of the Property Statement Property 1 is specified according to the statement PS1 (described in Chapter 4, Section 4.3.4.1): x
Property 1 – The door hydraulic circuit can never be without pressure: the state p4_1.9 = 1 (object Door HC) is never reached.
6.3.1.2 Step 2: Specification of the Set of Restrictions No restriction is imposed. Property 1 must be true under any circumstances. 6.3.1.3 Step 3: Building the Static Collaboration Diagrams The static collaboration diagram of landing system is presented in Fig. 6.11. Only the objects that are related to the opening and closing of the doors are included in the diagram. This figure highlights the communication that generates analysis obligations.
6 Application 2: Landing System
t5_19 o t2_12 t16_19 o t4_12
t1_12 o t1_8 O2.12 – Close t5_12 o t5_8 Door EC t6_12 o t5_8
O1.19 – Door EV Interfaces t6_19 o t4_12 t15_19 o t2_12
t2_8 o t2_9 O1.8 – Close Door EV
t3_8 o t1_9 t4_8 o t6_9 O1.9 – Door HC
t2_7 o t3_9
t1_12 o t1_7 O1.12 – Open t5_12 o t5_7 Door EC t6_12 o t5_7
155
O1.7 – Open Door EV p
O1.1 – Nose Door
t3_7 o t4_9 t4_7 o t6_9 p
O2.1 – Right Door
p O3.1 – Left Door
Fig. 6.11. Relevant interactions for Property 1
Briefly, the state without pressure (p4_1.9) is reached if both valves O1.7 – Open Door EV and O1.8 – Close Door EV are simultaneously open. The analysis of O1.9 – Door HC results in two scenarios that can lead to the state: open the Close Door EV when the Open Door EV is already open (Scenario 1p), or open the Open Door EV when the Close Door EV is already open (Scenario 2p). In order to prove that these scenarios are false, it is necessary to prove that whenever the Open Door EV is opened, it must be closed before ('T>0) the Close Door EV can be opened (Scenario 1c), and whenever Close Door EV is opened, it is closed before Open Door EV can be opened (Scenario 2c). The electro-valves are activated by their electric circuits (O1.12 and O2.12), which are commanded by the object O1.19 – Door EV Interface of the supervisory system. The verification of Property 1 encompasses all these classes and starts with the analysis of O1.9 – Door HC. 6.3.1.4 Step 4.1: Analysis of the Discrete Dynamics (O1.9 – Door HC) The analysis of this object is composed of a single search. The sequent that must be analysed is: x
Search 1 (up to the forbidden state p4_1.9): *0, !t1_1.9, !t2_1.9, !t3_1.9, !t4_1.9, !t5_1.9, !t6_1.9 ¸ p4_1.9, *f: p1_1.9 p1_1.9 *0, !t1_1.9, ..., !t6_1.9 p1_1.9, *f —o L (t2_1.9) *0, !t1_1.9, ... , !t6_1.9 ¸ p2_1.9, *f p4_1.9¸ p4_1.9 —o L (t5_1.9)
Firing of t2_9
Firing of t3_9
p3_1.9 p3_1.9 *0, !t1_1.9, ... , !t6_1.9 p1_1.9, *f —o L (t4_1.9) *0, !t1_1.9, ... , !t6_1.9 ¸ p3_1.9, *f p4_1.9¸ p4_1.9 —o L (t6_1.9)
Firing of t5_9
Firing of t6_9
*0, !t1_1.9, !t2_1.9, !t3_1.9, !t4_1.9, !t5_1.9, !t6_1.9 ¸ p4_1.9, *f
156
Modelling and Analysis of Hybrid Supervisory Systems
x
Definition of forbidden scenarios – If only the two last firings are included in the scenario, two forbidden scenarios are defined. In both cases, *0 = p1_1.9 and *f = . - Scenario 1p: t6_1.9/4_1.8; t4_1.9/3_1.7 - Scenario 2p: t5_1.9/4_1.7; t1_1.9/3_1.8
x
Definition of the concurrent scenarios – The concurrent scenarios are used to prove that p4_1.9 is never reached. They consider that it is impossible to fire transitions t6_1.9/4_1.8 and t5_1.9/4_1.7. These transitions are chosen because the other transitions set the positive and negative pressure in the hydraulic circuit, moving the doors. Therefore, it is unlikely that they cannot be fired. The following concurrent scenarios are defined: - Scenario 1c: t3_1.9/2_1.7; t4_1.9/3_1.7 - Scenario 2c: t2_1.9/2_1.8; t1_1.9/3_1.8
x
Conditions for Property 1 – Once there are no enabling functions associated with t6_1.9/4_1.8 and t5_1.9/4_1.7, it must be proved that they are never enabled in objects O1.7 and O1.8 while they are also enabled in O1.9. This condition corresponds to Case 3, described in Section 4.3.4.5 of Chapter 4. One of the implications of this condition is that t6_1.9/4_1.8 and t5_1.9/4_1.7 cannot be enabled when t4_1.9/3_1.7 and t1_1.9/3_1.8 are fired. - Given a firing of t4_1.9/3_1.7, t3_1.9/2_1.7 must fire before ('T>0) the enabling of t6_1.9/4_1.8 in O1.8. - Given a firing of t1_1.9/3_1.8, t2_1.9/2_1.8 must fire before ('T>0) the enabling of t5_1.9/4_1.7 in O1.7.
Fig. 6.12 illustrates the partial order of transition firings of the concurrent and forbidden scenarios related to Property 1. Scenario 1p t6_1.9/4_1.8
Scenario 2p t1_1.9/3_1.8
t4_1.9/3_1.7 t5_1.9/4_1.7 Scenario 1c t4_1.9/3_1.7
Scenario 2c t1_1.9/3_1.8
t3_1.9/2_1.7
t2_1.9/2_1.8
Fig. 6.12. Partial order of transition firings – Scenarios 1p, 1c, 2p and 2c – Property 1
6.3.1.5 Step 4.2: Elaboration of Hypotheses (O1.9 – Door HC) No hypothesis is made. 6.3.1.6 Step 4.3: Analysis of the Continuous Dynamics (O1.9 – Door HC) There is no enabling function associated with the transitions of this object. As a consequence, the date of the transition firings are determined by analysing objects O1.7 and O1.8. 6.3.1.7 Step 5.1: Analysis of the Discrete Dynamics (O1.8 – Close Door EV) Each scenario is analysed as following:
6 Application 2: Landing System
x
157
Scenario 1p – there is only one event of this scenario from the interface between O1.8 and O1.9: the firing of t4_1.8/6_1.9. The analysis is decomposed into two searches: - Search 1 (after the firing of t4_1.8/6_1.9): this search is considered irrelevant for the analysis of Property 1. - Search 2 – (up to the firing of t4_1.8/6_1.9): *0 = p2_1.8 and *f = p2_1.8 p2_1.8 *0, !t1_1.8, !t5_1.8 p1_1.8 —o L (t1_1.8) *0, !t1_1.8, !t5_1.8 ¸ p2_1.8
-
Definition of the scenario: Scenario 1p: t4_1.8/6_1.9; t1_2.12/1_1.8
x
Scenario 1c – there is no transition firing from the interface between O1.8 and O1.9.
x
Scenario 2p – the only transition firing from the interface between O1.8 and O1.9 is the firing of t3_1.8/1_1.9: - Search 1 (after the firing of t3_1.8/1_1.9): the search is considered -
irrelevant for the analysis of Property 1. Search 2 (up to the firing of t3_1.8/1_1.9): *0 = p1_1.8 and *f = . p2_1.8 p2_1.8 *0, !t1_1.8, !t5_1.8 p1_1.8, *f —o L (t1_1.8) *0, !t1_1.8, !t5_1.8 ¸ p2_1.8, *f
x
Definition of the scenario: Scenario 2p: t3_1.8/1_1.9; t1_2.12/1_1.8
Scenario 2c – the events to be considered are the firing of t2_1.8/2_1.9 and t3_1.8/1_1.9:
-
Search 1 (after the firing of t2_1.8/2_1.9): the search is considered irrelevant for the analysis of Property 1. Search 2 (from the firing of t3_1.8/1_1.9 up to the firing of t2_1.8/2_1.9): *0 = p4_1.8 and *f = . p3_1.8 p3_1.8 *0, !t1_1.8, !t5_1.8 p4_1.8, *f —o L (t5_1.8) *0, t3_1.8, !t1_1.8, !t5_1.8 ¸ p3_1.8, *f
-
Search 2 – Verification of other concurrent scenarios: from the firing of t3_1.8/1_1.9 (p4_1.8) the only possible scenario is Scenario 2c. Search 3 (up to the firing of t3_1.8/1_1.9): similar to Search 2 of Scenario 2c. Definition of scenarios: Scenario 2c: t2_1.8/2_1.9; t5_2.12/5_1.8; t3_1.8/1_1.9; t1_2.12/1_1.8
6.3.1.8 Step 5.2: Elaboration of Hypotheses (O1.8 – Close Door EV) The following hypothesis is made and corresponds to the hypothesis statement H1 (presented in Chapter 4, Section 4.3.3.6):
158
Modelling and Analysis of Hybrid Supervisory Systems
x
Hypothesis 1A: In the time interval of Property 1, the method calls made by object O1.8 are immediately performed: after the firing of t1_2.12/1_1.8, transition t3_1.8/1_1.9 or t4_1.8/6_1.9 fires in 'T = 0, and, after the firing of t5_2.12/5_1.8, transition t2_1.8/2_1.9 fires in 'T = 0.
6.3.1.9 Step 5.3: Analysis of the Continuous Dynamics (O1.8 – Close Door EV) There is no enabling function associated with the transitions. x
Scenario 1p: - Transition t4_1.8/6_1.9 is enabled in O1.8 in T4_8 = T1_2.12/1_1.8. Moreover, if this transition is fired (Scenario 1p) T4_1.8/6_1.9 = T1_2.12/1_1.8.
x
Scenario 2c: - Transition t2_1.8/2_1.9 is enabled in O1.8 in T2_8 = T5_2.12/5_1.8. Moreover, if this transition is fired (Scenario 2c) T2_1.8/2_1.9 = T5_2.12/5_1.8.
x
Scenarios 2p and 2c: - Firing of t3_1.8/1_1.9 (Scenarios 2c and 2p): T3_1.8/1_1.9 = T1_2.12/1_1.8.
6.3.1.10 Step 5.1: Analysis of the Discrete Dynamics (O1.7 – Open Door EV) The analysis of this object is similar to the analysis of O1.7 – Close Door EV. Fig. 6.13 illustrates the partial order of firings obtained after the analysis of objects O1.7 and O1.8. Scenario 1p
Scenario 2p
t1_2.12/1_1.8
t1_2.12/1_1.8
t6_9.O1/4_1.8
t1_1.9/3_1.8
t4_1.91/3_1.7 t5_1.9/4_1.7 t1_1.12/1_1.7
t1_1.12/1_1.7 Scenario 1c t4_1.9/3_1.7
t1_1.12/1_1.7
t3_1.9/2_1.7
t5_1.12/5_1.7
Scenario 2c t1_2.12/1_1.8 t5_2.12/5_1.8
t1_1.9/3_1.8
t2_1.9/2_1.8
Fig. 6.13. Partial order of firings – Scenarios 1p, 1c, 2p and 2c – Property 1
6.3.1.11 Step 5.2: Elaboration of Hypotheses (O1.7 – Open Door EV) The following hypothesis is made: x
Hypothesis 1B (hypothesis statement H1): In the time interval of Property 1, the method calls made by object O1.8 are immediately performed: after
6 Application 2: Landing System
159
the firing of t1_1.12/1_1.7, transition t3_1.7/4_1.9 or t4_1.7/5_1.9 fires in 'T = 0, and, after the firing of t5_1.12/5_1.7, transition t2_1.7/3_1.9 fires in 'T = 0. 6.3.1.12 Step 5.3: Analysis of the Continuous Dynamics (O1.7 – Open Door EV) There is no enabling function associated with the transitions. x
Scenario 1c: - Transition t2_1.7/3_1.9 is enabled in O1.7 in T2_7 = T5_1.12/5_1.7. Moreover, if this transition is fired (Scenario 1c) T2_1.7/3_1.9 = T5_1.12/5_1.7.
x
Scenario 2p: - Transition t4_1.7/5_1.9 is enabled in O1.7 in T4_7 = T1_1.12/1_1.7. Moreover, if this transition is fired (Scenario 2p) T4_1.7/5_1.9 = T1_1.12/1_1.7.
x
Scenario 1p and 1c: - Firing of t3_1.7/4_1.9 (Scenarios 1c and 1p): T3_1.7/4_1.9 = T1_1.12/1_1.7.
x
Conditions for Property 1 – Based on the analysis of O1.7 and O1.8, the following condition is determined for Property 1 to be true: - Given a firing of t4_1.9/3_1.7, t5_1.12/5_1.7 must fire before ('T>0) the firing of t1_2.12/1_1.8. Moreover, in order to ensure that t6_1.9/4_1.8 is not enabled when t4_1.9/3_1.7 fires, the firing of t1_2.12/1_1.8 must occur after the firing of t4_1.9/3_1.7. - Given a firing of t1_1.9/3_1.8, t5_2.12/5_1.8 must fire before ('T>0) the firing of t1_1.12/1_1.7. Moreover, in order to ensure that t5_1.9/4_1.7 is not enabled when t1_1.9/3_1.8 fires, the firing of t1_1.12/1_1.7 must occur after the firing of t1_1.9/3_1.8.
In order to calculate the date of transition firings and verify the property, objects O1.12 and O2.12 must be analysed.
6.3.1.13 Step 5.1: Analysis of the Discrete Dynamics (O2.12 – Close Door EC) Each scenario is analysed as follows: x
Scenario 1p: - Search 1 (after the firing of t1_2.12/1_1.8): this search is considered irrelevant for the analysis of Property 1. - Search 2 (up to the firing of t1_2.12/1_1.8): if only the last firing is considered, then *0 = p6_2.12 and *f = . p3_2.12 p3_2.12 *0, !t2_2.12, ..., !t8_2.12 p6_2.12, *f —o L (t4_2.12) *0, !t2_2.12, !t3_2.12, !t4_2.12, !t6_2.12, !t7_2.12, !t8_2.12 ¸ p3_2.12, *f
-
Definition of the scenario: Scenario 1p: t1_2.12/1_1.8; t16_11.9/4_1.12
160
Modelling and Analysis of Hybrid Supervisory Systems
x
Scenario 1c – there is no transition firing in the scenario from the interface of this object.
x
Scenario 2p: - Search 1 (after the firing of t1_2.12/1_1.8): the search is considered irrelevant for the analysis of Property 1. - Search 2 (up to the firing of t1_2.12/1_1.8): similar to Search 2 performed for Scenario 1p. - Definition of the scenario: Scenario 2p: t1_2.12/1_1.8; t16_11.9/4_1.12
x
Scenario 2c: - Search 1 (after the firing of t5_2.12/5_1.8): the search is considered irrelevant for the analysis of Property 1. - Search 2 (from the firing of t1_2.12/1_1.8 up to the firing of t5_2.12/5_1.8): *0 = p2_2.12 and *f = . p4_2.12 p4_2.12 *0, t2_2.12, ..., !t8_2.12 p2_2.12, *f —o L (t2_2.12) *0, !t2_2.12, !t3_2.12, !t4_2.12, !t7_2.12, !t8_2.12 ¸ p4_2.12, *f
-
-
Search 2 – Verification of other concurrent scenarios: from the firing of t1_2.12/1_1.8 (p2_2.12) the only possible scenario is Scenario 2c. Search 3 (up to the firing of t1_2.12/1_1.8): similar to Search 2 of Scenario1p. Definition of scenarios: Scenario 2c: t5_2.12/5_1.8; t5_11.9/2_1.12; t1_2.12/1_1.8; t16_11.9/4_1.12
6.3.1.14 Step 5.2: Elaboration of Hypotheses (O2.12 – Close Door EC) The following hypothesis is made: x
Hypothesis 1C (hypothesis statement H1): In the time interval of Property 1, the method calls made by object O2.12 are immediately performed: after the firing of t4_2.12/16_11.9, transition t1_2.12/1_1.8 fires in 'T = 0, and, after the firing of t2_2.12/5_11.9, transition t5_2.12/5_1.8 fires in 'T = 0.
6.3.1.15 Step 5.3: Analysis of the Continuous Dynamics (O2.12 – Close Door EC) There is no enabling function associated with the transitions. x
Scenario 1p: - Transition t4_1.8/6_1.9 is enabled in O1.8 in T4_8 = T1_2.12/1_1.8 = T16_11.9/4_2.12. Moreover, if this transition is fired (Scenario 1p) T4_1.8/6_1.9 = T1_2.12/1_1.8 = T16_11.9/4_2.12.
x
Scenario 2c: - Transition t2_1.8/2_1.9 is enabled in O1.8 in T2_8 = T5_2.12/5_1.8 = T5_11.9/2_2.12. Moreover, if this transition is fired (Scenario 2c) T2_1.8/2_1.9 = T5_2.12/5_1.8 = T5_11.9/2_2.12.
6 Application 2: Landing System
x
161
Scenarios 2p and 2c: - Firing of t3_1.8/1_1.9 (Scenarios 2c and 2p): T3_1.8/1_1.9 = T1_2.12/1_1.8 = T16_11.9/4_2.12.
6.3.1.16 Step 5.1: Analysis of the Discrete Dynamics (O1.12 – Open Door EC) The analysis of this object is similar to the analysis of O2.12 – Close Door EC Fig. 6.14 illustrates the partial order of firings obtained after the analysis of objects O1.12 and O2.12. Scenario 1p t16_1.19/4_2.12
Scenario 2p
t16_2.19/4_2.12
t1_2.12/1_1.8
t1_2.12/1_1.8 t6_1.9/4_1.8
t1_1.9/3_1.8
t4_1.9/3_1.7
t5_1.9/4_1.7
t1_1.12/1_1.7
t1_1.12/1_1.7 t6_1.19/4_1.12
t6_1.19/4_1.12 Scenario 1c t3_1.9/2_1.7
t4_1.9/3_1.7
t16_2.19/4_2.12
Scenario 2c t5_2.19/2_2.12 t5_2.12/5_1.8
t1_1.12/1_1.7 t5_1.12/5_1.7 t6_1.19/4_1.12
t15_1.19/2_1.12
t1_2.12/1_1.8 t1_1.9/3_1.8
t2_1.9/2_1.8
Fig. 6.14. Partial order of firings – Scenarios 1p, 1c, 2p and 2c – Property 1
6.3.1.17 Step 5.2: Elaboration of Hypotheses (O1.12 – Open Door EC) The following hypothesis is made: x
Hypothesis 1D (hypothesis statement H1): In the time interval of Property 1, the method calls made by object O1.12 are immediately performed: after the firing of t4_1.12/6_11.9, transition t1_1.12/1_1.7 fires in 'T = 0, and, after the firing of t2_1.12/15_11.9, transition t5_1.12/5_1.7 fires in 'T = 0.
6.3.1.18 Step 5.3: Analysis of the Continuous Dynamics (O1.12 – Open Door EC) There is no enabling function associated with the transitions. x
Scenario 1c: - Transition t2_1.7/3_1.9 is enabled in O1.7 in T2_7 = T5_1.12/5_1.7 = T15_11.9/2_1.12. Moreover, if this transition is fired (Scenario 1c) T2_1.7/3_1.9 = T5_1.12/5_1.7 = T15_11.9/2_1.12.
x
Scenario 2p: - Transition t4_1.7/5_1.9 is enabled in O1.7 in T4_7 = T1_1.12/1_1.7 = T6_11.9/4_1.12. Moreover, if this transition is fired (Scenario 2p) T4_1.7/5_1.9 = T1_1.12/1_1.7 = T6_11.9/4_1.12.
162
Modelling and Analysis of Hybrid Supervisory Systems
x
Scenarios 1p and 1c: - Firing of t3_1.7/4_1.9 (Scenarios 1c and 1p): T3_1.7/4_1.9 = T1_1.12/1_1.7 = T6_11.9/4_1.12.
x
Conditions for Property 1 – Based on the analysis of O1.12 and O2.12, the following condition is determined for Property 1 to be true: - Given a firing of t4_1.9/3_1.7 (Scenario 1p or 1c), t5_1.12/5_1.7 must fire before ('T>0) the firing of t1_2.12/1_1.8. For this purpose, t15_11.9/2_1.12 must fire in T15_11.9/2_1.12 < T16_11.9/4_2.12. Moreover, in order to ensure that the firing of t1_2.12/1_1.8 occurs after the firing of t4_1.9/3_1.7, T16_11.9/4_2.12 > T6_11.9/4_1.12. - Given a firing of t1_1.9/3_1.8 (Scenario 2p or 2c), t5_2.12/5_1.8 must fire before ('T>0) the firing of t1_1.12/1_1.7. For this purpose, t5_11.9/2_2.12 must fire in T5_11.9/2_2.12 < T6_11.9/4_1.12. Moreover, in order to ensure that the firing of t1_1.12/1_1.7 occurs after the firing of t1_1.9/3_1.8, T6_11.9/4_1.12 > T16_11.9/4_2.12.
In order to calculate the date of transition firings and verify the property, object O1.19 must be analysed.
6.3.1.19 Step 5.1: Analysis of the Discrete Dynamics (O1.19 – Door EV Interface) In O1.19, differently from the other analysed objects, the methods associated with t1_11.9, t2_11.9, t17_11.9 and t18_11.9 can be called by more than one transition. As a consequence, these transitions are copied when the unfolded version of OO-DPT net is obtained (Chapter 2, Section 2.5.3). The copies of the transitions are named as t1_11.9a (called by t16_11.7), t1_11.9b (called by t29_11.7), t2_11.9a (called by t14_11.7), t2_11.9b (called by t31_11.7), t17_11.9 (called by t19_11.7), t17_11.9b (called by t26_11.7), t18_11.9a (called by t17_11.7) and t18_11.9b (called by t28_11.7). In the case of Scenarios 1p and 2p, when both firings of the interfaces between O1-19-O1.12 and O1-19-O2.12 are considered, the sequence of firings is not known. As a consequence, all the possibilities must be considered, resulting in the decomposition of each scenario. Briefly, the results obtained are: x
Scenario 1p-1 (t16_11.9/4_2.12 before t6_11.9/4_1.12): - Search 1 (after the firing of t6_11.9/4_1.12): this search is considered irrelevant for the analysis of Property 1. - Search 2 (from the firing of t16_11.9/4_2.12 up to the firing of t6_11.9/4_1.12): this scenario is only possible if there is a firing of t5_11.9/2_2.12 between the firings of t16_11.9/4_2.12 and t6_11.9/4_1.12. In this case, there are 4 possible decompositions of Scenario 1p-1 (Scenarios 1p-1-1 up to 1p-1-4). The inclusion of t5_11.9/2_2.12 means that object O2.12 must be analysed again in order to include this firing after the firing of t1_1.12/1_1.7. The new partial order resulting from this second analysis of O2.12 is illustrated in Fig. 6.15 for the case of Scenario 1p-1-1. For the other scenarios, the partial order is similar, the only modification is that the firings of t1_11.9a and/or t2_11.9a are replaced by the firings of t1_11.9b and t2_11.9b.
6 Application 2: Landing System t11_1.19/4_9.4
163
Scenario 1p-1-1
t12_1.19/4_7.4 t16_1.17/ t14_1.17/
t13_1.19/4_8.4 t3_1.19 t16_1.19/ 4_2.12
1_1.19a
2_1.19a
t4_1.19
t5_2.19/ t1_12.O2/
2_2.12
t6_9.O1/4_1.8
1_8.O1
t4_9.O1/3_1.7 t1_12.O1/1_1.7 t6_1.19/4_1.12
Fig. 6.15. Partial order of firings – Scenario 1p-1-1 – Property 1
-
Search 3 (up to the firing of t16_11.9/4_2.12): the search is considered irrelevant for the analysis of Property 1. Definition of scenarios: Scenario 1p-1-1: t6_11.9/4_1.12; t4_11.9; t2_11.9a; t1_11.9a; t3_11.9; t5_11.9/2_2.12; t11_11.9; t12_11.9; t13_11.9; t16_11.9/4_2.12; (*0 = p22_11.9 and *f = ) Scenarios 1p-1-2 up to 1p-1-4: similar to Scenario 1p-1-1 but exchanging the firings of t1_11.9a and/or t2_11.9a by the corresponding firings of t1_11.9b and t2_11.9b.
-
x
Scenario 1p-2 (t6_11.9/4_1.12 before t16_11.9/4_2.12): - Search 1 (after the firing of t16_11.9/4_2.12): the search is considered irrelevant for the analysis of Property 1. - Search 2 (from the firing of t6_11.9/4_1.12 up to the enabling of t16_11.9/4_2.12): similar to Search 2 of Scenario 1p-1, this scenario is only possible if there is a firing of t15_11.9/2_1.12 between the firings of t6_11.9/4_1.12 and t16_11.9/4_2.12. In this case, there are 4 possible decompositions of Scenario 1p-2 (Scenarios1p-2-1 up to 1p-2-4) and object O1.12 must be analysed again. The new partial order of firings is illustrated in Fig. 6.16 for Scenario 1p-2-1. For the other scenarios, the partial order is similar; the only modification is that the firings of t17_11.9a and/or t18_11.9a are replaced by t17_11.9b and t18_11.9b. Scenario 1p-2-1
t16_1.19/4_2.12 t1_2.12/1_1.8 t6_1.9/4_1.8 t4_1.9/3_1.7
t1_1.12/1_1.7 t6_1.19/ 4_1.12
t15_2.19/ t8_1.19/4_12.4 t9_1.19/4_10.4
2_1.12
t17_1.17/ t19_1.17/ 18_1.19a
17_1.19a
t10_1.19/4_11.4
Fig. 6.16. Partial order of firings – Scenario 1p-2-1 – Property 1
164
Modelling and Analysis of Hybrid Supervisory Systems
-
x
Search 3 (up to the firing of t6_11.9/4_1.12): the search is considered irrelevant for the analysis of Property 1. Definition of scenarios: Scenario 1p-2-1: t16_11.9/4_2.12; t17_11.9a; t18_11.9a; t15_11.9/2_1.12; t8_11.9; t9_11.9; t10_11.9;ҏ t6_11.9/4_1.12; (*0 = p5_11.9 and *f = ) Scenario 1p-2-2 a 1p-2-4: similar to Scenario 1p-2-1 but exchanging the firings of t17_11.9a and/or t18_11.9a by the corresponding firings of t17_11.9b and t18_11.9b
Scenario 1c: - Search 1 (after the firing of t15_11.9/2_1.12): the search is considered irrelevant for the analysis of Property 1. - Search 2 (from the firing of t6_11.9/4_1.12 up to the firing of t15_11.9/2_1.12): similar to Search 2 performed for Scenarios 1p-2. - Search 2 – Verification of concurrent scenarios: after the firing of t6_11.9/4_1.12, the firing of t7_19.O2 is a possible conflicting scenario, as it makes the firing of t15_11.9/2_1.12 impossible. However, as the firing of t15_11.9/2_1.12 is also part of Scenarios 1p, both scenarios become impossible and Property 1 is still true. In this case, object O1.9 will be in a deadlock, but the forbidden state will not be reached). - Search 3 (up to the firing of t6_11.9/4_1.12): the search is considered irrelevant for the analysis of Property 1. - Definition of scenarios – The partial order of firings for Scenario 1c is presented in Fig. 6.17: Scenario 1c: t15_11.9/2_1.12; t8_11.9; t9_11.9; t10_11.9; t6_11.9/4_1.12; (*0 = p5_11.9 and *f = ) Scenario 1c t4_1.9/3_1.7
t3_1.9/2_1.7
t1_1.12/1_1.7 t5_1.12/5_1.7 t6_1.19/4_1.12
t8_1.19/4_12.4
t15_1.19/2_1.12
t9_1.19/4_10.4 t10_1.19/4_11.4
Fig. 6.17. Partial order of firings – Scenario 1c – Property 1
x
Scenario 2p-1 (t16_11.9/4_2.12 before t6_11.9/4_1.12): - Search 1 (after the firing of t6_11.9/4_1.12): this search is considered irrelevant for the analysis of Property 1. - Search 2 (from the firing of t16_11.9/4_2.12 up to the firing of t6_11.9/4_1.12): this search is similar to Search 2 performed for Scenario 1p-1. In this case, the object O2.12 should be analysed again in order to include the firing of t5_11.9/2_2.12 (after the firing of t1_2.12/1_1.8). It results in the partial order of firings illustrated in Fig. 6.18 for the case of Scenario 2p-1-1.
6 Application 2: Landing System
t11_1.19/4_9.4
165
Scenario 2p-1-1
t12_1.19/4_7.4 t13_1.19/4_8.4 t16_1.19/
t16_1.17/1 t14_1.17/2 t3_1.19
_1.19a
_1.19a
t4_1.19
t5_1.19/
4_2.12
t1_2.12/
2_2.12
1_1.8
t1_1.9/3_1.8
t5_1.9/ 4_1.7
t1_1.12/1_1.7 t6_1.19/4_1.12
Fig. 6.18. Partial order of firings – Scenario 2p-1-1 – Property 1
x
Search 3 (up to the firing of t16_11.9/4_2.12): this search is considered irrelevant for the analysis of Property 1. Definition of scenarios: similar to the one performed for Scenarios 1p-1.
Scenario 2p-2 (t6_11.9/4_1.12 before t16_11.9/4_2.12): - Search 1 (after the firing of t16_11.9/4_2.12): this search is considered irrelevant for the analysis of Property 1. - Search 2 (from the firing of t6_11.9/4_1.12 up to the firing of t16_11.9/4_2.12): similar to Search 2 performed for Scenario 1p-2. It also results in a new analysis of O2.12 in order to include the firing of t15_11.9/2_1.12 (after the firing of t1_2.12/1_1.8). The partial order resulting from this search is illustrated in Fig. 6.19 for the case of Scenario 2p-2-1. Scenario 2p-2-1
t16_1.192/4_2.12 t1_2.12/1_1.8 t1_1.9/3_1.8
t1_1.12/
t5_1.9/4_1.7
1_1.7
t6_1.19/
t15_1.19/
4_1.12
t8_1.19/4_12.4 t9_1.19/4_10.4
2_1.12
t17_1.17/ t19_1.17/ 18_1.19a
17_1.19a
t10_1.19/4_11.4
Fig. 6.19. Partial order of firings – Scenario 2p-2-1– Property 1
-
Search 3 (up to the firing of t6_11.9/4_1.12): the search is considered irrelevant for the analysis of Property 1. Definition of scenarios: similar to the one performed for Scenarios 1p-2.
166
Modelling and Analysis of Hybrid Supervisory Systems
x
Scenario 2c: - Search 1 (after the firing of t5_11.9/2_2.12): the search is considered irrelevant for the analysis of Property 1. - Search 2 (from the firing of t16_11.9/4_2.12 up to the firing of t5_11.9/2_2.12): similar to Search 2 performed for Scenarios 2p-1. - Search 2 – Verification of concurrent scenarios: after the firing of t16_11.9/4_2.12, the firing of t14_19.O2 is a possible conflicting scenario, as it turns the firing of t5_11.9/2_2.12 impossible. Similar to the case of Scenario 1c, this firing is also part of Scenario 2p. As a consequence, both scenarios are impossible and Property 1 is still true. - Search 3 (up to the firing of t16_11.9/4_2.12): the search is considered irrelevant for the analysis of Property 1. - Definition of scenarios: The partial order of firings for Scenario 2c is presented in Fig. 6.20. Scenario 2c: t5_11.9/2_2.12; t11_11.9; t12_11.9; t13_11.9; t16_11.9/4_2.12; (*0 = p22_11.9 and *f = ) t11_1.19/4_9.4
Scenario 2c
t12_1.19/4_7.4 t13_1.19/4_8.4 t16_1.19/ 4_2.12
t5_1.19/ t1_2.12/
t5_2.12/5_1.8
2_2.12
1_1.8
t1_1.9/3_1.8
t2_1.9/2_1.8
Fig. 6.20. Partial order of firings – Scenario 2c – Property 1
6.3.1.20 Step 5.2: Elaboration of Hypotheses (O1.19 – Door EV Interface) No hypothesis is made. Summarizing the previous results, the following statements are made: x x x
If any of the transitions t8_11.9/4_4.O12, t9_11.9/4_4.O10 or t10_11.9/4_4.O11 is not enabled, both Scenarios 1p-2 and 1c are impossible. If any of the transitions t11_11.9/4_4.O9, t12_11.9/4_4.O7 or t13_11.9/4_4.O8 is not enabled, both Scenarios 2p-1 and 2c are impossible. If any of the transitions t1_11.9a(b) or t2_11.9a(b) is not enabled, both Scenarios 1p-1 and 2p-1 are impossible.
6.3.1.21 Step 5.3: Analysis of the Continuous Dynamics (O1.19 – Door EV Interface) Scenario 1p-1: The date of firing of the transitions that are interface with objects that have not been analysed is not known. However, by analysing the enabling functions, junction functions and equation systems of object O1.19, the following statement is obtained concerning all the scenarios:
6 Application 2: Landing System
x
167
T6_11.9/4_1.12 t T4_11.9 = T2_11.9a(b) t (T1_11.9a(b) + KT2) t T3_11.9 = T5_11.9/2_2.12 t max(T11_11.9/4_4.O9, T12_11.9/4_4.O7, T13_11.9/4_4.O8) t T16_11.9/4_2.12 T6_11.9/4_1.12 t (T16_11.9/4_2.12 + KT2) T6_11.9/4_1.12 > T16_11.9/4_2.12.
But according to the analysis of the other objects and the hypotheses made, it is also true that: x x
T4_1.8/6_1.9 = T1_1.12/1_1.8 = T16_11.9/4_2.12. T3_1.7/4_1.9 = T1_1.12/1_1.7 = T6_11.9/4_1.12.
As a result, T3_1.7/4_1.9 > T4_1.8/6_1.9. Therefore, the scenario is impossible because the firing of t3_1.7/4_1.9 is a pre-condition for the firing of t4_1.8/6_1.9. The interpretation of the results is the following: Scenarios 1p-1 are the cases where the two commands emitted by the Door EV Interface (t16_11.9/4_2.12 and t6_11.9/4_1.12) are performed in the reverse sequence of their emission. The hypotheses and analyses result in the conclusion that a command emitted by de Door EV Interface is always performed in a time interval of 'T = 0. The analysis of Door EV Interface indicates that there is always a time interval of 'T > 0 between the emission of two commands. As a consequence, the commands are always performed in the same sequence as they are emitted. Scenarios 1p-1 are therefore impossible. Scenarios 2p-2: Making a similar reasoning to the one made for Scenarios 1p-1, it is possible to state that Scenarios 2p-2 are also impossible. Scenarios 1p-2: Analysing the enabling functions, junction functions and equation systems of object O1.19, the following statement is obtained about all the scenarios: x
T16_11.9/4_2.12 t T17_11.9a(b) t (T18_11.9a(b) + KT2) t T15_11.9/2_1.12 t max(T8_11.9/4_4.O12, T9_11.9/4_4.O10, T10_11.9/4_4.O11) t T6_11.9/4_1.12 t (T16_11.9/4_2.12 + KT2) T16_11.9/4_2.12 > T15_11.9/2_1.12 and T16_11.9/4_2.12 > T6_11.9/4_1.12
According to this result, in the case that the common events between Scenarios 1p-2 and 1c occur, all the conditions previously established for the occurrence of Scenario 1c instead of Scenario 1p-1 are satisfied. As a consequence, Scenarios 1p-2 are also impossible. The interpretation of the results indicates the following: Scenarios 1p-2 illustrate the sequence of events when Door EV Interface emits two commands for Close Door EC and Open Door EC. The commands are propagated to the objects Close Door EV and Open Door EV and executed in the same sequence of emission. However, the analysis of Door EV Interface indicates that whenever a command to open the valve Open Door EV is emitted, a command to close this valve must be emitted before a command to open valve Close Door EV is emitted. Moreover, the analysis also indicates that there is always a time interval KT2>0 between the command to close Open Door EV and the command to open Close Door EV. As a
168
Modelling and Analysis of Hybrid Supervisory Systems
consequence, valve Open Door EV is effectively closed when a command to open Close Door EV is emitted and the scenarios are impossible. Scenarios 2p-1: Following a similar reasoning to the one made for Scenarios 1p-2, Scenarios 2p-1 are proven impossible. Scenarios 1c and 2c: No additional condition is imposed for the viability of these scenarios. Up to this point, all the forbidden scenarios have been proven impossible. The validity of this result is conditioned to the proof of Hypotheses 1A, 1B, 1C and 1D. 6.3.1.22 Step 7: Verification of Hypotheses The verification of Hypotheses 1A and 1B are performed by composing objects O1.7, O1.8 and O1.9. The verification of Hypotheses 1C and 1D is performed by composing objects O1.7 and O2.12, and O1.8 and O1.12, respectively. In this case, it is necessary to introduce a new hypothesis (Hypothesis 1E) about the interface with the analogical relay (the model of object O1.13 – Analogical Relay is presented in Appendix A). Hypothesis 1E supposes that the relay is never isolating the electrical circuits when the supervisory system emits a command. The verification of Hypothesis 1E can be divided into two reachability properties to be proven: x x
The analogical relay is always closed during a time interval of [0, 15] after the pilot modifies the state of the Up/Down handle. The sequences Up and Down are completely performed in a time interval of [0, 14] after the pilot modifies the state of the Up/Down handle, ensuring that the electrical circuits are energized whenever necessary.
Particularly, the second reachability properties can be decomposed into a set of simplest reachability properties, each of them referring to the duration of a step of the Up and Down sequences (pressurize the general hydraulic circuit, open the doors, extend or retract the landing-gears, close the doors, depressurize the general hydraulic circuit). For each of these properties, a limited set of objects must be analysed, ensuring the viability of the analysis.
6.4 Final Remarks The main points to be highlighted about the modelling of the landing system are: x x
The continuous dynamics of the models are relatively simple when comparing to the other applications presented in this book. In many objects, they are a temporization between two events. There are few continuous variables shared among objects. Most of them are related to the pressure in the hydraulic circuits.
6 Application 2: Landing System
x x
169
On the other hand, there are many discrete communications among objects in closed loop. As a result, the behaviour of an object affects and is affected by the behaviour of many or even all the landing system objects. The system is composed of similar sets of objects. The models of the three sets of landing-gear/door are almost the same. The models of the electrical and hydraulic circuits of the doors are identical to the ones of the landinggears. This is useful because the analysis of one set of objects can be extended to the other similar sets.
This application highlighted the importance of introducing the right hypotheses, i.e., hypotheses that break the closed loop of discrete communication among the objects. In the case of Property 1, the introduction of Hypotheses 1C, 1D and 1E made the verification of the property possible by decomposing it into a set of simple analysis problems. If these hypotheses had not been introduced, the resulting number of scenarios would make the analysis problem untreatable. The analysis of the landing system also illustrated how the state explosion problem can be avoided by adopting a local focus (analysis of a single object at a time) and considering the causality among the events (the partial order). The verification of Property 1 results in the analysis of scenarios with about 10 to 15 transition firings from 6 objects. The same verification, if performed using a global focus (analysis of the whole landing system at the same time) should also consider the states and events of the other 41 objects. It would result in sequences with thousands of transition firings because the supervisory system verifies the consistency of the state of the landing system sensors every few milliseconds. Even if not relevant for the verification of Property 1, these events would be included in an analysis based on a global focus and would result in an excessive number of transition firing sequences. In the context of the French research group StrQdS, the landing system of the Rafale aircraft has been used to test and analyse verification tools for discrete event dynamic systems. Particularly, the following tools have been considered: NPTools+Lucifer translator (Ljung, 1999), Lesar (Halbwachs, 1992), SMV (Clarke et al., 1993) and UPPAL (Pettersson and Larsen, 2000). For the first three verification tools, the landing system is described using the Lustre language. In the case of UPPAL, it is described with timed automata. In all the four cases, the continuous dynamics is simplified and reduced to timed models. With the exception of SMV, the other tools were not able to perform the verification considering the system with 3 landing sets and a general context (the behaviour of the pilot is not known) (Boniol and Carcenac, 2002). These results illustrate the limitation of the current verification tools and highlight the importance of developing tools based on a modular approach. Although some tools, such as UPPAAL, allow the modular modelling of the system, the analysis is made using a global approach. Generally, the analysis process enumerates all the possible sequences of events, resulting in the explosion of the number of scenarios and states.
7 Application 3: Cane Sugar Factory
The purpose of this chapter is to illustrate the application of the modelling and analysis methods for a complex system, composed of processes with a large range of different dynamic characteristics. Some processes are essentially continuous, some are classified as batch processes and others can be considered as discrete event driven. Regarding the modelling method, this chapter highlithgs the importance of the PFS for understanding the relationship among the numerous processes. Regarding the analysis method, it illustrates the verification of a safety property in the case that the continuous dynamics has an important role. The application of this chapter is the supervision of cane sugar production in a factory. The industrial plant used as an example is Cruz Alta, from Açucar Guarani Company and located in the state of São Paulo, Brazil. In order to better illustrate the extent of the Cruz Alta factory, some figures about the sugar production are provided here. The factory processes about 11,000 tons of cane per day, producing about 1,300 tons of sugar and 2,000 tons of alcohol molasses per day. Section 7.1 presents the sugar production at the Cruz Alta factory and the requirements of the supervisory system. In Section 7.2, Step 1 of the modelling method is applied in order to describe the processes that compose the cane sugar production. This section also presents some examples of objects and classes. The OO-DPT net model of other classes can be found in (Villani, 2004). Section 7.3 illustrates the system analysis by verifying a safety property.
7.1 Description of the Cane Sugar Factory 7.1.1 Controlled Object The production of sugar in the Cruz Alta factory is composed of a number of mechanical and chemical processes that can be organized in the following stages (Hugot, 1986):
172
Modelling and Analysis of Hybrid Supervisory Systems
x
x x
x
x x
x
x
Reception – The cane arrives at the factory in trucks. It can be immediately used in the sugar production or can be sent to a storehouse and processed later. The cane used in the production is washed and put on a conveyor. Preparation – The cane on the conveyor is cut in a chopper and crushed in a shredder. A second conveyor sends it to the diffuser. Extraction – At Cruz Alta, the cane juice is extracted by diffusion. In the diffusion the chopped and shredded cane is soaked in a solution that is less concentrated than the juice in the cane. As a result the excess of sugar in the cane juice is released in the solution. The diffuser has a horizontal conveyor that transports a cane layer, which is abundantly sprinkled with the solution inside the diffuser. In this way the sugar is extracted from the cane. Juice treatment – The purpose of this stage is to sterilize, regulate the pH and adjust the juice colour. Firstly, the juice is mixed with SO2 to break sucrose molecules into glucose molecules. In order to restore the juice pH, limewater (CaO) is added. The juice is then pumped through heaters and sent to clarification. Clarification – The juice passes through the clarifier, which has a number of compartments where particles settle down. The flow of juice is continuous, but its speed is sufficiently slow for decanting. Evaporation – The clarified juice has about 85% of water. Evaporation must eliminate the major part of this water. It is performed in a multipleeffect evaporator. The product resulting from evaporation has a high density and is called syrup. Crystallisation and centrifugation – The syrup viscosity makes further concentration of syrup in the evaporators impossible. For this purpose, vacuum pans are employed. They perform the sugar crystallisation (growth of crystals). The sugar dough produced by the vacuum pans is sent to centrifuges that remove the remaining water. Drying and packing – The sugar obtained after the centrifugation is dried and packed.
7.1.2 Requirements of the Supervisory System The range of functions and services that must be provided by the supervisory system of a cane sugar factory is extremely large. It encompasses specific equipment monitoring functions as well as services that affect the whole plant. The selection of functions for the Cruz Alta factory does not aim to specify a complete supervisory system that responds to all factory needs. It focuses on providing a significant set to illustrate the modelling and analysis methods of this book.
7 Application 3: Cane Sugar Factory
173
From the point of view of the factory management, the supervisory system must provide the following functionalities: x x
The technical staff may start and interrupt the cane sugar processing at each stage of the sugar production. This function is used in the case of weekend stops. The technical staff may select between three different levels of production for each stage, according to the request and intermediate storages.
Other functionalities are specific to each stage. Regarding the reception stage, the supervisory system must: x x x
Decide the truck destination (production line or storehouse). Request the transfer of cane from the storehouse to the production line when necessary (e.g. during the night). Interrupt the provision of cane to the production line in the case of alarm.
Regarding the preparation stage, the supervisory system must: x x
Interrupt the preparation stage and turn off conveyors and other equipment in the case of alarm. Request the interruption of cane provision in the case of overload in the chopper or shredder.
No specific requirement is defined for the diffusion stage because the diffuser control system provides all the necessary supervision functions. Regarding the juice treatment, the supervisory system must: x x x x
Monitor the process, avoid tank overflow or pumping from an empty tank. Supervise the provision of sulphur to the rotating furnace. Supervise the provision of lime used for drying the air that is employed in the sulphitation process. Request the preventive maintenance of heaters.
Regarding the evaporation stage, the following functions are specified: x Monitor the process, avoid tank overflow or pumping from an empty tank. Regarding the crystallisation stage, the following functions are specified: x Determine the kind of dough (A, B or C) to be produced in each vacuum pan and configure it accordingly. x Avoid the overflow of intermediate tanks or pumping from an empty tank. x Request the expedition of molasses resulting from the production of dough C. Regarding the packing stage, the supervisory system must: x
Register the sugar produced in the factory.
174
Modelling and Analysis of Hybrid Supervisory Systems
7.2 Modelling of the Supervisory System and the Controlled Object In the application of the cane sugar factory, the use of PFS is particularly important because it describes the complicated relations in the flows of materials through the production processes. This section begins by presenting Step 1 of the modelling method. It then presents the objects and classes related to the reception and preparation stages. These objects are used in the verification of a safety property described in Section 7.3. The model of other objects and classes are presented in Villani (2004). 7.2.1 Step 1: Modelling the Flows of Material Due to the complexity of the flows of material, this application employs the PFS refinement techniques. Fig. 7.1 presents the general PFS of the system. The activities are related to the production stages and are further refined. Water Steam
Water Cane
Reception
Preparation
Extraction
Bagasse
Cane juice Sulphitation
Lime addition Lime Water
Sulphur Lime Water
Heating Steam Water
Syrup Clarification Mud cake
Evaporation
Steam Residual vegetal steam
Sugar Crystallisation and Centrifugation
Vegetal steam from nd the 2 effect
Drying and Packing
Sugar
Molasses
Fig. 7.1. PFS of the crystal cane sugar production
The vegetal steam generated in the [Evaporation] is firstly used in the crystallisation process. The residual vegetal steam can be used in the [Heating] and [Extraction]. If the residual steam is not enough, the [Heating] and [Extraction] use steam produced by the burning of the bagasse resulting from the extraction process. The amount of residual steam affects only the burning of bagasse. As it is a process that is not under the control of the supervisory system, the use of residual steam is not considered in the modelling. 7.2.1.1 Refinement of [Reception] At the Cruz Alta factory, the unloading of the trucks is performed by two cranes that are located beside the production line and the storehouse (Fig. 7.2). In both cases, there are two ways of unloading the cane: turning the truck cart or using a chain mechanism. The cane transportation from the storehouse to the production
7 Application 3: Cane Sugar Factory
175
line is performed by a truck with grips, which does not request a crane to load and unload the cane. The cane removed from the truck is put on two feed tables (Fig. 7.3): the first one receives the cane from the storehouse and the second one receives the cane from the trucks through a crane. The cane on the tables is washed by a shower system. Production line
Crane 1
Crane 2 Truck with grips
Storehouse for temporary storage Cane truck
Cane truck Feed tables
Fig. 7.2. Cane reception
Show ers Cane unloading using the truck w ith grips Feed Table 2
Feed Table 1
Cane unloading using the crane
Conveyor
Fig. 7.3. Feed tables and showers
Based on this description, [Reception] is refined in Fig. 7.4. Reception
Unload in the storehouse using chains Unload in the storehouse by turning the cart Unload in the production line using chains Unload in the production line by turning the cart
Water Move with grip truck
Washing Table 1
Water Washing Table 2
Fig. 7.4. Refinement of [Reception]
7.2.1.2 Refinement of [Preparation] The layout of the [Preparation] equipment is illustrated in Fig. 7.5. For modelling purposes, Conveyor 1, which receives the cane from the [Reception] is divided into two: Conveyor 1A, before the chopper, and Conveyor 1B, after the chopper. After
176
Modelling and Analysis of Hybrid Supervisory Systems
the shredder, a second conveyor (Conveyor 2) takes the cane to the diffuser. The excess of cane at the diffuser entrance is returned to the beginning of Conveyor 2 by Conveyor 3. The refinement of [Preparation] is presented in Fig. 7.6. Shredder Conveyor 1B
Conveyor 3
Chopper
To diffuser Excess of cane
Conveyor 1A Conveyor 2
Fig. 7.5. Preparation layout Preparation
Transport Conveyor 1A
Transport Conveyor 2
Process in the chopper
Transport Conveyor 1B
Process in the shredder
Remove the excess of cane Transport Conveyor 3
Fig. 7.6. Refinement of [Preparation]
7.2.1.3 Refinement of [Extraction] The layout of the diffusion process is illustrated in Fig. 7.7. The diffuser is divided into 14 slots. The cane layer on the diffuser conveyor is soaked abundantly with juice extracted from the diffuser. Under the cane layer, the diffuser is divided into 14 recipients that collect the juice that has just passed through the cane layer (the diffuser conveyor is a grid). A pump collects the juice in each recipient and sends it to the previous slot. The bagasse that leaves the last slot of the diffuser is sent to a milling train that extracts the excess of juice and makes it suitable to be burned in the furnaces, generating electrical power to the factory. The juice that is sent to the sulphitation process is part of the juice collected in the first recipient. The remaining juice from the first recipient is used in the diffusion process. The refinement of [Extraction] is presented in Fig. 7.8. 7.2.1.4 Refinement of [Sulphitation] The layout of the sulphitation process is presented in Fig. 7.9. The juice from the diffusion is stored in a tank. The burning of sulphur powder in a furnace generates the SO2 used in the sulphitation process: S + O2 o SO2. The compressed air used in the combustion is produced by a compressor. Before being sent to the furnace, the compressed air is dried in a chamber with lime in order to avoid the generation of SO3.
7 Application 3: Cane Sugar Factory
Valve VV Steam
To sulphitation Water + Valve V C steam C4
C5
C6
177
C2+C3
C7
C8
C9
C10 C11 C12
C13 C14
M
Valve VA Water
Milling train C1
C2
C3
C4
C5
C6
C7
C8
C9
C10
C11 C12 C13 C14
M
Fig. 7.7. Layout of the diffuser
Water Steam
Extraction
From C4 Extration C1
From C5
Extration C2
Extration C3 Flow control in V V
Pumping Pumping
Flow division in V C
Heating
From C7 Extration C4
From C8
Extration C5
Pumping
Extration C6
Pumping To C2
Pumping To C3
To C3 Flow control in V A
Extration C13
Extration C14
Pumping
Extration Milling train
Pumping To C11
Pumping To C12
To Sulphitation
Fig. 7.8. Refinement of [Extraction]
The SO2 produced in the combustion passes through a cooling coil and goes to the sulphitation column, which is composed of a set of inclined plates. The juice from the tank is introduced in the upper part of the sulphitation column and its speed is reduced by the plates. The gases are introduced in the lower part of the sulphitation column. The refinement of [Sulphitation] is presented in Fig. 7.10.
178
Modelling and Analysis of Hybrid Supervisory Systems Juice from extraction
Sulphitation column Air
Juice tank - TC
Air + SO2
To lime addition
Cold w ater Warm w ater
Air + SO2 Sulphur Furnace
Compressor Admission valve - VAC
Lime chamber
Fig. 7.9. Sulphitation layout
Sulphur
Production of compressed air
Storage in tank TC
Lime
Sulphitation
Water
Drying w ith lime
Control of flow in V AC
Burning of sulphur
Cooling the air
Pumping
Process at sulphitation column
Fig. 7.10. Refinement of [Sulphitation]
7.2.1.5 Refinement of [Lime Addition] Fig. 7.11 presents the layout of the lime addition process. Lime (CaO) is introduced in a rotary tank and is mixed with water. The lime water is collected through a set of orifices in the rotary tank. It is then directed to the lime water tank, which has a mixer and maintains the mixture homogenous. In the mixing tank, the lime water is mixed with the juice from the sulphitation, and is sent to the heaters. The refinement of [Lime Addition] is presented in Fig. 7.10. 7.2.1.6 Refinement of [Heating] The juice from the [Lime addition] passes through a set of 3 heaters. The Cruz Alta factory has three sets of four heaters. At least one heater of each set is usually under maintenance. A valve with two input and two output ports (V2I2O) is used to put the heater in operation or under maintenance. The layout of the heaters is presented in Fig 7.13. The refinement of [Heating] is presented in Fig. 7.14.
7 Application 3: Cane Sugar Factory
179
Water Lime water
CaO Rotary tank
Juice from sulphitation Mixer Lime water valve - VLC Lime water tank - TLC
To heating
Mixing tank - T M
Fig. 7.11. Layout of juice treatment equipment
Lime addition Water
Lime
Production of lime water
Mixture in tank TM
Store in tank TLC
Flow control in valve VLC
Pumping
Fig. 7.12. Refinement of [Lime addition]
7.2.1.7 Refinement of [Clarification] The clarification process is illustrated in Fig. 7.15. The juice from the heaters is stored in a tank (TCL). From the tank it is sent to three clarifiers. The clarifiers are tanks divided into a number of compartments. The juice flows continuously but slowly from one compartment to the next, allowing particles to settle down. The clarification process produces juice and mud. A pump extracts the mud and sends it to the filters. The filter decomposes the mud into juice and cake. The juice extracted from the mud is sent back to the TCL tank. The cake is a natural fertilizer and is commercialized. Fig 7.16 presents the refinement of [Clarification].
180
Modelling and Analysis of Hybrid Supervisory Systems Steam
Water
To clarification
Juice from lime addition
Fig. 7.13. Heater installation
Heating Steam
Steam
Steam
Steam
Flow Division
Heating
Heating
Heating
Heating
Flow control at V 2I2O
Flow control at V 2I2O
Flow control at V 2I2O
Flow control at V 2I2O
Heating
Heating
Heating
Heating
Flow control at V 2I2O
Flow control at V 2I2O
Flow control at V 2I2O
Flow control at V 2I2O
Heating
Heating
Heating
Heating
Flow control at V 2I2O
Flow control at V 2I2O
Flow control at V 2I2O
Flow control at V 2I2O
Fig. 7.14. Refinement of [Heating]
7 Application 3: Cane Sugar Factory
181
Juice from heating Clarifier
Clarifier
Clarifier
Juice tank TCL
Mud Filter
Filter
Filter
Juice to evaporation
Cake
Fig. 7.15. Clarification layout
Clarification
Store in tank TCL
Clarification at Clarifier 1 Clarification at Clarifier 2 Clarification at Clarifier 3
Flow division
Pumping
Filtering at Filter 1
Filtering at Filter 2 Filtering at Filter 3 Cake
Fig. 7.16. Refinement of [Clarification]
7.2.1.8 Refinement of [Evaporation] The evaporation process is performed in a multiple-effect evaporator (Benne et al., 2000), (Cadet et al., 1999) and (Elhaq et al., 1999). Each effect increases the concentration of the juice and the final product of the evaporation is called syrup. Each effect is composed of one or more units. In each unit, juice and steam are introduced simultaneously. The steam condensates and increases the juice temperature. Part of the water in the juice evaporates, generating the steam that is used in the next effect. Part of the steam from the second effect is sent to the crystallisation process. The residual steam from all the effects can also be used in other processes of the factory. At the Cruz Alta factory, the first effect is composed of three units, the second of four units, and the third, fourth and fifth of one unit. A layout of the evaporator is presented in Fig 7.17.
182
Modelling and Analysis of Hybrid Supervisory Systems
Steam
Steam used by other processes 2nd Effect
1st Effect Water Steam used by other process
3rd Effect
4th Effect
5th Effect Residual steam
Syrup
Return of juice (w hen the unit is emptied) Juice from clarific ation
Juice tank – TEV1
Juice tank – TEV2
Juice tank – TEV3
Fig. 7.17. Multiple-effect evaporator
Fig 7.18 presents the refinement of [Evaporation]. 7.2.1.9 Refinement of [Crystallisation and Centrifugation] The vacuum pans used in the crystallisation process are similar to the units of the evaporator, but instead of operating with a continuous flow of juice and steam, they perform a batch process and have an operation cycle. The product from the crystallisation is called dough and is sent to the centrifuges, which also operate in a batch process. The products from the centrifugation are the magma, the sugar, and the molasses. The crystallisation and centrifugation processes can be organized in a number of different configurations. It has two main inputs: syrup or magma, and seeds; and generates one output: dough. The centrifugation has one input: dough; and generates two outputs: magma or sugar, and molasses.
7 Application 3: Cane Sugar Factory
183
Evaporation Steam
Store in tank T EV1
Flow division
Pumping
st
Evaporation - 1 st Effect – 1 unit
Store in tank TEV2
st
Evaporation - 1 nd Effect – 2 unit
Steam division
st
Evaporation - 1 rd Effect – 3 unit Ev. 2-1 Ev. 2-1 Ev. 2-2 Ev. 2-2 Ev. 2-3 Ev. 2-3
nd
Evaporation – 2 st Effect – 1 unit
nd
Evaporation – 2 nd Effect – 2 unit
Flow division Ev. 2-1 Ev. 2-2 Ev. 2-3 Ev. 2-4
Steam division rd
Store in tank T EV3
Evaporation – 3 st Effect – 1 unit
nd
Evaporation – 2 rd Effect – 3 unit
th
Ev. 2-4 Ev. 2-4
Ev. 2-1 Ev. 2-2 Ev. 2-3 Ev. 2-4
nd
Evaporation – 2 th Effect – 4 unit
Evaporation – 4 st Effect – 1 unit
Vegetal steam nd 2 Effect
th
Evaporation – 5 st Effect – 1 unit
Residual vegetal steam
Fig. 7.18. Refinement of [Evaporation]
In the case of the Cruz Alta factory, the vacuum pans produce three different kinds of dough: A, B and C (Fig 7.19). The centrifugation of dough A results in sugar and sugar molasses A. The centrifugation of dough B produces magma B and sugar molasses B, while dough C results in magma C and sugar molasses C. Dough A is produced with the syrup from the evaporation process and uses magma B as seeds (more information about the crystallisation process can be found in Lauret et al. (2000) and Garcia et al.(2003). Dough B is produced from molasses A and uses magma C as seeds. Dough C is produced from molasses B and uses seeds that are bought by the factory. Sugar molasses C is a commercialized product used in the alcohol production. The refinement of [Crystallisation and Centrifugation] is presented in Fig 7.20. In the PFS of Fig 7.20, each activity models the crystallisation or centrifugation of a different kind of dough and can be refined to specify the vacuum pan or centrifuge that is being used. The Cruz Alta factory has ten vacuum pans that can be used to produce any kind of dough. As an example, Fig 7.21 presents the refinement of [Crystallisation of Dough A]. 7.2.1.10 Refinement of [Drying and Packing] The sugar from the centrifugation is sent to the sugar storage and then conveyed into a dryer. From the dryer, the sugar is sent to the packing machine. The layout of the installation is presented in Fig 7.22. The refinement of [Drying and Packing] is presented in Fig 7.23.
184
Modelling and Analysis of Hybrid Supervisory Systems Vacuum pans
Syrup
Dough tanks
Tank of syrup Dough A
Dough B
Dough C Centrifuges
Sugar
Magma tanks Magma B
Magma C Molasses tank
Molasses A To alcohol production Molasses B
Molasses C
Fig. 7.19. Crystallisation and centrifugation processes at the Cruz Alta factory
Crystallisation Crystallisation and and Centrifugation C t if ti
Crystallisation of Dough A
Storage of Dough A
Sugar
Centrifugation of Dough A
Storage of Molasses A
Vegetal steam 2nd Effect
Crystallisation Storage of of Dough B Dough B Vegetal steam from 2nd Effect
Centrifugation of Dough B
Crystallisation of Dough C Vegetal steam from 2nd Effect
Centrifugation of Dough C
Storage of Dough C
Storage of Magma B Storage of Molasses B
Storage of Magma C Storage of Molasses C Molasses C
Fig. 7.20. Refinement of [Crystallisation and Centrifugation]
7 Application 3: Cane Sugar Factory
Crystallisation of Dough A
185
Vegetal steam from 2nd Effect
Crystallisation of Dough A in Pan 1 Flow division
Crystallisation of Dough A in Pan 2
Crystallisation of Dough A in Pan 10
Magma B
Fig. 7.21. Refinement of [Crystallisation of Dough A]
Sugar
Sugar dryer Sugar storage
Packing machine
Sugar packages
Fig. 7.22. Layout of the drying and packing installations
Drying and packing
Storage in the sugar storage
Drying
Packing
Fig. 7.23. Refinement of [Drying and Packing]
7.2.2 Examples of Classes and Objects The processes of reception and preparation are modelled by the following objects and classes, among others: Controlled Object x x
C7 – Feed Table: O1.7 – Table 1; O2.7 – Table 2. C13 – Conveyor 1 – Chopper: O1.13 – Conveyor 1-Chopper.
186
Modelling and Analysis of Hybrid Supervisory Systems
Supervisory System x x
C74 – Table Interface: O1.74 – Table Interface C76 – Chopper Controller: O1.76 – Chopper Controller
The models of these classes are presented here. The other classes that compose the model of the Cruz Alta factory are presented in Villani (2004). C7 – Feed Table (Fig 7.24) This class models the feed tables that receive the cane from the trucks. The left part of the OO-DPT net models the cane unloading. The total volume of cane on the table is given by VM. When the Feed Table is turned on, the amount of cane dropped in the production line is approximately constant and is given by ‘qM*vVV.I3.9’, vVV.I3.9 is the speed of the table, set by the Speed Controller (C9). When the total amount of cane on the Feed Table exceeds the maximum amount (KV_M), a fault is detected because the excess of cane may overload the conveyor electric motor. When the Feed Table gets empty (firing of t9_7), qM becomes zero. The Feed Table also acts on in the corresponding Shower (C8), turning it on (t7_7) and off (t11_7). Unloading the cane Excess of t2_7 With grips or cane chains p1_7 t1_7 p2_7 t3_7
p3_7
t4_7
t5_7 p4_7
p5_7
t7_7
With cane p6_7
C7 – Feed Table Enabling functions: e1_7: V M > KV_M; e9_7: V M = 0; e10_7: V M > 0; Junction functions: j2_7: V M = V M + V CM; j6_7; j9_7: qM = 0; j10_7; j7_7: qM = Kq_M*v VV .I3.9; Equation systems: f 2_7: dV M/dT= qCB.I1.2 – qM f 3_7: dV M/dT = - qM
p9_7
p7_7
t8_7 p8_7
By turning the cart
On
Empty t10_7
t6_7 Off
t9_7
t12_7
t11_7 p10_7
Feeding e d i n ine Variables: Xint_7 = {V M, V CM, Kq_M, KV_M, I1, I2, I3}; Xpb_7 = {qM}; Xim_7 = {qCB.I1.2; vVV .I3.9}; Methods provided by the class: t2_7 – {VCM} – Drop cane on the table t3_7 – {I1} – Begin to unload on the table t4_7 – Finalize the unloading on the table t5_7 – Turn on the table t12_7 – Turn off the table Methods used by the class t7_7ot1_I2.8 – Turn on the shower t11_7ot2_I2.8 – Turn off the shower
Fig. 7.24. OO-DPT sub-net of class C7 – Feed Table
The model of the conveyor is based on a time delay approximation (Beek et al., 1999). When there is a continuous transportation phenomenon, the value of a variable y, at a distance L from the beginning (x=L), is approximated by the discretization of L in n parts. The time constant W depends on the transportation speed v: W = L/v. The value of y is calculated in n points (x=L/n, x=2L/n, etc) using the following expressions, where y0 = y(x=0) and yn = y(x=L): dy1/dT = -n/W * (y1-y0) dyn/dT = -n/W * (yn-yn-1) for i=2 up to n-1: dyi/dT= -n/(6*W) * (2*yi+1+3*yi-6*yi-1+yi-2)
7 Application 3: Cane Sugar Factory
187
Class C11 – Divided Conveyor uses this approximation to model the cane transportation on the conveyor. Class C12 – Preparation Equipment models both the chopper and shredder. Class C13 – Conveyor 1 - Chopper is the result of the composition of C11 and C12. C13 – Conveyor 1 - Chopper (Fig 7.25) C11 – Divided Conveyor has three discrete states: on (p1_13), off (p3_13) and fault (p2_13). The fault occurs when the conveyor is turned off and receives cane. The cane mass flow (mE1A) at the output 1A of Conveyor 1 (input of C12 – Preparation Equipment, which models the chopper) is a function of the mass flow at the
conveyor input and the time delay (WE1A), which is the time for the cane to be transported from the conveyor input to the Preparation Equipment. This delay is inversely proportional to the speed of C11 – Divided Conveyor (vVV.I3.9). The modelling of part 1B of the conveyor is similar to the modelling of part 1A. The density of the cane layer on the conveyor is considered constant (KU_E1). C11 – Divided Conveyor (Conveyor 1) t2_13 Off p1_13 t1
t4 On
t3_13 13
C13 – Conveyor 1 - Chopper
p3_13
p4_13
t7
p6_13 t8
13
t6_13
On
13
p5_13 t5
Off
C12 – Preparation Equipment (Chopper)
13
t9_13
p7_13
p8_13
Fault
t10_13
13
p2_13 Fault without cane excess With cane excess Variables: Variables: Xpb_13 = {mE1B}; Xpb_13 = {mP, CP MP}; Xim_13 = {vVV.I1.9}; Xim_13 = {vVV.I1.9, qM.I2.7, qM.I3.7}; Xint_13 = {K m_P1, K m_P2, KM_P, I1, I2}; Xint_13 = {mE1A, KW_E1A, WE1A, WE1B, x0A, x1A , Equation systems: x2A , x3A, x4A, x0B x1B , x2B , x3B, x4B , f4_13: mP = mE1A + Km_P2*MP*vVV.I1.9 KU_E1, I1, I2, I3}; dMP/dT = - Km_P2*MP*vVV.I1.9 Equation systems f6_13: mP = K m_P1 f1_13: mE1B = 0 dMP/dT = mE1A – mP f3_13: WE1A = K W_E1A/vVV.I1.9 f5_13: mP = mE1A WE1B = KW_E1B/vVV.I1.9 Enabling functions: x0A = (qM.I2.7+qM.I3.7)*KU_E1 e7_13: mE1A > K m_P1; e8_13: MP = 0; e9_13: MP > KM_P; dx1A/dT= - 4/WE1A * (x1A-x0A) Junction functions: j4_13: CP = 0; j5_13, j6_13: CP = KC_P; dx4A/dT= - 4/WE1A * (x4A-x3A) Methods provided by the class: dx2A/dT= - 4/(6*WE1A) * t3_13 – Turn on the preparation equipment (2*x3A+3*x2A-6*x1A+x0A) t8_13 – Turn off the preparation equipment dx3A/dT= - 4/(6*WE1A) * (2*x4A+3*x3A-6*x2A+x1A) mE1A = x4A Enabling function: x0B = mP e1_13: (qM.I2.C7+qM.I3.C7) > 0 dx4B/dT = - 4/WE1B * (x4B-x3B) Methods provided by the class: dx2B/dT = - 4/(6*WE1B) * t2_13 – Turn on Conveyor 1 (2*x3B+3*x2B-6*x1B+x0B) t3_13 – Turn off Conveyor 1 dx3B/dT = - 4/(6*WE1B) * (2*x4B+3*x3B-6*x2B+x1B) mE1B = x4B
p9_13
Fig. 7.25. OO-DPT sub-net of class C13 – Conveyor 1 - Chopper
The mass flow at the output of the Preparation Equipment (mP) is equal to the mass flow at the input of part 1B if mP is lower than maximum limit Km_P1, which is the maximum flow of cane that the Preparation Equipment is able to process. If the mass flow at the input of the Preparation Equipment (mE1B.I2.13) is greater than this limit, the cane is accumulated at the entrance of the Preparation Equipment. The
188
Modelling and Analysis of Hybrid Supervisory Systems
weight of accumulated cane is given by the variable MP. This amount of cane must be processed as soon as the input mass flow is lower than Km_P1. However, if MP exceeds the limit of KM_P, then a fault is detected in the Preparation Equipment. When the Preparation Equipment is off, the output mass flow is equal to the input mass flow. In this case, if there is accumulated cane at the input, it is consumed at a constant rate of Km_P2. The variable CP is the preparation coefficient of the Preparation Equipment and is a function of the discrete state on (CP=KC_P) or off (CP=0). C74 – Table Interface (Fig 7.26)
This is the class from the supervisory systems that implements the interface with the feed tables (C7). It decides which table must provide cane to the production line (O1.7 – Table 1 or O2.7 – Table 2) and where the trucks must unload the cane (O1.7 – Table 1 or O1.6 – Storehouse). It also estimates the amount of cane on each table (VM1 and VM2) in order to request the transfer of cane from the storehouse to O2.7 – Table 2 (t11_74). p2_74
C74 – Table Interface
p4_74 Turn off (external request)
t4_74
Inform VP 1 t14_74 p8_74
t5_74
t15_74 Inform VP 2
Turn off Table1
t3_74
t16_74 Inform VP 3
t6_74 p5_74 t7_74 Table 1 on
t1_74 Tables 1 and 2 off
p1_74t2_74 p3_74
t8_74
Table 2 on p6_74 t11_74 p7_74
t9_74
p9_74 t12_74
t13_74
t17_74
p10_74
t18_74 Receive at Table 1 t19_74 Receive at Storehouse
t10_74 Turn off Table 2 Variables: Methods provided by the class: Xint_74 = {V M1, V M2, KV , V C, q, I1, I2, I3}; t1_74 – Confirm tables off t2_74 – Begin cane supply Enabling functions: t4_74 – Interrupt cane supply e6_74: V M1 > 0; e7_74: V M1 d 0; t12_74 – Confirm transportation Storehouse – Table 2 e8_74: V M1 d 0 AND V M2 > 0; t13_74 – Reject transportation Storehouse – Table 2 e9_74: V M2 d 0 OR V M1 > 0; t14_74 – Inform Production Volume 1 e19_74: V C < KM1; e20_74: V C t KM1 t15_74 – Inform Production Volume 2 Junction functions: t16_74 – Inform Production Volume 3 j13_74: V M1 = V M1+ KV ; t17_74 – {O, V C} – Inform truck arriv al to the table interface j15_74: q = Kq1; j16_74: q = Kq2; j17_74: q = Kq3; Methods used by the class: j19_74, j20_74: V M1 = V M1+ V C; t5_74ot12_I1.7 – Turn off Table 1 Equation systems: t6_74ot5_I1.7 – Turn on Table 1 f 5_74: dV M1/dT= - q; f6_74: dV M2/dT= - q t7_74ot12_I1.7 – Turn off Table 1 t8_74ot5_I2.7 – Turn on Table 2 t9_74ot12_I2.7 – Turn off Table 2 t10_74ot12_I2.7 – Turn off Table 2 t11_74ot1_I3.75 – {KV} – Request transportation Storehouse – Table 2 t18_74ot3_I4.2 – Send truck to Table 1 t19_74ot2_I3.75 – {O, V C} – Send truck to Storehouse
Fig. 7.26. OO-DPT sub-net of class C13 – Conveyor 1 - Chopper
7 Application 3: Cane Sugar Factory
189
C76 – Chopper Interface (Fig 7.27)
This is the class from the supervisory system that implements the interface with the chopper (O1.13 – Conveyor 1 - Chopper). It starts (t1_76) and interrupts (t14_76) the cane preparation when requested by other objects. It also turns off the chopper (t12_76) when it is overloaded. The chopper is kept off until there is no accumulated cane at the chopper entrance (MP.I1.13d0).
t1_76
p2_76
t2_76
Interrupt cane supply t5_76 p4_76 t6 76 p5_76
p3_76 t7_76 p1_76
t3_76 p6_76 t4
76
Methods provided to other classes: t1_76 – Begin preparation t7_76 – Interrupt preparation Methods used by other classes: t2_76ot4_13.I1 – Turn on chopper t3_76ot10_13.I1 – Turn off chopper t4_76ot10_13.I1 – Turn off chopper t5_76ot4_74.I2 – Interrupt cane supply t6_76ot2_74.I2 – Begin cane supply
Variables: Xint_76 = {KM, I1, I2}; Xim_76 = {MP.I1.13}; Enabling functions: e10_76: MP.I1.13 > KM; e13_76: MP.I1.13 = 0;
Fig. 7.27. OO-DPT sub-net of class C76 – Chopper Interface
The objects described in this section have the following initial markings: x
O1.7 – Table 1 X1.7: VM = undefined; VCM = 0; Kq_M = 1; KV_M = undefined; I1 = undefined; I2 = Shower 1; I3 = Table 1 Speed Controller; qM = 0; m1.7 = {p2_7, p4_7};
x
O2.7 – Table 2 X2.7: VM = undefined; VCM = 0; Kq_M = 1; KV_M = undefined; I1 = undefined; I2 = Shower 2; I3 = Table 2 Speed Controller; qM = 0; m2.7 = {p2_7, p4_7};
x
O1.13 – Conveyor 1 - Chopper X1.13: mE1B = 0; mE1A = 0; WE1A = 0; WE1B = 0; KW_E1A = 1; KW_E1B = 1; x0A = 0; x1A = 0; x2A = 0; x3A = 0; x4A = 0; x0B = 0; x1B = 0; x2B = 0; x3B = 0; x4B = 0; KU_E1 = undefined; I1 = Conveyor 1 Speed Controller; I2 = Table 1; I3 = Table 2; VCM = 0; mP = 0; CP = 0; MP = 0; Km_P1 = 1; Km_P2 = undefined; KM_P = 15; m1.13 = {p1_13, p4_13};
x
O1.74 – Table Interface X1.74: VM1 = undefined; VM2 = undefined; KV = undefined; VC = 0; q = 0; I1 = Table 1; I2 = Table 2; I3 = Storehouse Controller; m1.74 = {p1_74, p8_74, p9_74};
190
Modelling and Analysis of Hybrid Supervisory Systems
x
O1.76 – Chopper Interface X1.76: KM = 10; I1 = Conveyor 1 – Chopper; I2 = Shredder; I3 = Table Interface; m1.76 = {p1_76};
7.3 Analysis of the OO-DPT Net Models This section presents the verification of a safety property that depends mostly on the continuous dynamics of the objects. Once the building of the sequent proof trees has already been illustrated in Chapters 4, 5 and 6, it is omitted in this chapter. Steps 4.1 and 5.1 only present the sequents and the results obtained from the proof trees. 7.3.1 Property 1 7.3.1.1 Step 1: Specification of the Property Statement Property 1 is specified according to the statement PS1 (described in Chapter 4, Section 4.3.4.1): x
Property 1 – The chopper (O1.13 – Conveyor 1 - Chopper) must not be overloaded (fault occurrence - event ef): the state p7_1.13 = 1 must never be reached.
7.3.1.2 Step 2: Specification of the Set of Restrictions Property 1 is submitted to a single restriction, defined according to the restriction statement R5 (described in Chapter 4, Section 4.3.3.2): x
Restriction 1A – The Juice Production Manager is always on when the chopper (O1.13 – Conveyor 1 - Chopper) has excess of cane to be processed: if p6_13 = 1 then p20_77 = 1.
7.3.1.3 Step 3: Building the Static Collaboration Diagrams The interactions among the objects that are relevant to this property are presented in Fig 7.28. The verification begins with the analysis of O1.13 – Conveyor 1 - Chopper, which is related to the forbidden state. Briefly, in order to prove the property, it must be verified that the quantity of cane at the entrance of the chopper is never sufficient to cause the fault (transition t9_1.13 is never enabled). O1.76 – Chopper Interface is the object that must monitor the chopper and act on the production line in order to avoid the fault. The preventive action is performed when the cane accumulated in the chopper reaches the threshold KM. In this situation, O1.74 – Table Interfaces must receive a request to interrupt the supply of cane, which means that O1.7 – Table 1 and O2.7 – Table 2 must be turned off until the chopper has processed the accumulated cane (MP = 0).
7 Application 3: Cane Sugar Factory
191
O1.7 – Table 1 qM
t5_74 o t6_74 o t7_74 o t12_7 t5_7 t12_7 t5_76 o t4_74 O1.74 – Table Interface
t6_76 o t2_74
O1.76 – Chopper Interface
MP
O1.13 – Conveyor 1 Chopper
t8_74 o t9_74 o t10_74 o t5_7 t12_7 t12_7
qM
O2.7 – Table 2
Fig. 7.28. Static collaboration diagram for Property 1
7.3.1.4 Step 4.1: Analysis of the Discrete Dynamics (O1.13 – Conveyor 1 - Chopper) The following sequent is analysed in order to determine the scenarios that result in p7_1.13 (Fig 7.25): x
Search 1 (up to the forbidden state p7_1.13): *0, !t1_1.13, ..., !t10_1.13 |–– p7_1.13
*f
x
Definition of forbidden scenarios – The proof tree shows that there are infinite scenarios from the forbidden state back to the moment when the chopper is turned on. The difference between the scenarios is the number of firings of transitions t8_1.13 and t7_1.13, which is the number of times that the chopper has been in the state ‘with excess of cane’ after being turned on. The sequence of firings for each scenario is the following, where i varies from 0 to f, *0= p4_1.13 p8_1.13 and *f = p8_1.13: - Scenario i: t9_1.13; t7_1.13(i+1); i*(t8_1.13(); t7_1.13();) t2_1.76/4_1.13.
x
Conditions for Property 1 – In order to prove that Property 1 is true, it is necessary to verify that transition t9_1.13 (Fig 7.25) is never fired. For this purpose, the condition specified by e9_1.13 (MP t KM_P) must never be satisfied. This situation is Case 1, described in Section 4.3.4.5 (Fig. 4.24 of Chapter 4).
7.3.1.5 Step 4.2: Elaboration of Hypotheses (O1.13 – Conveyor 1 - Chopper) No hypothesis is made. 7.3.1.6 Step 4.3: Analysis of the Continuous Dynamics (O1.13 – Conveyor 1 Chopper) The analysis of the enabling functions, junction functions and equation systems results in the following statements: x
Scenarios i: - At T2_1.76/4_1.13 and at T8_1.13, MP = 0. As a consequence, at T7_1.13i+1, MP = 0. - At T9_1.13, MP = KM_P. As a consequence, T9_1.13 > T7_1.13i+1. - In the state p6_1.13=1 (between T7_1.13i+1 and T9_1.13), mP = Km_P1.
192
Modelling and Analysis of Hybrid Supervisory Systems
-
When the chopper is in the state p6_1.13=1, the accumulated cane at the entrance of the chopper (MP) is given by f6_13, therefore: T9 _1.13
MP(T9_1.13) = T
³
(m1EA mP ).dT t KM_P
7 _1.13i1
-
m1EA and mP are calculated by: mP = Km_P1 m1EA = x4A = - dx4A/dT * WE1A/4 + x3A x3A = - dx3A/dT *WE1A/2 + (-2*x4A +6*x2A +x1A)/3 x1A = - dx1A/dT *WE1A/4 + x0A x2A = - dx2A/dT *WE1A/2 + (-2*x3A +6*x1A +x0A)/3 x0A = (qM.I2.7+qM.I3.7)*KU_E1
-
The manipulation of the equation system results in the following expression for m1EA: m1EA = WE1A/36 * (-7*dx4A/dT- 6*dx3A/dT - 12*dx2A/dT - 13*dx1A/dT) + 15*(qM.I2.7 + qM.I3.7)*KU_E1
-
The time interval [T7_1.13i+1, T9_1.13] is divided into [T7_1.13i+1, TC] and [TC, T9_1.13], where TC is the date of the event starting the control action that must avoid the fault: T9 _1.13
MP(T9_1.13) = MP(TC) + T
³
(m1EA mP ).dT = MP(TC) -
7 _1.13i1
Km_P1*(T9_1.13- TC) + WE1A/36 * (7*(x4A(TC) - x4A(T9_1.13)) + 6*(x3A(TC) – x3A(T9_1.13)) + 12*(x2A(TC) – x2A(T9_1.13)) + 13*(x1A(TC) – T9 _1.13
x1A(T9_1.13)) + 15*KU_E1*
³
(qM.I2.7 qM.I3.7 )
TC
-
The worst case is when x0A(TC) = max(qM.I2.7 + qM.I3.7) and x0A(T9_1.13) = min(qM.I2.7 + qM.I3.7) = 0. The condition for reaching p7_1.13=1 is: MP(T9_1.13) d MP(TC)- Km_P1*(T9_1.13-TC)+ WE1A/36 * 38*max(qM.I2.7+ T9 _1.13
qM.I3.7) + 15*KU_E1*
³
(qM.I2.7 qM.I3.7 ) t KM_P
TC
In order to verify the last expression, the objects O1.7 – Table 1 and O2.7 – Table 2 must be analysed. These objects interact with O1.13 – Conveyor 1 - Chopper by sharing variables qM.I2.7 and qM.I3.7 and through the objects O1.74 – Table Interfaces and O1.76 – Chopper Interface. Since the control action to avoid fault is executed by O1.76 – Chopper Interface, this is the next object to be analysed. 7.3.1.7 Step 5.1: Analysis of the Discrete Dynamics (O1.76 – Chopper Interface) The scenarios found in Step 4.1 are detailed: x
Scenario i: This object (Fig 7.27) can be in any reachable state when transition t9_1.13 is fired. The reachable states are: {p1_1.76}; {p2_1.76, p5_1.76};
7 Application 3: Cane Sugar Factory
193
{p3_1.76, p5_1.76}; {p4_1.76, p5_1.76}; {p2_1.76, p6_1.76}; {p3_1.76, p6_1.76}; {p4_1.76, p6_1.76}. A search should be done for each one of these states. It must determine the scenarios that, from the firing of t2_1.76/4_1.13, result in the
state. The restrictions imposed by the continuous dynamics must be verified. Briefly, the obtained results are: -
Final state {p1_1.76}: from the firing of t2_1.76/4_1.13 there is no possible sequence of transition firings that results in p1_1.76 without firing other transitions from the interface between O1.13 and O1.76.
-
Final state {p2_1.76, p5_1.76}: there is no possible sequence of firings.
-
Final state {p2_1.76, p6_1.76}: there is no possible sequence of firings.
-
Final state {p3_1.76, p5_1.76}: Search 1 (after the firing of t2_1.76/4_1.13): *0, !t1_1.76, !t5_1.76, !t6_1.76, !t7_1.76, t2_1.76 |–– p3_1.76, p5_1.76. Search 2 (up to the firing of t2_1.76/4_1.13): this search is considered irrelevant for the analysis of Property 1. Definition of the scenarios: the search results in an infinite number of scenarios. The difference between the scenarios is the number of firings of ‘t6_1.76/2_1.74, t5_1.76/4_1.74’. The sequence of firings for the scenarios is the following, where i and j vary from 0 to f: Scenario i-1-j: j*(t6_1.76/2_1.74(); t5_1.76/4_1.74()); t2_1.76/4_1.13.
-
Final state {p3_1.76, p6_1.76}: the reasoning is similar to the one made for the final state {p3_1.76, p5_1.76}. Infinite scenarios are found and the difference between them is the number of firings of ‘t6_1.76/2_1.74, t5_1.76/4_1.74’. The sequence of firings for the scenarios is the following, where i and j vary from 0 to f: t18_1.77/7_1.76//(j*(t6_1.76/2_1.74(); t5_1.76/4_1.74();)) Scenario i-2-j: t2_1.76/4_1.13.
-
Final state {p4_1.76, p5_1.76}: the reasoning is similar to the one made for the final state {p3_1.76, p5_1.76}. Infinite scenarios are found. The sequence of firings for the scenarios is the following, where i and j vary from 0 to f: Scenario i-3-j: t5_1.76/4_1.74; j*(t6_1.76/2_1.74(); t5_1.76/4_1.74();) t2_1.76/4_1.13.
-
Final state {p4_1.76, p6_1.76}: the reasoning is similar to the one made for the final state {p3_1.76, p5_1.76}. Infinite scenarios are found. The sequence of firings for the scenarios is the following, where i and j vary from 0 to f: Scenario i-4-j: t18_1.77/7_1.76//(t5_1.76/4_1.74; j*(t6_1.76/2_1.74(); () t5_1.76/4_1.74 ;)) t2_1.76/4_1.13.
7.3.1.8 Step 5.2: Elaboration of Hypotheses (O1.76 – Chopper Interface) The following hypotheses are made and correspond to the hypothesis statement H1 (presented in Chapter 4, Section 4.3.3.6):
194
Modelling and Analysis of Hybrid Supervisory Systems
x
x
Hypothesis 1A – The chopper (O1.13 – Conveyor 1 - Chopper) responds immediately to any method call made by O1.76 – Chopper Interface: transitions t2_1.76/4_1.13, t3_1.76/10_1.13 and t4_1.76/10_1.13 fire in 'T=0 after they are enabled in O1.76. Hypothesis 1B – The object O1.74 – Table Interface responds immediately to any method call made by O1.76 – Chopper Interface: transitions t5_1.76/4_1.74 and t6_1.76/2_1.74 fire in 'T=0 after they are enabled in O1.76.
7.3.1.9 Step 5.3 – Analysis of the Continuous Dynamics (O1.76 – Chopper Interface) The hypotheses of Step 5.2 result in the following statements: x
x x
Scenarios i-1-j and i-2-j are impossible because, according to Hypothesis 1B, t5_1.76/4_1.74 is enabled and fires in T7_1.13i+1 < T5_1.76/4_1.74 < T9_1.13, consuming the token in p3_76. In the case of Scenario i-4-j, T18_1.77/7_1.76 = T9_1.13, because otherwise t3_1.76/10_1.13 or t4_1.76/10_1.13 would be fired. In the case of Scenarios i-3-j and i-4-j, the sharing of variable MP results in: -
-
T7_1.13i+1 < T5_1.76/4_1.74 < T9_1.13, where the firing of t5_1.76/4_1.74 is the control action to avoid fault, introduced in the analysis of object O1.13 – Conveyor 1 - Chopper. MP(TC) = MP(T5_1.76/4_1.74) = KM. The condition that must be satisfied for reaching p7_1.13 is: KM - Km_P1*(T9_1.13- T5_1.76/4_1.74) + WE1A/36* 38*max(qM.I2.7+qM.I3.7) + T9 _1.13
15*KU_E1*
³
(qM.I2.7 qM.I3.7 ) t KM_P
T5 _1.76 / 4 _1.74
7.3.1.10 Step 5.1: Analysis of the Discrete Dynamics (O1.74 – Table Interface) Scenarios i-3-j and i-4-j: The search of scenarios is similar for the case of Scenarios i-3-j and i-4-j. As for the object O1.76 – Chopper Interface, O1.74 can be in any reachable state when t9_1.13 is fired. The reachable states are: {p1_1.74}, {p3_1.74, p4_1.74}, {p4_1.74, p5_1.74}, {p4_1.74, p6_1.74}, {p4_1.74, p7_1.74}, {p2_1.74, p3_1.74}, {p2_1.74, p5_1.74}, {p2_1.74, p6_1.74}, {p2_1.74, p7_1.74}. The search of the scenarios that lead to {p1_1.74} from the firing of t5_1.76/4_1.74 is
used as an example. From the discrete point of view, there are infinite scenarios, because before reaching p1_1.74 by the firing of t3_1.74, t5_1.74/12_1.7 or t10_1.74/12_2.7, O1.74 can alternate unlimited times between {p3_1.74, p4_1.74}, {p4_1.74, p5_1.74}, {p4_1.74, p6_1.74} and {p4_1.74, p7_1.74}. Some examples are: x x x x x
Scenario i-3 or 4-j-1: t3_1.74, t12_1.76/4_1.74 Scenario i-3 or 4-j-2: t5_1.74/12_1.7, t12_1.76/4_1.74 Scenario i-3 or 4-j-3: t10_1.74/12_2.7, t12_1.76/4_1.74 Scenario i-3 or 4-j-4: t3_1.74, t7_1.74/12_1.7, t12_1.76/4_1.74 Scenario i-3 or 4-j-5: t3_1.74, t9_1.74/12_2.7, t12_1.76/4_1.74
7 Application 3: Cane Sugar Factory
x x
195
Scenario i-3 or 4-j-6: t5_1.74/12_1.7, t6_1.74/5_2.7, t12_1.76/4_1.74 Scenario i-3 or 4-j-7: t10_1.74/12_2.7, t8_1.74/5_2.7, t12_1.76/4_1.74
7.3.1.11 Step 5.2: Elaboration of Hypotheses (O1.74 – Table Interface) The following hypotheses are made about the interface of this object: x
x
x
Hypothesis 1C (hypothesis statement H1) – O1.7 – Table 1 responds immediately to any method call made by O1.74 – Table Interface: transitions t5_1.74/12_1.7, t6_1.74/5_1.7 and t7_1.74/12_1.7 fire in 'T=0 after they are enabled in O1.74. Hypothesis 1D (hypothesis statement H1) – O2.7 – Table 2 responds immediately to any method call made by O1.74 – Table Interface: transitions t9_1.74/12_2.7, t8_1.74/5_2.7 and t10_1.74/12_2.7 fire in 'T=0 after they are enabled in O1.74. Hypothesis 1E (hypothesis statement H1) – O1.75 – Storehouse Controller responds immediately to any method call made by O1.74 – Table Interface: transitions t11_1.74/1_1.75, t6_1.75/12_1.74 and t3_1.75/13_1.74 fire in 'T=0 after they are enabled in O1.74.
7.3.1.12 Step 5.3: Analysis of the Continuous Dynamics (O1.74 – Table Interface) From the hypotheses presented and the analysis of the continuous dynamics, it results that the only possible state when t9_1.13 fires is {p1_1.74}. The following statements are then derived: x
x
x x x
The scenarios where the state in T9_13 includes p2_1.74=1 are impossible because they cannot be reached from the firing of t5_1.76/4_1.74, unless t6_76/2_1.74 or t16_1.77/2_1.74 fires. Transition t6_76/2_1.74 is an interface transition and is not part of the scenarios. Furthermore, according to Restriction 1A, t13_1.77/2_1.74 does not fire in O1.77. The scenarios where the state in T9_13 includes p4_1.74=1 are impossible because t3_1.74, t5_1.74/12_1.7 or t10_1.74/12_2.7 must be enabled and fire in T5_1.76/4_1.74, consuming p4_1.74. For the scenarios that end with the firing of t3_1.74, T3_1.74 = T5_1.76/4_1.74. For the scenarios that end with the firing of t5_1.74/12_1.7, T5_1.74/12_1.7 = T5_1.76/4_1.74. For the scenarios that end with the firing of t5_1.74/12_1.7, T10_1.74/12_2.7 = T5_1.76/4_1.74.
7.3.1.13 Step 5.1: Analysis of the Discrete Dynamics (O1.7 – Table 1 and O2.7 – Table 2) These objects influence the verification of Property 1 only through the values of qM.I2.7 and qM.I3.7. These variables are defined according to the discrete state of objects O1.7 and O2.7. In order to simplify the analysis procedure, instead of determining all the possible scenarios, it is considered that in the time interval [T7_1.13i+1, T9_1.13] the
196
Modelling and Analysis of Hybrid Supervisory Systems
tables can be in any reachable state, and in the time interval [T5_1.76/4_1.74, T9_1.13] their states are limited by Hypothesis 1F. 7.3.1.14 Step 5.2: Elaboration of Hypotheses (O1.7 – Table 1 and O2.7 – Table 2) The following hypotheses are made: x
x x
Hypothesis 1F (hypothesis statement H5) – After the firing of t3_1.74, t5_1.74/12_1.7 or t10_1.74/12_2.7, if transitions t6_76/2_1.74 and t16_1.77/2_1.74 do not fire, the state of O1.7 – Table 1 ‘off’ (p4_1.7=1) and O2.7 – Table 2 ‘off’ (p4_2.7=1) are reached in 'T=0. Hypothesis 1G (hypothesis statement H8) – For O1.7 – Table 1 and O2.7 – Table 2, vVV.I3.9 [1; 2]. Hypothesis 1H (hypothesis statement H8) – For O1.13 – Conveyor 1Chopper, vVV.I1.9 [0,5; 1].
7.3.1.15 Step 5.3: Analysis of the Continuous Dynamics (O1.7 – Table 1 and O2.7 – Table 2)
The following statements are derived from the hypotheses and continuous dynamics: x
For O1.7: qM(TtT5_1.76/4_1.74) = 0 and qM(T
x
For O2.7: qM(TtT5_1.76/4_1.74) = 0 and qM(T
x
As a result, for O1.13: KM - Km_P1*(T9_1.13- T5_1.76/4_1.74) + 4,2*max(TE1A) < KM+ 4,2*max(vVV.I1.C9) = 14,2 < KM_P = 15
x
Therefore Property 1 is true if the hypotheses are also true.
7.3.1.16 Step 7: Verification of Hypotheses Briefly, the verification of the hypotheses is made by fusing the objects: x
Hypothesis 1A is verified through the fusion of objects O1.13 – Conveyor 1 - Chopper and O1.76 – Chopper Interface.
x
Hypothesis 1B is verified through the fusion of objects O1.74 – Table Interface and O1.76 – Chopper Interface.
x
Hypothesis 1C is verified through the fusion of objects O1.74 – Table Interface and O1.7 – Table 1.
x
Hypothesis 1D is verified through the fusion of objects O1.74 – Table Interface and O2.7 – Table 2.
x
Hypothesis 1E is verified through the fusion of objects O1.74 – Table Interface and O1.75 – Storehouse Controller.
x
Hypothesis 1F is verified through the fusion of objects O1.74 – Table Interface, O1.7 – Table 1 and O2.7 – Table 2.
x x
Hypothesis 1G is verified through the fusion of objects O1.9 – Table 1 Speed Controller and O2.9 – Table 2 Speed Controller. Hypothesis 1H is verified by analysing object O3.9 – Conveyor 1 Speed Controller.
7 Application 3: Cane Sugar Factory
197
7.4 Final Remarks Comparing with the previous two applications, the cane sugar factory is the most complex one. It provides a large variety of processes with different features. The OO-DPT models of the classes are diverse: some classes have only continuous dynamics, others are only discrete and others are hybrid. The interaction among some objects is strong and includes the sharing of continuous variables and a large number of method calls in a short time interval. Other objects are relatively isolated from the remaining system, interacting only by sporadic method calls. The complexity of this application allows a better evaluation and comprehension of the modelling and analysis methods presented in this book. Regarding the modelling, the application highlights the importance of the object oriented paradigm for making the specification of the OO-DPT net in a systematic way feasible. Without using a modular approach that considers the behaviour of each component separately from the others, it is impossible to model such a complex system. The modular approach reduces the modelling problem to a sequence of problems of small complexity, such as modelling a tank or a vacuum pan. The PFS of Step 1 provides a general overview of the process and flow of material. It is useful for defining objects using the composition relationship, particularly when there is a closed loop of variable sharings among components. The other UML diagrams provide a focus on the use cases, helping the definition of the supervisory system objects. Regarding the analysis, the application highlights the importance of defining adequate hypotheses. It means that the success of the analysis depends mostly on what the person who is applying the analysis method knows about the system, and his ability to introduce hypotheses that simplify the analysis. This is particularly important for safety properties, where there is no initial (e0) and final (ef) events that limits the time interval to be considered. The number of scenarios may become too large. In the case of Property 1, during the analysis of object O1.13 - Conveyor 1 - Chopper, it is particularly useful to suppose that there is a control action to prevent the occurrence of a fault (division of the time interval T7_1.13 - T9_1.13 into two time intervals T7_1.13 - TC and TC - T9_1.13). Another example is Hypothesis 1F. Without it, the number of scenarios defined during the analysis of O1.7 – Table 1 and O2.7 – Table 2 would be too large.
8 Conclusion and Research Topics
This book addresses the problem of developing hybrid supervisory systems by dividing it into three phases: modelling, analysis and implementation. In the modelling phase, a model of both supervisory system and controlled object is built, using a modelling formalism named OO-DPT net. In the second phase, the behaviour of the system is validated by proving properties in the OO-DPT net model. The last phase, which is not detailed in this book, consists in converting the OO-DPT net of the supervisory system into an adequate programming language. The innovative aspects of this book can be summarized by three points: the OO-DPT net, the modelling method and the analysis method. The OO-DPT formalism merges Petri nets, differential equation systems and the object oriented paradigm. Its main advantage is the modular structure provided by the OO paradigm, which allows breaking down a complex and large scale system into small and simple subsystems that are easy to model. The modelling method systematizes the specification of the OO-DPT net and is based on UML diagrams, which has become a standard in the industrial and scientific environment. Each diagram shows the system under a different perspective, allowing the system to be understood by people from different areas, who do not know the modelling formalism. Regarding research topics and future works, a particular critical point of the modelling method is the definition of the supervisory system objects. In other words, the problem is how to decompose the supervisory system starting from the system requirements and to propose a set of objects that models its behaviour. While the candidates to classes and objects of the controlled object are easily identified by observing the real system, the same cannot be done for the supervisory system. In this book, the problem has been circumvented by proposing supervisory system objects that are images of objects of the controlled object. The image object in the supervisory system is responsible for interacting and storing the information related to the corresponding object of the controlled object. Another possible approach, still to be investigated, is the use of libraries composed of basic classes related to general functionalities of the supervisory system. The analysis method used in this book is based on the verification of behavioural properties for the OO-DPT net. Two kinds of properties are
200
Modelling and Analysis of Hybrid Supervisory Systems
considered. The reachability properties verify that a state is reached under certain conditions, while safety properties verify that a forbidden or dangerous state is never reached. The analysis method explores the modular structure of the OO-DPT net in order to decompose the verification. It is important to observe that the analysis method does not guarantee a solution. Among the model features that determine the success of the method is the communication among the system objects. Another important point is the introduction of hypotheses that reduce the number of scenarios to be analysed. The applications presented in Chapters 5, 6 and 7 show that the modelling of complex systems is a relatively easy task when compared to analysis. The main reason is that the modelling of hybrid system has been studied for many years. An example related to the OO-DPT net is a Doctoral thesis (Andreu, 1996), which introduced the basic concepts for merging Petri nets and differential equation systems a decade ago. On the other hand, the development of efficient and automatic methods for the analysis of hybrid system modelled by Petri nets and differential equation systems is an unsolved problem. Except for the analysis method presented in Chapter 4, this problem has only been addressed by another Doctoral thesis (Khalfaoui, 2003). This is an important research area still to be more deeply investigated. Research topics include how to make the analysis method more automatic and less dependent upon the person who performs the analysis, and how to define a set of the behavioural properties that ensures a correct behaviour of the system. Finally, there are two important activities of the supervisory system design that have not been addressed at all in this book. The first one is the use of simulation to perform a preliminary analysis of the system behaviour, to detect and to correct errors. The modular structure of the OO-DPT net can be explored in order to develop algorithms for distributed simulation. In this case, a research topic is how to group the objects in order to minimize the interaction among the simulation nodes. The second activity, not addressed in this book, is the third phase of the supervisory system development. The problem is how to implement the supervisory system ensuring that its behaviour corresponds to the behaviour of the OO-DPT net and the properties verified in the analysis phase are also verified by the implementation when interacting with the actual physical system.
A Complementary Data about Application 2: Landing System
This appendix presents the classes and objects that compose the model of the landing system described in Chapter 6. Controlled Object The model of the controlled object is composed of the following objects and classes: x x x x
x x x x x x x x x
C1 – Single Actuator Equipment: O1.1 – Nose Door, O2.1 – Right Door, O3.1 – Left Door; O4.1 – Nose Gear; C2 – Double Actuator Equipment: O1.2 – Right Gear, O3.2 – Left Gear; C3 – Up/Down Handle: O1.2 – Up/Down Handle; C4 – Discrete Sensor: O1.4 – Open Nose Door, O2.4 – Open Right Door, O3.4 – Open Left Door, O4.4 – Close Nose Door, O5.4 – Close Right Door, O6.4 – Close Left Door, O7.4 – Extended Nose Gear, O8.4 – Extended Right Gear, O9.4 – Extended Left Gear, O10.4 – Retracted Nose Gear, O11.4 – Retracted Right Gear, O12.4 – Retracted Left Gear, O13.4 – Pressurized General HC; C5 – General Electro-valve and Hydraulic Circuit: O1.5 – General EV/HC; C6 – Dedicated Electro-valve: no object (C7 and C8 are specialisation of this class). C7 – Positive Pressure Electro-valve: O1.7 – Open Door EV, O2.7 – Extend Gear EV; C8 – Negative Pressure Electro-valve: O1.8 – Close Door EV, O2.8 – Retract Gear EV; C9 – Dedicated Hydraulic Circuit: O1.9 – Door HC, O1.9 – Gear HC; C10 – General Hydraulic Circuit: no object (C11 and C12 are specialisation of this class). C11 – General Electric Circuit: O1.11 – General EC; C12 – Dedicated Electric Circuit: O1.12 – Open Door EC, O2.12 – Close Door EC, O3.12 – Extend Gear EC, O4.12 – Retract Gear EC; C13 – Analogical Relay: O1.13 – Analogical Relay;
202
A Complementary Data about Application 2: Landing System
Supervisory System The model of the supervisory system is composed of the following objects and classes: x x x x x x
C14 – Equipment Supervisor: O1.14 – Nose Door Supervisor, O2.14 – Right Door Supervisor, O3.14 – Left Door Supervisor, O4.14 – Nose Gear Supervisor, O5.14 – Right Gear Supervisor, O6.14 – Left Gear Supervisor; C15 – Set Supervisor: O1.15 – Nose Set Supervisor, O2.15 – Right Set Supervisor, O3.15 – Left Set Supervisor; C16 – System Supervisor: O1.16 – System Supervisor; C17 – Up/Down Handle Interface: O1.17 – Up/Down Handle Interface; C18 – General EV Interface: O1.18 – General EV Interface; C19 – Dedicated EV Interface: O1.19 – Door EV Interface, O2.19 – Gear EV Interface.
The OO-DPT subnets of the classes are presented as follows. C1 – Single Actuator Equipment
The model of this class has been presented in Chapter 6. C2 – Double Actuator Equipment (Fig. A.1) This class models the right and left landing-gear. Differently from the doors and the nose landing-gear, the right and left landing-gears are positioned by two hydraulic actuators. The position of these actuators is represented by variables x1 and x2. The first actuator locks and unlocks the actuator in the extended position, while the second one extends and retracts the landing gear. Kp is the pressure needed to move the actuators. Kx_1 and Kx_2 are the maximum position of the actuators. Kv is the speed of extension and retraction when the hydraulic pressure pI1.9 reaches Kp. C3 – Up/Down Handle (Fig. A.2) The up/down handle is used by the pilot to perform the retracting (t8_3) and extending (t1_3) sequences. When the position of the handle is modified, the analogical relay is closed (t3_3 and t4_3) and the supervisory system is notified of the new handle position (t2_3 and t6_3). C4 – Discrete Sensor (Fig. A.3) The sensors of the landing system have two discrete states: off (p1_4) and on (p2_4). The methods associated with t3_4 and t4_4 are used by the supervisory system to verify the current state of the sensors.
A Complementary Data about Application 2: Landing System
C2 – Double Actuator Equipment
Extending
t1_2
t7_2
t3_2
t4_2
p6_2
p3_2
t10_2 p4_2 t8_2 Retracting
Variables: Xint_2 = {x1, x2 , K p, Kv, Kx_1, Kx_2, I1, I2, I3}; Xim_2 = {pI1.9} Enabling Functions: e1_2, e6_2, e12_2: pI1.9 t Kp; e2_2, e9_2: pI1.9 < Kp; e14_2, e13_2, e7_2: pI1.9 d - Kp; e3_2, e10_2: pI1.9 > Kp; e4_2: x1 = 0; e5_2: x1 = K x_1; e8_2: x2 = 0; e11_2: x2 = K x_2; Equation systems: f2_2: dx1/dT = Kv; f4_2: dx1/dT = - Kv; f5_2: dx2/dT = Kv; f7_2: dx2/dT = - Kv;
t11_2
t12_2
t9_2
Partially extended
p1_2
p5_2
t6_2
t2_2 Retracted gear
Locking t5_2
p2_2
203
Extended gear
Partially locked t13_2
p8_2
p7_2 t14_2 Unlocking Methods used by the class: t1_2 o t2_I2.4 – Turn sensor off t4_2 o t1_I3.4 – Turn sensor on t11_2 o t1_I2.4 – Turn sensor on t14_2 o t2_I3.4 – Turn sensor off
Fig. A.1. OO-DPT sub-net of class C2 – Double Actuator Equipment
C3 – Up/Down Handle p2_3
t3_3
p6_3
t1_3
t7_3 p3_3
t4_3
p7_3 Down
Up p1_3
p4_3
t5_3
p8_3
p5_3
t6_3
p9_3
t8_3
t2_3
p10_3
Variables: Xint_3 = {I1, I2}; External methods provided by the class: t1_3 – Put the handle in the down position t8_3 – Put the handle in the up position Methods used by the class: t3_3 o t2_I1.17 – Perform up sequence t4_3 o t14_I2.13 – Close analogical relay t5_3 o t14_I2.13 – Close analogical relay t6_3 o t1_I1.17 – Perform down sequence
Fig. A.2. OO-DPT sub-net of class C3 – Up/Down Handle
C4 – Discrete Sensor t1_4 Off p1_4
On t2_4
t3_4
p2_4
Methods provided by the class: t1_4 – Turn sensor on t2_4 – Turn sensor off t3_4 – Confirm sensor off t4_4 – Confirm sensor on
t4_4
Fig. A.3. OO-DPT sub-net of class C4 – Discrete Sensor C5 – General Electro-valve and Hydraulic Circuit (Fig. A.5) The pressure on the general hydraulic circuit is determined by the position of the general electro-valve (Fig. A.4). When the general electro-valve is open, the pressure (pg) increases at a constant rate Kv_g until reaching the maximum pressure
204
A Complementary Data about Application 2: Landing System
Kp_g. When the valve is closed, the circuit is connected to the tank (return line) and
the pressure decreases to zero. General electro-valve Open Pressure in the general hydraulic circuit pvg
General electro-valve Closed Pressure in the general hydraulic circuit pvg
Source of constant pressure Kp p=0 Return line
Source of constant pressure Kp p=0 Return line
Fig. A.4. Positions of the general electro-valve
C5 – General Electro-valve and Hydraulic Circuit General Electro-valve p1_5 Closed
Open t1_5 t2_5
Open p2_5
General Hydraulic Circuit t3_5
p3_5
p4_5
Increasing
Pressurized
p6_5
Depressurized t4_5 t5_5 p
t7_5 p7_5
5_5
Close Decreasing
Variables: Xint_5 = {Kp_g, Kv_g, I1}; Xpb_5 = {pg} Enabling functions: e5_5: pg = 0; e6_5: pg = Kp_g; Equation systems: f4_5: dpg/dT = Kv_g; f5_5: dpg/dT = - Kv_g;
t6_5
p8_5 t8_5
Methods provided by the class: t1_5 – Open valve (pressurize the circuit) t2_5 – Close valve (depressurize the circuit) Methods used by the class: t6_5 o t1_I1.4 – Turn sensor on t8_5 o t2_I1.4 – Turn sensor off
Fig. A.5. OO-DPT sub-net of class C5 – General Electro-valve and Hydraulic Circuit C6 – Dedicated Electro-valve C7 – Positive Pressure Electro-valve C8 – Negative Pressure Electro-valve C9 – Dedicated Hydraulic Circuit C10 – General Hydraulic Circuit
The models of these classes have been presented in Chapter 6. C11 – General Electric Circuit
This class models the electric control of the position of the general electro-valve. It is defined as a specialization of class C10. The model of class C11 is defined by specifying the following interfaces for transitions t1_10, t5_10 and t6_10: x x x
t1_11 o t1_I1.5 – Open general electro-valve t5_11 o t2_I1.5 – Close general electro-valve t6_11 o t2_I1.5 – Close general electro-valve
A Complementary Data about Application 2: Landing System
205
C13 – Analogical Relay (Fig. A.6) The analogical relay opens after KT from the last call of the method associated with t14_13. This method is called when the position of the up/down handle is modified. The analogical relay actuates on the following electric circuits: O1.11 – General EC, O1.12 – Open Door EC, O2.12 – Close Door EC, O3.12 – Extend Gear EC, O4.12 – Retract Gear EC. C13 – Analogical Relay Open electric circuit
Closed
p1_13
p2_13
t4_13
p13_13
p3_13
t5_13
p14_13
p4_13
t6_13
p15_13
p5_13
t7_13
p16_13
p6_13
t8_13
p17_13
p7_13
t9_13
p18_13
p8_13
t10_13
p19_13
p9_13
t11_13
p20_13
p10_13
t12_13
p21_13
p11_13
t13_13
p22_13
t2_13 t1_13
t3_13
Open p24_13 t15_13
Variables: Xint_13 = {Taux, KT, I1, I2, I3, I4, I5}; Enabling function: e2_13: Taux= KT Junction function: j1_13, j3_13: Taux = 0; Equation system: f1_13 – dTaux/dT= 1; Method provided by the class t14_13 – Close analogical relay Methods used by the class: t4_13 o t3_I1.11 – Isolate the electric circuit t5_13 o t3_I2.12 – Isolate the electric circuit t6_13 o t3_I3.12 – Isolate the electric circuit t7_13 o t3_I4.12 – Isolate the electric circuit t8_13 o t3_I5.12 – Isolate the electric circuit t9_13 o t7_I1.11 – Not isolate the electric circuit t10_13 o t7_I2.12 – Not isolate the electric circuit t11_13 o t7_I3.12 – Not isolate the electric circuit t12_13 o t7_I4.12 – Not isolate the electric circuit t13_13 o t7_I5.12 – Not isolate the electric circuit
t16_13
Close electric circuit
p23_13 p12_13
t14_13
Fig. A.6. OO-DPT sub-net of class C13 – Analogical Relay C14 – Equipment Supervisor (Fig. A.7)
This class is part of the supervisory system. It verifies the state of the discrete sensor and determines the state of the landing-gear or door, according to Tables 6.1 and 6.2, presented in Chapter 6. The state of an object of this class can be checked using the methods associated with t6_14, t7_14 and t8_14. If the sensor signals are inconsistent, an alarm is activated and the object reaches a deadlock state.
206
A Complementary Data about Application 2: Landing System
C14 – Equipment Supervisor
t2_14
p4_14
t3_14
p5_14
t4_14
p6_14
t5_14
p7_14
Variables: Xint_14 = {I1, I2}; Methods provided by the class: t1_14 – Verify the equipment state Methods used by the class: t2_14 o t4_I1.4 – Confirm sensor on t3_14 o t3_I1.4 – Confirm sensor off t4_14 o t3_I2.4 – Confirm sensor off t5_14 o t4_I2.4 – Confirm sensor on Methods provided by the class: t1_14 – Verify the equipment state t6_14 – Confirm retracted t7_14 – Confirm under movement t8_14 – Confirm extended
Retracted t6_14
p2_14
p1_14
t1_14
Moving t7_14
p3_14
Extended t8_14
Verify sensors
t9_14
p8_14 Inconsistent state – set alarm on
Fig. A.7. OO-DPT sub-net of class C14 – Equipment Supervisor C15 – Set Supervisor (Fig. A.8)
This class determines the state of a set of door and landing gear, according to Table 6.3, presented in Chapter 6. The state of the set can be checked using the methods associated with t10_15, t11_15, t12_15, t13_15, t14_15, t15_15 and t16_15. If the door and landing-gear position are inconsistent, an alarm is activated and the object reaches a deadlock state. C15 – Set Supervisor
Verify the state of the door and landing gear p2_15
t2_15
p4_15
t4_15 p6_15
States 1 to 7 t10_15
t5_15 p7_15
t11_15
t6_15 p8_15
t12_15 t13_15
p1_15
t7_15 p9_15
t1_15 p3_15
t3_15
p5_15
t14_15
t8_15 p10_15
t15_15
t9_15 p11_15
t16_15
Variables: Xint_15 = {I1, I2}; Methods provided by the class: t1_15 – Verify the set state t10_15 – Confirm State 1 t11_15 – Confirm State 2 t12_15 – Confirm State 3 t13_15 – Confirm State 4 t14_15 – Confirm State 5 t15_15 – Confirm State 6 t16_15 – Confirm State 7 Methods used by the class: t2_15 o t1_I1.14 – Verify equipment state t3_15 o t1_I2.14 – Verify equipment state t4_15 o t6_I1.14 – Confirm retracted t5_15 o t7_I1.14 – Confirm under movement t6_15 o t8_I1.14 – Confirm extended t7_15 o t6_I2.14 – Confirm retracted t8_15 o t7_I2.14 – Confirm under movement t9_15 o t8_I2.14 – Confirm extended
t17_15 Inconsistent state – set alarm on t18_15
p12_15
t19_15
p13_15
Fig. A.8. OO-DPT sub-net of class C15 – Set Supervisor
A Complementary Data about Application 2: Landing System
207
C16 – System Supervisor (Fig. A.9)
This class checks the state of the three landing sets, determines the state of the landing system and inform the pilot. If the state of the landing set is inconsistent, an alarm is activated and the object reaches a deadlock state. Due to the large number of combinations (63), only two examples of consistent state (t14_16 and t15_16) and two examples of inconsistent state (t16_16 and t17_16) are presented. C16 – System Supervisor Verify the state of the 3 sets p2_16
t2_16 p5_16
t5_16
p8_16
t6_16
p9_16
Determine the system state and inform the pilot t14_16 p17_16 t18_16 p20_16
t21_16
t7_16 p10_16 t15_16 p18_16 t19_16
t1_16
p3_16
t3_16 p6_16
t8_16
p11_16
t9_16
p12_16
p1_16
t10_16 p13_16
t11_16 p14_16
Variables: Xint_16 = {Taux, KT, I1, I2, I3}; Enabling function: e1_16: Taux= KT Junction function: j21_16: Taux = 0; Equation system: f1_16: dTaux/dT = 1 Methods used by the class t2_16 o t1_I1.15 – Verify the set state t3_16 o t1_I2.15 – Verify the set state t4_16 o t1_I3.15 – Verify the set state t5_16 o t10_I1.15 – Confirm State 1 t6_16 o t11_I1.15 – Confirm State 2 … t16_16
p4_16
t4_16 p7_16
t12_16 p15_16
Inconsistent state – set alarm on p19_16 t20_16 p21_16
t13_16 p16_16 t17_16 Methods used by the class: t8_16 o t10_I2.15 – Confirm State 1 t9_16 o t11_I2.15 – Confirm State 2 … t10_16 o t16_I2.15 – Confirm State 7
Methods used by the class: t11_16 o t10_I3.15 – Confirm State 1 t12_16 o t11_I3.15 – Confirm State 2 … t13_16 o t16_I3.15 – Confirm State 7
Fig. A.9. OO-DPT sub-net of class C16 – System Supervisor C17 – Up/Down Handle Interface (Fig. A.10)
This class performs the up and down sequences according to the requests of the up/down handle (methods t1_17 and t2_17). When the method ‘Perform up sequence’ (t2_17) is called, the sequence is performed only if the WOW switch indicates that the aircraft is not landed (t5_17). If the handle is put in the down position while the supervisory system is performing the up sequence, then the up sequence is interrupted and the down sequence is started.
208
A Complementary Data about Application 2: Landing System
C17 – Up/Down Handle Interface p1_17 t1_17 p3_17 Up position
Down position
p2_17 t2_17
t3_17 p6_17 Performing down sequence Variables: Xint_17 = {I1, I2, I3}; Methods provided by the class: t1_17 – Perform down sequence p7_17 t2_17 – Perform up sequence
t4_17
p4_17 t5_17
WOW sensors off t6_17
p5_17
t7_17
Performing up sequence
t8_17
WOW sensors on
p6_17
Down sequence p6_17
p6_17
p6_17
p6_17
t9_17 p8_17 t11_17 p11_17 t14_17 p13_17 t17_17 p15_17 t20_17 p17_17 t23_1 p19_17 t26_17 p21_17 t29_17 p23_17 t32_17 p25_17 t35_17
p7_17 p9_17
t12_17
Up
p7_17 t15_17 p6_17
t18_17
p7_17 t21_17 p6_17
t24_17
p7_17 t27_17 p6_17
t30_17
p26_17 t33_17 p6_17 Down
t10_17 p10_17 t13_17 p12_17 t16_17 p14_17 t19_17 p16_17 t22_17 p18_17 t25_17 p20_17 t28_17 p22_17 t31_17 p24_17 t34_17 p27_17 t36_17 p7_17
p7_17
Methods used by the class: t9_17 o t2_I1.18 – Open general EV t10_17 o t1_I1.18 – Confirm general EV closed t11_17 o t10_I1.18 – Confirm general EV open t13_17 o t9_I1.18 – Close general EV t14_17 o t2_I2.19 – Extend actuators (open doors) t16_17 o t1_I2.19 – Confirm actuators retracted t17_17 o t18_I2.19 – Confirm actuators retracted t19_17 o t17_I2.19 – Retract actuators (close doors) t20_17 o t2_I3.19 – Extend actuators (extend gears) t22_17 o t1_I3.19 – Confirm actuators retracted
p7_17 Up sequence
p7_17
p7_17
Methods used by the class: t23_17 o t18_I3.19 – Confirm actuators extended t25_17 o t17_I3.19 – Retract actuators (retract gear) t26_17 o t17_I2.19 – Retract actuators (close doors) t28_17 o t18_I2.19 – Confirm actuators extended t29_17 o t1_I2.19 – Confirm actuators retracted t31_17 o t2_I2.19 – Extend actuators (open doors) t32_17 o t9_I1.18 – Close general EV t34_17 o t10_I1.18 – Confirm general EV open t35_17 o t1_I1.18 – Confirm general EV closed t36_17 o t2_I1.18 – Open general EV
Fig. A.10. OO-DPT sub-net of class C17 – Up/Down Handle Interface C18 – General EV Interface (Fig. A.11) When requested, this class actuates on the general electric circuit (C11), and opens or closes the general electro-valve. The position of the general electro-valve is confirmed by the state of the discrete sensor modelled by object O13.4 – Pressurized General HC. C19 – Dedicated EV Interface
The model of this class has been presented in Chapter 6. The initial state of the landing system is when it is completely extended (down position), i.e., when the aircraft is landed. It corresponds to the following initial marking:
A Complementary Data about Application 2: Landing System
C18 –General EV Interface
Closed valve p1_18 t2_18
p4_18
t5_18
t7_18 p8_18 Set off alarm
p6_18 t8_18
p9_18
t10_18
Requires opening and confirms
t1_18 p2_18
Sets off p3_18 alarm
Requires closing and confirms t6_18 p7_18 t3_18 p5_18
t4_18
t9_18
p10_18 Open valve
209
Variables: Xint_18 = {Taux, KT1, KT2, I1, I2}; Enabling functions: e4_18, e7_18: T= KT1; e2_18, e9_18: T= KT2 Junction Functions: j1_18, j5_18, j6_18, j10_18: T = 0; Equations systems: f 1_18, f5_18, f 6_18, f 10_18: dTaux/dT = 1 Methods provided by the class: t1_18 – Confirm general EV closed t2_18 – Open general EV t9_18 – Close general EV t10_18 – Confirm general EV open Methods used by the class: t3_18 o t3_I1.4 – Confirm sensor off t5_18 o t4_I2.11 – Energize electric circuit t6_18 o t2_I2.11 – Not energize electric circuit t8_18 o t4_4.I1 – Confirm sensor on
Fig. A.11. OO-DPT sub-net of class C18 – General EV Interface
Controlled Object x
O1.1 – Nose Door X1.1: x = 0; Kp = 10; Kv = 1; Kx = 0.5; I1 = Door HC; I2 = Closed Nose Door; I3 = Open Nose Door; m1.1 = {p1_1};
x
O2.1 – Right Door X2.1: x = 0; Kp = 10; Kv = 1; Kx = 0.5; I1 = Door HC; I2 = Closed Right Door; I3 = Open Right Door; m2.1 = {p1_1};
x
O3.1 – Left Door; X3.1: x = 0; Kp = 10; Kv = 1; Kx = 0.5; I1 = Door HC; I2 = Closed Left Door; I3 = Open Left Door; m3.1 = {p1_1};
x
O4.1 – Nose Gear X4.1: x = 0.5; Kp = 10; Kv = 1; Kx = 0.5; I1 = Gear HC; I2 = Retracted Nose Gear; I3 = Extended Nose Gear; m4.1 = {p5_1};
x
O1.2 – Right Gear X1.2: x1 = 2; x2 = 0.2; Kp = 10; Kv = 0.5; Kx_1 = 2; Kx_2 = 0.2; I1 = Gear HC; I2 = Retracted Right Gear; I3 = Retracted Right Gear; m1.2 = {p8_2};
x
O2.2 – Left Gear X2.2: x1 = 2; x2 = 0.2; Kp = 10; Kv = 0.5; Kx_1 = 2; Kx_2 = 0.2; I1 = Gear HC; I2 = Retracted Left Gear; I3 = Retracted Left Gear; m2.2 = {p8_2};
x
O1.3 – Up/Down Handle X1.3: I1 = Up/Down Handle Interface; I2 = Analogical Relay; m1.3 = {p10_3};
210
A Complementary Data about Application 2: Landing System
x
O1.4 – Open Nose Door m1.4 = {p1_4};
x
O2.4 – Open Right Door m2.4 = {p1_4};
x
O3.4 – Open Left Door m3.4 = {p1_4};
x
O4.4 – Close Nose Door m4.4 = {p2_4};
x
O5.4 – Close Right Door m5.4 = {p2_4};
x
O6.4 – Close Left Door m6.4 = {p2_4};
x
O7.4 – Extended Nose Gear m7.4 = {p2_4};
x
O8.4 – Extended Right Gear m8.4 = {p2_4};
x
O9.4 – Extended Left Gear m9.4 = {p2_4};
x
O10.4 – Retracted Nose Gear m10.4 = {p1_4};
x
O11.4 – Retracted Right Gear m11.4 = {p1_4};
x
O12.4 – Retracted Left Gear m12.4 = {p1_4};
x
O13.4 – Pressurized General HC m13.4 = {p1_4};
x
O1.5 – General EV/HC X1.5: pg = 0; Kp_g = 12; Kv = 4; I1 = Pressurized General HC; m1.5 = {p1_5, p5_5};
x
O1.7 – Open Door EV X1.7: I1 = Door HC; m1.7 = {p1_7};
x
O2.7 – Extend Gear EV X2.7: I1 = Gear HC; m2.7 = {p1_7};
x
O1.8 – Close Door EV X1.8: I1 = Door HC; m1.8 = {p1_8};
A Complementary Data about Application 2: Landing System
211
x
O2.8 – Retract Gear EV X2.8: I1 = Gear HC; m2.8 = {p1_8};
x
O1.9 – Door HC X1.9: p = - 9.6; I1 = General EV/HC; m1.9 = {p1_9};
x
O2.9 – Gear HC X2.9: p = + 9.6; I1 = General EV/HC; m2.9 = {p1_9};
x
O1.11 – General EC X1.11: I1 = General EV/HC; m1.11 = {p7_11};
x
O1.12 – Open Door EC X1.12: I1 = Open Door EV; m1.12 = {p7_12};
x
O2.12 – Close Door EC X2.12: I1 = Close Door EV; m2.12 = {p7_12};
x
O3.12 – Extend Gear EC X3.12: I1 = Extend Gear EV; m3.12 = {p7_12};
x
O4.12 – Retract Gear EC X4.12: I1 = Retract Gear EV; m4.12 = {p7_12};
x
O1.13 – Analogical Relay X1.13: Taux = 0; KT = 15; I1 = General EC; I2 = Open Door EC; I3 = Close Door EC; I4 = Extend Gear EC; I5 = Retract Gear EC; m1.13 = {p23_13, p24_13};
Supervisory System x
O1.14 – Nose Door Supervisor X1.14: I1 = Close Nose Door; I2 = Open Nose Door; m1.14 = {p1_14};
x
O2.14 – Right Door Supervisor X2.14: I1 = Close Right Door; I2 = Open Right Door; m2.14 = {p1_14};
x
O3.14 – Left Door Supervisor X3.14: I1 = Close Left Door; I2 = Open Left Door; m3.14 = {p1_14};
x
O4.14 – Nose Gear Supervisor X4.14: I1 = Retracted Nose Gear; I2 = Extended Nose Gear; m4.14 = {p1_14};
212
A Complementary Data about Application 2: Landing System
x
O5.14 – Right Gear Supervisor X5.14: I1 = Retracted Right Gear; I2 = Extended Right Gear; m5.14 = {p1_14};
x
O6.14 – Left Gear Supervisor X6.14: I1 = Retracted Left Gear; I2 = Extended Left Gear; m6.14 = {p1_14};
x
O1.15 – Nose Set Supervisor X1.15: I1 = Nose Door Supervisor; I2 = Nose Gear Supervisor; m1.15 = {p1_15};
x
O2.15 – Right Set Supervisor X2.15: I1 = Right Door Supervisor; I2 = Right Gear Supervisor; m2.15 = {p1_15};
x
O3.15 – Left Set Supervisor X3.15: I1 = Left Door Supervisor; I2 = Left Gear Supervisor; m3.15 = {p1_15};
x
O1.16 – System Supervisor -3 X1.16: Taux = 0; KT = 40.10 ; I1 = Nose Set Supervisor; I2 = Right Set Supervisor; I3 = Left Set Supervisor; m1.16 = {p1_16};
x
O1.17 – Up/Down Handle Interface X1.17: I1 = General EV Interface; I2 = Door EV Interface; I3 = Gear EV Interface; m1.17 = {p2_17, p6_17, p26_17};
x
O1.18 – General EV Interface X1.18: Taux = 0; KT1 = 4; KT2 = 1; I1 = Pressurized General HC; I2 = General EC; m1.18 = {p1_18};
x
O1.19 – Door EV Interface X1.19: Taux = 0; KT1 = 2; KT2 = 1; I1 = Close Door EC; I2 = Open Door EC; I3 = Open Nose Door; I4 = Open Right Door; I5 = Open Left Door; I6 = Close Nose Door; I7 = Close Right Door; I8 = Close Left Door; m1.19 = {p1_19};
x
O2.19 – Gear EV Interface X2.19: Taux = 0; KT1 = 2; KT2 = 1; I1 = Retract Gear EC; I2 = Extend Gear EC; I3 = Extended Nose Gear; I4 = Extended Right Gear; I5 = Extended Left Gear; I6 = Retracted Nose Gear; I7 = Retracted Right Gear; I8 = Retracted Left Gear; m2.19 = {p24_19};
References
Alla H, David R (2004) Discrete, continuous, and hybrid Petri nets. Springer Verlag, Berlin Alur R, Courcoubetisz C, Halbwachsx N, Henzinger TA, Hox PH, Nicollinz X, et al (1995) The algorithmic analysis of hybrid systems. Theoretical Computer Science 138: 3-34 Alur R, Henzinger T, Lafferriere G, Pappas G (2000) Discrete abstractions of hybrid systems. Proceedings of the IEEE 88(2): 971-984 Alur R, Dill DA (1994) Theory of timed automata. Theoretical Computer Science 126: 183235 Andreu D (1996) Commande et supervision des procédés discontinus: une approche hybride. Doctoral Thesis, Université Paul Sabatier, Toulouse Antsaklis PJ, Koutsoukos XD (2003) Hybrid Systems: Review and Recent Progress. In: Samad T, Balas G (eds.) Software-Enabled Control: Information Technologies for Dynamical Systems, IEEE Press Baresi L, Pezze M (2001) On formalizing UML with high-level Petri nets. Concurrent Object-Oriented Programming and Petri Nets, Advances in Petri Nets, Lecture Notes in Computer Science 2001:276-304 Beek DA, Rooda JE, Trienekens BJ (1999) Hybrid modelling and simulation of time-delay elements. The 11th European Simulation Symposium, Erlangen, pp 88-92 Benne M, Grondin- Perez B, Chabriat JP, Herve P (2000) Artificial neural networks for modelling and predictive control of an industrial evaporation process. Journal of Food Engineering 46(4): 227-234 Boniol F, Carcenac F (2002) Une étude de cas pour la vérification formelle de propriétés temporelles. Journées Formalisation des Activites Concurrentes, Toulouse Booch G (1994) Object-oriented analysis and design with applications. 2.ed. Benjamin/Cummings Pub. Co., Redwood City Cadet C,. Toure Y, Gilles G, Chabriat JP (1999) Knowledge modeling and nonlinear predictive control of evaporators in cane sugar production plants. Journal of Food Engineering 40(1-2): 59-70 Cassandras C (1993) Discrete Event Systems: Modeling and Performance Analysis, Irwin Publ. Champagnat D (1998) Supervision des systèmes discontinus: definition d’un modèle hybride et pilotage en temps-rèel. Doctoral Thesis, Université Paul Sabatier, Toulouse Champagnat R, Valette R, Hochon JC, Pingaud H (2001) Modeling, simulation and analysis of batch production systems, Discrete Event Dynamic Systems: Theory and Applications 11(1-2): 119-136 Clarke E (1993) Verification tools for finite-state concurrent systems. Lecture notes in Computer Science 8030: 124-175
214
References
Clarke EM, Wing JM (1996) Formal methods: state of the art and future directions. ACM Computing Surveys 28(4): 623-643 Dassault (1996) Genie theme 1 annexe au rapport final: programmation et verification du logiciel d’application de la fonction trains-trappes. Rappport N. DGT-66647 Dassault (1995) Genie theme 1: specification de la fonction trains-trappes d’un système atterrissseur version prèliminaire. Rapport N. 63491 Delatour J (2003) Contribution a la specification des systèmes temps réel: l’approche UML/PNO. Doctoral Thesis, Université Paul Sabatier, Toulouse Douglass BP (2004) Real Time UML: Advances in the UML for Real-Time Systems. Addison-Wesley Longman, Inc. Harlow Drath R (1998) Hybrid object nets: an object oriented concept for modelling complex hybrid systems. The 3rd International Conference on Automation of Mixed Processes: Hybrid Dynamic Systems (ADPM), Reims, pp 436-442 Elhaq SL, Giri F, Unbehauen H (1999) Modelling, identification and control of sugar evaporation - theoretical design and experimental evaluation. Control Engineering Practice 7(8): 931-942 Elkoutbi M, Keller RK (2000) User interface prototyping based on UML scenarios and high-level Petri nets. Lecture notes in Computer Science 1825:166-186 Engell S, Frehse G, Schnieder E. (eds.) (2004) Modelling Analysis and Design of Hybrid Systems. Lecture Notes in Control and Information Sciences, 279, Springer Verlag, Berlin Garcia A, Acebes LF, Prada C (2002) Modelling and simulation of batch processes: a case study. The 15th IFAC World Congress, Barcelona, Elsevier Inc. Genrich H (1987) Predicate/transition nets. Petri Nets: Central Models and Their Properties, Advances in Petri Nets, Lecture Notes in Computer Science 254: 207-247 Giese H, Graf J, Wirtz G (1999) Closing the gap between object-oriented modeling of structure and behavior. Lecture Notes in Computer Science 1723: 534-549 Girard JY (1987) Linear logic. Theoretical Computer Science 50:1-102 Girault F, Pradin-Chezalviel B, Valetter R (1997) A logic for Petri nets. Journal Européen des Systèmes Automatisés 31(3): 525-542 Gueguen H, Lefebvre M (2001) A comparison of mixed specification formalisms. Journal Européen des Systèmes Automatisés 35(4): 381-394 Gueguen H, Zaytoon J. Principes de la vérification des systèmes hybrides. Colloque Francophone sur la Modelisation des Systemes Reactifs, Toulouse, Hermes Science Publishing, Cachan, p.427-444 Guerrero DDS, Figueiredo JCA, Perkusich A (2001) An object-based modular CPN approach: its application to the specification of a cooperative editing environment. Advances on Petri Nets, Lecture Notes in Computer Science, 2001: 338-354 Halbwachs N, Lagnier F, Ratel C (1992) Programming and verifying real-time systems by means of the synchronous data-flow programming language Lustre. IEEE Transactions on Software Engineering 18(9): 785-793 Henzinger TA, Ho PH, Wong-Toi H (1997) HyTech: a model checker for hybrid systems. Software Tools for Technology Transfer 1: 110-122 Ho YC (1987) Basic research, manufacturing automation, and putting the cart before the horse. IEEE Transactions on Automatic Control AC-32(12): 1042-1043 Hugot E (1986) Handbook of cane sugar engineering. 3.ed. Elsevier Science Pub. Co., New York Incropera FP, De Witt DP (1990) Fundamentals of heat and mass transfer. 3.ed. Wiley, New York Jacobson I, Booch G, Rumbaugh J (1999) The unified software development process. Reading, Addison-Wesley, Massachusetts
References
215
Jensen K (1997) Coloured Petri nets: basic concepts, analysis methods and practical use. 2.ed., Springer Verlag, Berlin Jesus CDF, Almeida PIF (1999) Simulação do controle do processo de evaporação de múltiplo efeito utilizado na fabricação de açúcar. II Congresso de Engenharia de Processos do Mercosul, Florianópolis Khalfaoui S (2003), S. Méthode de recherche des scénarios redoutés pour l’évaluation de la sûreté de fonctionnement des systèmes mécatroniques du monde automobile. Doctoral Thesis, Université Paul Sabatier, Toulouse Köster F, Schof S, Sonnenschein M, Wieting R (2001) Modelling of a library with THORNs. Concurrent Object Oriented Programming and Petri Nets, Lecture Notes in Computer Science 2001: 375-390 Lakos C (1995) From coloured Petri nets to object Petri nets. Lecture Notes in Computer Science 935: 223-228 Lauret P, Boyer H, Gatina JC (2000) Hybrid modelling of a sugar boiling process. Control Engineering Practice 8(3): 299-310 Lemmon M, He KX, Markovsky I (1999) Supervisory hybrid systems. IEEE Control Systems 19(4): 42-55 Lennartson B, Tittus M, Egardt B, Pettersson S (1996) Hybrid systems in process control. IEEE Control Systems 16(5): 45-46 Ljung M (1999) Formal modelling and automatic verification of Lustre programs using nptools. 1999. Master Thesis, Royal Institute of Technology, Stockholm Miyagi PE (1988) Control system design, programming and implementation for discrete event production systems by using mark flow graph. Doctoral Thesis, Tokyo Institute of Technology, Tokyo Moody JO, Antsaklis PJ (1998) Supervisory Control of Discrete Event Systems using Petri Nets. Kluwer Academic Publishers, Norwell Murata T (1989) Petri Nets: properties, analysis and applications. Proceedings of the IEEE 77(4): 541-580 Paludetto M (1991) Sur la commande des procédés industriels: une méthodologie basée objects et réseaux de Petri. Doctoral Thesis, Université Paul Sabatier, Toulouse Petterson P, Larsen KG (2000) Uppaal2k. Bulletin of the European Association for Theoretical Computer Science 70:40-44 Ramadge RJ, Wonham WM (1987) Supervisory control of a class of discrete event processes. SIAM Journal of Control and Optimization 25(1):206-230 Rumbaugh J, Jacobson I, Booch G (2004) Unified Modeling Language Reference Manual. 2 ed, Addison-Wesley Longman, Inc. Harlow Salsbury TI (1996) Fault detection and diagnosis in HVAC systems using analytical models. 1996. Doctoral Thesis, Loughborough University, Loughborough Silva BI, Stursberg O, Krogh BH, Engell S (2001) An assessment of the current status of algorithmic approaches to the verification of hybrid systems. The 40th Conference on Decision and Control, Orlando, IEEE Press, Piscataway, pp 2867-2874 Silva BI, Richeson K, Krogh B, Chutinan A (2000) Modeling and verifying hybrid dynamic systems using Checkmate. The 4th International Conference on Automation of Mixed Process: Hybrid Dynamic Systems, Dortmund, Shaker Verlag, Aachen, pp 323-328 Silva M, Teruel1 E, Valette R, Pingaud H (1998) Petri nets and production systems. Lecture notes in Computer Science 1492: 85-124 Stursberg O, Kowalewski S, Preussig J, Treseler H (1998) Block-diagram based modelling and analysis of hybrid processes under discrete control. Journal Européen des Systèmes Automatisés 32(9-10): 1097-1118 Valentin-Roubinet C (2000) Hybrid Dynamic System verification with Mixed Petri Nets. The 4th International Conference on Automation of Mixed Processes: Hybrid Dynamic System, Dortmung, Shaker Verlag, Aachen, pp. 231-236.
216
References
Valk R (1998) Petri nets as token objects: an introduction to elementary object nets. Lecture Notes in Computer Science 1420: 1-25 Villani E (2000) Abordagem híbrida para modelagem de sistemas de ar condicionado em edifícios inteligentes. Master Thesis, Escola Politécnica da Universidade de São Paulo. São Paulo Villani E (2004) Modelagem e análise de sistemas supervisórios híbridos. Doctoral Thesis, Escola Politécnica da Universidade de São Paulo. São Paulo Wieting R (1996) Hybrid high-level nets. The 28th Winter Simulation Conference, Coronado, pp 848-855
Index
actuator 8 (aircraft) 148í149, 152 signal 4 booster actuator 6 smart actuator 9 adaptative control strategies 4 air temperature 117 airflow 114í115, 117, 124 alarm situation 127 alcohol molasses 171 production 183 analogical relay 144, 151, 164 analysis 5, 75 formal methods 75 formal techniques 40 method (aircraft) 157, 159í160, 162í166 (HVAC system) 131í132, 138, 142í143, 199í200 (sugar factory)) 172, 193, 197 obligations 154 procedure 195 obligation of 87, 89, 93, 100 of continuous dynamics 89, 98 of discrete dynamics 93, 100, 102, 105 of the first object 104 procedure 32 asynchronous behaviour 14 automata 14 backward reasoning 79í80, 82í84, 105 bagasse 174, 176 batch process 171, 182 behaviour monitoring 8
behavioural property 43, 143, 199í200 behavioural restrictions 4 Booch method 44 Bottom-up strategy 73 cake 179 cane juice 172 layer 172, 176 density of 187 mass flow 187 reception 175 sugar factory 171í172, 174, 197 processing 173 production 171 transportation 174, 187 cascade model 43 cause-effects rule 5 centrifugation 182 centrifuge 172, 182í183 chain mechanism 174 CheckMate 77 chopper 172í173, 175, 181, 189í192, 194 clarification 172, 179, 181 clarifier 179, 172 class 22, 44 attributes 53 child class 22, 70 decomposition 68, 70 composition 68í70 instantiation 22 method 53 parent class 22, 70 specification 50, 72 classification 22
218
Index
clock 76 time-dense clock 76 closed loop of dependence 52 code reuse 70 coloured Petri net 18 command signal 4 communication between objects 53, 55, 72, 119 complex system 197 composition 18, 113, 118, 120, 124, 131, 136, 142, 197 of the object analyses 103 compressor 176 concentration of the juice 181 concurrency 14, 45, 50, 53, 55 concurrent scenarios 106, 109, 156, 160, 164, 166 conditioned environment 114 conflict 14, 75 conflicting scenario 164, 166 constant volume of air 114 continuous communication 55, 61, 143 continuous control laws 4 continuous dynamic systems 2í3, 5 continuous dynamics 3, 5, 13í14, 132, 139, 142, 168, 171, 190, 193, 195í197 continuous interaction 51í52, 73 continuous models 4 continuous processes 3 models 3 continuous variables 2í3, 89, 117, 131, 135, 139, 168, 197 control action 192, 194, 197 coding 7í8 engineering 43 law 4, 123 PID (proportional integral derivative) control 8, 114, 118, 122í123 signals 151, 152 system 6í7, 10, 41, 43, 173 refinement 7í8 requirements 7 variables 142 controllable events 7 controlled object 6í7, 10, 41, 43, 46, 48í50, 71 (aircraft) 143, 148 (HVAC system) 115, 117, 124, 199 specification of 7
(sugar factory) 174, 185 controlled plant 71, 73 controller 4, 8 (aircraft) 144 (HVAC system) 113, 114, 123, 125í126, 128, 132 implementation 7í8 on/off controller 114,122,142 PLC (programmable logic controller) 8 conveyor 172í173, 175í177, 186, 187 cooling 115,137 coil 114í115, 118, 120, 122í124, 126, 128, 132, 137 crane 174í175 crystal cane sugar 174 crystallisation 172í174, 181í184 dangerous state 7, 200 deadlock 98, 164 decidability 76, 112 decision-making 8í9 complexity 8 problems 8 rules 5 decomposition 51í53, 113, 118, 120, 132, 142í143, 162í163 of the analysis problem 76í77, 87 rule 51í52, 117, 143 1st rule 51 2nd rule 51í52 3rd rule 51í52 development process 43 diagnosis 147 differential equation system 3, 5, 13, 199, 200 differential predicate transition net 13í14, 19í21, 23, 35, 40 definition 20 differential equation system 20 enabling function 20 initial marking 20 junction function 20 transition enabling 20 transition firing 20 variables 20, 21 diffuser 172, 176, 177 conveyor 175 diffusion 173, 176 discontinuities 3, 4 discrete communication 55, 61, 169 discrete devices 4 actuators 4
Index
command devices 4 monitoring devices 4 sensors 4, 145, 147 discrete dynamics 132í133, 138í139, 143, 171, 197 discrete event driven 171 discrete event dynamic systems 2í3, 5, 10, 22, 75í76 discrete events 3í4 discrete states 2í4, 187í188, 195 discrete variables 2, 14 event occurrence 9 event-driven 2, 3 instantaneous events 2 discrete event-driven dynamics 13, 15 discrete interaction 51, 53 discrete interface 126 discrete supervisory system 10 distributed simulation 200 distributed system 15 dough 172í173, 182í183 dryer 183 drying 172, 185 dynamic behaviour 7, 8 dynamic models 7, 10 electric circuit 151í152, 155, 168í169 electrical power 176 electro-valve 144, 147, 149í152, 155 evaporation 172í173, 181, 183 evaporator 172, 181í182 external entity 35 extraction 172, 174 factory management 173 fan 117, 127, 128, 132 fault 8 (aircraft) 144, 147 detection 8, 13, 147 diagnosis 8 (HVAC system) 117, 137 (sugar factory) 187, 190, 192, 194, 197 treatment 147 feed table 186, 188, 175 filters 179 fire management system 115, 119, 127 flow of cane 188 of material (HVAC system) 115 (sugar factory) 174
219
forbidden scenario 106, 109 forbidden state 104, 105 (aircraft) 149, 155í156, 164, 168 (sugar factory) 190í191, 200 formal languages 7 forward reasoning 79, 80, 82, 83, 93 furnaces 176 G-CPN (g-coloured Petri net) 22 global sequent 90, 93, 111, 136, 141 building 103 global variable 14 glucose molecules 172 graph of reachable markings 85 hardware architecture 43 heat exchange 122 heater 172, 173, 178í180, 183 heating, ventilation and air-conditioning system see HVAC system heterogeneity 2 heterogeneous nature 2 hierarchical architecture 8 hierarchical control 8 local control 8í10 planning 8í9 scheduling 8í9 supervision 8í10 hierarchical structure 23 hierarchy 18 high-level Petri net 13, 18, 22 HVAC system 113í115, 117, 124, 127, 142 HVAC equipment 115, 117 HVAC operator 115, 125í126 HVAC user 128 hybrid automata 14, 77 hybrid object net 22 hybrid Petri net 14 continuous place 14 continuous transition 14 hybrid supervisory system 6, 10, 43, 113 hybrid systems 1í3, 5, 10, 14 hydraulic actuators 144 hydraulic circuit 144, 147í151, 154, 156, 168í169 hydraulic reservoir 149 HyNet (hybrid high-level Petri net) 22 hypothesis 87, 89, 90, 112 elaboration of 89, 97, 102 statements H1 to H6 97 verification of 104 HyTech 77
220
Index
image variables 98 imply formula 79, 81, 93 inclined plates 177 incremental model 43 industrial production 171 information system 43 initial state 61, 130 interface 84 transition 91, 93, 98 intermediate storages 173 internal transition 91, 93 juice (sugar factory) 176 flow 179 treatment 172í173, 179 landing (down) sequence 144, 147 landing gear 143í149, 152, 168, 169 landing set 143, 144í146 landing system 143í145, 148, 153í154, 168í169 leakage 115, 117, 122 levels of production 173 lime 172, 176, 178 linear hybrid automata 77 linear logic 76í78, 87 connector 78
(multiplicative conjunction) 78í80, 82 (multiplicative disjunction) 78, 80, 82 —o (imply) 78 formula 78 meta-connector |–– 78 ‘,’ 78í79, 82 Proof of a sequent 78í81 tree 79í82, 90, 93, 95í96, 101, 135í136, 138, 190 proposition 78 rule 78í79
L 80 L 81
R 80, 85 R 81 Cut 78, 79 Exchange L 78, 80 Exchange R 78, 80 Identity 78 —o L 80í81 local control system 71, 73
logic atom 79, 81 bloc of formulas 78 classical logic 77í78 connector AND 77í78 IMPLY 78 OR 78 contraction proof-rule 77 intermediate lemma 78, 87 first order logic system 18 hypotheses 77 logical formula 18 mathematical proof 87 monoid 85 monomial 79, 81 monotonicity 77 proof 75 of a theorem 77 proposition 87 propositional logic system 18 propositions 77í78 weakening proof-rule 77, 78 logical and conceptual structure 7 long term horizon 9 long term strategic decision 8 magma 182í183 maintenance 178 management system 113, 115 manufacturing process 15 mass flow 187, 188 mathematical verification 75 measured variables 4 method call 53, 55, 68, 124, 126, 134, 135, 139, 151, 195, 197 mid term time horizon 9 milling train 176 mixed Petri net 14 mixing box 114, 115, 117, 118, 120, 122, 127, 128 mixing tank 178 model checking 76, 77 modelling activity 13 formalism 13, 14, 15, 76, 199 method 46, 171í172, 174, 197, 199 phase 7í8, 93 modular modular approach 169, 197 modular structure 40, 200 modularity 21, 84, 112
Index
molasses 173, 182 monitoring and control 5 mud 179 natural fertilizer 179 nature of state variables 5 non-decidability 76 non-linear model 4 non-reactive systems 9 object 21, 44 attributes 21 behaviour 21 dynamic instantiation 40 identity 21 interface 22í23 internal behaviour 89 internal evolution 84 internal implementation 22 memory 21 methods 21 modeling technique see OMT operations 21 specification 50, 72 object net 22 object-oriented differential predicate transition net see OO-DPT net object oriented) paradigm see OO paradigm object-oriented software engineering see OOSE OMT (object modeling technique) 44 OO (object oriented) paradigm 13, 21í23, 40, 44, 84, 197, 199 composition/decomposition relationship 44, 46, 60, 68í70, 73 encapsulation 21í23 generalisation/specialisation relationship 44í45, 60, 68, 70, 73, 118, 120, 123, 128, 130 inheritance 22, 70 programming language 22 relationship 44, 60, 68 OO-DPT net (object-oriented differential predicate transition net) 13, 23, 43 (aircraft) 148, 154, 162 class 23, 29 class attribute 23 communication
221
between objects 30 with external environment 35 constant parameters 28, 40 continuous communication 30, 33 definition 23 discrete interaction 30 discrete interface 30 dynamic fusion of transition 30 enabling function23 equation system 25 external interface 35 external method call 36 external variables 28, 36 global net 39 (HVAC system) 113, 119í120, 131, 142 image variables 28í30 initial marking 25 instantiation 29 internal variables 28 junction function 23 marking 23, 26 method call 32í35 implementation 32 signature 33í35 object 23, 26, 29 place variables 23, 27, 29 public variables 28, 30 sub net 23í24, 26, 37 sub-marking 26í28 (sugar factory) 171, 190, 197 transition fusion 30, 32, 36 underlying Petri net 37, 40 unfolded version 36, 66, 87 unfolding 36í37 variables 23, 26 OOSE (object-oriented software engineering) 44 operating mode 115, 128, 137 operator 117, 137 OPN (object Petri net) 23 ordinary differential equations 14 ordinary Petri net 40 packing 172í173, 183, 185 parallelism 45, 50, 55 partial order of events 84, 86, 112, 142 Petri net 13í18, 22í23, 35, 64, 76í77, 131, 199í200 analysis techniques 36, 104 arc weight 16 coloured Petri net 18
222
Index
date of transition firings 89 firing of transition 16 formal definition 16í17 g-coloured Petri net 22 high-level Petri net 13, 18, 22 hybrid high-level Petri net 22 hybrid Petri net 14 continuous place 14 continuous transition 14 initial marking 17 input arc 16 input place 16 marking 15í16 mixed Petri net 14 object Petri net 23 ordinary Petri net 40 output arc 16 output place 16 place 15 capacity 14 invariant 66, 104, 136 pre and post matrices 17 state equation 17 token 15, 16 transition 15 enabling 16 firing date 98 PFS (Production Flow Schema) 47í48, 72í73 activity 48, 55 arc 48 inter-activity 48 model 113, 115 progressive refinement 48 refinement techniques 174 physical entities 5í8 devices 5í6 plant 9 pilot panel 152 plant 71, 73 predicate transition net 13í14, 18, 35 action 18 definition 18 enabling condition 18 initial marking 18 transition
enabling 19 firing 19 variables 17í19 preparation stage 172í174 preventive action 190 preventive maintenance 173
processing of material 142 production line 173í175, 186, 188, 190 processes 174 stages 174 Production Flow Schema see PFS productive system 5í11, 41 aerospace systems 5 air conditioning unit 5 building management systems 5 systems 5 communication network 5 database systems 5 fuel tank 4 industrial automation 9 industrial systems 5, 9 information systems 5í7 man-made systems 2 manufacturing systems 5 transportation systems 5 programmable logic controller see controller, PLC programming language 43, 199 property restriction 89 property statement 89í90 (reachability) PR1 to PR2 91 (safety) PS1 104 specification of 90, 104 proportional integral derivative control see control, PID rational unified process see RUP reachability 77, 79í82, 84í85, 88í91, 111, 132, 154, 168, 200 tree 104, 136 reachable regions 77 reachable state 76, 192, 194, 196 reactive system 9 real time system 9 real-world system 5 reception stage 172í174 region graph 76, 77 renewed air 127 residual steam 174, 181 resource allocation 9 restriction 92 statement R1 to R6 92 specification of 92 reuse 113, 119, 132 room temperature 118 rotary tank 178
Index
rotating furnace 173 rule for specification of sequents 95, 101, 105, 109 Rule 1 to Rule 9, 95 Rule 10 to Rule 15, 101 Rule 16 to Rule 17, 105 Rule 18 to Rule 23, 109 RUP (rational unified process) 43 SACI-2 satellite 1,6 safety property 36, 88í90, 111, 143, 154, 171, 174, 190, 197, 200 scenario 45, 53 (aircraft) 155,156, 157 (HVAC system) 133,134í136,138,142 (sugar factory) 191í194,197 search for scenarios 77, 82í83, 89, 93í94, 100, 194 seeds 182, 183 sensors 8, 146 IMU (inertial measurement unit) sensor 6 on/off discrete sensors 144 pressure sensor 147 smart sensor 9 sequent 78 axiom sequent 78í79 (aircraft) 155 calculus 78 (HVAC system) 133,134í136,138,140 (sugar factory) 191 service automation 9 set point 115, 117, 123, 125, 136í137 shower system 175 shredder 172í173, 176, 187 simulation 5, 23, 75, 200 smoke 127 SO2 176í177 SO3 176 software engineering 7, 43, 70 tools 75, 77 state explosion problem 169 regions 76 variable 2 statecharts 44 static collaboration diagram 93, 111 (aircraft) 154 (HVAC system) 133,137
223
(sugar factory) 191 static structure 37, 39 storehouse 172í175 sucrose molecules 172 sugar production 172í173 sulphitation 173, 176í178 sulphur 173 supervision 171,173 supervisory system 10í11, 43, 49, 199 (aircraft) 143, 145, 147í149, 151í152, 155, 168í169 design 200 development of 13, 43 (HVAC system) 115, 117í118, 124, 127í128 (sugar factory) 171í174, 186, 188í189, 197 supply energy systems 5 switching 4 synchronisation 14 synchronism 45, 50, 55 syntactic approach 78 syrup 172, 181í183 system architecture 44 behaviour 75, 200 integrity 5 object 200 requirement 7í8, 88, 199 state 144, 145 system net 22 taking-off (up) sequence 144, 147 tank 173, 179 temperature ((HVAC system)) control 114 in the coil 117 in the zone 120, 123í124, 136 of the air 122, 124 of the airflow 117í118 of the water 122 set point 142 temporal sequence 86 theorem proving 76 thermal load 114, 124 three-way valve 114 THORN (timed hierarchical object-related net) 22 time interval model 4 timed automata 76, 77, 169 timed hierarchical object-related net see THORN
224
Index
time-driven 2 top-down strategy 73 transportation speed 186 truck 172í173, 175, 186, 188 UML (unified modelling language) 43 activity 44í45, 50, 53, 55, 64, 65, 72 activity diagram 44í46, 50, 53, 55, 64í66, 72, 116, 119, 131 decision point 65 synchronisation bar 65 actor 44, 49, 72 class diagram 44, 46, 60, 119 collaboration diagram 44í46, 53, 55, 61, 73, 93, 118, 131 component 44 component diagram 44 continuous activity 50, 64í65 deployment diagram 44 diagram 43í44, 73, 197, 199 discrete activity 50, 64í65 interaction diagram 44 interface 44 message 45 object diagram 44 sequence diagram 44í46, 53, 55, 61, 73, 118í119, 131 state 44 statechart diagram 44 use case 44, 49, 50, 72 use case diagram 44, 46, 49, 72, 116, 131 uncontrollable events 7 unified modelling language see UML up-down handle 144, 168
UPPAAL 77 vacuum pan 172í173, 182í183 validation 7, 10í11, 43, 111, 154 model 7, 72, 73 valve (aircraft) 167, 168 (HVAC system) 114, 118, 123 (sugar factory) 178 variable sharing 28í30, 33, 53, 55, 61 closed loop 48 vegetal steam 174 ventilation 115 Verdict 77 verification 7 (aircraft) 143, 154í155, 169 (HVAC system) 131í134, 136í137, 142, 199 of hypothesis 90, 112, 168 of the properties 11, 48, 75, 76 (sugar factory) 171, 174, 190, 195í196 tools 169 VLS-1 Brazilian Satellite Launch Vehicle 1í2, 6í7, 9 water ((HVAC system)) flow 115, 122 valve 122, 123 weight on the wheels system see WOW system WOW (weight on the wheels) system 144 zone 113í114, 127 zone temperature 115, 117, 137
Other titles published in this Series (continued): Adaptive Voltage Control in Power Systems Giuseppe Fusco and Mario Russo Advanced Control of Industrial Processes Piotr Tatjewski Process Control Performance Assessment Andrzej Ordys, Damien Uduehi and Michael A. Johnson (Eds.) Magnetic Control of Tokamak Plasmas Marco Ariola and Alfredo Pironti Publication due May 2007 Continuous-time Model Identification from Sampled Data Hugues Garnier and Liuping Wang (Eds.) Publication due May 2007 Model-based Process Supervision Belkacem Ould Bouamama and Arun K. Samantaray Publication due June 2007
Process Control Jie Bao, and Peter L. Lee Publication due June 2007 Distributed Embedded Control Systems Matjaˇz Colnariˇc, Domen Verber and Wolfgang A. Halang Publication due October 2007 Optimal Control of Wind Energy Systems Iulian Munteanu, Antoneta Iuliana Bratcu, Nicolas-Antonio Cutululis and Emil Ceanga Publication due November 2007 Model Predictive Control Design and Implementation Using MATLAB® Liuping Wang Publication due November 2007
