petri net based process scheduling: a model of the control system of flexible manufacturing systems

Journal of Intelligent and Robotic Systems 8: 99-123, 1993. 99 ..(~) 1993 Kluwer Academic Publishers. Printed in the Netherlands.

Petri Net Based Process Scheduling: A Model of the Control System of Flexible Manufacturing Systems

A N T O N I O C A M U R R I , P A O L O F R A N C H I , F R A N C E S C A G A N D O L F O , and R E N A T O Z A C C A R I A DIST - Department of Communication, Computer and System Sciences, University o f Genoa, Via Opera Pia l lA , 1-16145 Genoa, Italy e-mail: [email protected]

(Received: 26 February 1991; in final form: 9 October 1992)

Abstract. In this paper, we propose a class of algorithms for the sub-optimal solution of a particular class of problems of process scheduling, particularly focusing on a case study in the area of flexible manufacturing systems (FMSs). The general class of problems we face in our approach is characterized as follows: there is a set of concurrent processes, each formed by a number of temporally related tasks (segments). Tasks are executable by alternate resource sets, different both in performance and costs. Processes and tasks are characterized by release times, due dates, and deadlines. Time constraints are also present in the availability of each resource in resource sets. It has been proven that such a problem does not admit an algorithm for an optimal solution in polynomial time. Our proposed algorithm finds a sub-optimal schedule according to a set of optimization criteria, based on task and process times (earliness, tardiness), and/or time independent costs of resources. Our approach to process scheduling is based on Timed Coloured Petri Nets. We describe the structure of the coordination and scheduling algorithms, concentrating on (i) the general-purpose component, and (ii) the application-dependent component. In particular, the paper focuses on the following issues: (i) the automatic synthesis of Petri net models of the coordination subsystem, starting from the problem knowledge base; (ii) the dynamic behavior of the coordination subsystem, whose kernel is a High Level Petri net executor, a coordination process based on an original, general purpose algorithm; (iii) the structure of the real-time scheduling subsystem, based on particular heuristic sub-optimal multi-criteria algorithms. Further- more, the paper defines the interaction mechanisms between the coordination and scheduling subsystems. Our approach dearly distinguishes the mechanism of the net execution from the decision support system. Two conceptually distinct levels, which correspond to two different, interacting implementation modules in the prototype CASE tool, have been defined: the executor and the scheduler levels. One of the outstanding differences between these levels is that the executor is conceived as a fast, efficient coordination process, without special-purpose problem-solving capabilities in case of conflicts. The scheduler, on the other hand, is the adaptive, distributed component, whose behavior may heavily depend on the problem class. If the scheduler fails, the executor is, in any case, able to proceed with a general-purpose conflict resolution strategy. Experimental results on the real-time performance of the kernel of the implemented system are finally shown in the paper. The approach described in this paper is at the basis of a joint project with industrial partners for the development of a CASE tool for the simulation of blast furnaces.

Key words. High-level petri nets, timed Petri nets, concurrent scheduling, flexible manufacturing systems, CASE.

1. Introduction

In this paper, we propose a class of algorithms for the sub-optimal solution of a

particular class of problems of process scheduling, which can be characterized as

100 ANTONIO CAMURRI ET AL.

follows: there is a set of concurrent processes, each formed by a number of temporally related tasks (segments). Tasks are executable by alternate resource sets, different both in performance and costs. Processes and tasks are characterized by release times, due dates, and deadlines. Time constraints are also present in the availability of each resource in resource sets. It has been proven that such a problem does not admit an algorithm for an optimal solution in polynomial time [5]. Our proposed algorithm finds a sub-optimal schedule according to a set of optimization criteria, based on task and process times (earliness, tardiness), and/or time independent resource costs. The problem class faced in our approach includes both multiple processes and time constraints. The scheduling algorithms are based on a particular extension of Petri nets (PNs), Timed Colored PNs [2].

Process scheduling is a most general problem [16, 18]: situations in which such a need arise can be found in many research fields as well as in practical applications. Communication networks dealing with packet switching should find a possibly optimum routing policy in order to minimize queue size and time delays. Hard-real-time systems [13], too, show the need of efficient strategies, since they deal with precedence relations between tasks, for example if a task requires information produced by another one. In operating system design, a great deal of attention has been devoted to the scheduling problem [22]; time constraints are also important to synchronize the access to shared resources such as data or I/O devices. Such a problem may also be found in decision support systems [5] and in software project management [30], where it is known as the project management problem. Process scheduling finds useful application also in nonclassical domains. For example, since computer music performance systems [19, 12] are defined as 'computer systems connected to input devices (including musical keyboards or other real-time instruments) and to graphics and audio output devices' [4], they require real-time scheduling strategies for the management of events from input devices and of actions to be performed.

Several hypotheses have to be kept into account in the design of efficient schedulers. Xu and Parnas [29] recently developed a preemptive scheduler for multitask applications on a single processor. Our approach starts from a different hypothesis: it allows scheduling among a number of processors but it is not preemptive, as in most industrial machines. To do this, we propose the architecture shown in Figure 1. This is basically a two-level architecture. The approach followed in this paper, in fact, clearly distinguishes the mechanism of net execution from the decision support system. Based on this fact, two conceptually distinct levels (corresponding to two different, interacting implemented modules) have been developed: the executor (i.e. the coordination process), and the real-time scheduler level. Referring to the FMS context, taken as a case study in the paper, these levels correspond to the coordination and the scheduling subsystems.

One of the outstanding differences between these levels is that the executor is a fast, efficient Timed Colored PN animator, without any special-purpose, problem-solving capabilities in case of conflicts. The scheduler, on the other hand, is the adaptive, distributed component, whose structure and behavior may heavily depend on the

PETRI NET BASED PROCESS SCHEDULING IN FMS

Problem ~ t Scheduler

Specificatior~ l Executor

t Verifier User Modif eat on

Fig. 1. Overall system architecture.

101

problem class, even if a general architecture can be adopted in a number of possible cases. If the scheduler fails, the executor is, in any case, able to proceed with a general-purpose conflict resolution strategy.

Section 2 gives an overview of the FMS problem class, consisting of a production line in which different types of workpieces must be routed into a network of tool machines, trying to satisfy user defined optimization criteria. The definition of a proper high-level representation environment for this class of problems is briefly explained in Section 3: in [9], the reader can find major details on the structure of the FMS knowledge base, and how to automatically deduce suitable high-level timed Petri nets. Section 4 introduces Structured Timed Colored PNs, focusing on the extensions to PNs necessary for this class of process scheduling problems. The methods for automatically deriving a model of the coordination subsystem of the FMS in terms of PNs are introduced. Section 5 presents the basic low-level component, whose kernel is an original asynchronous discrete event simulator for Timed Colored PNs. The decision situations which are delegated to the real-time scheduler subsystem are described in Section 6.

