Proceedings of the 2002 Industrial Engineering Research Conference

A Structured Approach to Simulation Modeling of Manufacturing Systems

Douglas A. Bodner and Leon F. McGinnis Keck Virtual Factory Lab School of Industrial and Systems Engineering Georgia Institute of Technology Atlanta, Georgia 30332-0205, U.S.A. Abstract
Simulation is a powerful tool to analyze manufacturing systems for purposes of design and on-going operation. In recent years, simulation modeling and analysis have been enhanced significantly by increasingly powerful computational platforms. This has enabled development of high-fidelity models of manufacturing systems, at least from a computational perspective. Such high-fidelity modeling has important benefits in prototyping system performance; however, it must be supported by an underlying modeling discipline, or structured approach to modeling factory operations. In this paper, we describe results to date in specifying such an approach, based on a reference model of manufacturing systems. Results are implemented as generic code modules in SIMAN, and are demonstrated with a case study in semiconductor manufacturing.

Keywords
Computer simulation, manufacturing, reference model, modeling discipline.

1. Introduction
Modern manufacturing is characterized by high levels of automation and integration, complex interactions among system elements, and high capital costs. While modeling and analysis are important to help ensure good system performance, the integration and complexity of systems often makes purely analytic tools difficult to use. Hence, simulation remains one of the most widely used tools to fill this need. A number of commercially available software packages are in use both in industry and academia, including ARENA, AutoMod, QUEST and WITNESS. Such packages, and simulation in general, have experienced great improvements with recent advances in computational technologies. Specific improvements include graphical user interfaces to facilitate model-building, integration with spreadsheets and databases for better data management, and powerful capabilities to visualize and animate model execution. In general, increased computational power has enabled development of detailed "highfidelity" models of systems to aid in design and operation. The ability to create high fidelity models has important potential benefits in prototyping system performance. How does one go about creating these types of models? With increased complexity in manufacturing systems, increased model detail implies greater model development time. However, long model development time already is one of simulation's main drawbacks. We propose a structured approach to simulation modeling, or a modeling discipline, to be used to aid the model development process. While a discipline exists to some extent with the use of commercially available simulation software, it is not developed to the extent needed to enable high fidelity modeling. This situation has come about because, despite the recent innovations in simulation software, the underlying "languages" used by simulation packages have changed very little. In this paper, we propose an approach to start formalizing such a discipline. The remainder of this paper is organized as follows. Section 2 reviews the use of simulation modeling for manufacturing. In Section 3, we present the underlying model on which our simulation approach is based. Section 4 discusses our simulation modeling approach. Section 5 illustrates use of the approach in a semiconductor manufacturing application. Finally, Section 6 concludes with future research directions.

2. Simulation Modeling of Manufacturing

Discrete-event simulation is one of the most widely used methods to study, model, analyze, design and improve manufacturing systems. While simulation has many strengths, it has limitations that must be addressed to improve its effectiveness as a design and operational decision-support tool.

2.1. Manufacturing Systems and Simulation Most simulation efforts use commercially available simulation software. A number of packages are available, each with numerous features [5]. Most packages are based on the process-interaction modeling framework, in which a set of "processes" or "transactions" travel through a set of "blocks" or "resources" in the model. The processes are the active elements of the system, while the blocks are passive. An event occurs, or a future event is scheduled, when a process passes through a block. Clearly, one benefit is that this approach provides the modeler with built-in "infrastructure" for the simulation (i.e., event calendar, clock, etc.), so that the modeler may concentrate on specifying the model. In terms of modeling, this framework naturally enforces a "network-of-queues" representation of a factory, in which material (processes/transactions) flows through a set of machines and other resources (blocks). The processes follow a "seize-hold-release" behavioral pattern, which is appropriate in many respects for simple material flow modeling. Mujtabi [8] points out that traditional simulation approaches suffer limitations in representing the complex interactions that can occur in manufacturing, due to a lack of appropriate software tools/concepts. For example, one limitation is that traditional approaches are adequate for modeling passively scheduled systems, where decision-making is localized, but are not well suited for modern, integrated systems [1, 11]. Often, modelers must resort to ad-hoc coding in the simulation language (or often in the underlying programming language in which the simulation software is implemented). The seize-hold-release framework also does not model material handling systems well. Most simulation software, however, has adopted specialized material handling abstractions (e.g., conveyors) for this purpose. 2.2. Object-Oriented Simulation These shortcomings have spurred interest in new approaches to simulation. In particular, within the last ten years there has been significant research in object-oriented approaches to simulation of manufacturing systems [1, 7, 9]. The objectoriented programming (OOP) paradigm focuses on the specification of objects, with attributes and methods. Narayanan et al. [10] cite several advantages of the object-oriented approach, including modularity and re-use of code, natural mapping of modeling abstractions to manufacturing system elements, and explicit modeling of the manufacturing control system. Most object-oriented simulation research has resulted in implementations of simulation modeling architectures in such languages as Objective-C, C++ or Java. To date, however, these efforts have had limited direct impact on simulation practice. 2.3. Research Process In this research, we utilize a process used in developing object-oriented simulation approaches. Rather than focus on developing a "new language" for simulation, though, we seek to use existing languages/packages in a more disciplined manner, to serve as an aid to the "non-expert" simulation modeler who wishes to develop high-fidelity simulation models. We use the SIMAN language, from which ARENA is developed.

