Testing, Comparison, and Implementation Issues Oliver Rosea and Lars Mönchb and Roland Sturmc a
Lehrstuhl für Informatik III Universität Würzburg 97074 Würzburg, Germany1
b
Institut für Wirtschaftsinformatik Technische Universität Ilmenau 98684 Ilmenau, Germany
c
Department Cleanroom Manufacturing Fraunhofer Institut Produktionstechnik und Automatisierung (Fraunhofer IPA) 70569 Stuttgart, Germany
ABSTRACT In this paper we provide an overview of the testing and development framework and implementation issues of our scheduling, statistical operational control, and rescheduling methodologies. Our primary testing and validation methodology will involve the embedding of our scheduling approaches into a simulation environment that captures fundamental components of wafer fabrication. This environment will simulate the information arriving to a Manufacturing Execution System (MES), and the scheduling and rescheduling routines will use this data to determine optimal or near-optimal schedules for the work. In this framework, we will be able to provide statistical estimates of the performance of our various approaches, and determine if we are improving over current practice. This task entails determining the appropriate software for this approach, the testing of the environment on simple dispatching rules, and then implementation and testing of our shifting bottleneck approaches. Finally, we will incorporate a signaling methodology and fully integrate it with a rescheduling approach, and provide a guide for implementing our approach and integrating it with MES systems.
1. INTRODUCTION The main purpose of the simulation environment is to emulate the behavior of a real wafer fabrication facility (wafer fab) during scheduler development. The scheduler requires 1
Email:
[email protected]
up-to-date fab data to compute the schedule. In turn we have to implement the resulting schedule in a running fab to assess its quality. I.e., we need the simulation environment both to generate data and to test the generated schedule. In addition, we have to take into account that the scheduler has to become a stand-alone tool by end of the project. Thus, the simulation environment must be designed in way that facilitates separating the simulation environment from the scheduler with little effort.
2. ARCHITECTURE 2.1 ARCHITECTURE FOR INTERFACING SCHEDULER AND SIMULATION MODEL In a real wafer fab, a production planning and control tool obtains its information via the message bus of the Manufacturing Execution System (MES), stores this information in one or several databases, and computes fab control information based on the information found in the database. Then it stores the control information in the database for evaluation purposes, and finally transmits it to the shop floor where the control actions take place at the work centers. ASAP Simulation Model
Dispatcher
The Real Fab (MES, ERP,...)
Dispatcher
Bus Scheduler Data Model
Figure 1: Structure of the Simulation and Testing Environment
In our design, we mimic the structure found in a real wafer fab (see Figure 1). The simulation model generates data, this data is sent to a data model of the fab that stores this information. The message bus is replaced by a set of functions providing a clear separation of data that resides inside the simulation model and data that is going to be transferred to the data model. The scheduler makes only use of the data stored in the data model to compute the schedule. No internal information from the simulation model is going to be used. The resulting schedule is stored in the data model for testing and to serve as reference data that is required when a decision has to be made upon whether to reschedule or not. The schedule is implemented in the fab by a set of functions.
The center and integrating part of the design is the data model of the fab. It contains both static data, like tool set or product routes, and dynamic data, like tool status information and lot locations. In addition, it is used to store measured and scheduled lot movement instants, like actual and planned ready or completion times. The data model has interfaces to the simulation model, the scheduler, and the rescheduling mechanisms. It is open to future extensions with respect to content and interfaces and it serves as a common database for all four tasks of the project. 2.2 ARCHITECTURE FOR INTERFACING SCHEDULER AND REAL WAFER FAB The future MES system is a distributed system with several components. Core components like Work In Process (WIP) tracking, Machine Management, Process Specification Management, Dispatcher etc. are necessary to control a wafer fab. The trend is that MES core components and external applications such as Equipment Control Software communicate based on a standardized middleware. Future IT architectures for wafer fabs must be open and comply with de jure or de facto standards such as Common Object Request Broker Architecture (CORBA) specification [1], CORBAservices specifications, several Semiconductor Equipment and Materials International (SEMI) standards, or COM/DCOM. Not all information required for the scheduling process is available in state-of-the art core MES components. For example planned wafer release is typically provided in planning tools such as Enterprise Resource Planning (ERP), Supply Chain Management (SCM) or order release planning software, availability and current locations of reticles is handled by reticle management systems, location of lots in the fab especially in the 300 mm area is handled by Automated Material Handling and Storage Systems and their control system framework or by Equipment Control Systems, etc. In order to obtain a stand-alone scheduler, the functions interfacing to the simulation have to be replaced by functions interfacing to factory IT systems such as MES and ERP. No further changes in the software itself are required by design. To be interfaced with little additional work to other control and planning applications in a wafer fab, the scheduler and the data model have to provide standardized interfaces for middleware communication. As specified by SEMI E-105-0701 [2], the following interfaces have to be established: •
Scheduling Service Interface: This is the interface for services by the Scheduler in response to requests from, e.g., the MES dispatching component or some other client.
•
Scheduling Factory Input Interface: This is the interface used by other components to provide updated static or dynamic factory state information to the Scheduler data model. The updates are typically lot-tracking information, order release information, current machine status information and process flow specification information.
3. SIMULATION ENVIRONMENT The main purpose of the simulation environment is to emulate the behavior of a real wafer fabrication facility during scheduler development. Therefore, the simulation software used in this project has to provide the functionality to model specific characteristics of wafer fabs in semiconductor industry such as large process flows, multiple products, high number of manufacturing equipment (resources), availability models (Mean Time To Repair, Mean Time To Failure, Preventive Maintenance) and semiconductor specific process and equipment timing models (batch processing, single wafer processing, lot based processing, etc.). Additionally, an event-based online communication between the simulation and the scheduling software has to be established in order to realize the control of the material flow in the simulator based on decisions of the scheduler software. The manufacturing-oriented simulation software systems Autosched AP (Brooks/ASI), AutoSched (Brooks/ASI), Arena (Rockwell Software), Simple++ (Tecnomatix Technologies/AESOP), ProModel (PROMODEL Corp.), FactoryExplorer (WWK) and ManSim (Tyecin Systems Inc., now: Manugistics Inc.) were selected for the comparison. These simulation software tools are widespread in semiconductor and other branches of manufacturing industry. Generalpurpose simulation software such as GPSS/H was not considered here due to the lack of manufacturing-oriented easy-to-use modeling capabilities. For the comparison we took into consideration the following requirements: •
Modeling large fab models,
•
Semiconductor specific timing features,
•
Ability to model different dispatch policies with little effort,
•
Availability of different work station types and semiconductor specific equipment,
•
Availability of modeling secondary resources,
•
Acceptance in the semiconductor industry,
•
Reporting and statistics for output analysis,
•
Model debugging,
•
Simulator customization flexibility,
•
Run time performance,
•
Ability of communication with external software modules during runtime,
•
Modern software architecture of simulator.
Based on these requirements AutoSched AP (ASAP) 7.1 was selected as the simulation environment to be used in this project. This decision was based on the evaluation results for general semiconductor modeling applications and the project specific requirements: •
Communication with external software systems (here the scheduling software),
•
ASAP models can be customized with C++ code,
•
General acceptance in semiconductor manufacturing industry, and
•
User-friendly building of large scale models.
In particular for modeling large wafer fabs in order to analyze capacity and to evaluate dispatch rules, ASAP is a simulation tool widely accepted in semiconductor industry. 4. IMPLEMENTATION The research group develops code with Microsoft Visual C++ 6.0 and Microsoft Visual Studio for C++ including templates and macros provided by Brooks/ASI. ASAP’s data structures are based on the RogueWave tools.h++ library. In order to avoid license costs for a future scheduler product we base our data structures on the Standard Template Library (STL) instead. The source code version/revision/release management is provided by a Concurrent Versions System (CVS) server located at the University of Würzburg. All developers obtain and update code via local CVS clients. The CVS client and server software is provided under GNU public license. The current release of the source code of the simulation consists of the following parts. •
Implementation of the data model A detailed description of the data model can be found in at the end of this section.
•
Initialization of the static information of the data model We parse the ASAP fab model text files to obtain static data, like tool set or product routes.
•
Update functions for the data model The data model update is event-driven. As soon as one of the following events takes place data is transferred from the simulation to the data model: lot enters fab, lot leaves fab, lot enters operation, lot enters load port, lot leaves load port, reticle new location, reticle new state, station new state. These events are mapped to ASAP internal events. ASAP has a notification/subscription/publication mechanism that facilitates calling of C++code upon ASAP internal events.
•
Starting the scheduler and delayed reception of its results We use custom lots with custom action lists to start the scheduler. After the action that runs the scheduler a delay can be set before the scheduler results are sent to the simulation model. This delay mimics the computation time of the schedule in a real wafer fab. In addition, the scheduler results are added to the data model.
•
Implementation of a scheduler ASAP rule In order to make use of the external schedule we implemented a custom rule that dispatches lots based on a lot list and start times that are provided by the scheduler. Each tool uses this rule for dispatching.
•
Implementation of a simple scheduler We wrote a FIFO scheduler for testing the above modules and interfaces. This dummy scheduler scans the list of waiting lots at each tool and writes this list of lots back to the simulation model after a given delay.
The ASAP simulation package provided the required support to transfer data from the simulation to the data model and offered interfaces to run the simulation model on the basis of the scheduler results. In addition to the development of the C++ source code, we had to modify a given wafer fab model to integrate the update functions and to replace the dispatch rule by our custom rule. The data model stores information required by the scheduler in order to compute new schedules. The data model allows a fast access to these data. It is a cache like data storage, that can be found in most of the modern advanced planning systems (e.g., SAP’s “Advanced Planner and Optimizer (APO)”). Advanced Planning Systems require a large amount of data from traditional ERP Systems and/or MESs. This type of cache was mainly introduced in such systems in order to avoid performance problems that occur while performing a large number of data base queries. We can distinguish between two types of data in the data model: •
•
Static data like o Information about process flows (technological routes), o Required reticles, o Setup information, o Existing tool sets, o Tool dedications, o Data for calculating processing times, and Dynamic data like o Lot release information, o Lot states, o Tool states, o Setup state of a certain tool, o Reticle states.
We segmented the data model in order to allow an appropriate storage of these two types of data. The data model is used in three different situations. 1. Initialization of the data model at the beginning of the simulation.
2. Update of the objects during the simulation run (or during the runtime of the scheduler in a real environment) in an event-driven manner. 3. The scheduler component reads information from the data model. The data model consists of classes representing business objects and classes that are used to encapsulate technical functionality. We focused on applying object-oriented modeling techniques, because these techniques allow for an easy integration of association and aggregation relations between the real-world objects found in a wafer fab into the software. The suggested class hierarchy is shown in Figure 2. Double-linked lists, containing pointers of the represented objects, are the basic abstract data structures that are used in the data model.
0..*
D_Lot
1
D_Factory
1..* 0..* 1
D_Order
1
1
1
0..*
D_Part
D_Setup 0..* 1
D_Route
1 0..*
1
D_Object
1..*
D_Setup_Pairs
1..*
D_Operation 1..* 0..1
D_Reticle
D_Station
0..*
0..*
1..* 1
D_StnFam
0..*
Figure 2: Class Hierarchy of the Data Model in UML Notation
In the future we try to use more sophisticated abstract data structures in the data model, that support the search for elements in a more efficient way. We identified hash tables and maps as candidates for abstract data structures that are appropriate for that task.
ACKNOWLEDGMENTS
The authors would like to thank Kai Hübner, Detlef Pabst, Andre Pfeuffer, and Jens Zimmermann for their programming efforts and valuable discussions. The team is partially supported by the Semiconductor Research Corporation (2001-NJ880). REFERENCES [1]
Object Management Group: CORBA/IIOP Specification 2.2 (www.omg.org).
[2]
Semiconductor Equipment and Materials International (SEMI): SEMI E105-0701, Provisional Specification for CIM Framework Scheduling Component.