Finally, experimental results on the performance of the kernel of the implemented system are shown in Section 7.

2. Process Scheduling: The Case Study

This section introduces the FMS case study and defines the basic concepts for a suitable high-level representation of the problem. Basic temainology and some definitions are borrowed from [5]. The case study has its primary focus in the scheduling of concurrent projects, where a project is a set of temporally related tasks whose performance gives a complete production cycle of a workpiece in an FMS. Different projects correspond to different production cycles for different workpieces, but projects may be conflicting in the use of machines and resources. In general, different pallets will be necessary for each workpiece type in the FMS. Therefore, the number of different pallets available in the FMS defines the maximum number of projects which can be carried out. A set of projects has to be run simultaneously, that is, different types of workpieces must simultaneously be processed by the FMS. Task activities are defined in terms of functions. A task can be assigned to one or more


machines (stations) in the production line. Machines are a class of possible resources; in general, a task can be accomplished by different resource sets. The decision on the resource set for a given task instance at a given time is delegated to the real-time scheduling subsystem, which operates according to the optimization criteria and the constraints defined in the problem. Each resource is characterized by an availability table, which specifies the time intervals in which the resource is available: this models real world situations, such as periodic maintenance of machines, or possible periods of time in which a machine is devoted to other higher-priority activities, external to the actual model. The architecture of the FMS should allow the continuity in the production process, even in the case of unavailability (programmed or not) of machines. Couples of tasks in a given project are linked by temporal relations. In general, temporal relations specify either simple precedence relations, with possible definitions of waiting times between the ending instant of a task and the beginning of the next, or more complicated explicit time relations: for example, the overlapping of the completion of a task with the beginning of the next one. In an FMS domain, the latter case is generally unnecessary, since a workpiece is generally processed only by one task at a given time. In any case, our approach allows general temporal relations

among tasks to be defined. Waiting times between two sequential tasks may have soft constraints: for example, a workpiece after apainting task may need to wait for a time interval from 10 to 30 rain, before its processing by the next task. This is another typical decision situation: the coordination subsystem delegates all decision situations to the real-time scheduling subsystem, which should determine the optimum value for a given case, based on specified criteria.

In Figure 2 a simple example of FMS scheme is shown. The example regards two projects to be carried out. Each project consists of a sequence of two tasks for a different workpiece. For both projects, the first task can be accomplished by using either machine M1 or machine M2; in both cases a further resource R1 is needed. Therefore, Task 1 has two possible Task Instances (TI), TI11 and TI12, correspond-

ing to the use of M 1 or M2, respectively. The same situation occurs for Task 2, with the only difference that in this case we have three TIs (TI21, TI22, TI23), and machines M3 and M4 are needed from TI22, so they appear in two different resource sets. We assume that each resource in the example (generic or machine type) has an availability table, formed by couples of time points, defining the time intervals in which such resource is available. Yet, a waiting time is needed between the end of task 1 and the start of task 2, for both projects. Each project has different waiting time ranges.

A production line in which different projects are concurrently processed needs a scheduling policy to optimize the productivity, based on criteria and costs of some kind. We assume that tasks and projects have constraints on their workpieces' release time, due date and deadline, respectively, the initial time at which the task or project could start, the due time for its completion, and the maximum time allowed for its completion. Optimization criteria, based on task and project times, or on time independent machine costs, are taken into account in the problem's formulation (see Section 6).


/

©

103

\

\

Fig. 2. A production Iine.

System properties, both temporal and structural, for the definition of the problem are represented in a FMS knowledge base, implemented as a structured frame-based multiple inheritance semantic network, described in detail in [9]. A short overview of the representation scheme can be found in Section 3.

3. High Level Representation: The FMS Knowledge Base

Each entity in the system is an object, with related properties and/or methods (procedural definitions). The user interacts with the system by asserting new properties or querying the system about the FMS status.

The FMS knowledge base consists of a taxonomic organization of problem entities. Such representation has significant advantages, deriving from their object oriented structure, such as a considerably reduced memory occupation and easy definition of new tasks, projects, or other entities, based on already existing objects. Besides, the user defines the problem in terms of simple assertions, demanding to the system the task of (automatically) synthesizing the corresponding PN model of the coordination subsystem. Finally, a taxonomic representation of the problem domain can be a useful platform for the development of the higher level components of the control system of the FMS, the overall scheduling and planning subsystems.

At this high-level, conceptual model, two basic components can be distinguished: (i) a terminologic component, which models the definitional aspects, i.e., it regards the definition of the general terms and properties of the objects involved in a given problem class (a taxonomy of concepts, including the definition of projects, tasks, optimizing criteria, resource sets, etc.; as an example of the formalism, see Figure 3); (ii) an assertional component, regarding particular, individual properties of the objects involved in a given problem instance. A representation for temporal knowledge has been introduced in both components, based on the constructs called tense maps, which


part of

l / n i ~ . t

task of

wai t executable by

I--1 1/nil

Fig. 3.

executed 1/1

.._•mber I 1 /n~ , , . , l iability

availabil i ty

A fragment of the FMS knowledge base for the problem in Figure 2.

allows a partial order on time instants. Time intervals are defined as couples of time instants [3,28]. From a problem definition at this level, it is possible to detect inconsis- tencies on time constraints between objects in the taxonomy [9]. A detailed description of the Artificial Intelligence methodologies adopted in the design of the knowledge base are described in [9]. In the following we give only a sketch of its structure.

An FMS knowledge base is a taxonomy of objects, following the terminologic definitions introduced in the previous section: there are high-level objects, or classes, representing projects, tasks, resource sets, criteria, and other high-level entities. Particular projects can be created as instances of the projects class. The projects class contains the basic properties common to any project: a release time (the initial time for a project), a due date (the wished completion time of a project), a deadline (the maximum time after the due date allowed for the project to terminate), the list of tasks involved in the project, the time relations among couple of tasks. Some time relations may be left unspecified by the user; in this case they are supplied by the inference mechanisms of the system (classification, inheritance and special purpose inference algorithms).

The tasks involved in a project are instances of the Tasks class, but inherit also properties from their project: for example, it is possible to introduce a due date and a deadline for each task, but if they are lacking, proper default values are computed by taking those (if any) of their project. An algorithm has been developed for determining proper default values, starting from the project values and from the time relations among tasks.