3. A Reference Model of Manufacturing

Our goal is to develop a set of domain-specific simulation modeling tools for manufacturing system. The first step in that process is to specify a reference model for manufacturing upon which the simulation tools are based. A reference model is a standardized representation for a problem domain such as manufacturing [3, 13]. In this section, we summarize a previously developed model used to develop object-oriented simulation modeling tools [4, 9]. 3.1. Domain Analysis In developing the reference model, we have used the process of domain analysis, which is used in software engineering for software modeling of complex systems [2]. In domain analysis, the goal is to organize knowledge about a class of systems or problems (i.e., the domain). Our domain is the set of discrete-parts manufacturing systems, with a primary focus on material flow modeling and control in these systems. Domain analysis is used to classify important manufacturing system elements, their structure, behavior and inter-relationships. 3.2. Reference Model The resulting reference model classifies manufacturing system entities along two main axes: plant vs. control, and processing vs. transportation. Elements in the plant classification comprise the physical factory, such as machines, material and transporters. Elements in the control classification comprise the logical factory, including decision-makers, performance evaluators and information about the physical factory. Elements in the processing classification focus on the intermediate transformation steps that turn raw materials into finished goods, while elements in the transportation

classification address the logistics of moving material through the various process stages. Table 1 shows this classification, and explicitly addresses the importance of material and information transfers/flows. Table 1. Reference model classification
Plant Machines, material processing operations, storage buffers, machine setup, inspection Operational Interface Commands Control Controllers, operators, machine state information, controller domains, process recipes, machine scheduling, process monitoring

Processing Functional Interface

Status updates

Material transfer via shared locations Commands

Status updates

Information transfer via networks

Transporters, conveyors, material movement operations Transportation

Controllers, operators, transporter state information, controller domains, material movement requests, process plans

Important elements in the reference model include the following. Material is processed as a set of jobs, each of which has a type, a space requirement and a process plan (set/sequence of operations that must be performed to transform a job so that it is finished). A location is a well-defined place that can hold, transport or process material. It has capacity and behavior. For example, a machine processing location can be "busy," "idle," or "failed." Its behavior also includes the set of operations that it can perform. The control system is increasingly important in today's systems. It is composed of a set of controllers that make operational decisions and communicate with one another. Controllers may or may not be organized into a hierarchy. An individual controller has a domain of responsibility (controller domain), which may for example be the set of machines in a cell controller's cell, or may be a device for a device controller. Material is transferred between domains through shared locations (visible to controllers of more than one domain). A controller maintains a representation of each entity with which it communicates (clients). The production system consists of the set of devices and controllers that transform material. An "operation-location map" specifies which operations can be performed at which processing locations. The transportation system consists of the set of devices and controllers that move material. A controller's "domain map" specifies which transporters or transport systems can move material from one location to another.

4. Domain-Specific Modeling Abstractions

Based on the reference model, we present a set of manufacturing-specific modeling abstractions for simulation, implemented in SIMAN. Our design goals are to promote the development of a simulation modeling discipline for manufacturing, and to provide a means to represent the control system explicitly. 4.1. Material and Process Plans Similar to traditional uses of simulation, we use simulation processes (called "entities" in SIMAN) as material, or jobs. A job's attributes are represented by SIMAN entity attributes, which are in an array format. The first attribute for any job entity, A(1), equals the job type. In addition, A(2) equals the current position of the job in its process plan; A(3) equals the space required by the job in terms of standard location sizes; and A(4) equals the number of "sub-jobs" contained by the job, if the system uses batching. Batching is represented using the SIMAN GROUP block, which combines job entities into one entity for handling purposes. Each job type has a unique process plan, which is represented as a record in the SIMAN TABLES element in the experimental frame, listing the names of operations to be performed. The easiest type of process plan to represent is a simple sequential plan. However, it is possible to represent other types, for example a rework loop, with a more complex use of the same TABLES element. When a job finishes a processing operation, its next operation can be looked up in the process plan TABLE, based on its job type, A(1), and its

