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.
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.
Computer simulation, manufacturing, reference model, modeling discipline.
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 "high-
fidelity" 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 . 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  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 object-
oriented programming (OOP) paradigm focuses on the specification of objects, with attributes and methods. Narayanan
et al.  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
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 . 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 Operational Control
Machines, material processing Commands Controllers, operators, machine
operations, storage buffers,
machine setup, inspection
← state information, controller
domains, process recipes,
Processing → machine scheduling, process
Status updates monitoring
Interface ↕ Material transfer via
↕ Information transfer via
Transporters, conveyors, Commands Controllers, operators,
material movement operations ← transporter state information,
controller domains, material
Transportation → movement requests, process
Status updates 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 . 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 .
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 . 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.
The authors would like to acknowledge funding from the W. M. Keck Foundation.
1. 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.
2. 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,
3. Biemens, F. P., and Vissers, C. A., 1989, "Reference Model for Manufacturing Planning and Control," Journal of
Manufacturing Systems, 8(1), 35-46.
4. 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.
5. Elliott, M., 2000, "Buyer's Guide: Simulation Software," IIE Solutions, 32(5), 55-64.
6. 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.
7. 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.
8. 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.
9. 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.
10. 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.
11. 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.
12. Schruben, L., 1983, "Simulation Modeling with Event Graphs," Communications of the ACM, 26(11), 957-963.
13. 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.