13
Real time scheduling of batch systems St ephane Julia a , Robert Valette b, * a Depto. de Inform atica, Universidade Federal de Uberl ^ andia, P.O. Box 593, 38400-902 Uberl ^ andia, MG, Brazil b LAAS-CNRS, 7 Avenue du Colonel-Roche, 31077 Toulouse Cedex, France Received 28 January 2000; received in revised form 13 May 2000 Abstract The approach presented in this article is based on the real time simulation of p-time Petri net for the real time scheduling of batch systems. After defining the dierent kinds of con- straints that can exist in a linear hybrid production system, we present the conflict resolution principle used by a token player algorithm at the global coordination level. Ó 2000 Elsevier Science B.V. All rights reserved. Keywords: Petri nets; batch processes; real time scheduling 1. Introduction The globalization of markets and the ever changing needs of society generated the substitution of mono product processes by flexible multi-product processes called – batch systems. These systems are used in particular by the food and fine chemistry industries. They operate on continuous raw materials (generally fluids) and are com- posed of continuous equipment (a continuous flow of material goes through them, as in thermal exchanges, for example) and also discrete equipment (reactors, intermedi- ary buers, etc.). A batch is a quantity of material that is characterized by real num- bers (volume units, etc.). The act of manipulating diverse batches which can be treated simultaneously and which are transferred from one reactor to another shows that these systems look to a certain extent like flexible manufacturing systems [15]. As a matter of fact, in these kinds of systems, there exist similar resource allocation mechanisms. For example, the same reactor can be necessary to treat dierent batch- es. If the reactor works in a closed mode (a single batch, at the same time, in a single www.elsevier.nl/locate/simpra Simulation Practice and Theory 8 (2000) 307–319 * Corresponding author. Fax: +33-5-61-33-69-36. E-mail addresses: [email protected] (S. Julia), [email protected] (R. Valette). 0928-4869/00/$ - see front matter Ó 2000 Elsevier Science B.V. All rights reserved. PII: S 0 9 2 8 - 4 8 6 9 ( 0 0 ) 0 0 0 2 1 - 5

Real time scheduling of batch systems

Embed Size (px)

Citation preview

Real time scheduling of batch systems

St�ephane Julia a, Robert Valette b,*

a Depto. de Inform�atica, Universidade Federal de Uberlandia, P.O. Box 593,

38400-902 Uberlandia, MG, Brazilb LAAS-CNRS, 7 Avenue du Colonel-Roche, 31077 Toulouse Cedex, France

Received 28 January 2000; received in revised form 13 May 2000

Abstract

The approach presented in this article is based on the real time simulation of p-time Petri

net for the real time scheduling of batch systems. After de®ning the di�erent kinds of con-

straints that can exist in a linear hybrid production system, we present the con¯ict resolution

principle used by a token player algorithm at the global coordination level. Ó 2000 Elsevier

Science B.V. All rights reserved.

Keywords: Petri nets; batch processes; real time scheduling

1. Introduction

The globalization of markets and the ever changing needs of society generated thesubstitution of mono product processes by ¯exible multi-product processes called ±batch systems. These systems are used in particular by the food and ®ne chemistryindustries. They operate on continuous raw materials (generally ¯uids) and are com-posed of continuous equipment (a continuous ¯ow of material goes through them, asin thermal exchanges, for example) and also discrete equipment (reactors, intermedi-ary bu�ers, etc.). A batch is a quantity of material that is characterized by real num-bers (volume units, etc.). The act of manipulating diverse batches which can betreated simultaneously and which are transferred from one reactor to another showsthat these systems look to a certain extent like ¯exible manufacturing systems [15].As a matter of fact, in these kinds of systems, there exist similar resource allocationmechanisms. For example, the same reactor can be necessary to treat di�erent batch-es. If the reactor works in a closed mode (a single batch, at the same time, in a single

www.elsevier.nl/locate/simpra

Simulation Practice and Theory 8 (2000) 307±319

* Corresponding author. Fax: +33-5-61-33-69-36.

E-mail addresses: [email protected] (S. Julia), [email protected] (R. Valette).

0928-4869/00/$ - see front matter Ó 2000 Elsevier Science B.V. All rights reserved.

PII: S 0 9 2 8 - 4 8 6 9 ( 0 0 ) 0 0 0 2 1 - 5

reactor), it can be seen as a discrete resource like in a ¯exible manufacturing system.This means that these resources are non-preemptive disjunctive ones.

It is at the global coordination level of batch systems, during the real time sched-uling [14], that the resource allocation mechanism problems appear. The generalprinciple of the real time scheduling of production systems is based on the real timesimulation of the system model, which is carried out in parallel with the real workingof the system. Then, the real time scheduling consists of making decisions in real timeeach time a con¯ict appears.

The scheduling problem of ¯exible production systems has been studied by severalresearchers. When we consider ¯exible manufacturing systems, the principal purposeis to ®nd a solution, which minimizes the makespan. For example, in [12], Lee andDiCesare use a t-timed Petri net model to represent a ¯exible manufacturing system.In particular, the model allows one to represent the di�erent production routes andthe shared resources (a more general model than an event graph). To ®nd a sequenceof operations which minimizes the makespan, the authors apply a branch and boundalgorithm to the model and transitions are ®red as soon as they are enabled. Withsuch an approach, several limitations have to be taken into account. Even using abranch and bound algorithm, there exists the problem of the state explosion andif we manage to obtain an optimal solution, in any way, it will not be possible to ob-tain it in real time. Another problem is that ®ring transitions as soon as they are en-abled will not give us necessarily the optimal schedule as Silva and Valette haveshown it on a simple example in [14]. For batch systems, obtaining a feasible sched-ule consistent with a set of constraints (not necessarily optimal) is more relevant.Therefore, the scheduling problem has to be seen as an analysis of a system, undera set of constraints as in [7]. As a matter of fact, in a batch system, a waiting time toolong between two operations can damage the batch. Of course, the same does nothappen with a part of a ¯exible manufacturing system where only the makespanis, most of the time, the criterion to optimize. Another problem which has to be high-lighted, is that working at the global coordination level, the solution of the schedul-ing problem will have to be calculated in real time to take into account the possibleperturbations which can appear during the real operation of the system. Actually,the operation durations are ill known in food and ®ne chemical industry becausethey depend on raw material quality. Consequently, it would not be realistic to fol-low a perfect sequence of operations calculated o�-line.

To follow, the authors will de®ne a model adapted to the representation of theconstraints which are able to exist within a batch system. A specialized inferencemechanism will be presented too. Applied to the model of the system, this inferencemechanism is used to solve in real time the con¯ict situations.

2. Real time simulation model

The model used for the real time scheduling of batch systems has to describein real time the operation sequences to be made on the batches, to communicatewith the external world, and to be submitted to explicit temporal constraints. In

308 S. Julia, R. Valette / Simulation Practice and Theory 8 (2000) 307±319

particular, it has to evolve in synchronization with the physical system. The globalcoordination and real time monitoring of production systems based on a modelhas been presented in [5]. Each time, the state of the system changes (each time anoperation ends), the detection module veri®es if the state of the simulation modelis compatible with the actual state of the system and brings up to date the state ofthe simulation model. The decision module indicates then which operation (or whichoperations) has to be initiated (Fig. 1).

In the case of hybrid systems, it is common to separate the model of the system intwo distinct models [1]: the reference model and the control module, which speci®esthe control policy. The reference model represents a qualitative view of the behaviorof the system independently of any control policy (model of the global behavior of areactor, for example) and is used at the detection level to verify if a reactor does notover¯ow, for example. The control module controls the ¯ow of products, which haveto be treated and is used more for production management.

When the representation of the resource allocation mechanism is essential, then,Petri nets are well adapted. Extended models have been proposed [3] to consider thehybrid aspect of batch systems. When batch systems can be seen as linear hybrid sys-tems [6], then, by approximation, it is generally possible to remain within the contextof an event driven simulation and to use a discrete model with time considerations.Then, the activities are characterized by durations. In place of monitoring thresholdsfor determining the dates of the end of activity events, they are derived by simulatinga p-time Petri net by means of a token player algorithm.

In this paper, the main objective is to treat the real time scheduling problem ofbatch systems and, for that, we will only work using the control module of the modelwhich will be represented by a discrete model (discrete states and continuous time)obtained by approximation of a linear hybrid model. First of all, several kinds ofconstraints, which exist in batch systems, have to be de®ned.

2.1. Recipe

The production route constraints (the recipes of the batch process) describe the setof operations, organized in time, for the realization of products. They are represented

Fig. 1. Global coordination of production systems founded on a model.

S. Julia, R. Valette / Simulation Practice and Theory 8 (2000) 307±319 309

by sequences of places and transitions. The tokens which go through these sequencesrepresent the products in transformation (the treated batches). The beginnings andthe ends of the operations are attached to the transitions (the events) and the oper-ations (treatment and transfer operations of batches) are attached to the places.

The net of Fig. 2 gives an example of such a recipe which is applied to the batchmodeled by the token in place of Bi. This place represents the entry bu�er of the pro-duction route. Place Bo represents the exit bu�er. Places O1, O2, and O3 represent thethree treatments that have to be applied to the batch. And, ®nally, the transitionsrepresent the beginnings and the ends of operations O1, O2, and O3.

2.2. Resource allocation constraint

The resource allocation constraints permit the representation of ¯exible behaviorin hybrid systems when the discrete resources (reactors in a closed mode and inter-mediary bu�ers) are shared among the diverse recipes. The resources are representedby tokens of the places, which are connected to the production route constraints. Forexample, the constraint given in Fig. 3 means that the reactor, represented by thetoken in the place R, will be used as well to realize treatments of the recipe 1 as torealize treatments of the recipe 2.

Fig. 2. Recipe.

Fig. 3. Resource allocation constraint.

310 S. Julia, R. Valette / Simulation Practice and Theory 8 (2000) 307±319

The global model of the system is obtained by merging (place and transitionmerging) the diverse constraints (all the Petri net templates). It will be importantto verify that the global model is deadlock free. Unfortunately, in the case of batchsystems, for any transfer operation, we have to request a new resource before releas-ing the preceding one. This can lead to a deadlock resulting from a siphon, which isempty. A classical example of deadlock in the case of batch systems is presented in[16]. An approach for deadlock avoidance is shown in [4,15]. It consists of adding anew place to the global model that controls the maximum number of tokens in thesiphon.

2.3. Continuous aspect of the model

A typical way to encapsulate continuous phenomena within a discrete model is toturn explicit their durations. These durations are continuous values and in conse-quence a kind of hybrid model is obtained. In batch systems, durations of transferoperations and durations of transformation operations can be associated with placesor transitions of the Petri net model. For example, Azzopardi and Lloyd [2] use, inthe case of batch systems, a p-timed Petri net model to solve the optimum-schedulingproblem. Nevertheless, to use a timed Petri net model, it is necessary to know theexact operation durations for all the con®gurations. In batch systems, it will be inpractice impossible to know the exact durations of the transformation operations.For example, for a batch of milk to be boiled, it will have a minimum duration be-fore which the milk will not boil and a maximum duration after which the milk willburn. Owing to this, a simple-timed model will not be useful either to compute a re-alistic previsional schedule, or to compute the real time schedule. It is then necessaryto introduce uncertain durations in the formal model. The p-time Petri net model de-®ned by Khansa [11], will allow us to introduce the uncertain durations of the trans-formation operations of the batches. The de®nition of this model is the followingone:

De®nition 1. A p-time Petri net is a pair áR,Ipñ, where· R is a marked Petri net,· Ip is the application de®ned as

Ip : P ! �Q� [ 0� � �Q� [ �1�

pi! Ipi � �ai; bi� with 06 ai6 bi

Ipi � �ai; bi� is the static interval which represents the permanency duration (sojourntime) of a token in pi. Before the duration ai, the token in pi is in the non-availablestate. After ai and before bi, the token in pi is in the available state for the ®ring of atransition. After bi, the token in pi is again in the non-available state and cannotenable any transition anymore: ``token death''. In the batch system case, the ``death''of a token has to be seen as a constraint that is not respected.

The dynamic evolution of a p-time Petri net depends on the marking of the netand on the temporal situation of the tokens (non-available, available, dead). For

S. Julia, R. Valette / Simulation Practice and Theory 8 (2000) 307±319 311

the real time scheduling of hybrid systems, when the model is a Petri net, the problemis then to simulate in real time the temporal model, to highlight the con¯ict situationsand to verify that the local con¯ict resolution will not have as a direct consequencethe death of a token (constraint violation).

3. General approach for the real time scheduling

The principal aim of this approach is to take into account the state of the systemnot only at a single instant corresponding to the reception date of the last messageof an operationÕs end. We work on a short temporal projection that permits oneto emphasize possible future con¯icts.

3.1. Con¯ict de®nition

First of all, we have to de®ne what a con¯ict is for a p-time Petri net. For an au-tonomous Petri net, only qualitative time information is represented; for example,two operations executed at the same time (parallelism) or two operations in mutualexclusion (transitions in con¯ict for a given marking). When explicit quantitativetime is represented on the model, the problem is much more complex. With a p-timePetri net, the resource con¯icts are visible during a time interval and not only at asingle time point. It is then possible to generate more ®red sequences, which can leadto better solutions. Indeed, it is not always a good strategy to ®re transitions as soonas they are enabled as Silva and Valette showed in a simple example [14]. The nec-essary de®nitions to understand the con¯ict notion of a p-time Petri net were intro-duced in [8,9]. We recall them here.

De®nition 2. Visibility interval of a token: A visibility interval [(dp)min; (dp)max]associated with a token of a place p of a p-time Petri net de®nes· the earliest date (dp)min when the token in p becomes available for the ®ring of an

output transition of p,· the latest date (dp)max after which the token becomes non-available (dead) and

cannot be used for the ®ring of any transition.

In the context of a batch system, the death of a token means that a temporal con-straint has been violated.

De®nition 3. Enabling interval of a transition: if a transition has n input places and ifeach one of these places has several tokens in it, then the enabling interval [(ht)min;(ht)max] of this transition is obtained by choosing for each one of these n inputplaces a token, the visibility interval associated to this token, and making theintersection of all the obtained visibility intervals.

De®nition 4. Con¯ict time interval: if two transitions t1 and t2 are in structuralcon¯ict, then the con¯ict time interval of these transitions is obtained by making the

312 S. Julia, R. Valette / Simulation Practice and Theory 8 (2000) 307±319

intersection of the enabling intervals of t1 and t2. Inside the obtained time interval, t1

and t2 are in e�ective con¯ict for the marking; outside this time interval, they are notin e�ective con¯ict.

Let us consider the example of Fig. 4, with the following static intervals associatedwith the places p1, p2, and p3:

��dp1�min; �dp1

�max� � �1; 6�;��dp2�min; �dp2

�max� � �0; 7�;��dp3�min; �dp3

�max� � �2; 6�:At date 0 a token arrives in p1, at date 2 a token arrives in p3, and, ®nally, at date

3, a token arrives in p2. The visibility intervals of these tokens are

��dp1�min; �dp1�max� � �1; 6�;��dp2�min; �dp2�max� � �3; 10�;��dp3�min; �dp3�max� � �4; 8�:

The enabling intervals are [3;6] for t1 and [4;8] for t2. The con¯ict time intervalassociated to the pair (t1;t2) is [4;6].

3.2. Con¯ict state

When a token which represents a batch, enables a transition which is in structuralcon¯ict with other transitions, then, considering the visibility interval of this token,we have to calculate the possible arrival dates of other tokens which are in the inputplaces of the transitions in structural con¯ict with the enabled transition. Accordingto the possible arrival dates of these tokens, it is then possible to de®ne the diversevisibility intervals of the diverse tokens and to draw up the possible con¯ict timeintervals. From the obtained results, the useful part of the net, necessary to studylocally the possible con¯icts for the involved shared resource, can be isolated.

We can consider for example the net of Fig. 5 at date d� 6. The token in O31 be-comes available for the ®ring of t41. t41 is in structural con¯ict with t42 and t43. We havethen to calculate the possible arrival dates of tokens in O32 and in O33 between thedate 6 and 14 which correspond to the minimum and maximum bounds of the

Fig. 4. Con¯ict for a p-time Petri net.

S. Julia, R. Valette / Simulation Practice and Theory 8 (2000) 307±319 313

visibility interval of the token in O31. Here, we only want to establish the possibleexistence of an e�ective con¯ict between several transitions in a p-time Petri net. Then,we choose as arrival dates, the earliest arrival dates of the tokens. At date 10 (minimumbound of the visibility interval of the token of place O22), if the transition t32 is ®red,then a token appears in O32 and its visibility interval is [8 + 10;10 + 10]� [18;20]. If thetransitions of the recipe 3 are ®red as soon as possible, at date 7 + 3� 10 with 7 theminimum bound of the visibility interval of the token of place O13 and 3 the minimumbound of the static interval of the place O23, a token appears in O33 and its visibilityinterval is [2 + 10;5 + 10]� [12;15]. Since the visibility interval of the resource is[0;+1[, the enabling interval of t41 is [6;14], the enabling interval of t42 is [18;20],and the enabling interval of t43 is [12;15]. The con¯ict time interval of the pair (t41;t43)is equal to �6; 14� \ �12; 15� � �12; 14� and we will eventually be able to have an e�ec-tive con¯ict between t41 and t43 in a p-time Petri net. The con¯ict time interval of thepair (t41;t42) is equal to �6; 14� \ �18; 20� �£ and we will not have an e�ective con¯ictbetween t41 and t42. It means that t41 will be necessarily ®red before t42. The part of thenet that represents the recipe 2 will not be directly involved in the ®ring of t41 and wewill not consider it at the local level of the con¯ict analysis. The useful part of the netfor the con¯ict analysis of the shared resource of place R is represented in Fig. 6.

Fig. 5. Con¯ict for a shared resource.

314 S. Julia, R. Valette / Simulation Practice and Theory 8 (2000) 307±319

3.3. Con¯ict resolution

As the con¯ict resolution technique must be used in real time, instead of enumer-ating the set of the acceptable sequences we can obtain from the state of the Petri netfragment of Fig. 6, we look at the local level of the con¯ict and the consequences of aparticular decision. If we consider the net of Fig. 6, at date d� 6, the token in O31

becomes available for the ®ring of t41. It seems normal then to ®re t41 as soon as pos-sible, since there is no token in O33 at that time. If we ®re t41 at date d� 6, a newtoken appears in O41 and its visibility interval is equal to [2 + 6;3 + 6]� [8;9]. Fromthis new state (a token in O41 with its visibility interval equal to [8;9] and a tokenin O13 with its visibility interval equal to [7;12], we want to verify the consequencesof this decision (®ring t41 at date d� 6) on the rest of the net of Fig. 6. In particular,we want to verify that this decision will not cause a constraint violation, i.e. the deathof a token. The tool which allows one to represent all the possible evolutions of ap-time Petri net is the class graph de®ned by Khansa [10] from that of [13]. Such agraph allows one to de®ne the ``death token classes'' corresponding to the possibilityof existence of ``death tokens''.

Fig. 7 represents the class graph of the net of Fig. 6 obtained after the ®ring of t41

at date d� 6. The classes of the graph are the following ones:

Fig. 6. Useful part of the con¯ict.

S. Julia, R. Valette / Simulation Practice and Theory 8 (2000) 307±319 315

C0 : M0 � fO41;O13g; �26 dO416 3� ^ �16 dO13

6 6�C1 : M1 � fO13;Rg; �06 dO13

6 4� ^ �06 dR6 �1�C2 : M2 � fO41;O23g; �06 dO41

6 2� ^ �36 dO236 4�

C3 : M3 � fO23;Rg; �16 dO236 4� ^ �06 dR6 �1�

C4 : M4 � fO33;Rg; �26 dO336 5� ^ �06 dR6 �1�

C5 : M5 � fO43g; �16 dO436 4�

C6 : M6 � fRg; �06 dR6 �1�C7 : M7 � fO23;Rg; �36 dO23

6 4� ^ �06 dR6 �1�For example, the class C0 means that we have for the net of Fig. 6, after the ®ring oft41, a token in O41 and a token in O13. The token in O41 will have to stay in this place,before being used for the ®ring of a transition, at least a duration equal to 2 and atmost a duration equal to 3. The token in O13 will have to stay in this place, at least aduration equal to 1 and at most a duration equal to 6. On the graph, we have two arcsfrom the class C0. The one, which connects C0 to C1 means that if we choose to ®re t51

before ®ring t23, the transition t51 will be ®red necessarily between the minimumduration 2 and the maximum duration 3. The one, which connects C0 to C2 meansthat if we choose to ®re t23 before ®ring t51, the transition t23 will be ®red necessarilybetween the minimum duration 1 and the maximum duration 3. The detailedalgorithm used to construct this graph is presented in the Khansa PhD thesis [10].

There is no ``death class'' in this graph and consequently, we can ®re the transition t41

at date d� 6. We suppose now that instead of having [2;3] as the static interval attachedto O41, we have the static interval [18;20]. The class graph obtained if the transition t41

is ®red at date d� 6 is the one of Fig. 8 and the state classes are the following ones:

C0 : M0 � fO41;O13g; �186 dO416 20� ^ �16 dO13

6 6�C1 : M1 � fO41;O23g; �126 dO41

6 19� ^ �36 dO236 4�

C2 : M2 � fO41;O33g; �86 dO416 16� ^ �26 dO33

6 5�

The class C2 is a death token class, which leads us to a deadlock. In fact, we cansee that in this state class, the token in O41 has to stay in this place, at least aduration equal to 8. The shared resource will not be available in place R before

Fig. 7. Class graph without death token classes.

316 S. Julia, R. Valette / Simulation Practice and Theory 8 (2000) 307±319

this duration. On the other hand, the token in O33 only stays in this place at mosta duration equal to 5. If we remain for a longer duration in this particular place,then we will have the death of the token and a constraint violation for the batchsystem. We know that after having waited at the maximum a duration equal to 5in the place O33, the resource in R will not be available and the death of the tokenin O33 will occur.

We deduce from this class graph that the transition t41 cannot be ®red at dated� 6 when the token in O31 becomes available and we will have to try in any wayto ®re the transition t43 before t41, expecting then that we will not have the deathof the token in O31.

3.4. Token player algorithm

When the model of the system is a Petri net, then, the real time simulation, whichis carried out in parallel with the real operation of the system, is made using a specialinference mechanism called token player.

Fig. 9. Token player algorithm for a p-time Petri net.

Fig. 8. Class graph with death token classes.

S. Julia, R. Valette / Simulation Practice and Theory 8 (2000) 307±319 317

Fig. 9 represents such an algorithm when the model is a p-time Petri net. The com-munication process between the real system and the model is made by sending andreceiving messages. The received messages generally represent operation endings andare the events attached to the operation ending transitions. When we receive one ofthese messages, if the corresponding transition is not enabled, i.e. if the token, whichis in the input place of this transition (the one associated to the external event) is notavailable at this moment then, the token player algorithm detects an abnormal be-havior. The detection function is then followed by a diagnosis function in order toidentify the reasons of such an inconsistency between the state of the system andthe state of the model. The problem of the detection based on a model of the processis presented in details in [16].

Each time a token becomes available, we verify if it enables a transition. If it is thecase and if the transition is not in structural con¯ict, then we ®re it and we send anew message to the system to initiate a new operation (an event attached to the ®redtransition and corresponding to the beginning of an operation). If the transition is instructural con¯ict, we isolate the con¯ict state (the corresponding Petri net fragment)and then we verify if we can ®re the transition (con¯ict resolution mechanism). If thecon¯ict resolution mechanism allows one to ®re the corresponding transition as soonas the token becomes available, then we ®re the transition and a new message is sentto the system to initiate a new operation.

Finally, if there is death of a token (detection of an internal event, which representsthe maximum bound of a visibility interval), then, there is a constraint violation,which could have been caused by bad management of the available resources (wrongdecisions) or by a physical problem at the system level. We have then to relax a con-straint (increase the value of the maximum bound of a static interval) each time it ispossible. On the contrary, the batch is damaged: in particular, this situation happenswhen the maximum bound represents the maximum treatment duration of a batch.

4. Conclusion

The presented approach can be seen as a simulation with imprecise dates for the®ring of transitions. The advantage is that the token player algorithm of a p-time Pe-tri net can be seen as a special inference mechanism which can be used for the realtime scheduling and which can accept several acceptable sequences. It is thus a toolvery well adapted to the real time monitoring of batch systems, which are ¯exibleproduction systems. Another great interest of this approach is that the calculationof the con¯ict time intervals allows us to isolate the useful part of the net when a de-cision has to be made (con¯ict resolution). The class graph (each node of the classgraph encapsulates an in®nite number of states) is then generated only from a Petrinet fragment and not from the entire Petri net model. The combinatory problem cor-responding to the explosion of the number of states which exists each time the auto-mata corresponding to the marked Petri net is generated is thus avoided.

As a future work proposal, we will study the situations where the correspond-ing class graphs contain both death token classes and safe ones. In particular,

318 S. Julia, R. Valette / Simulation Practice and Theory 8 (2000) 307±319

it will be interesting to show how, changing the minimum and the maximumbounds of certain static intervals (the ones associated to the batch transformationoperation), we could eliminate the death token classes and keep at the same timemost of the safe classes. In this way, we could keep only the sequences withoutdeadlock.

References

[1] D. Andreu, J.C. Pascal, Events as a key of a batch process control system, in: Proceedings of the

CESAÕ96 IMACS Multiconference, Symposium on Discrete Events and Manufacturing Systems,

Lille, France, 1996, pp. 297±302.

[2] D. Azzopardi, S. Lloyd, Reduction of search space for scheduling of multi-product batch process plan

through Petri net modelling, in: Proceedings of the Second IFAC/IFIP/IFURS Workshop on

Intelligent Manufacturing Systems, Viena, 1994.

[3] R. Champagnat, P. Esteban, H. Pingaud, R. Valette, Petri net based modelling of hybrid systems,

Computers in Industry 36 N1-2 (1998) 139±146.

[4] R. Champagnat, P. Esteban, H. Pingaud, R. Valette, From scheduling to supervision in batch

processes, in: Proceedings of the Second IMACS Multiconference CESAÕ98, Computational

Engeneering in Systems Applications, Symposium on Industrial and Manufacturing Systems,

Nabeul-Hammamet, Tunisia 1998, pp. 673±678.

[5] M. Combacau, Commande et surveillance des syst�emes �a �ev�enements discrets complexes: application

aux ateliers ¯exibles, PhD Thesis, University of Paul Sabatier, France, 1991.

[6] A.R.C. Courcoubetis, N. Halwachs, T.A. Henzinger, P.H. Ho, X. Nicollin, A. Olivero, J. Sifakis, S.

Yovine, The algorithmic analysis of hybrid systems, Theoretical Computer Science 138 (1995) 3±34.

[7] J. Erschler, P. Esquirol, Decision aid in job-shop scheduling: a knowledge based approach, in:

Proceedings of the IEEE International Conference on Robotics and Automation, San Fransisco,

1986, pp. 1651±1656.

[8] S. Julia, Conception et pilotage de cellules ¯exibles �a fonctionnement r�ep�etitif mod�elis�ees par r�eseaux

de Petri, PhD Thesis, University of Paul Sabatier, France, 1997.

[9] S. Julia, R. Valette, J.M. Fernandes, Scheduling batch systems using a token player algorithm, in:

Proceedings of the IEEE International Conference on Systems, Man, and Cybernetics, San Diego,

1998.

[10] W. Khansa, R�eseaux de Petri p-temporels: contribution �a lÕ�etude des syst�emes �a �ev�enements discrets,

PhD Thesis, University of Savoie, France, 1997.

[11] W. Khansa, P. Aygalinc, J.P. Denat, Structural analysis of p-time Petri nets, in: Proceedings of the

Symposium on Discrete Events and Manufacturing Systems, CESAÕ96 IMACS Multiconference,

Lille, France, 1996.

[12] D.Y. Lee, F. DiCesare, Scheduling ¯exible manufacturing systems using Petri nets and heuristic

search, IEEE Transactions on Robotics and Automation 10 (3) (1994) 123±132.

[13] M. Menasche, PAREDE: an automated tool for the analysis of time Petri nets, International

workshop on timed Petri nets, Torino, July 1985, pp. 162±169.

[14] M. Silva, R. Valette, Petri nets and ¯exible manufacturing, in: G. Rozenberg (Ed.), Advances in Petri

Nets, Lecture Notes in Computer Science, Springer, 1989, pp. 374±417.

[15] M. Silva, E. Teruel, R. Valette, H. Pingaud, Petri nets and production systems, in: W. Reisig,

G. Rozenberg (Eds.), Lectures on Petri Nets II: Applications, Lecture Notes in Computer Science

1492, Advances in Petri Nets, Springer, 1998, pp. 85±124.

[16] R. Valette, Petri nets for control and monitoring : speci®cation, veri®cation, implementation, in:

Proceedings of the Workshop Analysis and Design of event-driven Operations in Process Systems,

London, 1995.

S. Julia, R. Valette / Simulation Practice and Theory 8 (2000) 307±319 319