PETRI NET BASED PROCESS S C H E D U L I N G IN FMS 105

In Figure 3 the structure of a fragment of the FMS knowledge base for the problem of Figure 2 is shown. In the figure, objects classes are represented by ellipses, large arrows are IS-A links, i.e., inheritance links among object classes; single arrows and boxes represent slots and methods (properties) of objects.

4. A Timed Colored Petri Net-Based Coordination Subsystem

Petri nets find useful applications in the modeling of systems characterized by a distributed and concurrent nature, and by the synchronization among tasks in the use of shared resources [23-26]. In particular, PNs allow a structured definition of the model, reflecting the nature of the problem. This leads, for example, to faster implementation and maintenance of the simulation and control subsystem's model, of the scheduling strategies and of the consistency checking procedures.

Furthermore, in the last decade, new formal extensions to the original PN model (P-T nets) played (and are still playing) a fundamental role in the diffusion of PNs into several fields, such as FMS and Operations Research. A particular usefulness of PNs has been recently pointed out in the field of FMS [20]. Timed PNs and Stochastic PNs [1, 21, Colored PNs (CPNs) [17] and Predicate/Transition nets (Pr-T nets) [14] are among the most significant extensions, known as High Level PNs (HLPNs), and are currently used in many application fields. HLPNs are a powerful tool for the definition of models of concurrent distributed systems at a higher level of abstraction. This fact is of considerable help in the modeling of FMS, typically involving a large number of resources and tasks. HLPNs allow the definition of individual tokens, and transitions behave in different ways according to the firing color (selected from the input places): a transition in a HLPN corresponds to a set (a class) of transitions in the P-T net model. This can be considered a particular 'object oriented' approach, in which classes of tasks, corresponding to transitions, are connected to their related resource sets (set of places). A different approach for introducing object-oriented concepts into PN theory can be found in [7]: the authors define objects as subnets (with a fixed topology) in an extended P-T net model (PROT nets); high level transitions are objects representing subnets.

Several other approaches for the modeling of FMS using PNs have been recently developed: in [27], PNs are used in conjunction with knowledge based paradigms (rule-based systems) for monitoring tasks of FMS; in [6], Stochastic PNs are introduced for the performance evaluation of FMS; yet, in [21], the problem of designing the control system of an FMS based on Colored PNs and rule-based techniques is faced; a control system for FMS based on both an extension of Colored PNs and artificial intelligence concepts (yet rule-based systems) is presented in [15]; the integration of PNs and Operation Research methods in an Expert Systems environment is proposed in [23]. Finally, the hybrid A-Nets model is introduced in [10], for high level representation of robotic actions. A-Nets combine a structured frame-based knowledge representation with HLPNs.


4.1. THE TIMED COLORED PETRI NETS MODEL

We adopt an extension of Colored PNs, embedding timed transitions. Before choosing a PN model, a simple but relevant consideration should be kept into account: the more powerful the model is, the more difficult (less tractable) computationally it becomes, from the point of view of analysis. Therefore, if the basic need is analysis, then the less (possible) sophisticated PN model should be chosen. On the contrary, for simulation-based applications (as in our case), based on an 'analysis by synthesis' method, the choice of a powerful PN models can be advantageous. The basic features of the PN model we adopted (STCPN - Structured Timed Colored Petri Nets) are now briefly discussed.

Colors correspond in our model to the different projects: at a given time, a project state is identified in a STCPN by the set of tokens of its color. The flow of tokens of a given color in the STCPNs model represents the evolution of the associated project. A neutral color is defined: a resource (place) marked with a neutral color can be utilized by any project, that is, a neutral colored token can be used in any colored firing occurrence.

Transitions correspond either to TIs (TI-transitions) or to waiting processes (W- transitions), and are characterized by a processing time, which can be deterministic or stochastic. Immediate transitions (with a null processing time) are allowed; their default management in case of conflicts follows [1], that is, conflicts between immediate and timed transitions are always solved in favor of immediate transitions.

The information on the processing time of a TI-transition is particularly useful in case of system simulation. In a real world environment we have real (low level) local controllers, each of them 'linked' with a suitable TI-transition at STCPN level: the firing of a TI-transition causes messages to be sent to its controller for the activation of the corresponding real task instance; the expiring of the transition can be driven by the completion of the task instance, via messages coming to the transition from its controller. In a simulated environment, we know the parameters of the machine(s) executing the task (for example the speed) associated to a TI-transition, and we can use them for computing its processing time, either deterministic or stochastic. W- Transitions may have soft-constrained processing times: only the range is known. The real-time scheduling subsystem will decide a suitable value in the defined range for each soft-constrained W-transition. Other basic properties of transitions are a status,

the set of the allowed firing colors, and a set of functions defining the code for the local controllers; for each transition, there is a function for each color (i.e. project) in the net.

Places can be of two types, corresponding to either resources or queues. Graphic- ally, resources are circles, queues are hexagons. A place can have a set of tokens, possibly of different colors. A place of type resource is characterized also by a possible availability table. The availability table defines the set of time intervals (couples of time instants) in which the resource is available for possible task executions. A resource set is defined for each TI-transition as the set of all its input places of type

PETRI NET BASED PROCESS SCHEDULING IN FMS 107

resource. Different resource sets can have places in common: this means that there are

topologic conflicts in the PN. For example, in Figure 4, the resource set of Ti l l is the

set of places formed by M1 and R1 ( I Q u e u e l is a queue place). Besides, the resource

sets of both TI l l and TI12 share the resource RI: this corresponds to the topologic

conflict between the two transitions. Thefiring rule is the same adopted in CPNs, with the exception of the delays due

to the transition's processing time. In fact, a transition firing causes the consuming of

input tokens, and only after the transition's processing time has expired the output tokens are placed on the output places. This causes tokens to appear/disappear in the net: they are stored in transitions for the duration of their processing time. This is a bad feature, from the point of view of analysis properties: it is possible to reduce this behavior to the standard CPN model if we consider a (timed) transition as a particular

subnet, simply formed by a sequence of transition-place-transition. These transitions are immediate: the first one consumes input tokens, and marks the intermediate place; after the processing time, the final transition fires (it is the firing rule which changes, now), consumes the token from the intermediate place and produces output tokens. Therefore, any timed transition in our PN model can be seen as a sequence transition- place-transition.

As for the firing rule, a transition fires if all input places are marked with a given color, or some places are marked with the neutral color and the remaining places with the same color. The firing color must belong to the set of transition allowed colors.

Multiple firing of the same transition, due to the availability of multiple pre-sets, is

generally not used in this model, even if it is allowed by the H L P N model. A further condition has been added to the firing rule of transitions, because of the presence of availability tables on resources: an input place is available if it is marked and at the current time, and within a 'reasonable' time horizon, the resource is available from its availability table. The 'reasonable' horizon is deterministic in the case of FMS simulation: it is the time point obtained by adding the current time to the processing time (computed for the firing color) of that transition.

The subnet related to the Task 1 of the previous example of Figure 2 is shown in Figure 4.

Model FIIS - ~ t example - li~e llnit" 5 sec

e~ Ill ~ /'%1 I~1 "~ "-"

j"

"7 \. 0.flt~euel

Fig. 4. A subnet describing Task 1.


Note that this net could be collapsed into a smaller STCPN, using the properties of HLPNs: all TIs could be represented by means of a single transition with a slightly different firing rule, allowing multiple concurrent firing for disjoint pre-sets [17]. We have chosen in this case a representation as in Figure 4, with separate transitions, because of its major resemblance to the problem's nature, its easier understanding and better tractability. In other cases we use multiple firing transitions.

4.2. MACRO-STRUCTURES

Explicit object-oriented properties, typical of HLPN-based approaches, for the definition of classes (for example the Place, Transition, Colored-Token classes) coexist in STCPNs with a basic feature named Macro-Structures (MS). MS are defined in terms of particular typical generalizations of subnets; they are a sort of generalization (at a higher level of abstraction) of PROT nets. A first difference from PROT nets is that our system is not primarily conceived as an object-oriented graphic programming environment, in which the user builds its macro-PNs and uses them for building the whole model. We have directed our efforts in defining the problem type, deriving some basic pre-defined general MSs, leaving to the system the task of automatically creating a STCPN starting from the initial problem FMS knowledge base. Such a STCPN, modeling the coordination subsystem of the FMS, is built by the system by connecting instances of MSs. We stress that an M S is not a topologically fixed construct (a subnet) which can be instantiated assigning variable values, such as token values etc. (as procedures in programming languages). Instead, it is a class of topologically 'similar" constructs, i.e. having some common basic features. MSs are therefore high-level entities defined in terms of frames in the FMS knowledge base. An example of three instances of the same MS (the Task MS) is shown in Figure 5; their common feature is that all cases are conflicts (or alternatives), but their topologies are considerably different. The STCPN in Figure 4 is another instance of the Task MS, too.

The set of general MSs available in the system can be easily updated. In fact, it is possible to introduce new high-level frames, representing some particular behavior in terms of methods and slots, possibly referring to existing frames (i.e., specializing existing MS frames using inheritance).

4.3. AUTOMATIC SYNTHESIS OF THE STCPN MODEL

Usually, the task of constructing the PN model of the coordination subsystem is left to the designer; in some cases, powerful graphic aids are available in the implemented software systems [6]. Our approach also allows the automatic synthesis of a STCPN model of the FMS, starting from the FMS knowledge base. Besides the objects/frames representing the projects and related knowledge, the system embeds the definition of different frames for the representation of MSs: the main are the Task MS and the Wait/Connection MS. They are sub-classes of the MSs class. A Task MS embeds the definition of its TIs, its related resource sets and its I/O queues. A Task MS behaves

PFTRI NET BASED PROCESS SCHEDULING IN FMS 109

,/'-~ l_queuel

q ' J

L,

[ / /

~j T!.t!

/ - - '~ 0Jltte~te 1 "tk._jP

F-%x I NU~q~I

~t TIl l I'I12 ",.,. /

~fk Que ue I

.,f--'~, I_Queuel

2 ̧

"TLM -?,.2 ,

, I / I \ I /' ', !£ \1 , 1

L, L,,. .., ,.,,,L__._-a

• '~ / . . 1 ', / . 1 .

" . , , ,,, j /1" --.... ,,, / . I

~ _ Q u e u e l

S2

Fig. 5. Three different instances of the Task Macro Structure.

as a place, a Wait/Connection MS as a transition. Figure 4 shows the Task MS for the task 1 of the previous example. Its complete STCPN model is shown in Figure 6. It is composed of a sequence of a Task MS instance and an instance of Wait/Connection MS, followed by another instance of the Task MS. Wait/Connections MSs are automatically created starting from the temporal relations among the tasks of a given project. Task MSs are created starting from the available task and resource set properties represented in the FMS knowledge base. During this construction process, as many TI-transitions as the number of resource sets are created for each task; each transition has a set of input places corresponding to its resource sets. Each set of the TIs for a given task is successively connected both to an input queue (a place connected in input to all TI-transitions of the given place), and to an output queue (a place connected in output to all TI-transitions of the given task). A proper algorithm for the creation of a STCPN model for the coordination subsystem explores the FMS knowledge base to build the MS instances and their connections as previously explained• The result of the execution of such an algorithm given as input the initial problem instance automatically produces the STCPN in Figure 6. A further

110

Fig. 6.

Model F1¢5 - HeI exlmple - I i~e U~tit: 5 set:

\ //

/ \ , y

\

• ,, x ~ / - ~ l quet~e2

/ / , 1 / (TI2z m 3

Automatically generated STCPN for the FMS in Figure 2.

ANTONIO CAMURRI ET AL.

graphic algorithm automatically defines the Cartesian coordinates for each node in

the STCPN. The initial marking of such STCPN is determined by the following algorithm:

- one neutral token is assigned to all the places available to all projects; - resource places that can be used only by a limited set of projects will have one

token for each color/project, according to their definition in the problem instance

Knowledge Base; - for each project, it will be assigned one token (or more, depending on the number

of workpieces of the same type to be processed) with the proper color to the input queue(s) of its initial task(s) (in the example, colors P1 and P2 in the place

I__Queuel).

5. S i m u l a t i o n a n d R e a l - T i m e C o n t r o l o f t h e F M S

The coordination subsystem is modeled by a STCPN. Its dynamic behavior is given by the flow of the (colored) tokens into the STCPN. A particular STCPN animator, an original discrete event simulator, is the kernel of the coordination subsystem. In this section we describe both the simulated and the real-time control mechanisms; we shall speak of animation for the real-time case algorithm.

PETRI NET BASED PROCESS SCHEDULING IN FMS 1 1 1

5.1. THE BASIC ALGORITHMS FOR CONTROL AND SIMULATION

As in many simulation or concurrent languages, the central (virtual) processor is multiplexed among the processes (transitions): this function is performed by a

scheduler process (the Time Object) which guarantees simultaneous time-flow across all processes by giving a time slice to each in turn. Time is divided in atomic slices which are the only instants in which action may take place, i.e., a transition can either fire or expire. The different management of these time slices results in the development of two separate schedulers: the synchronous and the asynchronous scheduler.

The synchronous scheduler, dedicated to real-time requirements, checks each transition in turn at every time instant to see if it is involved in any event, and, in that case, executes the transitions. This approach seems to be particularly suitable in a real environment since it does not require any hypothesis on the duration of each transition. Regularly checking for the completion of a transition activity, it easily copes with the unfixed time delays which may be due to the human factor in a real world application, On the other hand, from the asynchronous point of view, only a set of relevant time slices are examined. These instants are characterized by the following

conditions:

(i) the initial time; (ii) any time slice in which a resource becomes available according to its availabil-

ity table; (iii) any time slice in which the controller associated to a transition communicates

the completion of its task instance, that is the transition has to expire

immediately and mark its output places.

In the following discussion, only the asynchronous scheduler is taken into account, since all the consideration that will be made can be applied with minor modifications to the other scheduler as well. A time ordered table (Time Table) is defined for keeping track of the above-mentioned time slices; the cases (i) and (ii) correspond to an initialization of the table with those particular time slices. Case (iii) causes a dynamic updating of the table, according to the net behavior.

At each significant time slice, the firing rule is tested for each transition, and, if verified, the transition is activated and the code for its controller executed. In a simulated environment, a transition can remain active for several time slices, according to the user definition of its temporal duration (possibly nondeterministic). The controller drives the expiring of its transition's activity, sending end-of-activity messages to the transition. A test on the firing rule of all transitions is executed in the time slot immediately following the expiring of a transition, for determining possible transitions which could be enabled by the expiring and marking of the transition's

output places. The net animator is not dependent on net topology, although particular

net constructs caused some complexities on the structure of the algorithm. In particular, the algorithm provides a general-purpose behavior for conflict resolution: the


firing rule can not be computed locally in a transition, but depends on the state of other conflicting transitions. Normally, the net animator delegates to the real-time scheduler subsystem the decision on the conflicting transitions. This general purpose behavior has been included in case of faults in the real-time scheduling subsystem.

5.1.1. The Asynchronous Discrete Event Simulator for STCPNs

In this section we describe the algorithms for both real-time control and simulation of the STCPN model of the coordination subsystem. The two different cases are referred to, respectively, as animation and simulation of a STCPN. The basic difference between them lies in the handling of bi-directional communications of the transition controllers. In the simulated environment, expiring instants of transitions are computed and stored into the Time Table; in the real-time case, messages are coming in the current time slice. Both algorithms are described here, since they differ only in these circumscribed features.

The basic algorithm is quite simple: at each time slice present in the Time Table (which includes also each time slice in which a transition controller communicates to its transition its end-of-task execution), we scan all the net transitions and execute each of them. We divided slot execution into three phases: first, immediate transitions (with 0 time duration) are executed (xtransO procedure) then all other transitions fire but do not (yet) mark places (xtransl procedure), time goes on one slot, and finally, expiring transitions mark their output places (xtrans2 procedure). Here follows the execution algorithm in a C-like pseudo-language (the term 'trans' stands for a generic transition; the term 'place' refers to places of both resource and queue types):

Xnet() /* Net execution module */ {

set up initial values in Time Table do {

xslot_start()

xslot_end() } while(not empty(Time Table));

}

xslot_start() /* starting time slot execution module */ {

while (there are enabled immediate transitions) xtrans0(trans)

for all trans

xtransl(tra~s) /* consume input tokens */ )

xslot_end() /* ending time slot execution module */ {

for all trans expiring at next Time Table entry xtrans2(trans) /* produce output tokens */

}

The phase 0 deals with zero time transitions (i.e. short-circuits, immediate transitions, which must fire in null time). It is worth noting that the 'for all trans' pseudocode shown above is simplified: in each time slot, all transitions are selected by

PETRI NET BASED PROCESS S C H E D U L I N G IN FMS l l 3

a hashing random algorithm: this avoids unwanted priorities among concurrent transitions.

Another point about the management of immediate transitions is shown below in the xtransO procedure: in xs lo t s tar t , the first two lines of code, regarding the immediate transition loop, are in their turn looped until no further immediate transition is available. This allows the management of chains of immediate transitions. It is obvious that this solution implies that loops involving only immediate t rans i t ions are forbidden.

xtrans0(trans) /* immediate transitions management */

Transition trans {

if (the duration of trans is not zero)

return

Color = select(trans)

compute the firing probability of trans

if ( probability is 0 )

return

for all input places of trans unmark the place

for all output places of trans

mark the place )

xtransl(trans) /* first phase of (normal) transitions management */ Transition trans {

if (the duration of trans is zero) return

Color = select(trans)

if (Color == failure) return

compute the firing probability (P) of trans if ( P is 0 )

return

else if ( P is -I ) { /* there is a conflict */

trans = T_real_time_scheduler(trans); }

execute transition function code

send activation message to trans' controller

for all input places of trans unmark the place

]

select(trans)

Transition trans {

check firing rule and availability tables choose the firing color(s) for trans,

Color = UNKNOWN

if (no color available)

return failure

if (trans has more than one firing color)

if (C_real_time_scheduler available on trans)

Color = C real time scheduler(trans)


if (Color = = UNKNOWN)

/* there is no scheduler or it has failed */

Color = FIFO(list of ivailable colors)

return Color }

xtrans2(trans)

Transition trans {

if (the duration of trans is zero)

return

for all output places of trans mark the place

if (beyond deadlifie)

simulation is aborted

exit with an error message

FIFO is a function implementing the First-In First-Out policy, given a list of tokens.

The firing probability of a transition is a function depending on the status of its input places. It is used both in case of not availability of a real-time scheduling decision and to detect topological conflicts. This computation might be complicated because such a transition status may depend on the status of neighbor places (for example, in case of topologic conflicts). Here follows a simplified algorithm:

probability(trans)

Transition trans {

double prob = 1.0

for each input place p of trans

prob = prob * prebplace( p, trans )

if( T_real_time_scheduler available )

if( 0 < prob < 1 ) /* topological conflict */ return -I

/* the special-purpose real_time_scheduler is not available for this transition:

in this case, the default PN executor scheduling strategy is invoked */

random = pick up ~ number between 0 and 1 if( random > prob )

return 1

else

return 0 }

The probability of a transition t r a n s to fire with respect to p is a number between 0 and 1 computed as follows:


prob_place( p, trans )

Place p

Transition trans {

int counter = 0

for each transition in output of p except trans {

if (transition already scheduled)

continue

if (duration of transition is zero)

continue

if (transition can fire)

counter = counter + 1 }

if(counter is not zero)

return 1/counter

else

return 1.0

l l5

6. The Scheduling Subsystem

PN theory does not provide any conflict-solving method: the firing rule does not specify, for example, which of the conflicting transitions must fire and when.

As previously stressed, decision situations play a fundamental role in the net evolution; the decision level should deal with two basic problems:

(i) conflict solving; (ii) guiding the net execution towards the (sub)optimum solution (based on time,

costs, etc.).

These two aspects are, of course, deeply interconnected since they both rely on the choice of a path at a decision point, which in most cases is a conflicting situation. Before describing in further detail the structure of the scheduler, the conflicting situations will be briefly discussed.

6.t. CONFLICTING SITUATIONS

Some critical situations are possible, which can be classified in the following categories:

(i) a topologic conflict (Figure 7a), (ii) a color/project conflict (Figure 7b),

(iii) a duration indeterminacy (typically W-transitions) (Figure 7c), (iv) mixed situations, typically a simultaneous topologic and color conflict

(Figure 7d).

A topologic conflict arises when a single token could enable more than one transition in a mutually exclusive way: a decision must be taken, regarding the

116

("~. MI t I . ~ )

\i ~ ' i I I l £ [ : r ] IIL?.

\

ANTONIO CAMURRI ET AL.

/ /

/ / 1

/ fZ : I l l

t 1 I

t G

(it"' /

-

1 O

,~ ]~1~ l _ Q u e u e l jf',~...,

~l ITIu I l!Tita

Fig. 7. Conflicting situations.

transition to activate. In the FMS environment, this means that at least two machines, able to process the incoming pallet, exist; therefore, there is the need to establish a policy according to which the most suitable processing cycle for that particular pallet is decided. A colour conflict concerns the transitions enabled at a given time, characterized by multiple enabling sets of tokens of different colors. In this case, the decision depends also on token semantics, i.e., it is affected by the role the token plays in the specific problem instance. This means that a single machine could find multiple pallets ready for processing at a given time, and there is the problem of choosing which of them must be chosen first, and which must be delayed. It is worth noting that the decision might also take into account possible further tokens (project) which are not yet available, but will be generated in the 'near future', by one of the preceding transitions. That is, an enabled project can be delayed for giving precedence to another one which is going to be ready for execution. This allows a sort of 'branch in the future' in the scheduling process. For example, let us consider Figure 6: a project available for execution in place I__queue2, can be delayed to wait for another project currently running on one between the W1 and W2 wait transitions. This can be done very simply using the data structure of the PN, which reflects the topological features of the problem: a similar behavior is considerably more difficult and ineffi-

PETRI NET BASED PROCESS SCHEDULING IN FMS 1 17

cient in traditional simulation algorithms, based on simpler data structures, which

require time-consuming search processes on tables, for finding the possible connected

tasks. The third critical situation is a typical case of duration with soft constraints, i.e.,

without a fixed time limit. In this case, since the net is intrinsically deterministic, a decision should be taken on the length of this time duration, in the allowed time span. Soft constraints are used in FMS language to give the decision system a degree of freedom in order to minimize input queues for the machines. Queues may in fact cause stocking problems in real applications, and they should be avoided to limit the cost

of additional stockage. Of course, some of the above described situations may occur simultaneously, and

a cooperation mechanism among the strategies should be taken into account. A real-time scheduling subsystem has the role of a decision-maker, for the previous

cases. It utilizes the knowledge stored in the KB, both on the structure (high-level, definitional component of the KB) and on the features of the particular problem (lower level, assertional component), including the optimizing criteria. The following consideration should be taken into account in the definition of a feasible scheduler: the optimum solution is generally not available in a reasonable amount of time, for real world cases. For example, in our FMS case study, we have to cope with a lot of tasks and resources, even in easy application problems. Therefore, only local (or quasi-local, as we have seen) decision-making processes are realistically manageable, to have reasonable response times from the system.

In the following sections, two sample scheduler architectures are examined.

6.2. A MONTE CARLO-LIKE GENERAL-PURPOSE SCHEDULER

One of the easiest, general purpose schedulers which could be conceived is the Monte Carlo-like schema depicted in Figure 8. The PN is run allowing the random default choice to solve topologic conflicts. The output is then evaluated by a special module which decides, on the bases of prior evaluation, whether to re-run the net or to output the current best result. A memory of past choices can be defined, so that, based on simple heuristics, the repetition of simulations already discarded can be avoided. This decision to re-run the net could be taken either by setting a fixed number of iterations or by constraining the variance of the simulation within a limit, or by any other method. The basic advantage of this schema is its flexibility, since it is problem independent. This, on the other hand, can result in poor performance because of the trade off time versus quality of the solution. The more iterations allowed, the better the solution found (apart from some degenerated situations). The most outstanding disadvantage is that it is not feasible in a real-time environment, where time limits are tight and a good decision is to be found in a short, fixed amount of time. Therefore, this scheduling mechanism should be used only for off-line planning in small/medium size problems. With these hypotheses, it is reasonable to think the algorithm can lead to a good suboptimum schedule. This method is also good in real-world applications

118

Executor

ANTONIO CAMURR[ ET AL.

Fig. 8.

Evaluator

( , , B e s t ~

A Monte Carlo-like schema.

where it is not possible to have precise a-priori information, and only an overall statistic is provided.

6.3. SPECIAL PURPOSE SCHEDULERS

In this section we describe some problems which can arise in the definition of special purpose schedulers, based on the FMS case study previously introduced. A simple special purpose scheduler has been developed to train our architecture to this kind of application. The focus is on the flexibility of our system architecture, which allows an easy integration of scheduling mechanisms. Different, mixed scheduling strategies can be defined based on other criteria, not only on the time constraints as in this sample scheduler. It is easy to define a scheduling strategy, in the colour conflict case, based for example on the above discussed 'branch in the future' case. It may happen that several pallets are ready to be processed on the same machine at the same time. We call R this set of tokens. A decision on which pallet should be selected first must be taken.

A naive solution gives precedence to the pallet belonging to R with the most tight schedule. A more sophisticated solution could take into account also possible tokens currently processed by a preceding transition. Let us call F the (possibly void) set of such tokens. In this case, the selected token could be the one with the tightest schedule in both the sets R and F. If there is more than one token, a precedence is given according to a FIFO policy among those already present in the set R.

The colour scheduler is realized by means of the function C real timescheduler, called by the executor algorithm, which takes into account the pool of conflicting

PETRI NET BASED PROCESS SCHEDULING IN FMS 1 19

pallets and returns the selected one. There are three criteria adopted in turn to reach

the best choice in our case: at first, the pallet with the closest d u e d a t e is chosen; on the other hand, if no d u e d a t e is specified for any pallet, the deadline is taken into

account. As a last attempt, a random choice is allowed; that is, if no expiring dates are specified, all the pallets are here considered to hold the same priority.

This can be expressed by the following algorithm:

fill the sets R and F

FirstDue = set of project(s) whose due date is specified and closest

in sets R and F

FirstDead = set of project(s) whose deadline is specified and closest

in sets R and F

if (FirstDue not empty)

select a project p from FirstDue and present in R

if (p does not exists)

select a project p from FirstDue and present in F

return p }

if (FirstDead not empty) {

select a project p from FirstDead and present in R

if (p does hot exists)

select a project p from FirstDead and present in F

return p }

return UNKNOWN /* the scheduler is not able to choose */

/* in this case, the executor is demanded to determine a default,

choice (a FIFO policy in our case), see the code of the function

select() */

Another conflicting situation could arise if two or more machines are competing in order to get a pallet ready for processing; this means that only one of these transitions is allowed to fire. This is a topological conflict. In this situation there is of course no ambiguity as to which project to choose: a decision is to be taken on which transition must be fired. In FMS language, it can be stated that a task could be performed in several different ways and the most profitable combination of human and machine resource must be found. The assumption here chosen is to fire the fastest transition, provided this decision does not damage any incoming project. In other words, if one of the transitions immediately above the conflicting one is processing a project which should be given precedence due to its time limits, then it may be chosen to leave the fastest transition to such a job and to fire the next fastest transition for the current job. This is not, of course, the only choice that could be made; other heuristics could be designed, for example to take into account the resource costs and to combine it with the deadline of the project.

The algorithm is straightforward: the procedure T real time scheduler is invoked by each transition. If there exist conflicting transitions, they are detected, and among them, the two transitions with minimum duration are selected. The upper transitions are then examined to see if there exist an incoming project which is likely to be running out of time and which could take advantage of finding the quickest transition waiting for it. If such a project is found, then the current project is assigned


the next fastest transition, otherwise, the fastest transition is chosen. The discarded transitions are then marked as already examined, so to save computation time; in this

way, they will not be taken into account anymore as likely to be scheduled for the current time slot.

In pseudocode this is expressed as follows:

detect the conflicting transitions select the fastest two transitions check for possible incoming projects which could be given precedence

mark discarded transitions as already considered return firing transition

The most general problem which could be solved by the net includes also the definition of compulsory time delays between consecutive tasks. Such delays can be generally defined as a time interval indicating the minimum and maximum delay allowed between the tasks. A decision should be taken, in a deterministic environment, as to which duration to adopt, whether the minimum or the maximum or maybe an intermediate one. Since Petri nets superimpose time delays on the projects (there can be conflicts or the desired transition could be already busy), it is reasonable to adopt a fixed time delay as the minimum. This choice seems to be satisfactory also from the theoretical point of view, since it minimizes the probability that the sum of net's delay with the fixed delay would exceed the maximum interval allowed.

Therefore, the algorithm of the W r e a l t i m e s c h e d u l e r here only assigns the minimum time delay to the transition, instead of a random duration, for example.

7. Experimental Results

The architecture described in this paper has been implemented in different versions, running on both Unix and PC/MS-DOS platforms [9, 8]. The software system, called FMS-PTX, is based on the PETREX C Tools software library [11]. The Unix version is currently used in a joint industrial project for the simulation and real time control of a large-size system (a blast furnace). This version is implemented under a real-time asset of Unix (DEC RT-Ultrix, on a DEC workstation 5000/240). In Table I, a

Table I.

Total ExecTime (sec) Transitions (#/sec)

Sun 4/280 SunOS 4.0.3 12.00 5,000 IBM Risc 6000/520 AIX 3.l.5 4.75 12,632 DEC 5O00/24O Ultrix 4.2 3.00 20,000 PC 486 33Mhz MS-DOS 5.0 9.10 6,593

The benchmarks has been done using the standard C compilers, with the default optimization (level 1).


benchmark on the performance of the system kernel is shown, under the following hypotheses: the test PN model has 60 000 scheduled transitions, with 10 000 topological conflicts; at each transition firing, a single-statement rule, involving floating point computations, is executed. The table gives the total execution time and the number of transitions scheduled per second.

8. Conclusion

We presented a class of algorithms for the sub-optimal solution of a particular class of problems of process scheduling. The global hybrid approach for the problem specification has been discussed. A case study, regarding the design of the coordination and the real-time scheduling subsystems of an FMS, has been adopted in the paper. The approach described in this paper is based on both an extension of PNs and object-oriented, structured knowledge representation paradigms. The paper focuses on the former, i.e. a Timed Colored Petri net based process scheduling system.

STCPNs have been introduced as a modeling tool for the coordination subsystem, defining its major innovative features, such as the object oriented Macro Structure, and enlightening its basic differences from other existent PN-based approaches. The method for the automatic construction of a STCPN model starting from an FMS knowledge base has been described.

Basic algorithms and ideas have been presented for the dynamic behavior of the coordination subsystem and for the scheduling policies of the real-time scheduling subsystem. In particular, the algorithms for an original asynchronous discrete events simulator/animator of STCPNs has been described in detail. Furthermore, some experimental results on the real-time capabilities of the kernel of the implemented Petri nets executor have been shown in Section 7.

We have seen that the design of efficient heuristics for driving the token flow is deeply connected to the problem class structure. Given a problem class, the high-level formalism, briefly described in section 3, allows us to design and to specify proper scheduling heuristics modules, based on some given optimization criteria. The high- level component is devoted to the description of both the problem specification and the heuristics and criteria description. Strategies are described by means of this formalism, and a schedule generator module automatically converts them into executable code. Therefore, starting from this high-level model representation, it is possible to derive automatically both particular PN-based models of a problem, as described in the paper, and particular scheduler software modules. The resulting system is thus capable of generating ad hoc software environments for any problem in the class defined at the high level, operating as a sophisticated CASE tool.

Acknowledgements

We acknowledge many useful discussions with Marcello Frixione about knowledge representation issues on SI-nets. We also thank Riccardo Minciardi and Pier Paolo


Puliafito for the useful discussions on the FMS case study, and the referees for helpful comments.

This work is partially supported by Special Projects on Robotics and Artificial Intelligence of the Italian Ministry of University and Research (MURST 40%) and of the National Council of Research (CNR-PFI2, grant no.18/89.00562.67/ 115.14231).

References

1. Ajmone Marsan, M., Balbo, G., and Conte, G., A class of generalized stochastic Petri nets for the performance evaluation of multi-processors systems, A CM Trans. Comput. Syst. 2(2), 93-122 (1984).

2. Ajmone Marsan, M., Balbo, G., and Trivedi, K. (eds.), Proc. IEEE/ACM Int. Workshop Timed Petri Nets, Torino, Italy, (July 1985).

3. Allen, J.F., Towards a general theory of action and time, Artificial Intell. 23, 123-154 (1984). 4. Anderson, D.P. and Kuivila, R., A system for computer music performance, ACM Trans. Comput.

Syst. 8(1), 56-82 (1990). 5. Anthonisse, J.M., Van Hee, K.M. and Lenstra, J.K., Resource-constrained project scheduling: an

international exercise in DSS development, Note OS-N8702, Centre for Mathematics and Computer Science, Amsterdam, the Netherlands (1987); also in J. Decision Support Syst. (1989).

6. Balbo, G., Chiola, G., Franceschini, G., and Molinar Roet, G., Generalized stochastic Petri nets for the performance evaluation of FMS, Proc. IEEE Int. Conf. Robotics and Automation, Raleigh, North Carolina, March 1987, IEEE Computer Society Press, pp. 1013-1018.

7. Bruno, G. and Morisio, M., Petri-net based simulation of manufacturing cells, Proc. IEEE Int. Conf. Robotics and Automation, Raleigh, North Carolina, March 1987, IEEE Computer Society Press, pp. 1174-1179.

8. Camurri, A. and Franchi, P., An approach to the design and implementation of the hierarchical control system of FMS combining a structured knowledge representation formalism and high-level Petri nets, Proc. 1990 IEEE Int. Conf. Robotics and Automation, Vol. 1, Cincinnati, USA, IEEE Computer Society Press, (1990), pp. 520-525.

9. Camurri, A. and Frixione, M., Structured representation of FMS integrating SI-nets and high-level Petri nets, Appl. Artificial Intell. 4(2), 109-131 (1990).

10. Camurri, A., Poggi, A., Vercelli, G. and Zaccaria, R., A-Nets: Structured representation of time and actions using Petri nets, European Workshop on Application and Theory of Petri Nets, Venice, June (1988).

11. Camurri, A. and Troiano, E., PETREX: a software tool for system modeling and simulation based on Petri nets, Proc. AICA Annual Conference, Trieste, Italy, (1989), Associazione Italiana Calcolo Auto- matico.

12. Dannenberg, R.B., A real time scheduler dispatcher, Proc. 1988 Intl. Computer Music Conference, Cologne, 19-24 Sept., I988, ICMA, San Francisco, CA, pp. 239-242.

13. Faulk, S.R. and Parnas, D.L., On synchronization in hard-real-time systems, Comm. ACM 31(3), 274-287 (1988).

14. Genrich, H.J. and Lautenbach, K., System modelling with high-level Petri nets, Theoret. Comput. Sci. 13, 109-136 (1981).

15. Gentina, J.C. and Corbeel, D., Coloured adaptive structured Petri net: A tool for the automatic synthesis of hierarchical control of Flexible Manufacturing Systems (FMS), Proc. IEEE Int. Conf. on Robotics and Automation, Raleigh, North Carolina, March 1987, IEEE Computer Society Press, pp. 1166-I 173.

16. Gonzales, M.J. Jr., Deterministic processor scheduling, Comput. Surveys 9, Sept. (1977). 17. Jensen, K., Coloured Petri nets and the invariant method, Theoret. Comput. Sci. 14, 317-336 (1981). 18. Lawler, E.L., Lenstra, J.K., and RinnooyKan, A.H.G., Recent developments in deterministic sequenc-

ing and scheduling: A survey, in Proc. NATO Advanced Study and Research Institute on Theoretical Approaches to scheduling Problems, Durham, England, July (1981); also in M.A.H.Dempster et al. (eds), Deterministic and Stochastic Scheduling, D.Reidel, Dordrecht


19. Loy, G., Designing an operating environment for a real time performance processing system, Proc. 1985 Int. Computer Music Conf., Burnaby B.C. (1985), ICMA, San Francisco, CA, pp. 9-13.

20. Martinez, J., Alla, H. and Silva, M., Petri nets for the specification of FMSs, in A.Kusiak (ed.), Modeling and Design of Flexible Manufacturing Systems, Elsevier, Amsterdam (1986), pp. 389-406.

21. Martinez, J., Muro, P., and Silva, M., Modeling validation and software implementation of production systems using high-level Petri nets, Proc. IEEE Int. Conf. Robotics and Automation, Raleigh, North Carolina, March 1987, IEEE Computer Society Press, pp. 1180-1185.

22. Mok, A.K., The design of real-time programming systems based on process models, Proc. IEEE Real Time Systems Symposium, Austin, Texas, Dec 1984, IEEE Press, pp. 5-17.

23. Pagnoni, A., Stochastic nets and performance evaluation, in W. Brauer, W. Reisig, and G. Rozenberg (eds), Advances in Petri Nets 1986, Lecture Notes in Comput. Sci. 254, Springer-Verlag, New York (1987).

24. Peterson, J.L., Petri Net Theory and the Modeling of Systems, Prentice-Hall, New York (1981). 25. Petri, C.A., General net theory, in B. Shaw (Ed.), Proc. Joint IBM and University of Newcastle-upon-

Tyne Seminar (1976), pp. 131-169. 26. Reisig, W., Petrinetze, Springer-Verlag, Berlin, Heidelberg (1982). 27. Sahraoui, A., Atabakhche, H., Courvoisier, M. and Valette, R., Joining Petri nets and knowledge

based systems for monitoring purposes, Proc. IEEE Int. Conf. Robotics and Automation, Raleigh, North Carolina, March 1987, IEEE Computer Society Press, pp. 1160-1165.

28. Shoham, Y., Temporal logics in AI: Semantical and ontological considerations, Art~cial Intell. 33, 89-104 (1987).

29. Xu, J. and Parnas, D.L., Scheduling processes with releases times, deadlines, precedence, and exclusion relations, IEEE Trans. Software Engrg. 16(3), 360-369 (1990).

30. Lung-Chen Liu, and Horowitz, E., A formal model for software project management, IEEE Trans. Software Engrg. 15(10), 1280-1293 (1989).

petri net based process scheduling: a model of the control system of flexible manufacturing systems

Documents