A(2) attribute is incremented when it is moved to the next operation. The time for a processing operation is stored as a record in another TABLE, referenced by the operation ID, and represented as a distribution of processing times.

4.2. Locations, Material Processing and Material Transport SIMAN provides a RESOURCE block that traditionally is used to represent processing machines. Here, we use it as a basis for modeling a location. A location may be a processing location within a machine, or a storage buffer. A location's capacity may be set by the RESOURCE's capacity variable. Its behavior, in terms of states, is implemented as a state transition graph [12]. A processing location's event graph may contain only the states "busy" and "idle," or it may contain other states such as "failed" and "setup." A transition between states consists of an event (e.g., "complete" is the event transition from "busy" to "idle"). Complex event transitions are modeled using the SIMAN BRANCH block, which routes entities to various sections in the model code, each section representing a state. These sections of code are grouped into a sub-model to form the representation of the location. Figure 1 illustrates the implementation of an event graph for a particular location.

Figure 1. Device locations and event graphs The processing time, repair time and setup times shown in the figure can be set such that they are looked up from TABLES element containing these data (e.g., operation time). A machine consisting of several such locations can be created by coupling multiple RESOURCES within a sub-model. A transporter is modeled by use of a SIMAN TRANSPORTER block, which is similar to a RESOURCE block. In traditional simulation models, the job entities flow through the machines in the system according to the block structure of the simulation model. While such blocks as BRANCH allow for flexible routings, this representation enforces the passively scheduled system representation where decision-making is made at a local level. To represent the manufacturing control system more explicitly, we separate the plant representation from the control representation, similar to [6]. 4.3. Manufacturing Control System Our focus is to develop a generic controller representation that can be used to encapsulate material flow control decisions such as routing, dispatching and induction. Such control is an active process (i.e., the act of decision-making). Hence, we use SIMAN entities to model the flow of decision logic in a controller model. The controller model includes a generic block structure that handles the decision-making process. In this process, the controller acts similarly to a server in a client-server system. It receives a "service request" from a "client" (e.g., a machine has finished processing a job and requests that the job be transported to its next machine). Based on this message, the controller invokes a decision-making routine, or "script." This script may result in the dispatching of a transporter, for example, to move a job. In this case, the script must specify the transporter based on (i) the operation-location map (implemented as a TABLE), which the controller uses in conjunction with the job's process plan to determine the next machine, and (ii) the controller's domain map (also implemented as a TABLE), which the controller uses to select a transporter capable of moving the job between its current location and its next. If the next machine is not available, the controller script may select a storage buffer as the next location. If a transporter is not available, or if no next location is available, the controller stores the request in a pending work queue. Communication between elements in the simulation (e.g.,

machine and controller) is modeled using the WAIT-SIGNAL block set. This construct halts an entity until it receives the appropriate signal code. For example, a job entity is halted after processing until the controller releases it to a transporter with the correct signal. A control entity is halted at the beginning of the controller decision process until it receives the correct signal code (service request) to release it and route it to the appropriate decision function to respond to the type of service requested (e.g., routing, dispatching). A controller has a set of scripts, each of which implements a particular decision-making function. A control entity is routed to a script's logic using a BRANCH block that matches the script to the decision type required. The generic controller structure is shown in Figure 2.

Figure 2. Controller model

5. Case Study
This approach has been used to model a case study application in semiconductor manufacturing. The specific system modeled is a cluster tool, which is an enclosed processing system that integrates a number of different processing chambers around a central material handling system, usually a robot or set of robots. Chambers are mounted onto a central frame surrounding the material handling system. The whole tool interior operates as a cleanroom. A cluster tool can be custom-built for a particular application, with specific chambers attached that handle the desired process operations. A sample cluster tool configuration is shown in Figure 3.

Figure 3. Cluster tool Cluster tools are highly automated, and they improve throughput by eliminating the need for semiconductor wafers to pass through compression chambers between operations. At the same time, they are expensive, on the order of $2-3 million each. The equipment manufacturer must be able to model throughput accurately, to justify the cost to the chipmaker who purchases equipment. In this instance, simulation was the tool chosen by the equipment manufacturer, which was using a detailed simulation model of the type of cluster tool under study. This model was implemented in a popular, commercially available simulation software package. Even though the equipment manufacturer had in-house simulation personnel, it relied on the simulation vendor's consultants to perform any modifications to the model (e.g., to incorporate new configurations or features). This, of course, was a significant expense. The in-house personnel performed simulation experiments using the vendor's models. In our model, each process chamber was modeled as a machine having one location, with an event graph having "busy" and "idle" states. The robot was modeled as a TRANSPORTER. The cluster tools controller was modeled as a controller

