Formal methods in manufacturing

Electrical Engineering Illustrated with real-life manufacturing examples, Formal Methods in Manufacturing provides state-of-the-art solutions to common problems in manufacturing systems Assuming some knowledge of discrete event systems theory, the book first delivers a detailed introduction to the most important formalisms used for the modeling, analysis, and control of manufacturing systems (including Petri nets, automata, and max-plus algebra), explaining the advantages of each formal method It then employs the different formalisms to solve specific problems taken from today’s industrial world, such as modeling and simulation, supervisory control (including deadlock prevention) in a distributed and/or decentralized environment, performance evaluation (including scheduling and optimization), fault diagnosis and diagnosability analysis, and reconfiguration Containing chapters written by leading experts in their respective fields, Formal Methods in Manufacturing helps researchers and application engineers handle fundamental principles and deal with typical quality goals in the design and operation of manufacturing systems Tai ngay!!! Ban co the xoa dong chu nay!!! K15943 Formal Methods in Manufacturing Formal Methods in Manufacturing Formal Methods in Manufacturing Formal Methods in Manufacturing I N D U S T R I A L I N F O R M AT I O N T E C H N O L O G Y S E R I E S Series Editor RICHARD ZURAWSKI Formal Methods in Manufacturing Edited by Javier Campos, Carla Seatzu, and Xiaolan Xie Embedded Systems Handbook, Second Edition Edited by Richard Zurawski Automotive Embedded Systems Handbook Edited by Nicolas Navet and Franỗoise Simonot-Lion Integration Technologies for Industrial Automated Systems Edited by Richard Zurawski Electronic Design Automation for Integrated Circuits Handbook Edited by Luciano Lavagno, Grant Martin, and Lou Scheffer Industrial Communication Technology Handbook Edited by Richard Zurawski Formal Methods in Manufacturing Boca Raton London New York CRC Press is an imprint of the Taylor & Francis Group, an informa business MATLAB® is a trademark of The MathWorks, Inc and is used with permission The MathWorks does not warrant the accuracy of the text or exercises in this book This book’s use or discussion of MATLAB® software or related products does not constitute endorsement or sponsorship by The MathWorks of a particular pedagogical approach or particular use of the MATLAB® software CRC Press Taylor & Francis Group 6000 Broken Sound Parkway NW, Suite 300 Boca Raton, FL 33487-2742 © 2014 by Taylor & Francis Group, LLC CRC Press is an imprint of Taylor & Francis Group, an Informa business No claim to original U.S Government works Version Date: 20131227 International Standard Book Number-13: 978-1-4665-6156-4 (eBook - PDF) This book contains information obtained from authentic and highly regarded sources Reasonable efforts have been made to publish reliable data and information, but the author and publisher cannot assume responsibility for the validity of all materials or the consequences of their use The authors and publishers have attempted to trace the copyright holders of all material reproduced in this publication and apologize to copyright holders if permission to publish in this form has not been obtained If any copyright material has not been acknowledged please write and let us know so we may rectify in any future reprint Except as permitted under U.S Copyright Law, no part of this book may be reprinted, reproduced, transmitted, or utilized in any form by any electronic, mechanical, or other means, now known or hereafter invented, including photocopying, microfilming, and recording, or in any information storage or retrieval system, without written permission from the publishers For permission to photocopy or use material electronically from this work, please access www.copyright.com (http:// www.copyright.com/) or contact the Copyright Clearance Center, Inc (CCC), 222 Rosewood Drive, Danvers, MA 01923, 978-750-8400 CCC is a not-for-profit organization that provides licenses and registration for a variety of users For organizations that have been granted a photocopy license by the CCC, a separate system of payment has been arranged Trademark Notice: Product or corporate names may be trademarks or registered trademarks, and are used only for identification and explanation without intent to infringe Visit the Taylor & Francis Web site at http://www.taylorandfrancis.com and the CRC Press Web site at http://www.crcpress.com Contents Preface ix Editors xiii Contributors xv PART I Modelling and Simulations of Manufacturing Systems Chapter Modelling Manufacturing Systems with Place/Transition Nets and Timed Petri Nets Maria Paola Cabasino, Mariagrazia Dotoli and Carla Seatzu Chapter Modelling Manufacturing Systems in a Dioid Framework 29 Thomas Brunsch, Laurent Hardouin and Jörg Raisch Chapter Modelling Manufacturing Systems and Inventory Control Systems with Hybrid Petri Nets 75 Maria Paola Cabasino, Alessandro Giua and Carla Seatzu Chapter Hybrid Models for the Control and Optimization of Manufacturing Systems 105 Christos G Cassandras and Chen Yao Chapter Freight Transportation in Distributed Logistic Chains 135 Angela Di Febbraro and Nicola Sacco PART II Chapter Supervisory Control of Manufacturing Systems Deadlock Avoidance Policies for Automated Manufacturing Systems Using Finite State Automata 169 Spyros Reveliotis and Ahmed Nazeem Chapter Structural Deadlock Prevention Policies for Flexible Manufacturing Systems: A Petri Net Outlook 197 Juan-Pablo López-Grao, José-Manuel Colom and Fernando Tricas Chapter Deadlock Avoidance Policies in Production Systems by a Digraph Approach 229 Maria Pia Fanti, Bruno Maione and Biagio Turchiano v vi Chapter Contents Supervisory Control of Manufacturing Systems Using Petri Nets 259 Carla Seatzu and Xiaolan Xie Chapter 10 Supervisory Control of Manufacturing Systems Using Extended Finite Automata 295 Martin Fabian, Zhennan Fei, Sajed Miremadi, Bengt Lennartson and Knut Åkesson Chapter 11 Inference-Based and Modular Decentralized Control of Manufacturing Systems with Event-Driven Dynamics 315 Shigemasa Takai and Ratnesh Kumar Chapter 12 Model Predictive Control of Manufacturing Systems with Max-Plus Algebra 343 Ton J.J van den Boom and Bart De Schutter PART III Chapter 13 Performance Evaluation of Manufacturing Systems and Supply Chains Performance Evaluation of Flexible Manufacturing Systems by Coloured Timed Petri Nets and Timed State Space Generation 381 Gasper Muˇsiˇc, Liana Napalkova and Miquel Àngel Piera Chapter 14 Performance Evaluation and Control of Manufacturing Systems: A Continuous Petri Nets View 409 Manuel Silva, Estíbaliz Fraca and Liewei Wang Chapter 15 Performance Evaluation of Flexible Manufacturing Systems with Timed Process Algebra 453 María Carmen Ruiz, Diego Cazorla, Fernando Cuartero and Hermenegilda Macia Chapter 16 Lean Buffer Design in Production Systems 477 Jingshan Li, Semyon M Meerkov and Xiang Zhong Chapter 17 Inventory Allocation and Cycle Time Estimation in Manufacturing and Supply Systems 503 Liming Liu and Yang Sun Chapter 18 Minimizing Total Place Capacity under Throughput Constraint for a Weighted Timed Event Graph 527 Alix Munier Kordon vii Contents Chapter 19 Scheduling of Semiconductor Manufacturing Systems Using Petri Nets 553 Fei Qiao and MengChu Zhou Chapter 20 Model Synthesis, Planning, Scheduling and Simulation of Health-Care Delivery Systems Using Petri Nets 571 Vincent Augusto and Xiaolan Xie PART IV Chapter 21 Fault Diagnosis of Manufacturing Systems Fault Diagnosis of Manufacturing Systems Using Finite State Automata 601 Stéphane Lafortune, Richard Hill and Andrea Paoli Chapter 22 Fault Diagnosis in Petri Nets 627 Elvia Ruiz-Beltrán, Antonio Ramirez-Treviño and J.L Orozco-Mora Chapter 23 Online Control Reconfiguration for Manufacturing Systems 653 Yannick Nke and Jan Lunze Index 683 602 Formal Methods in Manufacturing methodology, often called the Diagnoser Approach, that was initiated in the work of Sampath et al in [26,27] We present the necessary background on automata, parallel composition and observer automata, before presenting the key notions and steps of the diagnoser approach Our presentation is focused on the monolithic version of the diagnoser approach, which employs a single diagnoser built from the overall system model Moreover, we only consider permanent faults There is a large body of literature on numerous extensions of the diagnoser approach beyond the basic set-up covered in this chapter These extensions include decentralized-information architectures, modular architectures, intermittent faults, active diagnosis, systems with unreliable observations and systems modelled by timed or stochastic automata Some relevant references will be mentioned later on in Sections 21.7 and 21.8 Moreover, other approaches have been proposed for diagnosis of systems modelled by automata, such as state-based approaches, partial order techniques for distributed systems and time template approaches These other approaches will not be surveyed in this chapter, but we encourage the reader to consult the literature We point out a small subset of relevant references that can serve as starting point for the interested reader: [2,10,12,17,18,20,32,40] We also refer the reader to Chapter 22 in this book for diagnosis of systems modelled by Petri nets and to the recent survey paper [41] for additional references This chapter is organized as follows Since the system of interest is modelled as a set of interacting automata coupled by common events, we start in Section 21.2 with a review of automata and parallel composition We then discuss the analysis of automata with unobservable events by observer automata in Section 21.3 We hope that these two sections will make the chapter self-contained for readers with little background in discrete event system theory Sections 21.4 and 21.5 present the basics of the diagnoser approach Section 21.4 is concerned with online diagnosis (i.e., at run-time) using diagnoser automata, while Section 21.5 presents the formal notion of diagnosability and how to test for it using verifier automata A controlled pump–valve system is employed as running example in Sections 21.2 through 21.5 Section 21.6 illustrates the steps of modelling, analysis and diagnosis, in the context of a generic component in manufacturing systems, a pneumatic piston Section 21.7 discusses two of the many research trends in past and current literature: cooperative diagnosis for systems with decentralized information and sensor selection for diagnosability Section 21.8 concludes the chapter Our discussion of basic discrete event system theory concepts and of observer and diagnoser automata follows their formal presentation in the textbook [4] Our treatment of verifier automata is based upon their original definition in [39], although we have altered the definition to simplify their structure and avoid non-determinism The example in Section 21.7 is inspired by the modelling methodology introduced in [28] for automated manufacturing systems 21.2 MODELLING 21.2.1 LANGUAGE PRELIMINARIES Let E be the finite set of events associated with the dynamic behaviour of the manufacturing system under consideration A trace (or string) is a finite sequence of events from E The length of a trace s, denoted by |s|, is a non-negative integer corresponding to the number of events composing the trace, counting multiple occurrences of the same event The empty trace, denoted by ε (not to be confused with the generic event e ∈ E), is the trace containing no events; thus, |ε| = The concatenation of two traces s1 and s2 is the trace s1 s2 (i.e., s1 followed by s2 ) The empty trace ε is the identity element for concatenation Trace s1 is called a prefix of trace s1 s2 We write that e ∈ s if event e occurs somewhere in trace s Denote by E∗ the set of all finite traces of elements of E, including the empty trace ε; the * operation is called the Kleene closure For example, if E = {e, f , g}, then E∗ = {ε, e, f , g, ee, ef , eg, fe, ff , fg, ge, gf , gg, eee, } A subset of E∗ is called a formal language over E, or simply a language 603 Fault Diagnosis of Manufacturing Systems Using Finite State Automata 21.2.2 AUTOMATA As was explained in Chapters and 10, the logical behaviour of discrete event systems, such as manufacturing systems, is naturally modelled by automata Automata can be thought of as directed graphs where nodes represent physical states of the system and arcs, which are labelled by event names, and represent discrete transitions of the states upon occurrence of the corresponding events The events can be internal events of the system (such as a command of a controller to move a part or a sensor that triggers when a part is moving along a conveyor) or exogenous events that represent the effect of the environment on the system (such as an operator pressing a switch) Automata are intuitive to use (when the number of states is small), and at the same time, they provide a mathematical formalism that is amenable to algorithmic analysis using software tools (when the number of states is large) We recall the formal definition of an automaton Automaton: A deterministic automaton, denoted by G, is a five-tuple G = (X, E, f , x0 , Xm ) where X is the set of states; E is the finite set of events associated with the system modelled by G; f : X × E → X is the transition function: f (x, e) = y means that there is a transition labelled by event e from state x to state y, also denoted by the transition triple (x, e, y) (in general, f is a partial function on its domain); x0 is the initial state; and Xm ⊆ X is the set of marked states A set of example automata is shown in Figure 21.1 representing a pump, a valve, and a controller These automata could represent a portion of a larger manufacturing system and will be employed as a running example through the chapter to illustrate some of the technical concepts being discussed Considering the valve model, the nominal behaviour of the valve is that it is initially closed (VC), where the initial state is indicated by the short arrow, and the valve transitions to its open position (VO) under the open valve command (ov) Likewise, the valve returns to the closed position under the close valve command (cv) This model also includes faulty behaviour in that the valve can transition to a stuck-closed (SC) or stuck-open (SO) state via the occurrence of fault events sc and so, respectively For simplicity, the pump model does not include any faulty behaviour and transitions between the pump off-state (POFF) and the pump-on state (PON) under the commands poff and pon, respectively The controller runs the system through the cycle of events: open valve, turn pump on, ov,cv poff pon pon SC sc POFF sc ov cv VC poff ov VO ov cv so PON C2 pon so C1 C3 SO cv ov,cv FIGURE 21.1 Automata models of valve, pump and controller C4 poff 604 Formal Methods in Manufacturing turn pump off and close valve Such a cycle could be initiated by a higher level controller where the material output of this subsystem is being employed for cooling or is feeding a larger manufacturing process In the earlier definition (and example), each automaton is said to be deterministic because the transition function has codomain X; in non-deterministic automata, the transition function would be defined as fnd : X × E → 2X (Given a set A, the notation 2A means the power set of A, i.e., the set of all subsets of A.) In words, each one of the previously mentioned automata is deterministic since the occurrence of an event completely determines the next state of the system, as there is only one transition for each event out of a given state It is customary to extend the transition function f of an automaton from domain X × E to domain X × E∗ in the following recursive manner: f (x, ε) := x f (x, se) := f (f (x, s), e) for s ∈ E∗ and e ∈ E Hereafter, we assume that f has been extended to traces Proper selection of which states to mark, that is, to include in Xm , is a modelling issue that depends on the problem of interest By designating certain states as marked, we may, for instance, be recording that the system, upon entering these states, has completed some operation or task The use of marked states is essential in analysis of deadlock and livelock in manufacturing systems modelled by automata In diagrams of automata, marked states are identified by double circles Marked states not play an explicit role in fault diagnosis; hence, in the remainder of this chapter, we shall often ignore Xm , except in the construction of verifier automata, where state marking is a convenient tool Moreover, while set X in the definition of an automaton could potentially be infinite, in this chapter, we will assume that X is finite; in this case, G is referred to as a finite-state automaton Automata are used to represent and manipulate languages The language generated by G = (X, E, f , x0 ) is defined as the set L(G) := {s ∈ E∗ : f (x0 , s) is defined} Considering the automaton that models the valve in Figure 21.1, this automaton generates the language {ov, sc, so, ov.cv, ov.sc, ov.so, ov.cv.ov, } By definition, language L(G) is prefix-closed, that is, for any trace s ∈ L(G), all the prefixes of s are also in L(G) Clearly, all the states of G that are not accessible or reachable from x0 by some trace in L(G) can be deleted without affecting L(G) Such states are therefore deleted from G When deleting a state, all the transitions that are attached (incoming or outgoing) to that state are also deleted This operation is denoted by Ac(G), where Ac stands for taking the accessible part of an automaton If G = Ac(G), then G is said to be accessible 21.2.3 PARALLEL COMPOSITION OF AUTOMATA Discrete event models of complex systems, such as manufacturing systems, are rarely built in a monolithic manner Instead, a modular approach is used where models of individual components are built first, followed by the composition of these models in order to obtain the model of the overall system The synchronization, or coupling, between components can be captured by the use of common events Namely, if components A and B both share event c, then event c should only occur if both A and B execute it The process of composing individual automata (which model interacting system components) in a manner that captures the synchronization constraints imposed by their common events is formalized by the parallel composition operation Consider deterministic automata G1 = (X1 , E1 , f1 , x01 ) and G2 = (X2 , E2 , f2 , x02 ) Assume that G1 and G2 are both accessible Let i : Xi → 2Ei be the feasible event function of Gi , defined as follows: 605 Fault Diagnosis of Manufacturing Systems Using Finite State Automata i (x), for x ∈ Xi , is the set of all events e ∈ Ei for which fi (x, e) is defined (recall that the transition function of an automaton is in general a partial function) Parallel composition: The parallel composition of G1 and G2 is the automaton G1 || G2 := Ac(X1 × X2 , E1 ∪ E2 , f , (x01 , x02 )) where ⎧ (f1 (x1 , e), f2 (x2 , e)) ⎪ ⎪ ⎨ (f1 (x1 , e), x2 ) f ((x1 , x2 ), e) := (x ⎪ , f2 (x2 , e)) ⎪ ⎩ undefined if e ∈ 1 (x1 ) ∩ 2 (x2 ) if e ∈ 1 (x1 ) \ E2 if e ∈ 2 (x2 ) \ E1 otherwise In the parallel composition, a common event, that is, an event in E1 ∩ E2 , can only be executed if the two automata both execute it simultaneously Thus, the two automata are synchronized on the common events The events in (E2 \ E1 ) ∪ (E1 \ E2 ), which are private as opposed to common, are not subject to such a constraint and can be executed whenever possible In summary, a component can execute its private events without the participation of the other component; however, a common event can only happen if both components can execute it The earlier definition is extended to more than two automata using associativity Consider the component automata for our example given in Figure 21.1 The resulting parallel composition of these three automata is displayed in Figure 21.2 After parallel composition, the states are triples with valve, pump and controller states as components The pump command events pon and poff from the controller are shared with the pump; therefore, they can only occur with the controller and pump synchronized This is reflected in the parallel composition of Figure 21.2 In the component controller model, event pon transitions the automaton from state C2 to state C3 sc VC,POFF,C1 so SO,POFF,C1 ov SC,POFF,C1 ov ov sc VO,POFF,C2 cv so pon SO,POFF,C2 cv SC,POFF,C2 pon pon sc VO,PON,C3 so poff SO,PON,C3 SC,PON,C3 poff poff sc VO,POFF,C4 so SO,POFF,C4 FIGURE 21.2 Parallel composition of valve, pump and controller automata SC,POFF,C4 cv 606 Formal Methods in Manufacturing In the component pump model, the same pon event transitions the automaton from state POFF to state PON The required synchronization in the parallel composition is captured by the fact that the pon event transitions the combined system model from states of the form (•,POFF,C2) to states of the form (•,PON,C3), where the state of the valve is inconsequential because it does not share the pon event Similar logic follows for the poff event, and in the case of synchronization between the controller and valve, the ov and cv commands The fault events sc and so, however, are private to the valve component model and hence can occur at any time, without participation of the other components 21.2.4 PROJECTION AND INVERSE PROJECTION In analysis of systems with observable and unobservable events, a common operation on traces and languages is the natural projection, or simply projection, from one set of events to a second one Let us consider two sets of events, denoted by Es and El , where Es ⊂ El ; in words, the set Es is contained in the larger set El Projections are denoted by the letter P; a subscript is typically added to specify either Es or both El and Es for the sake of clarity when dealing with multiple sets In the present discussion, we assume that the two sets El and Es are fixed and we use the letter P without subscript First, for traces of events, projection P is defined as follows: P : El∗ → Es∗ where P(ε) := ε  e P(e) := ε if e ∈ Es if e ∈ El \ Es P(se) := P(s)P(e) for s ∈ El∗ , e ∈ El In words, the projection operation takes a trace formed from events in the larger event set (El ) and erases those events in it that not belong to the smaller event set (Es ) ∗ The corresponding inverse map is P−1 : Es∗ → 2El and it is defined as follows: P−1 (t) := {s ∈ El∗ : P(s) = t} Thus, given a trace of events in the smaller event set (Es ), the inverse projection P−1 returns the set of all traces from the larger event set (El ) that project, under P, to the given trace Projection P and its inverse P−1 are extended to languages by simply applying them to all the traces in the language For L ⊆ El∗ , P(L) := {t ∈ Es∗ : (∃s ∈ L) [P(s) = t]} and for Ls ⊆ Es∗ , P−1 (Ls ) := {s ∈ El∗ : (∃t ∈ Ls ) [P(s) = t]} −1 It can be verified that Ps [P−1 s (L)] = L; however, in general, L ⊆ Ps [Ps (L)] Fault Diagnosis of Manufacturing Systems Using Finite State Automata 607 21.2.5 OBSERVABLE AND UNOBSERVABLE EVENTS The framework of discrete event system theory is able to address the notion of events being unobservable An event being unobservable implies that physically there is no sensor, or algorithm, for directly detecting the occurrence of that event In the context of this chapter, we are in particular interested in unobservable events that represent the occurrence of faults As we proceed, we will present a formal methodology for inferring the occurrence of these unobservable fault events based on the observation of events that can be seen Results also exist for formally synthesizing the control for discrete event systems in the presence of unobservable events, but that is beyond the scope of this chapter Consider the pump–valve–controller system example given earlier, where the composed system model is displayed in Figure 21.2 For this system, each command event is observable, Eo = {cv, ov, poff, pon} This is physically intuitive Since we are generating the command events, we will know when they occur The occurrence of a command event, however, does not guarantee that the corresponding action will take place For example, just because the open valve command ov is generated, that does not mean the valve will physically open If a fault event occurs, such as the valve becomes stuck-closed sc, then the valve will not actually open In the pump–valve–controller example, both fault events are considered unobservable, Euo = {sc, so} For the pump–valve–controller system as defined, the (unobservable) fault events cannot be inferred based on the generation of the (observable) command events This follows from the fact that the generation of a command event does not guarantee the corresponding action will occur In general, it is necessary for a system to include sensors in order for the occurrence of unobservable events to be inferred In the case of our running example, consider the addition of a flow sensor that is capable of generating discrete events that indicate that flow is either present, or not The addition of such a sensor may assist us in determining the occurrence of a fault event There are a few practical approaches for including such sensor information in a model One approach is to generate an automaton model for the sensor In the case of our flow sensor, if the pump is on and the valve is open, then the sensor will detect flow If the pump is off or the valve is closed, then the sensor will detect an absence of flow In this case, the sensor model would share events with the other system components, but the sensor outputs (flow, no flow) would be private to the sensor In order to formally employ these sensor outputs in the inference process, we would simply compose the sensor automaton with the other component automata Note that in this example we are implicitly assuming that the pump does not fail If a pump fault were possible, we would then need another sensor, for example, a pressure sensor A drawback of creating an automaton model for the sensor is that it leads to growth of the system model when it is composed with the other component models In this simple example, this would not be an issue, but as the number of components and sensors grows, the size of the entire system model could become prohibitively large An alternative approach is to create a sensor map Such an approach for this pump–valve–controller system is described in [4] The result of this analysis is the determination that if the pump is on and the valve is open, then the occurrence of a stuck-closed event will cause the sensor output to change from detecting flow to detecting no flow We capture this effect by adding the event f2nf and an additional state to the system model of Figure 21.2 Furthermore, the presence of the flow sensor allows us to distinguish the transition into state (SC,PON,C3) from the other two states of the form (•,PON,C3) since the flow sensor will indicate no flow when the valve is stuck-closed, even when the valve has been commanded open and the pump turned on This fact is captured by the addition of the observable event ponnf (pump on, no flow) The new system model incorporating information from the flow sensor is shown in Figure 21.3 where the new state is state 13 and the other states have been renamed to make the state names shorter Another more extensive manufacturing example is included at the end of this chapter where the sensors are modelled by their own automata 608 Formal Methods in Manufacturing sc so ov ov ov sc so pon pon 13 sc so cv ponnf poff f2nf poff cv poff cv sc 10 so 11 12 FIGURE 21.3 Pump–valve–controller automaton modified to include flow sensor information When the output of a sensor is being employed for control, some care must be taken to model the sensors correctly Often control decisions are made on the basis of a sensor reading Under such conditions, the event of polling a sensor should be distinguished from the event of the sensor output changing The reading of the sensor in general does not need to synchronize with the output change Furthermore, if multiple subsystems are polling the same sensor, their reading events not need to be synchronized either 21.3 ANALYSIS OF AUTOMATA WITH UNOBSERVABLE EVENTS When the total event set E is partitioned into observable and unobservable events, that is, E = Eo ∪Euo , we employ the natural projection P from (larger set) E to (smaller set) Eo : P : E∗ → Eo∗ We need to introduce the notion of unobservable reach of a state x ∈ X, which is denoted by UR(x) and defined as follows: ∗ ) [(f (x, t) = y)]} UR(x) = {y ∈ X : (∃t ∈ Euo (21.1) Note that x ∈ UR(x) by definition This definition is extended to sets of states B ⊆ X by UR(B) =  UR(x) (21.2) x∈B The concept of observer automaton is very useful in the analysis of partially observed systems The construction of observers is basically the same as the standard determinization process of non-deterministic automata in automata theory; it is explained next Fault Diagnosis of Manufacturing Systems Using Finite State Automata 609 21.3.1 OBSERVER AUTOMATA Let G = (X, E, f , x0 ) be a deterministic automaton and let E = Eo ∪ Euo The observer of G, denoted by Obs(G), is defined as Obs(G) = (Xobs , Eo , fobs , x0,obs ) and it is built as follows: Step 1: Define x0,obs := UR(x0 ) Set Xobs = {x0,obs } Step 2: For each B ∈ Xobs and e ∈ Eo , define fobs (B, e) := UR({x ∈ X : (∃xe ∈ B) [x = f (xe , e)]}) whenever f (xe , e) is defined for some xe ∈ B In this case, add the state fobs (B, e) to Xobs If f (xe , e) is not defined for any xe ∈ B, then fobs (B, e) is not defined Step 3: Repeat step until the entire accessible part of Obs(G) has been constructed By construction, the observer automaton Obs(G) is deterministic, and it generates the language L(Obs(G)) = P[L(G)] The states of Obs(G) capture the state estimates of G for the observed traces of L(G) Specifically, let B(t) ⊆ X be the state of Obs(G) that is reached after trace t ∈ P[L(G)] has been observed, that is, B(t) = fobs (x0,obs , t) Then x ∈ B(t) if and only if x is reachable in G by a trace in P−1 (t) ∩ L(G) Recall our pump–valve–controller system with flow sensor from Figure 21.3 Considering the initial state of the automaton in Figure 21.3, its unobservable reach consists of states 1, and 3, since ∗ Specifically, state is reached via those are states that can be reached via traces in the language Euo ε, state is reached via so and state is reached via sc Following the algorithm described earlier, the unobservable reach of state is then the initial state of the corresponding observer automaton, x0,obs = {1, 2, 3} Continuing with the algorithm, the only observable event defined for the states in x0,obs is the event ov Within the original automaton, the event ov takes state to state 4, state to state and state to state Since the union of the unobservable reach of each of states 4, and does not take the original automaton to any states beyond these three, the state of the observer automaton reached by ov is then {4, 5, 6} Continuing this process until the entire accessible part of the observer has been constructed leaves us with the observer automaton depicted in Figure 21.4 {3} {1,2,3} ov ov {6} {4,5,6} ponnf pon cv cv ponnf {7,8,9,13} poff {10,11,12} f2nf {9} poff {12} FIGURE 21.4 Observer automaton for the pump–valve–controller system with flow sensor 610 Formal Methods in Manufacturing As stated previously, the observer automaton will always be deterministic and each state of the observer provides an estimate of the state of the original automaton following the observation of a trace of events For example, if the trace ov.pon.poff is observed, then the underlying automaton is in state 10, 11 or 12 21.4 ONLINE DIAGNOSIS For simplicity of discussion, consider a single (unobservable) fault event f whose occurrence must be diagnosed at run time Every distinct fault event fi can be diagnosed individually in the same manner When diagnosing fault event fi , the other fault events, fj , j = i, are treated as unobservable events It is convenient to define the two languages: Lf := {s ∈ L(G) : f ∈ s} (21.3) Lnf := {s ∈ L(G) : f ∈ / s} (21.4) We refer to Lf as the faulty language and to Lnf as the non-faulty language The objective in online fault diagnosis is to determine, on the basis of the system model G and of the observed part t of the current system trajectry s, where P(s) = t, if the fault event to be diagnosed, f , has occurred or not in trace s Of course, s is not known by the diagnosing module; only t ∈ P[L(G)] and the structure of G are known At any given time during the operation of the system, there are three possible answers to the diagnosis question: (i) yes (ii) no and (iii) maybe The answer of the diagnosis module, which we shall call diagnoser, will be • Yes iff P−1 (t) ∩ L(G) ⊆ Lf • No iff P−1 (t) ∩ L(G) ⊆ Lnf • Maybe iff P−1 (t) ∩ L(G) ∩ Lf = ∅ and P−1 (t) ∩ L(G) ∩ Lnf = ∅ The observer automaton does not provide the answer to this question as it does not distinguish between traces in Lf and traces in Lnf when its state estimates are constructed To address this issue, we build a refined observer that records the previous occurrence of event f in the state estimates; the resulting automaton is called a diagnoser automaton 21.4.1 DIAGNOSER AUTOMATA To classify states of G in terms of their reachability from initial state x0 by traces in Lf and/or traces in Lnf , we employ a labelling mechanism that consists of two labels: (1) label Y associated with Lf and (2) label N associated with Lnf These labels are associated with states in the state estimates recorded by the diagnoser automaton The label of the initial state x0 is always N, since it is assumed that the fault event has not occurred when the system is turned on Once label N has been updated to Y due to a trace containing event f in reaching a particular state, the label will remain Y for all future reachable states of G from the current state, to record the fact that if s1 ∈ Lf and s1 s2 ∈ L(G), then s1 s2 ∈ Lf Namely, event f causes the label to change from N to Y, after which there is no further label change (This is because we are dealing with permanent faults The situation would be different if we were considering intermittent faults; more than two labels may be needed in that case.) We can capture this label propagation rule in the form of an automaton Consider the automaton in Figure 21.5 Let us refer to this automaton as the label automaton for diagnosing event f and denote it by Alabel := ({N, Y}, { f }, flabel , N) The state names in Alabel contain the label information To obtain the diagnoser automaton, which is denoted by Diag(G), we first compose G with Alabel by parallel composition and then we compute the observer in the usual manner: Diag(G) = Obs(G||Alabel ) (21.5) Fault Diagnosis of Manufacturing Systems Using Finite State Automata N f 611 f Y FIGURE 21.5 Label automaton for building diagnoser The parallel composition G||Alabel does not affect the language generated by G, since f is a common event and it can always be executed by Alabel However, the composition effectively attaches labels to the states of G as the states of G||Alabel are of the form (x, label), where label ∈ {N, Y}; we call the second component of the state pair the label of the first component The label attached to x will depend on the absence (N) or presence (Y) of f in traces that reach x from x0 State splitting will occur for those states of G that are reachable by traces that contain f and by traces that not / s1 and f ∈ s2 , then the two states contain f In other words, if f (x0 , s1 ) = x and f (x0 , s2 ) = x, with f ∈ (x, N) and (x, Y) will appear in G||Alabel After G||Alabel has been obtained, Diag(G) is obtained by constructing the observer, as described in Section 21.3.1 Based on our earlier discussion and on the construction of Diag(G), online diagnosis decisions are issued on the basis of the label(s) in the current state of Diag(G) with respect to the fault event under consideration: • If all the states of G in the state of Diag(G) have label Y, then the diagnosis decision is Yes In this case, the state of Diag(G) is said to be fault certain • If all the states of G in the current state of Diag(G) have label N, then the diagnosis decision is No In this case, the state of Diag(G) is said to be no-fault certain • If the current state of Diag(G) contains at least one state of G with label N and at least one state of G with label Y, then the diagnosis decision is Maybe In this case, the state of Diag(G) is said to be fault uncertain These decisions are a consequence of the state estimation property of observer automata Let xd be the current state of Diag(G) If (x, N) ∈ xd , then there exists s ∈ Lnf such that f (x0 , s) = x Similarly, if (x, Y) ∈ xd , then there exists s ∈ Lf such that f (x0 , s) = x In summary, to perform online diagnosis, we need to construct the diagnoser automaton off-line, store it and track its state online in response to the observed events monitored by the diagnoser The diagnostic decision is issued on the basis of the current state of Diag(G) It is also possible to construct the current state of the diagnoser automaton online from the structure of G||Alabel and the previous state of Diag(G) In such a scenario, one performs step of the algorithm in Section 21.3.1 for B(t) equal to the previous state of Diag(G) and e equal to the currently observed event This avoids the need to pre-compute and store the entire structure of Diag(G) (note that G||Alabel still needs to be stored), at the price of a small amount of computation to on the fly upon each observed event Recalling our pump–valve–controller example, let us construct a diagnoser for the stuck-closed fault sc The label automaton in this case has the same form as the automaton in Figure 21.5 where the f event is replaced by sc and the state labelled Y is replaced by a state labelled YSC, in order to distinguish this fault from a stuck-open fault Composing this label automaton with the automaton of Figure 21.3 and then constructing the observer produces the diagnoser automaton shown in Figure 21.6 This automaton has the same structure as the observer automaton of Figure 21.4, except that the state names now include labels Note that it is not generally true that the observer and diagnoser automata will be isomorphic Examining this diagnoser automaton, we can see that state {9YSC} is fault certain Following the observation of the trace ov.pon.f2nf, for example, the system is guaranteed to be in state and the stuck-closed fault sc is guaranteed to have occurred In other words, all traces in the language 612 Formal Methods in Manufacturing {3YSC} {1N,2N,3YSC} ov ov {4N,5N,6YSC} {6YSC} ponnf pon cv cv ponnf {7N,8N,9YSC,13YSC} f2nf poff {10N,11N,12YSC} {9YSC} poff {12YSC} FIGURE 21.6 Diagnoser automaton for the stuck-closed fault of the system that project to ov.pon.f2nf include the event sc On the other hand, state {10N, 11N, 12YSC} is fault uncertain Following the observation of the trace ov.pon.poff, one does not know if the event sc has occurred or not For example, the traces ov.pon.poff and ov.pon.sc.poff can both be generated by the system and both have the same projection, but the former does not include the fault event, while the latter does 21.5 DIAGNOSABILITY ANALYSIS The preceding discussion on online diagnosis leaves open the question of whether or not an occurrence of f will always be eventually diagnosed by Diag(G) The key word in this question is eventually Let sY ∈ Lf Then it is of the form sY = spre fstail The question is: how long can stail be until Diag(G) enters a fault-certain state? Note that stail contains both observable and unobservable events in general If G keeps executing unobservable events in stail , then no diagnosis can be performed as the state of Diag(G) never gets updated To preclude such situations, it is customary to assume that G has no cycles of unobservable events that are reachable after any occurrence of f This assumption guarantees that the number of unobservable events between any two observable events in stail is bounded We will assume that this assumption holds in the remainder of this section Another useful assumption is that of liveness of the language Lf ⊆ L(G) A language K is said to be live if for all s ∈ K, there exists t, |t| ≥ 1, such that st ∈ K We make this assumption for the sake of simplicity in the following discussion It ensures that events will keep occurring after f and that stail can be made arbitrarily long Formally, given any n ∈ N, we can always obtain |stail | > n In fact, since there are no cycles of unobservable events after f in G, we know that observable events will keep occurring as stail grows In view of the preceding discussion and assumptions, two scenarios are possible when Diag(G) tracks the observable events in stail , as stail grows arbitrarily long: (1) Diag(G) remains in faultuncertain states or (2) Diag(G) reaches (and stays in) fault-certain states The first case is not desirable as it implies that the given occurrence of f will never be diagnosed, even if Diag(G) tracks the system for an arbitrarily long number of events This leads us to defining the notion of diagnosability of a fault event in a given language Under the preceding assumptions, this definition is as follows: Fault Diagnosis of Manufacturing Systems Using Finite State Automata 613 Diagnosability: Fault event f is not diagnosable in L(G) w.r.t Eo if there exist two traces sN and sY in L(G) that satisfy the following three conditions: (i) sY ∈ Lf and sN ∈ Lnf (ii) sY is of arbitrarily long length after f (iii) P(sN ) = P(sY ) When no such pair of traces exists, f is said to be diagnosable in L(G) w.r.t Eo This definition captures the fact that when diagnosability holds, we are sure that if f occurs, then Diag(G) will enter a fault-certain state in a bounded number of events after the occurrence of f This is because Diag(G) has a finite set of states (since G is assumed to be finite state), and if Diag(G) were to loop forever in fault-uncertain states, then this would contradict the property of diagnosability, as it would imply the existence of a pair of traces sY and sN that satisfy conditions (i)–(iii) in the earlier definition The earlier definition is equivalent to the original one in [26], which explicitly employs the universal and existential quantifiers ∀ and ∃ and also allows for several fault events and types It is possible to use Diag(G) and G to determine if the property of diagnosability holds or not; this involves examining the cycles of fault-uncertain states in Diag(G), as they could imply a violation of diagnosability It turns out that not every cycle of uncertain states in Diag(G) implies a violation of diagnosability; for this reason, each such cycle must be examined individually to determine if it leads to the existence of a pair sY and sN associated with a violation of diagnosability Instead of pursuing this approach, we will present in Section 21.5.1 an alternative test that is based on the construction of an automaton whose state space is quadratic in terms of |X|, the cardinality of the state space of G; this automaton is called the verifier automaton (or simply, verifier) Consider the diagnoser, depicted in Figure 21.6, for the stuck-closed fault of our example system This diagnoser automaton includes a fault-uncertain cycle {1N, 2N, 3YSC} → {4N, 5N, 6YSC} → {7N, 8N, 9YSC, 13YSC} → {10N, 11N, 12YSC} → {1N, 2N, 3YSC} Examining the system model given in Figure 21.3, however, demonstrates that the system is actually diagnosable The underlying system can generate an arbitrarily long trace of events without the sc fault event that correspond to this cycle of the diagnoser; however, it cannot produce an arbitrarily long trace with the sc fault that corresponds to this cycle If the sc event occurs, then the system will eventually generate the ponnf event or the f2nf event which will cause the diagnoser to exit the identified fault-uncertain cycle Let us now consider the diagnosis of the stuck-open fault This diagnoser will employ a label automaton analogous to the one employed for the stuck-closed diagnoser, with the difference being that the fault f event in this case is so and the faulty label is YSO instead of YSC The diagnoser is constructed in the same manner described previously, an observer is built for the parallel composition of the system automaton and label automaton The resulting diagnoser is shown in Figure 21.7 This diagnoser automaton has the same form as the stuck-closed diagnoser, just with different labels The diagnoser of Figure 21.7 includes a fault-uncertain cycle similar to the one contained in the stuck-closed diagnoser, {1N, 2YSO, 3N} → {4N, 5YSO, 6N} → {7N, 8YSO, 9N, 13N} → {10N, 11YSO, 12N} → {1N, 2YSO, 3N} In this case, however, it turns out that the stuck-open fault so is not guaranteed to be diagnosed in finite time Looking back at the underlying system automaton, there exist arbitrarily long traces both with and without the so fault event that correspond to this cycle Specifically, the trace ov.pon.poff.cv does not include the fault event and can be repeated indefinitely The event so inserted at any point in this arbitrarily long trace can also be generated by the system Since these two traces have the same projection, the stuck-open fault so is not diagnosable In other words, it cannot be guaranteed that the so fault will be diagnosed in a finite time after its occurrence In this example, we built diagnosers for the two fault events separately, though both fault events could be addressed in a single diagnoser 614 Formal Methods in Manufacturing {1N,2YSO,3N} {3N} ov ov {6N} {4N,5YSO,6N} ponnf pon cv cv ponnf {7N,8YSO,9N,13N} f2nf poff {10N,11YSO,12N} {9N} poff {12N} FIGURE 21.7 Diagnoser automaton for the stuck-open fault One potential issue with the approach to testing diagnosability illustrated here is that the state space of the diagnoser automaton in the worst case grows exponentially with the number of states of the underlying system automaton Furthermore, diagnosability cannot be determined solely from the diagnoser automaton; the diagnoser automaton must be analysed with respect to the underlying system automaton An alternative approach to testing diagnosability that addresses these two issues is presented in the next section 21.5.1 VERIFIER AUTOMATA First, parallel to system model G, we build the so-called fault-free system model, which is obtained by deleting all f transitions in G and taking the accessible part after that We denote the result by Gnf and define it as Gnf = (Xnf , E, fnf , x0 ) By construction, L(Gnf ) = Lnf Let Eε = E ∪ {ε} The verifier automaton of G is denoted by Ver(G) Ver(G) is deterministic with a transition function involving event pairs It is defined according to the following construction procedure: Ver(G) := Ac((Xnf × X), Eε × Eε , fver , (x0 , x0 ), Xver,m ) where Xver,m is initialized to the empty set The accessible part in the definition is generated in terms of the transition function fver : (Xnf × X) × (Eε × Eε ) → (Xnf × X) which is defined as indicated in the following, with the following convention: a transition to a state pair is included whenever the indicated fnf (x1 , e) and/or f (x2 , e) on the right-hand side of the following equations is defined in the respective components of the state pair (x1 , x2 ): For e ∈ Eo : fver ((x1 , x2 ), (e, e)) = ( fnf (x1 , e), f (x2 , e)) (21.6) Fault Diagnosis of Manufacturing Systems Using Finite State Automata 615 For e ∈ Euo \ {f }: fver ((x1 , x2 ), (e, ε)) = ( fnf (x1 , e), x2 ) (21.7) fver ((x1 , x2 ), (ε, e)) = (x1 , f (x2 , e)) (21.8) fver ((x1 , x2 ), (ε, f )) = (x1 , f (x2 , f )) (21.9) For f : and add state (x1 , f (x2 , f )) to Xver,m The final step of the construction, after the entire accessible part of Ver(G) has been generated, is to enlarge the set of marked states Xver,m by performing its accessible-closure: add to Xver,m any state of Ver(G) that is reachable from a state in Xver,m , until no further state can be marked Some comments are in order First, the traces of event pairs that are in L(Ver(G)) represent two traces, the left trace sl and the right trace sr , respectively, formed by the left and right elements of the pairs Clearly, sl ∈ Lnf , sr ∈ L(G) and P(sl ) = P(sr ) Second, we adjoin a set of marked states Xver,m to the definition of the verifier By construction, a state of Ver(G) is marked if and only if it is reached from the initial state by a trace of event pairs that includes the pair (ε, f ) In other words, marked states record the fact that the right automaton has executed event f Consequently, by definition of fver , state (x1 , x2 ) ∈ Xver,m is reachable from the initial state (x0 , x0 ) if and only if there exists a trace pair (s1 , s2 ) with the following properties: s1 ∈ Lnf and s2 ∈ Lf P(s1 ) = P(s2 ) We conclude from these observations that fault event f is diagnosable in language L(G) w.r.t Eo if and only if Ver(G) does not contain a cycle of marked states For if such a cycle existed, trace s2 in the earlier argument could be made arbitrarily long, thereby violating the definition of diagnosability Conversely, when diagnosability is violated, any pair of traces (snf , sf ) that cause the violation of the property will lead to a cycle of marked states in Ver(G) In fact, the construction of Ver(G) could be halted as soon as a cycle of marked states has been detected Returning to our pump–valve–controller example, we will construct the verifier for the stuck-open fault In order to construct the fault-free system model, we begin with the automaton of Figure 21.3 and delete all occurrences of the so fault event States 2, 5, and 11 must then be deleted because they are no longer accessible The resulting fault-free model is shown in Figure 21.8 Next we can construct the verifier for the stuck open fault following the procedure from the beginning of this section We will illustrate this procedure by referring to the completed stuck-open verifier displayed in Figure 21.9 The initial state of the verifier is the state pair (1,1) consisting of the initial state of the fault-free system model and the initial state of the full system model We then construct the rest of the verifier state space employing the definition of the verifier transition function The first element of the definition of the verifier transition function (Equation 21.6) defines transitions consisting of pairs of observable events This equation leads to the construction of the cycle of verifier states (1, 1) → (4, 4) → (7, 7) → (10, 10) → (1, 1) The second element of the verifier transition function definition (Equation 21.7) addresses events that are unobservable but that are not the fault event being diagnosed In this case, the only event that fits this definition is the stuck-closed event, sc For example, beginning with the initial verifier state (1,1), event pair (ε, sc) leads to state (1,3) and event pair (sc, ε) leads to state (3,1) Subsequently, state (3,3) is reached from (1,3) via event pair (sc, ε) and from (3,1) via event pair (ε, sc) In each case, the left state and left event of any pair corresponds to the fault-free model, while the right state and right event of any pair corresponds to the full system model The third element of the verifier transition function 616 Formal Methods in Manufacturing sc ov ov sc ponnf pon sc 13 f2nf poff poff cv 10 sc cv 12 FIGURE 21.8 Fault-free system model for the stuck-open fault sc,ε ε,sc 1,1 1,2 ε,so ov,ov 3,2 sc,ε ov,ov ε,so ov,ov ε,sc 4,4 pon,pon 7,7 cv,cv 4,5 ε,so poff,poff cv,cv ε,so 13,8 7,8 ε,so sc,ε ε,so 10,11 ov,ov ε,sc 6,4 ε,sc sc,ε cv,cv cv,cv sc,ε 13,7 12,11 ε,sc ε,so cv,cv 10,12 ε,sc 6,6 ponnf,ponnf 13,13 f2nf,f2nf cv,cv 12,10 3,3 ov,ov ov,ov sc,ε sc,ε 4,6 7,13 sc,ε ε,sc poff,poff 3,1 sc,ε pon,pon ε,so 10,10 6,5 sc,ε 1,3 sc,ε ε,sc 9,9 poff,poff 12,12 sc,ε FIGURE 21.9 Verifier automaton for the stuck-open fault definition (Equation 21.9) addresses the unobservable fault event f for which diagnosability is being tested In this case, the fault event is so Again beginning with the initial verifier state (1,1), the event pair (ε, so) takes the verifier to state (1,2) This state is then marked (as indicated by the double circles) to indicate that it is reached by an event pair of the form (ε, f ) Repeated application of the verifier transition function definition leads to the construction of the remainder of the verifier Verifier states, such as (3,2), that are subsequently reached from marked states are also marked (state (3,2) is reached from state (1,2) in this case)