Object-Oriented Design of a Modular Scheduling Architecture

Object-Oriented Design of a Modular Scheduling Architecture P. Brandimarte Dipartimento di Sistemi di Produzione ed Economia dell’Azienda, Politecnico di Torino, Torino, Italy Submitted by R. Levi (71, Politecnico di Torino, Italy Received on January 10,1999

Abstract The importance of finite-capacity schedulers is increasing, with respect to the widespread MRP packages, due to their ability to model the shop floor more accurately. However, this very advantage may turn into a disadvantage. since it is quite difficult to devise a high-quality general purpose scheduler able to cope with the technological peculiarities of different production environments. Furthermore, a detailed schedule is prone to disruptions due to the uncertainty affecting the shop floor. Hence, we need both a modular approach to devise and assemble local schedulers and a way to link predictive and real time scheduling. To cope with both requirements, we propose a scheduling approach based on a generalization of the well-known shifting bottleneck method. The scheme is based on the coordination of local schedulers by a general scheme, such that the knowledge needed to cope with technological peculiarities is locally confined. The aim of the coordination mechanism is to generate a set of local due dates .which can be used as targets to drive real time dispatching. Keywords: Production scheduling, Object-orientedprogramming, Conceptual modeling

1

INTRODUCTION

Detail machine scheduling has been the subject of intense academic research since the early work carried out in the 50s. However, the practical application of scheduling software is a much more recent tendency; furthermore, this is probably due to the increase in computing power and the development of good user interfaces, rather than to algorithmic breakthroughs. Another reason is that the implementation of MRP systems, despite their well known limitations, laid down the necessary data foundations to introduce finite capacity schedulers. Detail schedulers are based on a relatively accurate model of the shop floor and are intrinsically able to cope with capacity constraints. This should result in better performances from the point of view of flow time reduction, saving in setup costs, and respect of due dates. However, detail schedulers do have some disadvantages. The first issue is that it is difficult to come up with a general purpose approach; dispatching rules are efficient and flexible, but the results are not always good. Another difficulty is that a detailed schedule carries too much information and is vulnerable to disruptions. Since we have to cope with a stochastic environment, we need a better tool to drive real time dispatching. In some sense, schedulers should yield a reference trajectory. A way to exploit reference trajectories is described, e.g., in [l]; however that approach is suitable when continuous flows are a reasonable approximation, and this is certainly not the case in small batch manufacturing. To summarize the preceding observations, we need a modular and robust approach. From these points of view, MRP systems have some good points. Basically, a MRP system generates a set of planned orders on the basis of a simplified but quite general model of the production f a c i l i (a lead time). These orders are associated to release times and due dates, which can

Annals of the ClRP Vol. 48/1/1999

be used as a reference trajectory. The problem with MRP systems is that they are strictly hierarchical and that the model on which they are based is not realistic. Still, we may try to overcome such limitations by exploiting an advanced algorithmic framework in a modular and robust way. The algorithmic knowledge is provided by the Shifting Bottleneck paradigm, described in section 2, which can be extended within an object oriented modeling framework, as described in section 3.

2

THE SHIFTING BOlTLENECK CONCEPT AND ITS EXTENSIONS

2.1 The basic Shifting Bottleneck algorithm The Shifting Bottleneck (SB) procedure was originally proposed in [2] for the classical

J // c,, scheduling

problem, i.e. the minimization of makespan in a job shop environment. The idea is to decompose the multimachine scheduling problem into a set of single machine subproblems. The single machine subproblems are of the

1/ I;: / L,,

type, i.e. they require to minimize the

maximum lateness, subject to release time constraints. The local release times and due dates characterizing the single machine problem apply to the single job operations. They define a time window which is not a real problem datum, but a way to coordinate the subproblems. The local time windows are computed on the basis of a disjunctive graph representation of the overall problem. Consider, for instance, a flow shop consisting of three machines, where three jobs must be processed. The problem can be represented by the disjunctive graph depicted in fgure 1. Operations are represented by nodes: nodes 0 and 10 are dummy nodes, corresponding to the start and end of the schedule, whereas nodes (1,2,3) represent the three operations of job 1; similarly, nodes (4,5,6) and (7,8,9) correspond to

365

jobs 2 and 3 respectively. Solid arcs (conjunctive arcs) represent technological precedence constraints; dotted arcs (disjunctive arcs) represent scheduling constraints (i.e. two operations to be executed on the same machine cannot overlap: the selection of an orientation of a disjunctive arc specifies which operation is executed before the other one). In figure 1 only the disjunctive arcs of machine 2 are represented. If machine 2 is the bottleneck, then each of its operations ( 2 3 8 ) can be scheduled taking into account a release time given by the processing time of the preceding operations (the head of an operation) and a due date, related to the processing time of the operations after the one we are considering (the tail of an operation).

Figure 1: Disjunctive graph representation of a simple scheduling problem. The results obtained by sequencing the single machines are progressively frozen, in order of machine criticality; in other words when a machine is scheduled, the corresponding disjunctive arcs are oriented, changing release times and due dates for the remaining machines. Bottlenecks are spotted by solving the single machine subproblems and measuring machine criticality by the maximum lateness of the schedule.

2.2 Extensions of the basic SB scheme The original SB scheme was aimed at a rather academic problem: the objective function is the makespan, no alternative machine is given for an operation, and there is no technolagical peculiarity (such as setup times, batch processors, or assembly operations). Nevertheless, it is possible to adapt the approach to real l i e problems [3, 41. The crucial point is that in a real life problem the subproblems to be solved are not plain single machine problems, but more complex ones; for instance, if there is a batch processor for thermal treatments, we get a subproblem requiring to minimize the maximum lateness on a batch processor subject to release times. These subproblems may be nontrivial, but they are considerably simpler than the overall scheduling problem. Furthermore, the interaction among the subproblems is always based on release times and due dates. Structurally, we always get subproblems of the form

.../ ri,.../ L,,

. Assigning

release times and

due dates is the general coordination scheme, and it does not necessarily depend on the underlying scheduling subproblems. The common way to extend the SB procedure is to apply the method to an extended version of the

366

disjunctive graph [5], which is used to compute operation release times and due dates. Using the graph as a coordination mechanism has definite advantages in a deterministic setting, but it enforces a tight subproblem interaction. In fact, operations can be scheduled as soon as their predecessors have been scheduled. Since no gap is left in the schedule, we get a high-quality, but sensitive solution. The real time scheduler, which is part of the Production Activity Control (PAC) subsystem, has no room to react to unpredictable events. So, predictive scheduling produces a wealth of detail information which is not actually used. However, we can devise a different coordination scheme where more space is given to local schedulers; this is simply obtained by assigning time windows to local schedulers according to a suitable coordination strategy. The useful result of predictive scheduling is not actually the complete detail schedule, in terms of a Gantt chart, but the local release times and due dates which can be used as a reference trajectory to drive PAC. Note that, unlike MRP systems, these milestones are not given once and for all; they can be negotiated between each local scheduler and the coordinator module. Furthermore, they are realistic, since each local scheduler has the necessary knowledge to cope with the pertaining technological peculiarities. However, this knowledge is locally confined; modularity and extensibility are ensured by the fact that the coordinator communicates with different local schedulers only through the negotiation of time windows. Since modularity is so important, we also need a proper conceptual tool to design the overall system. This is provided by object oriented visual modeling methodologies, as described in the next section.

3

OBJECT ORIENTED MODELING

3.1 Object oriented conceptual modeling with UML The Unified Modeling Language (UML) is a visual modeling language, based on the integration of different object oriented software engineering methodologies developed over the years by its proponents [6]. It covers all the system design phases from the collection of user requirements, through analysis and design, to implementation. Different formalisms are used to capture different facets of the system, at different levels of detail. In this paper we just use two diagrams to illustrate the SB-based scheduling architecture, the class diagram and the sequence diagram. Other tools are actually used, such as use case diagrams to capture system requirementsfrom the users' point of view, state diagrams to capture complex dynamic behavior, and deployment diagrams to represent the physical structure of the system. The class diagram represents the static view of the system, i.e. the classes of objects on which the system is based and their associations. There are many types of association, ranging from simple ones (such as oneto-one and one-to-many associations) to more sophisticated ones (such as inheritance). By visualizing the overall class structure, the developer may design modular and maintainable systems. The sequence diagram depicts the sequence of object interactions which are used to implement some user requirements. Objects interact by exchanging

messages; each message invokes a method of the receiving object, and this diagram shows the sequence of exchanged messages in a given scenario.

3.2 An outline model of the SB based architecture In this section we aim at showing how the SB idea may be used to develop a modular and robust scheduler. We do not want to provide a detailed model, but just to give a glimpse of the application of UML to the design of a SB-based scheduler. One of the first steps in object modeling is, obviously, to start guessing which are the classes the system rests on. From the (limited) point of view of this paper, the two main classes are the coordinator and the local scheduler. In order to ensure modularity, we must hide the details of each local scheduling algorithm within welldefined boundaries, i.e. a common interface. The communication between different classes must be kept to a minimum. Each local scheduler just needs a time window, represented by the local release times and due dates for each operation to be scheduled. In principle, the coordinator only needs to know if each local scheduler can meet the proposed targets or not. We can sketch the rough cut class diagram depicted in figure 2. I

Coordinatcr

j

l..li 1..'I cI

Generic Local Scheduler

~

*Schedule(ReleaseTirn, DueDates) ' Status '

-

Consistency requires that the coordinator assigns nonoverlapping time windows to different operations of the same job; the release time of an operation is the due date for its predecessor. Tight time windows ensure schedule quality, but reduce real time flexibility. Different mechanisms, depending on the structure of the manufacturing system and on the presence of stable bottlenecks, may be used to assign and update time windows. Due to space limitations, we do not want to discuss such mechanisms here, but it must be emphasized that they do not affect the overall system architecture, but only the internal details of the coordinator. The negotiation between the coordinator and the local schedulers can stop when realistic time windows are obtained; however, negotiation can be stopped earlier, since we do not really aim at generating a detail schedule, but a set of realistic targets for real time scheduling.

1 Sched. 3 1

LF o c &

[Local Sched. 1

types of local scheduler. Any local scheduler must receive time windows and must try to find a schedule meeting these constraints by minimizing the maximum lateness. However, different schedulers can achieve this objective in very different ways. In fgure 2 we see how different local scheduler classes are linked to the generic class by an inheritance association. It should be emphasized that LocalSched1 is not a single object instance but a class; it could be a scheduler able to cope with parallel machines, whereas LocalSched2 and LocalSched3 could be schedulers able to cope with batch processing and sequence dependent setup times. This difference is reflected in how the Schedule and MinLmax operations are actually implemented, but it does not affect the interface (technically speaking, the signature of the method). The specific implementation is hidden from the coordinator, which only sees a generic scheduler; in other words the algorithmic SB framework is exploited within an object oriented architecture through the polymorphism mechanism of object oriented languages. It is also worth noting that, unlike MRP systems, time windows are in some sense negotiated between the coordinator and each local scheduler, since there is a two-way information flow between the two hierarchical levels. Each local scheduler may enforce cost constraints on the minimization of the maximum lateness (e.g., a very small batch is not allowed). In this sense the SB-based architecture leaves some autonomy to local schedulers. Furthermore, a local scheduler may manage a single machine but also a complex cell; in fact, it may have to schedule a single operation, or a complex task consisting of a set of operations related by a complex operations graph.

I

4

Fgure 2: A simplified class diagram pointing out the inheritance association among local schedulers. A class is represented by a rectangle showing its name, its attributes (none is actually shown in figure 2) and its operations (to be implemented by methods). The coordinator class has three operations: ImportOrders, which can be used to import orders from the higher levels, possibly from a MRP system, or from an order entry system; Setwindows, which is used in order to give an initial (tentative) time window to the local schedulers; Updatewindows. which can be used in order to update the time windows in the case one or more local scheduler cannot meet the time window targets. The diagram shows an association between the Coordinator class and the Generic Local Scheduler class: it is a one-to-many association, since many local schedulers can be coordinated by a single coordinator. The Generic Local Scheduler is actually an abstract class, which represents an abstraction of the different

A class diagram only shows the static structure of a system. To describe the dynamic object interactions, a sequence diagram can be used, such as the one depicted in figure 3. The diagram describes a scenario in which an external actor (the user) starts the predictive scheduling process by asking the coordinator to import a portfolio of orders. Then the coordinator sets the initial time window for each task to be camed out by the single cell and asks each local scheduler to schedule its tasks within the proposed time windows. Before solving each scheduling subproblem, the local scheduler must request a state update from the PAC object associated to each cell. If the status returned by all the local schedulers is OK, the predictive scheduling task is done.

367

5

Otherwise, time windows are updated based on the results, and the process is iterated.

REFERENCES

[l] Brandimarte, P., Sharifnia, A., Von Turkovich, B.F., 1996, Continuous Flow Models of Manufacturing Systems: a Review, Annals of the CIRP, 45/1:441444. [2] Adams, J., Balas, E., Zawack. D., 1988, The

4

CONCLUSIONS In the paper we have shown how a shifting bottleneck based algorithmic framework and object oriented modeling based on UML may be used together in order to outline a modular scheduling architecture. The resulting architecture is able to cope with unusual technological features and it is, in some sense, a generalization of the MRP order scheduling mechanism. Unlike MRP, the architecture explicitly deals with capaaty constraints and it is not strictly hierarchical. Local due dates are negotiated between the coordination and the local scheduling levels in order to obtain realistic targets to drive real time scheduling. We have only pointed out a vertical negotiation process: however, a horizontal negotiation process is possible between local real time schedulers in order to cope with schedule disruptions. This and other generalizations are the subject of ongoing research.

Shifting Bottleneck Procedure for Job Shop Scheduling. Management Science, 34:391-401.

[3] lvens, P.,Lambrecht, M., 1996, Extending the Shifting Bottleneck Procedure to Real-Life Applications, European Journal of Operational Research, 90:252-268. [4]

Ovacik, I.M., Uzsoy, R., 1994, Decomposition Methods for Complex Factory Scheduling Problems, Kluwer, Dordrecht.

[5] Demeulemeester, E.L., Herroelen, W.S.. 1996, Modeling Setup Times, Process Batches and Transfer Batches using Activity Network Logic, European Journal of Operational Research,

89~355-365. (61 Booch, G., Jacobson, I..Rumbaugh, J., 1998,The

Acknowledgments

Unified Modeling Language User Guide, AddisonWesley, Reading, MA.

The work described in the paper has been partially funded by MURST Project A M (Autocoordinamento Agenti Autonomi).

C

A user -

I

Genericlocal

I

1

i LocalSchedN : i Genericlocal

i

i t

I

orders am imported fmm an external system, possibly an MRP system

y 2: $stW"&%s

()

I

initial virwjann are set

3: Schedule(Releaselirnes. DueD scheduling requires to send &ease t h e s and dwt dates to the local, schedulers. H h i h get the actual state from the Rodcution Activity Control objects and call the algorithm to minimize Lmax

4: GetState

---d 7: GetState 8: Minimax( )

1 necessary, the time vhdons are updated and the process is repeated

Figure 3: A simplied sequence diagram

368

>

1