SCHEDULING AND SIMULATION
4. CASE STUDY IN SEMICONDUCTOR MANU- FACTURING
4.3 Software implementation of the shifting bottleneck heuristic
4.3.1 Implementation approach
It was the goal of our research to develop a scheduler prototype to test the applicability of the shifting bottleneck heuristic for realistic scenarios in a dynamic production environment. The anticipated problems in runtime performance and memory usage of the application resulted in a number of requirements for the selection of the programming language and the efficiency of the data structures used. Since we did not intend to shift the focus of our research work to implementation issues, we tried to apply mainly commercial or semi-commercial software libraries.
We implemented the scheduler prototype in the programming language C++ because it generates fast and efficient code. In addition, there are many software libraries developed in this programming language. The third reason for selecting C++ was the opportunity of designing our application according to the object-oriented paradigm fi*om which we expected several advantages concerning the complexity of the prototype implementation.
4.3.2 Efficient data structures
The execution speed of the prototype is mainly determined by the applied data structures. In our case, the software implementation of a disjunctive graph plays an important role.
The reason is that, during the execution of the scheduling algorithm, such a graph has to be traversed completely from the source to the destination nodes and back repeatedly to compute the start and end times for processing the jobs. As a consequence, we have to select a data structure that facilitates that in a fast manner. Apart from that, we modified the scheduling algorithm in order to minimize the number of traversals. In general, this was possible only by increasing the memory usage of the algorithm by storing intermediate results in an additional data structure.
Another problem that had to be solved by means of special data structures was avoiding cycles in the schedule. Cycles are not allowed in a
feasible schedule. During schedule computation it is possible that the algorithm generates cycles because the exact cycle times of the tool groups are available only at the end of the algorithm. If no additional precautions are taken the final schedules may have cycles. We avoid the generation of cycles in our prototype implementation by means of additional data structures that store precedence constraints.
Apart fi'om the representation of disjunctive graphs, lists for collecting pointers to business objects are the most important data structures. AVL trees are used to facilitate efficient access to these lists. AVL trees are binary trees that are balanced with respect to the height of their subtrees (Ottmann and Widmayer, 1996).
4.3.3 Generic approach for integrating subproblem solution procedures
We chose an object-oriented approach for developing subproblem solution procedures (SSPs). The basic idea was to implement an abstract class named "Subproblem Solution Procedure" that encapsulates all fiindamental characteristics of a SSP for the shifting bottleneck heuristic. We integrated the following abstract concepts into the class "Subproblem Solution Procedure."
• Management of schedules for parallel tools; the schedules contain the combination of lots to adequately represent scheduling entities, i.e., batches can be represented in the schedules,
• Management of reference schedules,
• Avoidance of cycles in the disjunctive graph due to scheduling decisions on a tool group level,
• Transformation of a node set from the disjunctive graph into a lot set for which a tool group schedule has to be computed,
• Communication of the schedules to the shifting bottleneck heuristic, and
• Selection of alternative performance measures.
On the second level of the heritage hierarchy we derive fiirther relatively general classes from the abstract class "Subproblem Solution Procedure,"
e.g., "Dispatched Subproblem Solution Procedure." The basic characteristic of these derived classes is to consider always only jobs that are actually available at the instant of the scheduling decision.
In concrete classes that provide a certain scheduling solution approach, we only have to implement the solution algorithm in its "Solve_Problem"
method. As a consequence, we are able to integrate C++-based optimization libraries in a straightforward manner. For instance, we integrated the GaLib library for Genetic Algorithm methods (Wall, 1999; Voss and Woodruff, 2002) into our prototype.
4.3.4 Simulation-based approach for performance evaluation We use a generic architecture for performance evaluation as described in Monch et al. (2003). The core of this architecture is a blackboard-type data layer that contains all objects that are relevant for the scheduling decision.
We consider the following types of information:
• Dynamic data
Lot release information for new orders, Status information of the tools,
Status information of the lots (each order is split into a set of lots), and
Setup conditions of the tools.
• Static data
Order-related process plans, Operation-related resource lists.
Setup times, and
Information required for the computation of processing times for the operations.
• Statistical data
Actual start time of an operation, Actual tool used for an operation.
Order completion times, and Utilization of the tools.
• Control data for the production system Planned start time for an operation.
Planned tool for an operation, and Tool schedules.
The data blackboard is implemented in C++ and kept in the main memory of the computer. At periodic intervals the data objects are saved into an object-oriented database. The objects are updated by simulator events. In return, we transfer schedules to the data blackboard. They are provided as tool dispatch lists that are used by the simulator. The architecture has the advantage that we need little effort to integrate the prototype into an existing shop floor control system. We need only to replace the interfaces between the blackboard and the simulator by interfaces to a real factory information system such as a MES or the ERP system.
Figure 5-4 depicts the developed architecture.
In our prototype, we use the discrete event factory simulator AutoSched AP 7.2 and the object-oriented database POET. We note that the development of the prototype took over five person-years of effort.
ASAP Simulation Model
Dispatcher
MES and ERP System
Dispatcher
Blackboard Data Modell Shifting Bottleneck Heuristic
OODB
Figure 5-4. Performance assessment architecture for the Shifting Bottleneck heuristic.