Simulation and analysis of discrete-event control systems based on Petri nets using PNetLab

ARTICLE IN PRESS

Control Engineering Practice 15 (2007) 241–259 www.elsevier.com/locate/conengprac

Simulation and analysis of discrete-event control systems based on Petri nets using PNetLab Francesco Basile, Ciro Carbone, Pasquale Chiacchio DIIIE, Universita` degli Studi di Salerno, Via Ponte Don Melillo, 1, 84084 Fisciano (SA), Italy Received 17 August 2005; accepted 10 July 2006 Available online 26 September 2006

Abstract Supervisory control based on Petri Nets (PNs) or Colored Petri Nets (CPNs) model of the plant leads to supervisors which can be PN/ CPN themselves (compiled supervisors) or simply a set of logical predicates (interpreted supervisors). There is a lack of simulation and analysis tools that can be used in both cases and can support the development of supervisors. In this paper PNetLab is presented, a simulation and analysis tool developed by the Automatic Control Group of the University of Salerno. It allows drawing of a PN/CPN model by a graphical user interface and the definition of the supervisor as a PN/CPN or as a standard C=C þ þ program implementing logical predicates. Functionalities to analyze the closed-loop model with all kinds of supervisors (PN/CPN/logical predicates) are available (token game and coverability tree) as well as standard functionalities when both the plant and the controller are PNs (P-invariants, T-invariants, minimal siphons and traps computation). In addition, PNetLab includes management of time (plant modelled by timed PNs/CPNs) and conflict management so as to permit testing of scheduling strategies together with the supervisor as required in performance optimization problems. Finally, the tool’s simulation engine can be linked from an external program allowing look-ahead supervisory techniques. The tool is available free of charge for interested readers. r 2006 Elsevier Ltd. All rights reserved. Keywords: Computer-aided control system design; Discrete-event systems; Petri-nets; Simulation; Supervisory control

1. Introduction 1.1. Literature background In supervisory control theory the plant to be controlled is composed by the physical system together with the low-level controllers, directly connected to the physical system, which permits the execution of simple activities. So the plant represents the behavior of the system-as-controlled and can be regarded as an event generator (Charbonnier, Alla, & David, 1999). Supervisory control theory for Discrete-Event Systems (DESs) was initiated by Ramadge and Wonham (1989). In their seminal work they represent both the plant—i.e. the system-as-controlled—and the desired closed-loop behavior, by regular languages. The specific problem addressed was to synthesize a higher-level controller, called supervisor, to achieve the largest subset of the desired language, disabling or enabling controllable events. The unwanted sequences may be related, for example, to safety requirements. Notice that the supervisor does not act directly on the physical system but on the low-level controllers. Although regular languages have been a useful framework to start such DES control theory, they are limited to represent systems consisting of numerous interacting subsystems. For this reason, a control theory for DES modelled by Petri Net (PN) (Murata, 1989) has been developed, extending general PN models with the concept of controllable transitions. In the Corresponding author. Tel.: +39 899 64400; fax: +39 6233227957.

E-mail addresses: [email protected] (F. Basile), [email protected] (C. Carbone). 0967-0661/$ - see front matter r 2006 Elsevier Ltd. All rights reserved. doi:10.1016/j.conengprac.2006.07.006

ARTICLE IN PRESS 242

F. Basile et al. / Control Engineering Practice 15 (2007) 241–259

supervisory control PN theory it is assumed that the set of transitions T of a net is partitioned into two disjoint subsets: T uc , the set of uncontrollable transitions, and T c , the set of controllable transitions. The Colored Petri Net (CPN) setting extends the framework of PN by adding color and modular attributes to the net (Jensen, 1995). The color attribute is developed to deal with systems having similar or redundant logical structures. Recently, in literature some results of supervisory control theory start to be extended to the CPN context (Giua, Fanti, & Seatzu, 2003, 2006). This means that a simulation tool oriented to supervisory control development must allow to design a PN/CPN plant model where controllable transition can be disabled by an external agent, the supervisor. In the case of a CPN plant model the supervisor must be capable of disabling only some occurrence color of a transition. In some supervisory control techniques it is required that the supervisor knows not only the generated events but also the state of the PN/CPN plant. This techniques lead to the so-called state-based supervisors (Holloway, Krogh, & Giua, 1997; Li & Wonham, 1994). This means that to permit analysis of systems with state-based supervisors, the simulation tool must make available the actual state of the plant to the supervisor. Moreover, time attributes could be added to PN or CPN models in order to allow time-based performance measures of the system and in this case they are, respectively, denoted Timed Petri Nets (TPNs) and Colored Timed Petri Nets (CTPN). The simulation tool must also manage these timed models so as to permit the testing of scheduling strategies together with the supervisory policies. To better clarify the importance of this point, notice that the closed-loop system (plant plus supervisor) may present conflicts (i.e. more than a transition is enabled but only one can effectively occur). Since real systems must be deterministic a scheduling strategy is required in addition to the supervisor. Normally, the scheduling strategy is based on performance indexes related to time. Then, a tool which permits an easy integration between scheduling strategies and supervisors could be useful to test the scheduling strategies. Although supervisory control based on PNs appeared in literature in the early 1990s, nowadays there is a lack of tools allowing the analysis and simulation of the plant (modelled as a PN/CPN) together with the supervisor/scheduler that can be a PN/CPN itself (compiled supervisor case) or a program implementing logical predicates (interpreted supervisor case). 1.2. Paper contribution In this paper PNetLab is presented, a simulation and analysis tool developed by the Automatic Control Group of the University of Salerno. It allows drawing of timed/untimed PN/CPN plant models by means of a Java Graphical User Interface (GUI) (Fig. 1). The definition of the supervisor as a PN/CPN or a standard C=C þ þ program is also possible. In both cases the supervisor can enable/disable controllable transitions in the plant model and has full access to the plant state. For the closed-loop system (plant plus supervisor) simulation is performed both in the timed and untimed case. Token game and computation of coverability tree is also possible. If both the plant and the supervisor are modelled as PNs,

Fig. 1. PNetLab GUI.

ARTICLE IN PRESS F. Basile et al. / Control Engineering Practice 15 (2007) 241–259

243

standard functionalities for analysis are available like computation of P-invariants, T-invariants, minimal siphons and traps. Additionally, these computations are also available as an object library that can be linked to supervisory and scheduling algorithms eventually requiring them, thus simplifying their development. The tool also considers non-deterministic systems by recognizing conflicts during system evolution and allowing selection (even casual selection) of the transitions to be enabled. Advanced supervisors and schedulers may require the use of look-ahead and what-if techniques; another interesting feature of PNetLab is that its simulation engine, without the graphical interface, can be linked to program implementing such supervisors/schedulers. Schedulers could not limit themselves to enable/disable transitions but could require forcing of a given state to the plant (i.e. forcing the low-level controllers to assume a given state). Obviously, such schedulers do not come from supervisory control theory but, nevertheless, can solve practical scheduling problems—see (Amato, Basile, Carbone, & Chiacchio, 2005; Carbone, 2005) for an example. PNetLab allows the supervisor/scheduler to impose the state to the plant. In fact, directly from PNetLab, by using primitive functions and variables that make accessible the net marking and conflicts management, it is possible to write a program implementing a scheduling strategy in C=C þ þ. Furthermore, directly from PNetLab, such a program is compiled together with the net modelling the plant behavior in order to test by simulation the effects of scheduling strategy on the plant. It is worth to remark that our simulation tool can help in testing scheduling strategies based on the actual state of the plant (state-based scheduler or real-time scheduler) rather than on statistical model. This new approach in scheduling is referred in technical literature as Manufacturing Execution System (Qiu & Zhou, 2004). For conciseness’ sake, it is not possible to report all the details of the tool. The purpose, here, is to show by examples how the tool can be effectively used in designing and testing supervisors and schedulers for DESs. The tool is available free of charge to interested readers and is downloadable from http://www.automatica.unisa.it together with all examples presented in the paper and the user manual. Three case studies related to industrial automation systems are presented and the C=C þ þ language is used to implement the interpreted controller. Since in industrial automation the IEC 1131 standard is assuming a primary role in the development of control systems, some considerations are in order:








The supervisory control theory and PNetLab can be applied to other fields (coordination of transport systems, workflow management, computer networks, etc.) than industrial automation where the IEC 1131 is not applicable. The subject of the paper is a simulator for DESs oriented to support supervisory control design. In industrial automation systems this kind of control is normally executed on general purpose machines that are not required to be IEC 1131 compliant. As a matter of fact, this kind of control can be regarded as a part of a supervisory control and data acquisition/Manufacturing Execution Systems (SCADA/MES) whose role is the coordination of other controllers, like PLCs. The tool is offered as a freeware to the scientific community. Then, a royalty-free compiler (as available for the C=C þ þ language) is used to integrate the control policy in the simulator (no IEC 1131-free compilers are available at the moment).

The paper is organized as follows. First, the features of the tools are presented. Then, its use in three case studies is presented starting from a PN plant with a non-PN supervisor (interpreted supervisor), then a CPN plant with a CPN supervisor (compiled supervisor). Finally, a timed CPN plant with a scheduler. In the last sections some details on the most innovative parts of the tools are given: the conflict management and the simulation algorithm. 2. Main PNetLab features It is here assumed that the reader already knows PN and CPN concepts and terminology as introduced in Murata (1989), Jensen (1995), and Girault and Valk (2003), anyway in the introduction of the next two sections some background material is briefly recalled for clearness’ sake. PNetLab is composed of many separate modules that cooperate in the construction and analysis of PN/CPN, timed or untimed, models by means of shared files. All the programs are written in C þ þ and Java programming languages, in order to guarantee efficiency and portability. The main features of the tool can be summarized as follows:




Graphical interface: Developed in Java, it allows the following functionalities:  Graphical model editing, including cut/copy and paste, selection and moving of objects or subnets, thus allowing the drawing of very large models.  Interactive token game for PNs (CPNs): enabled transitions by both plant and controller are highlighted and the user can decide their firing by mouse clicking.

ARTICLE IN PRESS F. Basile et al. / Control Engineering Practice 15 (2007) 241–259

244



















 Definition of deterministic or stochastic transitions timing, simulation parameters and conflict management options. Stochastic transition timing can be easily implemented—by C language code—by the user for each transition.  Integrated editor to write C þ þ supervisory and scheduling algorithms. Structural properties: For open-loop PN models (not for CPNs):  Computation of P- and T-invariants.  Computation of minimal siphons and traps.  Computations of pre-incidence, post-incidence and incidence matrices. These computations are also available as an object library that can be linked to supervisory and scheduling algorithms eventually requiring them, thus simplifying their development. Coverability tree: Can be computed both for open-loop and closed-loop systems. In the closed-loop case the supervisor can be a program. Simulation: PNetLab simulation engine has been developed in C þ þ and offers a very fast event-driven simulation; it works in cooperation with the graphical interface and provides interactive simulations with graphical animation of the model and movement of the tokens, step-by-step and off-line simulations, forward and backward time progression. Remarkably, the simulation works also when the supervisor is not a PN or CPN but it is a program implementing logical predicates. The simulation state is periodically saved on a xml file, so that previous simulation runs can be resumed at any time. Supervisory control oriented: PNetLab allows the integration of a PN/CPN model with a standard C=C þ þ control algorithm thus allowing closed-loop analysis and simulations of supervised systems. A boolean variable—whose value can be set by the supervisor—is associate to each transition (to each transition color) in the PN (CPN) plant model. It is also easy to integrate external tools for the solution of programming problems in order to implement very sophisticated supervisory control algorithms. For instance, a direct interface with Xpressr has been developed by Dash Optimization to include linear programming techniques in the supervisor. Conflict management: The closed-loop system (plant plus supervisor) can result in a non-deterministic system, i.e. more than one transition is enabled but only one can effectively occur. Since real systems must be deterministic a scheduling strategy is required in addition to the supervisor. To this purpose the tools recognize such conflicts and allow their resolution in different ways. Linkable simulation engine: The simulation engine, without the graphical interface, can be linked to a program allowing the development of supervisors and schedulers based on look-ahead and what-if techniques. State forcing: The supervisor/scheduler can enable/disable transitions and also impose a given state to the PN model of the plant. PNML: The tool supports the PNML standard which allows PN tools to exchange PN models—see Weber and Kindler (2003) and the web site http://www.informatik.hu-berlin.de/top/pnml/about.html for further details.

The tool has been registered into PN Tool Database at link http://www.informatik.uni-hamburg.de/TGI/PetriNets/ tools/db.html; on this web site an automatic and flexible comparison of PNetlab features with several other tools can be obtained. 3. Place/Transition net models In this section notations about Place/Transition (P/T) nets are briefly recalled and a classical example is used to show the effectiveness of PNetLab in analyzing a closed-loop model when an interpreted supervisor is adopted. 3.1. P/T net background It is assumed that the reader knows PN theory (Murata, 1989), only notations used in the Section 3.2 are recalled here. A P/T net is a structure N ¼ hP; T; Pre; Posti where P is a set of m places represented by circles, T is a set of n transitions represented by bars, P \ T ¼ ;, P [ Ta;, Pre (Post) is the j P j  j T j-sized, natural-valued, pre-(post-)incidence matrix and j P j (j T j) denotes the cardinality of the set of places (transitions). For instance, Preðp; tÞ ¼ w (Postðp; tÞ ¼ w) means that there is an arc from p (t) to t (p) with weight w. The incidence matrix C of the net is defined as C ¼ Post  Pre. A marking is an m  1 vector m : P ! N that assigns to each place of a P/T net a non-negative integer number of tokens. A P/T system or net system hN; m0 i is a P/T net N with an initial marking m0 . A transition t 2 T is enabled at a marking m iff mXPreð; tÞ. If t is enabled, then it may fire yielding a new marking m0 ¼ m þ Postð; tÞ  Preð; tÞ ¼ m þ Cð; tÞ. The notation m½t4m0 means that an enabled transition t may fire at m yielding m0 . A firing sequence from m0 is a (possibly empty) sequence of transitions s ¼ t1 . . . tk such that m0 ½t1 4m1 ½t2 4m2 . . . ½tk 4mk . A marking m is reachable in hN; m0 i iff there exists a firing sequence s such that m0 ½s4m. Given a net system hN; m0 i the set of reachable markings is denoted by

ARTICLE IN PRESS F. Basile et al. / Control Engineering Practice 15 (2007) 241–259

245

RðN; m0 Þ. The function r : T ! N, where rðtÞ represents the number of occurrences of t in s, is called firing count vector of the fireable sequence s. If m0 ½s4m, then it is possible to write in vector form m ¼ m0 þ Cð; tÞ  r. This is known as the state equation of the system. 3.2. Logical controller case study The example discussed in this section could be very useful to show the possibility to invoke—from the interpreted supervisor/scheduler—an external program, in this case an integer programming problem solver, which is equipped with an application program interface (API) for the operating environment where PNetLab runs (Windows, at present). This could be very useful for research and educational purposes. Assume that a set of legal markings L  Nm is given, and consider the basic control problem of designing a supervisor which restricts the reachability set of plant in closed loop to L \ RðN; m0 Þ. Of particular interest are those PN state-based control problems where the set of legal markings L is expressed by a set of nc linear inequality constraints called generalized mutual exclusion constraint (GMEC). A single GMEC is a couple ðl; kÞ where l : P ! Z is an m  1 weight vector and k 2 Z. Given the net system hN; m0 i, a GMEC defines a set of markings that will be called legal markings: Mðl; kÞ ¼ fm 2 Nm j l T mpkg. The markings that are not legal are called forbidden markings. It is assumed that the set of transitions T of a net is partitioned into two disjoint subsets: T uc , the set of uncontrollable transitions, and T c , the set of controllable transitions. A controllable transition may be disabled by the supervisor—a controlling agent which ensures that the behavior of the system is a legal one, i.e. it must ensure that the forbidden markings are not reached. In the paper the control variable function CV : T c ! f0; 1g is introduced; if CV ðtÞ ¼ 0, the controllable transition t is disabled, otherwise t is enabled. Thus, a maximally permissive supervisor must disable a controllable transition iff its firing would lead to a forbidden marking or to a marking from which a forbidden marking can be reached by firing only uncontrollable transitions. Let C uc and ruc be, respectively, the incidence matrix and the firing count vector of the uncontrollable subnet (i.e. obtained from the plant net by removing controllable transitions). When the plant net model is a PN, it has been shown in Li and Wonham (1994) that, if the critical subnet is acyclic, a maximally permissive supervisor must enable a transition t 2 T c under the net marking m iff m½t4m0 and the following logical predicate: l T m0 þ l T C uc ruc pk

(1)

is true for any ruc X0. Li and Wonham showed that to check if (1) is true for any ruc X0 is equivalent to evaluate if l T m0 þ l T C uc r¯ uc pk,

(2)

where r¯ uc is the solution of the following integer linear programming (ILP) problem: maxruc s:t:

l T C uc ruc ( C uc ruc pm0 ; ruc X0

ð3Þ

with variables ruc . Note that the ILP problem (3) is in the standard form maxx s:t:

cT x ( Axpb; xX0

ð4Þ

with constraint matrix A ¼ C uc , cT ¼ l T C uc , known term vector b ¼ m0 and variables x ¼ ruc . Thus, to enable a controllable transition t the controller has to perform the following operations: (a) compute the state marking m0 that the system would reach if t fires by applying the state equation; (b) solve the ILP problem (3); (c) evaluate the logical predicate (2). It is clear that such a supervisor consists of an algorithm, i.e. it is an interpreted supervisor. To simulate the closed-loop behavior, a simulator should make possible to write in a proper programming language the algorithm code, compile such a

ARTICLE IN PRESS F. Basile et al. / Control Engineering Practice 15 (2007) 241–259

246

code and execute it together with the plant net simulation. Furthermore, during the simulation the simulator should be interfaced with an ILP solver and must provide the current net marking to the algorithm. Consider the net in Fig. 1, and let mðp1 Þpb be a GMEC to be enforced on the net. From the control specification it results l ¼ ½1 0 0 0 0 0 0 0 0 0, b ¼ ½2. Assume that T uc ¼ ft1 ; t2 ; t3 ; t4 ; t5 g and T c ¼ ft6 ; t7 ; t8 g. By applying (2), under a certain net marking m, 8t 2 T c , it results CV ðtÞ ¼ 1 iff m½t4m0 and the logical predicate m0 ðp1 Þ þ maxðrðt2 ÞÞp2

(5)

is verified. The computation of maxðrðt2 ÞÞ requires the online solution of ILP (3). In Fig. 1 the enabled transitions are highlighted. Note that, the only enabled controllable transition is t7 while t8 is disabled by the controller since its firing would lead to a forbidden marking and t6 is disabled under the current net marking. See Algorithm 1 for an example of C þ þ implementation of the controller described in this example. Note that the user—from the C þ þ subroutine Controller()—can access the current net marking and change the control variable function value. PNetLab provides to the user several primitive functions and variables; some of them are described as follows:







mð:Þ: Function m(’p’) provides the current marking of place with label ’p’. Alternatively, m(i) provides the marking of the ði  1Þth drawn place. CV ½:: By assigning CV[i]=0 transition ti is disabled. nPlacesðÞðnTransðÞÞ: Number of places (transitions). matIncð:; :Þ: matInc(i,j) provides the element ði; jÞ of the incidence matrix associated to the drawn PN. For a complete list of primitive function and variables the reader can refer to the user manual of PNetLab.

Algorithm 1 (Logical case study C þ þ optimization algorithm). int nrow, ncol, nvgmec=1, i, j; nrow=nPlaces(); // Number of places ncol=nTrans(); // Number of transitions // Define the incidence matrix C and initialize it int  C=NULL; C=dmat_int(nrow, ncol, 0); // Define the constraint matrix Lgmec and initialize it int  Lgmec=NULL; Lgmec=dmat_int(nvgmec, nrow, 0); // Build the incidence matrix C by using // the PNetLab function matInc(i,j) for (i=0; ionrow; i++) for (j=0; joncol; j++) C[i][j]=matInc(i, j); // Build the constraint matrix Lgmec Lgmec[0][0]=1; // Define vector kgmec int kgmec[]=f 2g ; // In this example the GMEC is m(1)o=1 // Definition of the vector utran which specifies // the controllable and uncontrollable transitions // utran[i-1]=1 means that transition tj is uncontrollable int  utran=NULL; utran=dvet_int(ncol, 0); utran[0]=1; utran[5]=1; utran[6]=1; utran[7]=1; void Controller::controller(){ // Load the current PN marking by using function m(i) int  marking=NULL; marking=dvet_int(nrow, 0); for(i=1; i o= nrow; i++) marking[i-1]=m(i); // Call function mpli which performs operations ac

ARTICLE IN PRESS F. Basile et al. / Control Engineering Practice 15 (2007) 241–259

247

// for each controllable transition. // It evaluates for each controllable transition // the predicate (2) and the ILP problem (3) // by calling the external solver program Xpress r mpli(C, nrow, ncol, marking, Lgmec, kgmec,... nvgmec, utran, CV); g 4. CPN models In the following subsections, multiset definition and notations about CPNs are briefly recalled. In the literature different ways to define CPNs can be found depending on the way of defining incidence matrix and transition colors. Usually, only one formalism is available in a certain tool. PNetLab allows to define a CPN in two different ways. The main characteristics of CPN based on transition guards are recalled; this formalism makes CPN models easy to read. In addition, a CPN representation is recalled, where vectors and matrices of integer numbers only are necessary to represent CPN structure and to evaluate its evolution; this formalism is interesting for supervisory control research purposes, even if the CPN models result to be less readable. 4.1. Multiset Let D be a set. A multiset P (resp. non-negative multiset) a over D is defined by a mapping a : D ! Z (a : D ! N) and may be represented as a ¼ d2D aðdÞ d where the sum is limited to the elements such that aðdÞa0. Let ZðDÞ ðNðDÞÞ denote the set of all multisets (resp. non-negative multisets over D). The multiset e is the empty multiset such that for all d 2 D;
ðdÞ ¼ 0. A multiset can be represented by a vector a ¼ ½aðd 1 Þ aðd 2 Þ    aðd k ÞT 2 Zk . Given two multisets a; b 2 ZðDÞ and a number a 2 Z: the sum of a and b is denoted by c ¼ a þ b and is defined as 8d 2 D : gðdÞ ¼ aðdÞ þ bðdÞ. The difference of a and b is denoted by c ¼ a  b and is defined as 8d 2 D : gðdÞ ¼ aðdÞ  bðdÞ, thus the difference of two non-negative multisets may be negative. The product of a and a is denoted as c ¼ aa and is defined as 8d 2 D : gðdÞ ¼ aaðdÞ. apb means that 8d 2 D : aðdÞpbðdÞ. 4.2. CPN background A general definition of CPN is presented and in the next subsection the differences of the two formalisms available in PNetLab are discussed. A CPN is a bipartite directed graph represented by the 6-tuple N ¼ ðP; T; Pre; Post; Cl; CoÞ where P is the set of m places represented by circles, T is the set of n transitions represented by bars, Cl is the set of colors, Co : P [ T ! Cl is a color function that associates to each element in P [ T a non-empty ordered set of colors in the set of possible colors Cl. 8p 2 P; Coðpi Þ ¼ fai;1 ; ai;2 ; . . . ; ai;ui g  Cl is the ordered set of possible colors of tokens in pi , and ui is their number. 8t 2 T; Coðtj Þ ¼ fbj;1 ; bj;2 ; . . . ; bj;vj g  Cl is the ordered set of possible occurrence colors in tj , and vj is their number. Pre; Post 2 NðClÞjPjjTj are matrices such that Preðp; tÞ : CoðpÞ ! NðCoðtÞÞ and Postðp; tÞ : CoðtÞ ! NðCoðpÞÞ are mappings for each pair ðp; tÞ 2 P  T. Finally, C ¼ Post  Pre is called incidence matrix. For each place pi 2 P, the marking mi of a place pi is defined as a non-negative multiset over CoðPi Þ. The mapping mi : CoðPi Þ ! N associates to each possible tokenP color in Pi a non-negative integer representing the number of tokens of that color that is contained in place pi , and m ¼ d2Coðpi Þ mi ðdÞ d. The column vector of ui non-negative integers, whose hth component mi ðhÞ is equal to the number of tokens of color ai;h that are contained in pi , is denoted as mi . The marking of a CPN is an m-dimensional column vector of multisets, i.e. 2 3 m1 6 7 m ¼ 4    5. mm A CPN system hN; m0 i is a CPN with initial marking m0 .

ARTICLE IN PRESS 248

F. Basile et al. / Control Engineering Practice 15 (2007) 241–259

4.2.1. Representation of transitions by guards and incidence matrix by expression. In this formalism the incidence matrix is represented by using expressions containing variables; transition colors are not explicitly defined but they are implicitly defined via guard functions. Co : P ! Cl is a color function that associates to each element in P a non-empty ordered set of colors in the set of possible colors Cl. Thus, transition colors are not directly defined. To each transition t is associated a guard function denoted by GðtÞ, having boolean values, defined from t into expressions containing variables. These variables have types which usually are the colors of the places connected to the transitions. An assignment of values to variables such that GðtÞ ¼ 1 is called binding. The set of all possible bindings for a transition t is denoted as BðtÞ. Pre; Post are matrices such that each pair ðp; tÞ 2 P  T is mapped into an expression containing variables having types which are the colors of the place p. The value of the expression Preð; tÞ ðPostð; tÞÞ, after the value represented by the binding b has been assigned at each variable, is denoted by Preð; tÞ½b ðPostð; tÞ½bÞ. A transition t 2 T is enabled for binding b at a marking m iff mXPreð; tÞ½b. If an enabled transition t 2 T fires for binding b at a marking m it yields the marking m0 ¼ m þ Postð; tÞ½b Preð; tÞ½b ¼ m þ Cð; tÞ½b. When this representation is used, PNetLab represents each possible token color in a place p by a n-tuple hti ¼ ðc1 ; c2 ; . . . ; cn Þ, where cj is an integer; symbol (1) is used as black token, i.e. a token having no color. The following expression functions, used in pre-incidence and post-incidence entries (arc expressions) and guard functions, are defined: (i) prðp; c1 ; c2 ; . . . ; ck Þ: for each token hti in the place p the function builds a new token formed only by the specified components c1 ; c2 ; . . . ; ck of the token hti. (ii) concðht1 i; ht2 i; . . . ; htk iÞ: the function builds the new token ðht1 i; ht2 i; . . . ; htk iÞ formed by the concatenation of the specified components. (iii) id: this function selects all the components of a token. Fig. 2 shows the windows used in PNetLab for the setting of place, transition and arc parameters for CPNs with guards. 4.2.2. Representation of incidence matrix by matrices In this formalism incidence matrix entries are represented by matrices. Pre and Post are the pre-incidence and post-incidence m  n-sized matrices, respectively. Preðpi ; tj Þ is a mapping from the set of occurrence colors of tj to a non-negative multiset over the set of colors of pi , namely, Preðpi ; tj Þ : Coðtj Þ ! NðCoðpi ÞÞ, for i ¼ 1; . . . ; m and j ¼ 1; . . . ; n. In the sequel Preðpi ; tj Þ represents a matrix of ui  vj non-negative integers, whose generic element Preðpi ; tj Þðh; kÞ is equal to the weight of the arc from place pi w.r.t. color ai;h to transition tj w.r.t. color bj;k . Postðpi ; tj Þ : Coðtj Þ ! NðCoðpi ÞÞ, for i ¼ 1; . . . ; m and j ¼ 1; . . . ; n. In the sequel Postðpi ; tj Þ represents a matrix of ui  vj non-negative integers, whose generic element Postðpi ; tj Þðh; kÞ is equal to the weight of the arc from transition tj w.r.t. color bj;k to place pi w.r.t. color ai;h . The incidence matrix C is a m  n matrix, whose generic element Cðpi ; tj Þ : Coðtj Þ ! ZðCoðpi ÞÞ, for i ¼ 1; . . . ; m and j ¼ 1; . . . ; n, is the ui  vj matrix of integer number Cðpi ; tj Þ ¼ Postðpi ; tj Þ  Preðpi ; tj Þ.

Fig. 2. Windows for the setting of place, transition and arc parameters for CPN with guards.

ARTICLE IN PRESS F. Basile et al. / Control Engineering Practice 15 (2007) 241–259

249

A transition tj 2 T is enabled w.r.t. color bj;k at a marking m iff mi ðhÞXPreðpi ; tj Þðh; kÞ for each place pi 2 P and for all h ¼ 1; . . . ; ui . If an enabled transition tj 2 T fires at m w.r.t. color bj;k then the marking m0 is obtained where, for all pi 2 P and 8h ¼ 1; . . . ; ui ; m0i ðhÞ ¼ mi ðhÞ þPostðpi ; tj Þðh; kÞ  Preðpi ; tj Þðh; kÞ. Fig. 3 shows the windows used in PNetLab for the setting of place, transition and arc parameters for CPNs without guards. 4.3. A manufacturing example This subsection shows—via a manufacturing example—the difference between the two formalisms available in PNetLab for CPN models as shown in Figs. 4 and 5. Consider a plant formed by two machines ðM1; M2Þ and one robot R. An unlimited source of raw parts is assumed for each machine. Raw parts are moved on pallets and they can be of four different types (type1, type2, type3, type4). Four pallets are available for each machine. Each machine can process each raw part type and it is equipped with two different tools. A tool is used for raw parts of type1 and type2 and another one is used for raw parts of type3 and type4. A machine can process two parts at a time only if they require different machine tools. The robot is used to load raw part from the raw part buffer to the machine input buffer, which is assumed to have capacity one. If the machine is not busy and the right tool is available the part starts to be processed. At the end of the processing phase the tool is released, then the finished part is unloaded from the pallet and the pallet is loaded with a raw part of the same type; these activities are modelled as a unique event. Assume that the plant is controlled. The work flow of the two machines can be described by the CPN in Fig. 4 or in Fig. 5—except for dashed places and arcs—depending on which type of CPN representation is chosen. The net in Fig. 4 is interesting for supervisory control research purposes thanks to matrix representation of pre-incidence and post-incidence matrix, while the net in Fig. 5 is easier to read thanks to guard functions. Anyway, their behavior is equivalent. In Tables 1 and 2 the description of places and transitions of both nets are reported. Transitions t1 , t3 , t6 , t8 are supposed to be controllable and transitions t2 , t4 , t5 , t7 , t9 , t10 are supposed to be uncontrollable. Since in the plant there are four part types, each place has four token colors denoted by c1 , c2 , c3 and c4 . If the formalism without guards and expressions is used, each transition has four occurrence colors and the net in Fig. 4 models the system where the only non-null matrices Pre and Post are those reported. For this formalism, a transition tj is said to be uncontrollable w.r.t. the color bj;k if its firing w.r.t. to the color bj;k cannot be disabled by an external agent, otherwise tj is said to be controllable w.r.t. the color bj;k . If a transition tj is controllable (uncontrollable) w.r.t. all its colors, tj is said to be controllable (uncontrollable). Since this paper is not focused on supervisory control theory, it has been preferred to consider a transition simply controllable or uncontrollable. Otherwise, if the formalism with guards and expressions is used, the net in Fig. 5 is obtained where all transitions with exception of t3 , t8 has guard functions always true. For this formalism, the concept of controllable transition has not been introduced in the literature. Probably, it could be referred with respect to the bindings. Now, consider the problem of enforcing, only by eventually disabling controllable transitions, the following constraints on the net: P4 P4 (1) Pi¼1 m12 ðci Þ þP i¼1 m13 ðci Þp2 (M1 capacity is two). 4 4 (2) Pi¼1 m4 ðci Þ þ Pi¼1 m5 ðci Þp2 (M2 capacity is two). 4 4 (3) i¼1 m10 ðci Þ þ i¼1 m11 ðci Þp1 (robot starts raw part transfer if M1 input buffer is free).

Fig. 3. Windows for the setting of place, transition and arc parameters for CPN without guards.

ARTICLE IN PRESS 250

F. Basile et al. / Control Engineering Practice 15 (2007) 241–259

Fig. 4. A colored Petri net model without guards.

P4 P4 (4) Pi¼1 m2 ðci Þ þ Pi¼1 m3 ðci Þp1 (robot starts raw part transfer if M2 input buffer is free). (5) 4i¼1 m10 ðci Þ þ 4i¼1 m2 ðci Þp1 (robot capacity is one). When the supervisor is modelled by a PN structure, the disabling of transition t under the color bj;k is possible if there is an input arc of transition t having weight different from zero w.r.t. color bj;k . This is why if a transition tj is uncontrollable w.r.t. color bj;k it is required that Preðpc ; tj Þð; bj;k Þ ¼ e where ps is a supervisor place, since the occurrence of the transition under color bj;k cannot be forbidden. It is immediate to verify that all places of the considered supervisor, reported and dashed circles in Fig. 4, verify this property. By following the technique shown in Giua and Seatzu (2004) it is possible to compute the pre- and postincidence matrices of control places p14 , p15 ðp6 ; p7 Þ (drawn as dashed circle in Fig. 4) and their initial marking to impose the constraints 1–4 and of the place p17 needed to impose the constraint 5. Notice that place p17 and places p14 , p15 ðp6 ; p7 Þ have one token color (named c5 ) since they simply model resources availability. Finally, places p16 ðp8 Þ can be computed by the same technique to allow a raw part processing on machine M1 (M2) if the right tool is available. These places have two token colors (named c6 and c7 ) since each machine has two different tools. Analogously, even if there is no systematic methodology, for the net in Fig. 5 it is possible to devise control places (drawn as dashed circle in Fig. 5) and related guards and arc expressions so that the behavior of the net systems in Figs. 4 and 5 is equivalent. In general, it is not possible to implement as a colored subnet the supervisor, and it has to be implemented as a program. PNetLab offers several primitive functions and variables to implement in C=C þ þ code a supervisor for CPN models and it allows the possibility to simulate the closed-loop behavior when interpreted supervisors are adopted.

ARTICLE IN PRESS F. Basile et al. / Control Engineering Practice 15 (2007) 241–259

<1> <2><3> <4>

P9

P1

<1> <3> <2> <4>

1

1 t6

1

pr(9,1)

1

P10

t1

1

pr(1,1)

P17

<5>

P14 <5>

1 P2

P6 1

1

t7

{5}

pr(10,1)

{5}

t2

pr(2,1)

P11

P3

{5}

{5} 1

1

g8 a2

t8

1 <6> <7> P16

P12 1

<5> <5>

1

g3

t3

a1

<6> P8 <7>

P4 1

1

pr(12,2)

t9

P15

<5>

1

pr(4,2)

t4

pr(12,1)

pr(4,1)

P13

P5

{5}

1

1 t10 pr(13,1) g3=((pr(3,1)==1 || pr(3,1)==2) & (pr(8,1)==6)) || ((pr(3,1)==3 || pr(3,1)==4) & (pr(8,1)==7))

P7 <5> <5>

{5}

t5 pr(5,1) a1=conc[pr(3,1); pr(8,1)] a2=conc[pr(11,1); pr(16,1)]

g8=((pr(11,1)==1 || pr(11,1)==2) & (pr(16,1)==6)) || ((pr(11,1)==3 || pr(11,1)==4) & (pr(16,1)==7))

Fig. 5. A colored Petri net model with guards having the same behavior of the model in Fig. 4.

Table 1 Transitions description of models in Figs. 4 and 5 Name

Description

t6 ðt1 Þ t7 ðt2 Þ t8 ðt3 Þ t9 ðt4 Þ t10 ðt5 Þ

Start of M1 (M2) input buffer loading A raw part has been loaded on M1 (M2) input buffer M1 (M2) starts processing a raw part A raw part has been processed by M1 (M2) A finished part has been moved from M1 (M2) and its pallet has been replaced with a raw part of the same type

Table 2 Places description of models in Figs. 4 and 5 Name

Description

p9 ðp1 Þ p10 ðp12 Þ p11 ðp3 Þ p12 ðp4 Þ p13 ðp5 Þ

Presence of a pallet with a raw part in M1 (M2) raw part buffer Robot is transferring a raw part on M1 (M2) input buffer Presence of a pallet with a raw part in M1 (M2) input buffer M1 (M2) is processing a raw part Presence of a pallet with a raw part in machine M1 (M2)

251

ARTICLE IN PRESS 252

F. Basile et al. / Control Engineering Practice 15 (2007) 241–259

(a)

(b)

(c)

(d)

Fig. 6. Example used to discuss infinite server semantic.

5. TPN models The introduction of a timing specification is essential in order to use PN models for performance evaluation of distributed systems. Nets with deterministic timing1 and one phase firing rule, i.e. a timed enabling (called the service time of the transition) followed by an atomic firing, are considered here. Service times of transitions are supposed to be mutually independent and time independent. As for P/T nets a time function f : T ! R is introduced, which associates to each transition t 2 T the delay time from enabling to firing. As to CPN nets with guards a time function f : BðtÞ ! R is introduced, which associates to each possible binding of a transition t the delay time from the enabling to the firing of transition t. As for CPN nets without guards, instead, a time function f : CoðtÞ ! R is introduced, which associates to each occurrence colors of a transition t the delay time the enabling to the firing of a transition under a certain occurrence colors. In all cases, if necessary, the delay time may not be a real constant and it can be specified by user-defined function in standard C=C þ þ syntax. After a time function has been introduced, PN models and CPN models take, respectively, the name of TPNs and CTPNs. PNetLab is able to deal with infinite server semantic transitions, from the point of view of the queueing theory. Remind that for an infinite server transition, infinite instances of a same transition can work in parallel at a given marking. This means that such a transition has as many servers as the number of tokens in its incoming places. A k-server transition t can easily be obtained from an infinite server one by adding a self-loop place around t with k tokens (Campos & Silva, 1992). In order to explain how PNetLab deals with infinite server transitions, consider the simple net system shown in Fig. 6(a). Let transition t2 be infinite server, with deterministic firing time equal to 5 s. Markings represented in Fig. 6(b)–(d) are obtained, respectively, at time instant 2, 5 and 7 s. Note that if transition t2 is not infinite server, the marking in Fig. 6(d) is obtained at time instant 10 s. 5.1. A scheduler for the crane/aisle system In this section the possibility of using PNetLab to validate scheduler algorithms for complex systems is shown. For these systems, when a real-time2 scheduling policy has to be designed, the computer simulation is often the only tool available to test its performance. However, a scheduling policy can be usually implemented as a program and often the interaction with the plant consists of complex actions that cannot be modelled as transition enabling signals. At this aim, in addition to the PNetLab functions presented in Section 3.2, it is worthwhile to cite addToken(.) (delToken(.)) and compToken(.), used to add a token to (remove a token from) a place and extract a specific token component. The implementation of a scheduling policy to optimize a crane/aisle system is discussed here (for further details, see Amato et al., 2005; Carbone, 2005). A crane/aisle system is an important component of a modern automated warehouse, which consists of a number of aisles, each one served by a crane, shuttles, picking/refilling positions and in/out buffers. On both sides of each aisle there is a storage rack composed of a number of storage locations for the stock units (SUs). Each crane can move both horizontally and vertically at the same time, and performs the following operations: (i) picking of the SU to be stored at the buffer input of the aisle, referred as the input/output (I/O) point of the aisle; (ii) storage of the SU into the assigned location S of the rack; (iii) movement to location R where a retrieval has been requested; (iv) retrieval of the SU stored in R; (v) coming back to the I/O point. This set of operations is called, in the warehousing system context, a dual command (DC) machine cycle. 1 2

The user can easily associate to each transition a stochastic firing delay by writing few C=C þ þ code lines. Based on the current state of the plant.

ARTICLE IN PRESS F. Basile et al. / Control Engineering Practice 15 (2007) 241–259

253

Fig. 7. PNetLab GUI showing the C þ þ optimization algorithm for the crane/aisle CTPN model.

It is assumed that each SU arrives at the I/O point with the storage location already assigned. Thus, the only degree of freedom, in the optimization procedure, is the clever sequencing of the retrieval orders. The approach followed can be roughly described as follows: consider a list of N C storage and retrieval orders; optimize the sequencing of the N C retrievals; when the N C DCs have been performed consider a new list of N C orders and repeat the same procedure. In order to describe Algorithm 2 proposed below, denote by R the set composed of the retrieval location addresses, by S the ordered list of storage location addresses and by N C the cardinality of R and S. Remind that, given two points P1 ¼ ðx1 ; y1 Þ and P2 ¼ ðx2 ; y2 Þ, the Chebichev distance d C ðP1 ; P2 Þ between P1 and P2 is defined as d C ðP1 ; P2 Þ:¼ maxfjx1  x2 j; jy1  y2 jg.

(6)

The Chebichev metric has been used since the crane moves simultaneously in both directions. Algorithm 2 (Crane/aisle optimization). begin repeat
Take the first element s 2 S;
Select r 2 R with the minimum distance from s measured by the Chebichev metric;
Perform the DC cycle with storage in s and retrieval from r;
Update: R ¼ R  frg, S ¼ S  fsg; until ðR ¼ ;Þ; end. Algorithm 3 represents a possible C þ þ implementation of Algorithm 2. Fig. 7 shows the CTPN crane/aisle model together with the editor window for the controller C þ þ code, in the PNetLab integrated environment, thus the simulation of the closed-loop model can be performed. Place p1 contains the list of storage/retrieval orders for the crane (S [ R), exactly as they are generated from an external tokens generator.3 Each colored token (see Fig. 7) represents a crane order, having format (Op,x,y,z,w,IDpallet); each token component has the following meaning:




3

Op—Operation type (Op ¼ 1: storage, Op ¼ 2: retrieval). x,y,z,w—Rack coordinates. IDpallet—Pallet identification number. Actually, in this example orders are simply assigned as initial marking, without using any token generator.

ARTICLE IN PRESS 254

F. Basile et al. / Control Engineering Practice 15 (2007) 241–259

All tokens—as soon as they arrive in place p1 —are removed from place p1 and stored into the list CraneOrders. This temporary list4 is used to resort all crane orders, according to Algorithm 2. Afterwards, the CraneOrders content is added to place p1 and each token is served with a FIFO policy. At the end of the simulation a report file is produced. This file contains all the markings occurred during the simulation. The transition between two markings is labelled with the firing time and with the triggering events. By analyzing this file it is possible to evaluate the performance of an algorithm, for instance it is possible to calculate the throughput of the plant. Algorithm 3 (Crane/aisle C þ þ optimization algorithm). void Controller::controller()f bool Idle = (m(‘‘p9’’)40); int NT = m(‘‘p1’’); if ((Idle) &&(NT40))f // If the Crane is idle and there is at least one mission... CTOrder OrdT; SLinkListoCTOrder4CraneOrders; // [Op jx jy jz jw jIDMission] for (int i=1; io=NT; i++)f // Extract all tokens from place p1 and put them in the CraneOrders list // by using the PNetLab function compToken(place, token index, token component) OrdT.set(compToken(‘‘p1’’,1,1),compToken(‘‘p1’’,1,2),compToken(‘‘p1’’,1,3), compToken(‘‘p1’’,1,4),y ycompToken(‘‘p1’’,1,5),compToken(‘‘p1’’,1,6)); CraneOrders.ADD(OrdT); delToken(‘‘p1’’,1); // Remove the first token from place p1 g // Choose the‘‘minimal distance’’ mission for the Crane SLinkListoint4Xpre, Ypre; for (int j=1; jo=CraneOrders.size; j++) f Xpre.ADD((CraneOrders.n(j).Order[1]) (CraneOrders.n(j).Order[0]!=1)); Ypre.ADD((CraneOrders.n(j).Order[2]) (CraneOrders.n(j).Order[0]!=1)); g int i_Tmin = MinDist(x0traslo[0], y0traslo[0], Xpre, Ypre); int token[6] = f CraneOrders.n(i_Tmin).Order[0],CraneOrders.n(i_Tmin).Order[1],CraneOrders. nði_TminÞ:Order½2; . . . ...CraneOrders.n(i_Tmin).Order[3],CraneOrders.n(i_Tmin).Order[4],CraneOrders.n(i_Tmin). Order½5g; addToken(‘‘p1’’,token); // Append the token ‘‘token’’ at the end of the place p1 for (int j=1; jo=CraneOrders.size; j++) if (j!=i_Tmin)f int token[6] = f CraneOrders.n(j).Order[0],CraneOrders.n(j).Order[1],CraneOrders.n(j). Order½2; . . . ...CraneOrders.n(j).Order[3],CraneOrders.n(j).Order[4],CraneOrders.n(j).Order[5]g ; addToken(‘‘p1’’,token); g g g

6. Conflict management A conflict is a situation where not all that is enabled can occur at once (Recalde, Teruel, & Silva, 1998). More formally, t; t0 2 T are in effective conflict relation at marking m iff there exist k; k0 2 N such that mXk  Preð; tÞ ^ mXk0  Preð; t0 Þ, but màk  Preð; tÞ þ k0  Preð; t0 Þ. A necessary condition for the effective conflict is that
t\
t0 a;, and in this case t and t0 are said to be structural conflict relation. The structural conflict relation (or choice) is a structural pre-requisite for the behavioral property of conflict. PNetLab is able to recognize structural conflicts autonomously. As a consequence, during 4 CraneOrders is an object of a class pre-defined by the user. This is an important feature of PNetLab: it is very simple to include all the needed C þ þ classes and libraries.

ARTICLE IN PRESS F. Basile et al. / Control Engineering Practice 15 (2007) 241–259

255

the net compiling phase, it builds a proper data structure of such structural conflict transitions which will be queried at run time. In timed models, in order to avoid the coupling between resolution of conflicts and duration of activities,5 transitions in conflict are supposed to be immediate except for timed transitions modelling a watchdog timer or immediate transitions modelling a failure detection; only in these special cases it can be accepted that a timed transition—modelling a watchdog timer—can interrupt another timed transition or that an immediate transition—modelling an error detection process—can be in conflict with a timed transition. In CPN models with guards also conflicts between bindings may arise. In PNetLab the following solution has been adopted. There is no need to remove tokens from a place in the same order as they were added. However, when the tokens contained in a place represent SUs, it is important to preserve the incoming order for their removing. Therefore, each place is assumed to be a queuing place, with a FIFO policy. Hence, no conflict among bindings may arise. In CPN models without guards different occurrence colors of a transition are considered as different transitions. PNetLab manages conflicts by using the following resolution policies according to step S2 in Algorithm 4, described afterwards:









Predefined scheduling order: When this conflict management policy is selected, PNetLab assigns a sort of static priority to the transitions in conflict, based on the order in which they have been drawn. Same firing rates: Transitions in conflict relation have the same firing probability. Stochastic firing rates: The conflict resolution between transitions can be obtained by using routing rates (Campos & Silva, 1992). Let T 0 ¼ ft1 ; . . . ; tk g T be in structural conflict (i.e. having equal pre-incidence function: Preð:; t1 Þ ¼    ¼ Preð:; tk Þ). The constants r1 ; . . . ; rk 2 Nþ (routing rates) are explicitly defined in the net interpretation P in such a way that when t1 ; . . . ; tk are enabled, transition ti 2 T 0 fires with probability ri =ð kj¼1 rj Þ (or with long run rate, in the case of deterministic conflicts resolution policy). In Fig. 2 it is possible to note a dedicated box in the transition window for the routing rate input. Controller: When an effective conflict arises during the simulation, the subroutine Controller is called in order to solve the conflict. In this case the conflict resolution is charged to the user, who has the responsibility of programming the proper conflict resolution policy. At this aim, the user can gain the access to the list of the groups of transitions in effective conflict, by means of a suitable dynamic data structure (extern int **runtimeConflict).

The user can choose the desired conflict resolution policy in the simulation parameters window (see Fig. 8). Moreover, in order to avoid unpredictable behaviors from PNetLab, confusions (Fig. 9) have to be excluded. 7. The simulation algorithm DESs simulation can be realized by a very general scheme, named event scheduling scheme and described in Cassandras and Lafortune (1999). The event scheduling scheme should be thought as a procedure for generating sample paths based on the used DES model and driven by a given clock structure. The core is represented by the scheduled event list (SEL) which contains all enabled transitions at the current state, which are always sorted on a smallest-scheduled-time-first. This means that the next transition is always the first element of the SEL, with the associated firing time. It causes updates to state and time. Hence, based on the new value of the state, some of the enabled transitions fire while other transitions are enabled. Once a transition is enabled, it is entered in the SEL with its scheduled firing times, maintaining the right sorting order. The SEL used in PNetLab (see Fig. 10) is a dynamic data structure, implemented as a double linked list of nelem elements; each row contains the index of the enabled transition (item event in Fig. 10), the corresponding firing time (item time) and a list of nt token indexes (item listid) which have been reserved into the incoming places and that will be removed after the firing (reserved tokens6). Assigned the maximum number of simulation steps N S , time interval ½tmin ; tmax  and the initial marking (state), PNetLab runs Algorithm 4. When the Petri net is untimed, t is always equal to tmin and the simulation ends either if the number of simulation steps exceeds N S or if there are no events left in the SEL. It is important to notice that, before firing all the enabled transitions at the current simulation step, the Controller subroutine is always called thus eventually disabling those transitions that could lead to a forbidden marking and/or solving conflicts among transitions. 5

When a timed activity is associated with transitions, a conflict resolution policy may be a race between conflicting transitions, which makes no sense in presence of a physical plant. 6 PNetLab works by reserving in places all the tokens that enable a transition.

ARTICLE IN PRESS 256

F. Basile et al. / Control Engineering Practice 15 (2007) 241–259

Fig. 8. PNetLab window for the setting of the simulation parameters.

p1

p2

t1

t2

t3

Fig. 9. PNetLab does not admit confusions.

event time succ prev tokens

nt

event time succ prev tokens

listid ......

NULL

nt

listid ......

nelem end begin event time succ prev tokens

nt

listid ......

event time succ prev tokens NULL

nt

listid ......

Fig. 10. Structure of the scheduling event list implemented in PNetLab.

Notice also that when the conflict resolution policy chosen by the user is by controller, step S2 is jumped and the conflict resolution is carried out in step S3. At step S4, the infeasible transitions are those enabled transitions which have been disabled by the conflict resolution module or by the controller. In this case, it is necessary to release the corresponding reserved tokens, ready to be removed after the firing.

ARTICLE IN PRESS F. Basile et al. / Control Engineering Practice 15 (2007) 241–259

257

At each simulation step k some transitions are added or removed from the SEL. Then, the minimum firing time of transitions which are in the SEL at the current simulation step denoted as tfire has to be computed. Algorithm 4 (PNetLab simulation algorithm). begin k = 1; t ¼ tmin ; repeat S1: Add to SEL all the enabled transitions with the corresponding firing times and reserve tokens in the incoming places; S2: Solve conflicts according to the chosen resolution policy; S3: Call the Controller subroutine; S4: Remove all infeasible transitions from the SEL and release the associated reserved tokens; S5: Compute tfire . S6: Pull all the transitions having firing time tfire out of the SEL; S7: Fire all transitions considered in step S5 and update the state; t=tfire ; k = k+1; until ðSEL ¼ ;Þ or ðt4tmax Þ or ðk4N S Þ; end.

8. PNetLab architecture In this section the software architecture of PNetLab is presented (see Fig. 11). PNetLab offers the possibility of compiling the PN model together with a given optimization algorithm, in order to simulate the closed-loop system and analyze its performance. For brevity’s sake, PNetLab architecture is explained referring to CTPN with guards, since this is the more complex case. Starting from a CTPN drawn by using the graphical interface, the module Build_Model produces a formal representation in .xml format of the PN (CTPN) model in terms of pre–post-incidence matrices (PNmodel), guard and arc functions (Guard, ArcFunctions), time functions associated to timed transitions (TimeFunctions) and a file (NetParameters) of the model parameters. Then, two modules (Arc_Expr and Trans_Expr) are used to translate ArcFunctions, Guard and TimeFunctions in C þ þ source code files. These files are compiled and linked together with the optimization algorithm (files Controller.cpp and Controller.h) in order to produce a single executable file Simulator. By running Simulator it is possible to simulate the closed-loop system (PN model plus control algorithm) and analyze its performance. At the end of the simulation, the results are available in appropriate report files and can be shown in the graphical interface. File Simulator.exe is made up of compiled C þ þ code of a CTPN modelling the plant (with or without a controller) and the simulation engine. It accepts an initial marking as input—representing a certain state of the plant—and can be run for a specified time interval, producing the final state of the plant as output. In this way PNetLab can be linked to other programs, offering a powerful tool for the development of model-based predictive control techniques. Moreover, since the simulation engine is a compiled C þ þ optimized code, a very fast simulation (suitable for real-time applications) is assured. In PNetLab, the simulation of the closed-loop system and the token game in timed and untimed cases are also possible. In addition, for the open-loop PN model, the tool performs P-invariant and T-invariant computation (by the algorithm shown in Martinez & Suarez, 1982) and minimal siphon and trap computation (by the algorithm shown in Cordone & Ferrarini, 2003). PNetLab can compute the coverability tree both for open-loop and closed-loop systems, and it offers a very suitable management of transition conflicts.

9. Conclusions PNetLab a simulation and analysis tool for DESs oriented to supervisory control development has been presented. The tool has been developed by the Automatic Control Group of the University of Salerno and is available free of charge to interested readers. The main features of the tool have been shown to be:

ARTICLE IN PRESS F. Basile et al. / Control Engineering Practice 15 (2007) 241–259

258

Fig. 11. PNetLab software architecture.











Graphical definition of the PN/CPN plant model where controllable transitions can be enabled by an external agent. Possibility to implement the supervisor as a PN/CPN (compiled supervisor) or as a program implementing logical predicates. The supervisory algorithms can depend on the state of the plant. Simulation, token game and coverability tree for the closed-loop system (plant plus supervisor) independently by the form of the supervisor. Management of timed systems. Management of actual (run-time) conflicts. Linkable simulation engine. PNML compliant.

Effectiveness of its use in developing and testing supervisors and schedulers has been shown by means of case studies. References Amato, F., Basile, F., Carbone, C., & Chiacchio, P. (2005). An approach to control automated warehouse systems. Control Engineering Practice, 13, 1223–1241. Campos, J., & Silva, M. (1992). Structural techniques and performance bounds of stochastic Petri net models. In G. Rozemberg (Ed.). Advances in Petri nets 1992. Lecture notes in computer science (Vol. 609, pp. 353–391). Berlin: Springer. Carbone, C. (2005). Control-oriented discrete event models for manufacturing and transport systems. Ph.D. thesis, University of Salerno, Italy. Downloadable from: hhttp://www.supelec.fr/lss/CTS/WWW/CTS_publications.htmi. Cassandras, C. G., & Lafortune, S. (1999). Introduction to discrete event systems. Dordrecht: Kluwer Academic Publishers. Charbonnier, F., Alla, H., & David, R. (1999). The supervised control of discrete event system. IEEE Transactions on Control System Technology, 7(2), 175–187. Cordone, R., & Ferrarini, L. (2003). Some results on the computation of minimal siphons in Petri nets. 42th IEEE international conference on decision and control (CDC’03) (pp. 3754–3759). Maui, HI, USA. Girault, C., & Valk, R. (2003). Petri nets for systems engineering. Berlin: Springer. Giua, A., Fanti, M. P., & Seatzu, C. (2003). Generalized mutual exclusion constraints and monitors for colored Petri nets. 2003 IEEE international conference on systems, man and cybernetics (pp. 1860–1865), Washington, DC. Giua, A., Fanti, M. P., & Seatzu, C. (2006). Monitor design for colored Petri nets: An application to deadlock prevention in railway networks. Control Engineering Practice, 14(10), 1231–1247. Giua, A., & Seatzu, C. (2004). Monitor design for colored Petri nets with uncontrollable and unobservable transitions. Seventh workshop on discrete event systems (pp. 361–366). Reims, France. Holloway, L. E., Krogh, B. H., & Giua, A. (1997). A survey of Petri nets methods for controlled discrete event systems. Discrete Event Dynamic Systems: Theory and Applications, 7(7), 151–190. Jensen, K. (1995). Colored Petri nets. Basic concepts, analysis methods and practical use. Volume 1. Monographs on theoretical computer science. New York: Springer. Li, Y., & Wonham, W. M. (1994). Control of vector discrete-event systems II—Controller synthesis. IEEE Transactions on Automatic Control, 39(3), 512–531.

ARTICLE IN PRESS F. Basile et al. / Control Engineering Practice 15 (2007) 241–259

259

Martinez, J., & Suarez, M. S. (1982). A simple and fast algorithm to obtain all invariants of a generalized Petri net. In C. Girault, W. Reisig (Eds.). Informatik-Fachberichte 52: Application and theory of Petri nets: Selected papers from the first and second European workshop on application and theory of Petri nets. Strasbourg, September 23–26, 1980, Bad Honnef, September 28–30, 1981 (pp. 301–310). Berlin: Springer. Murata, T. (1989). Petri nets: Properties, analysis and applications. Proceedings of the IEEE, 77(4), 541–580. Qiu, R. G., & Zhou, M. C. (2004). Mightly MESs; state-of-the-art and future manufacturing execution systems. IEEE Robotics and Automation Magazine, 11(1) 19–25,40. Ramadge, P. J., & Wonham, W. M. (1989). The control of discrete event systems. Proceedings of the IEEE, 77(1), 637–659. Recalde, L., Teruel, E., & Silva, M. (1998). On linear algebraic techniques for liveness analysis of p/t systems. Journal of Circuits, Systems, and Computers, 1(8), 223–265. Weber, M., & Kindler, E. (2003). The Petri net markup language. In H. Ehrig, W. Reisig, G. Rozenberg, & H. Weber (Eds.). Petri net technology for communication-based systems. Lecture notes in computer science (Vol. 2472, pp. 124–144). Berlin: Springer.