sub-model that communicates with the process chambers via WAIT-SIGNAL codes. Each chamber location was modeled as a shared location for material transfer purposes (i.e., visible to the tool controller). The model was used to perform basic throughput analysis for the cluster tool in the production of multiple wafer types. The model proved beneficial in providing the ability to specify control logic explicitly. The eventual goal is to provide simulation users with this structured approach so that they build and modify complex models.

6. Conclusions and Future Work

This paper has presented a structured approach to simulation modeling of manufacturing systems, implemented in the SIMAN simulation language. Further details are available in [5]. The benefits of this approach are to help enable the development of high fidelity models, for example models of systems with explicit controllers and control logic to prototype manufacturing control software, and (ii) to provide a "standard" structure for use by non-experts in developing these types of models. Drawbacks of the current implementation relate mainly to the numeric nature of many of the SIMAN variables and constructs (e.g., WAIT-SIGNAL codes). Ensuring that numeric values are consistent and synchronized between different sub-models, especially when offsets are needed, is tedious at best. It is interesting to note that simulation experts often caution against using advanced features such as WAIT-SIGNAL blocks, due to their complexity. We feel that a disciplined approach to their use ameliorates this problem, and provides a powerful modeling tool in manufacturing. Future plans involve implementation in a more advanced simulation software package (e.g., ARENA or AutoMod), and use of integration tools to allow data to be stored in spreadsheet or database form.

Acknowledgments
The authors would like to acknowledge funding from the W. M. Keck Foundation.

References
1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. Adiga, S., and Glassey, C. R., 1991, "Object-Oriented Simulation to Support Research in Manufacturing Systems," International Journal of Production Research, 29(12), 2529-2542. Arango, G., and Prieto-Diaz, R., 1991, "Domain Analysis Concepts and Research Directions," in Domain Analysis and Software Systems Modeling, Prieto-Diaz, R., and Arango, G. (eds.), IEEE Computer Society, Los Alamitos, CA, 9-33. Biemens, F. P., and Vissers, C. A., 1989, "Reference Model for Manufacturing Planning and Control," Journal of Manufacturing Systems, 8(1), 35-46. Bodner, D. A., 1996, Real-Time Control Approaches to Deadlock Management in Automated Manufacturing Systems, Ph.D. dissertation, School of Industrial & Systems Engg., Georgia Institute of Technology, Atlanta, GA. Elliott, M., 2000, "Buyer's Guide: Simulation Software," IIE Solutions, 32(5), 55-64. Medeiros, D. J., 2000, "Flexible Control for Manufacturing Systems: A Simulation-Based Approach," in Progress in Material Handling Research: 2000, Graves, R. J., McGinnis, L. F., Ogle, M. K., Peters, B. A., Ward, R. E., and Wilhelm, M. R. (eds.), The Material Handling Institute, Charlotte, NC, 217-224. Mize, J. H., Bhuskute, H. C., Pratt, D. B., and Kamath, M., 1992, "Modeling of Integrated Manufacturing Systems Using an Object-Oriented Approach," IIE Transactions, 24(3), 14-26. Mujtabi, M. S., 1994, "Simulation of Modelling of Manufacturing Enterprise with Complex Material, Information and Control Flows," International Journal of Computer Integrated Manufacturing, 7(1), 29-46. Narayanan, S., Bodner, D. A., Sreekanth, U., Govindaraj, T., McGinnis, L. F., and Mitchell, C. M., 1994, "Modeling Control Decisions in Manufacturing Systems Simulation Using Objects," in Proceedings of the 1994 IEEE International Conference on Systems, Man, and Cybernetics, San Antonio, TX, 1392-1397. Narayanan, S., Bodner, D. A., Sreekanth, U., Govindaraj, T., McGinnis, L. F., and Mitchell, C. M., 1998, "Research in Object-Oriented Manufacturing Simulations: An Assessment of the State of the Art," IIE Transactions, 30(9), 795-810. Platzman, L. K., and Gershwin, S. B., 1986, "Simulating Computer Integrated Manufacturing Systems: How to Model What Traditional Methods Force You to Ignore," in Proceedings of the 1986 IEEE International Conference on Systems, Man, and Cybernetics, Atlanta, GA, 1007-1008. Schruben, L., 1983, "Simulation Modeling with Event Graphs," Communications of the ACM, 26(11), 957-963. Van Haren, C. R., and Williams, T. J., 1990, "A Reference Model for Computer Integrated Manufacturing from the Viewpoint of Industrial Automation," in Proceedings of CIMCON '90, Gaithersberg, MD, 42-62.