IIE Transactions (2003) 35, 29–48
Copyright 2003 ‘‘IIE’’
0740-817X/03 $12.00+.00
DOI: 10.1080/07408170390116643
Simulation-based shop floor control: formal model,
model generation and control interface
YOUNG JUN SON1 , RICHARD A. WYSK2 and ALBERT T. JONES3
1
Systems and Industrial Engineering Department, The University of Arizona, Tucson, AZ 85721-0020, USA
E-mail: [email protected]
2
Department of Industrial and Manufacturing Engineering, The Pennsylvania State University, University Park, PA 16802, USA
E-mail: [email protected]
3
Manufacturing Systems Integration Division, National Institute of Standards and Technology, Gaithersburg, MD 20899, USA
E-mail: [email protected]
Received February 2001 and accepted March 2002
In this paper, a structure and architecture for the rapid realization of a simulation-based real-time shop floor control system for a
discrete part manufacturing system is presented. The research focuses on automatic simulation model and execution system
generation from a production resource model. An Automatic Execution Model Generator (AEMG) has been designed and
implemented for generating a Message-based Part State Graph (MPSG)-based shop level execution model. An Automatic Simulation Model Generator (ASMG) has been designed and implemented for generating an Arena simulation model based on a
resource model (MS Access 97) and an MPSG-based shop level execution model. A commercial finite capacity scheduler, Tempo,
has been used to provide schedule information for the Arena simulation model. This research has been implemented and tested for
six manufacturing systems, including The Pennsylvania State University CIM laboratory.
1. Introduction
Traditionally, simulation has been applied to long-term
planning, design and analysis of manufacturing systems.
These models have been termed ‘throw away models’
because they are seldom used after the initial plans or
designs are finalized (Thomson, 1994; Drake et al., 1995).
Wysk et al. (1992) proposed that once the system design
has been constructed, the simulation that was used for
evaluation could then be used as a basis for system control. This approach has been illustrated as part of the
RapidCIM project and has been implemented at both the
Penn State CIM laboratory and the Texas A&M Computer-Aided Manufacturing (TAMCAM) laboratory.
This type of control is referred to as simulation-based
control.
Figure 1 depicts the architecture for simulation-based
control. In a simulation-based shop floor control system,
a simulation model acts as a supervisor, interacting with a
shop level executor while the executor actually interfaces
with the physical equipment. In order for the simulation
model to perform these activities effectively, it needs to be
specifically designed and detailed for shop floor control.
There must be a high degree of fidelity and granularity
among the control (execution) model, the resource model,
and the simulation model.
The high cost of control software development and
maintenance has been recognized as a significant problem
inhibiting Computer Integrated Manufacturing (CIM)
solutions. This fact holds true for the Shop Floor Control
Systems (SFCSs), the central and critical component of
CIM. In response to this problem, the main goal of this
research is to develop a methodology that will reduce the
time and expense required to develop or modify a fully
integrated, simulation-based, real-time SFCS. To achieve
the stated goal, the following specific objectives are established:
1. The first objective is to create a formal model of
manufacturing resources that can be used for control.
The focus in this research is shop floor control simulation and execution. This formal model allows the
other objectives that are stated next.
2. The second objective is to create a methodology and a
software system to extract execution model information and related simulation-based control model information for shop floor operation from a resource
description.
3. The third objective is to develop a methodology for
interfacing a simulation-based controller with an external scheduler. Tempo, a commercial finite capacity
scheduler, was selected for implementation as the
30
Son et al.
Fig. 1. Architecture for simulation-based shop floor control.
external scheduler. Certain commercial software
products are identified in this paper. These products
were used only for demonstrations purposes. This use
does not imply approval or endorsement by NIST, nor
does it imply that these products are necessarily the
best available for the purpose.
The following assumptions and constraints characterize the target environments for which this research is
applied:
1. The manufacturing system under consideration is a
discrete part manufacturing system.
2. The control system under consideration is intended to
operate with automated equipment such as NC machines and robots; however, human-assisted or manual workstations also can be included if the human
responds to prompts in a deterministic manner as the
equipment would respond.
3. The manufacturing system under consideration includes a set of material processors (machines), material handlers (robots), and buffers. The material
handling equipment under consideration is the direct
address material handling equipment.
4. Capacities of material processors and material handlers under consideration are one. All movement of
parts between non-material handling equipment requires a material handler.
5. The manufacturing system under consideration does
not consider assembly/disassembly operations. In addition, the unit of parts flowing throughout the system
is always one.
6. Both the flow-shops and job-shops are taken into account in this research.
2. Literature review
To control a dynamic Flexible Manufacturing System
(FMS) the concept of real-time control of manufacturing
cells using a simulation model(s) has been the subject of a
number of research projects (Davis and Jones, 1988; Wu
and Wysk, 1989; Harmonosky and Robohn, 1991;
Manivannan and Banks, 1991; McConnell and Medeiros,
1992; Kim and Kim, 1994; Smith et al., 1994; Drake
et al., 1995; Rahimifard and Newman, 1995; Peters et al.,
1996; Son et al., 1999). Smith et al. (1994) examined the
application of discrete event simulation to shop floor
control of a FMS. In general, the output of scheduling is
either a sequence of jobs for each resource (equipment) or
a combination of dispatching rules. Kim and Kim (1994)
presented a simulation-based real-time scheduling mechanism in which dispatching rules were dynamically varied
based on evaluation of the candidate rules; this is associated with the latter case. In this research, the former
case has been adopted, and Section 6 concentrates on the
related issues.
Simulation has been used to evaluate operation strategies or schedules. Although the basic manufacturing
modeling requirements are the same in both design and
control applications, there are some basic differences
in the requirements on the simulation tools needed in
these applications (Kachitvichyanukul et al., 1991). For
example, in design applications, we typically are only
interested in summary performance measures for comparing systems; in contrast, in control applications, we
are not only interested in summary reports, but also reports detailing the behavior of individual jobs. Since
Oldfather et al. (1966) developed the earliest simulation
generator, researchers have reported a variety of simulation generators. Mathewson (1984) defined a simulation
generator as a software tool that translates the logic of a
model into the code of a simulation language, enabling a
computer to mimic a modeler’s behavior.
Five approaches have been proposed to define the
simulation model, and they are: (i) natural language interface (Heidorn, 1974); (ii) graphical interface (Doshi
et al., 1985; Murray and Sheppard, 1988); (iii) interactive
dialogue interface (Doshi et al., 1985; Murray and
Sheppard, 1988); (iv) the use of the resource and process
description (Lee, 1996); and (v) the use of the resource
and execution models (Son, 2000). In this research, a
resource model and an execution model are used for
system specification.
The earliest use of a natural language interface was the
Natural Language Programming for Queueing simulations (NLPQ) (Heidorn, 1974). When the required information had been collected, the NLPQ generated the
simulation code in GPSS. Ford and Schroer (1987) developed the Electronic Manufacturing Simulation System
(EMSS) also using a natural language interface. Yuan
et al. (1993) used a batch file containing a list of operation equations and the remaining system specifications to
generate the simulation code.
The system specification has been also obtained either
via a graphical interface or an interactive dialogue mon-
31
Simulation-based shop floor control
itor (Doshi et al., 1985; Murray and Sheppard, 1988). A
graphical interface is useful for describing the structure or
layout of components within a system.
Lee (1996) presented an automatic simulation modeling methodology based on the part flow information and
the resource description. The process model represents
the process sequence and the resource alternatives for
manufacturing each part. Aytug and Dogan (1998) used
a similar methodology for simulation generation for
KANBAN-controlled manufacturing systems. Both
methodologies use the generated simulation model for
only design and analysis of the system. Peters et al. (1996)
developed the simulation control system directly from
information about the shop floor stored in a relational
database using a similar methodology proposed by
Centeno and Standridge (1992). In this approach, the
look-ahead simulation tool is used to predict the feasibility of a given production schedule.
In this paper, we refine and extend the previous research
as follows. First, we present a more systematic framework
for the generation of Simulation-based Shop Floor Control System (SSFCS) by: (i) formally modeling the components (execution model, simulation model, and resource
model) that comprise the SSFCS; and (ii) clearly defining
algorithms to extract information from each other. Sec-
ond, the generated simulation model (same model) is capable of running in three different modes (refer to Section
5.1). In one of those three modes, schedule information (a
sequence of jobs for each resource) is read from an external database, where schedules have been generated by
TempoTM (refer to Section 6).
3. Framework and general concept
3.1. Solution framework
Figure 2 overviews the proposed approach in this research in developing an integrated, real-time, Simulationbased Shop Floor Control System (SSFCS). In Fig. 2, the
major components that this research focuses on are
highlighted, and each component will be discussed in
detail in the following sections. ‘TA ’, ‘TB ’, ‘TC ’ and ‘TD ’ in
Fig. 2 are development times in each stage and will be
used to illustrate the improvement made out of the proposed approach in Section 7. Previous work (Smith and
Joshi, 1993) has been done to reduce ‘TC ’. The research in
this paper attempts to reduce ‘TB ’ and ‘TD ’. Refer to
Section 7 to find more details of the results. Prior to
discussing the model generation methodologies, Section
3.2 first explores the generic information that comprises
Fig. 2. Overview of the development of the simulation-based control system.
32
Son et al.
the resource model, the execution model (shop level), and
the simulation model.
3.2. Resource models, execution models, and simulation
models
3.2.1. Convention of notations
A partition of a set A is a collection of disjoint subsets of
A whose union is all of A. A ¼ hA1 ; A2 ; A3 i represents that
A is partitioned to A1 , A2 , and A3 .
Brackets are used to enclose the list of attributes describing an object. For example, a ¼ ½id; name; description
represents that an object a is characterized by attributes
called id, name, and description. A period is used to represent values of these attributes. For instance, a:id ¼ 1
represents that the value of an attribute id of an object a is
one.
3.2.2. Resource models
A resource model contains a set of definitions and symbolic descriptions that are required to describe all of the
individual resources in a facility as well as the necessary
interactions between these resources. It includes both the
physical and logical information in the facility directed
toward the manufacture of the products. Resources (R)
include equipment (E), tools (T), fixtures (F), instruction
sets (I), connectivity graph (CG), locations (L), ports (P),
facilitators (FA), which are formally defined as follows:
R ¼ E [ T [ F [ I [ CG [ L [ P [ FA [ . . .
Methodologies developed in this paper interact with
only E and CG. Therefore, discussions in this section
focus only on E and CG, and the other sets will not be
further mentioned after this section. To find various usage of the production resource model, refer to Steele et al.
(2001).
A manufacturing system is made up of several items of
equipment (devices). Several classes of equipment have
been identified. Wysk et al. (1995) have defined these
classes of Equipment (E) as Material Processing (MP),
Material Handling (MH), Material Transporting (MT),
and Buffer Storage (BS). All the equipment in the factory
are classified as belonging to only one of these classes.
Formally, the equipment (E) is defined as follows:
E ¼ hMP ; MH ; MT ; BSi, where:
MP ¼ hNMP ; PDi; BS ¼ hABS; PBSi;
ABS ¼ hSABS; LABSi, and
PBS ¼ hSPBS; LPBSi.
Equipment classified to the MP class is the one that
transforms a product in some way. MP is partitioned into
NMP (Normal Material Processors class) and PD (Passive Devices class). If material processing equipment requires an equipment level controller, it belongs to the
NMP class. Otherwise, it belongs to the PD class. NMP
class equipment includes machining centers, inspection
devices, assembly machines, and so on. PD class equipment includes gravity-based inverters, heat lamps used
for drying parts after a painting operation, etc. In this
paper, the MP class refers to the NMP class unless
otherwise defined.
Equipment classified in the MH class are those that
transfer products between pieces of equipment (generally
e 2 E MH ). This type of equipment includes robots,
human operators, etc. Equipment classified in the MT
class are those that move products from one location to
another location. This type of equipment includes AGVs,
conveyors, fork trucks, human operators, etc.
Equipment classified in the BS (Buffer Storage) class
are those that store products. General equipment storing
products is classified either as ABS (Active Buffer Storage
class) or PBS (Passive Buffer Storage class). If the storage
equipment requires an equipment level controller, it belongs to ABS class; otherwise, it belongs to PBS class.
Some requirements of an ABS equipment level controller
include synchronization with MH class equipment, location allocation, capacity control, etc. ABS is partitioned
into SABS (System Active Buffer Storage class) and
LABS (Local Active Buffer Storage class). SABS class
equipment are those associated with the system level activities, meaning that raw materials initiate and final
products terminate their appearance to/from the production system. LABS class equipment is associated with
local activities. Equipment classified to the PBS class is
the one that store products and does not need an equipment level controller. Since no controller exists for this
class of equipment, the supervisory level controller
(simulation in our case) must take care of all the decisions
associated with the equipment. PBS is partitioned into
SPBS and LPBS in the same way as in the case of ABS.
A Connectivity Graph (CG) is a graph showing the
connections between the equipment in the facilities. Each
node is associated with a physical equipment entity. Arcs
are associated with equipment interactions (e.g., high
level tasks). The connectivity graph is formally defined as:
CG ¼ ðN ; AÞ, where
N ¼ fn1 ; n2 ; . . . ; ni g is the set of nodes corresponding
to E,
A ¼ faij ji; j 2 N g.
3.2.3. Execution models
Several techniques have been used to implement execution models, including Petrinets (Kasturia et al., 1988;
Huang and Chang, 1992), push-down automata (Mettala,
1989), finite state automata (Smith and Joshi, 1993), object-oriented methods, graphical representations (Cho
and Wysk, 1995), and programmable logic control.
Common information embedded in these techniques is
composed of two sets: (i) specifications for specific states;
and (ii) a set of variables and associated actions that result in a state change. In this research, a Message-based
33
Simulation-based shop floor control
Part State Graph (MPSG) presented by Smith (1992) is
adopted to take advantage of the technology that automatically generates a Cþþ program from the model.
The MPSG (Smith and Joshi, 1993) is a formal model
of the execution portion of shop floor control that operates in a distributed control environment. Individual
controllers in a distributed environment communicate
using a well-defined protocol (messages) to affect system
operation. An MPSG is a modified Deterministic Finite
Automaton (DFA) similar to a Mealy machine (Hopcroft
and Ullman, 1979). An MPSG, M, is defined formally as
the octuple, M ¼ ðQ; q0 ; F ; R; ACT ; P ; d; cÞ, where Q is a
finite set of states, q0 2 Q is an initial state, F Q is a set
of final states (Smith, 1992). R is a finite set of controller
events and serves as the input alphabet. Additionally, R is
partitioned into a set of input messages (RI ), a set of
output messages (RO ), and a set of controller tasks (RT ).
ACT is a finite set of controller actions, where each
a 2 ACT is an executable function that performs some
controller action. P is a finite set of physical preconditions
for controller actions. P is partitioned so that for each
a 2 ACT , there is a corresponding qa 2 P , where qa is a
function which returns either true or false. d : Q R ! Q
is a state transition function. Similarly, c : Q ðRO [
RT Þ ! ACT is a controller action transition function
(Smith and Joshi, 1993).
3.2.4. Simulation models
Different people classify simulation information differently. Moreover, simulation models of the same system
can significantly differ depending on the nature of the
application. In this research, we classify the general simulation information so that it can most easily be fitted
into our methodology. A simulation model (SM) is the
collection of Default Components (DC), Static Information (SI), Dynamic Information (DI), Interaction with
External Modules (IEM), Animation (AM), and Statistics
Required (SR). Formally,
SM ¼ DC [ SI [ DI [ IEM [ AM [ SR:
Each component in our classification is explained as follows:
1. Default Components (DC): in order to model and run
a Simulation Model (SM), some additional analysis
information is required, including simulation duration,
number of replicates, project information, etc.
2. Static Information (SI): the set of static information
(SI) in a simulation (SM) is roughly similar to the
information contained in an experiment file. It includes
physical and logical data pertaining to the shop, such
as layout and resource information (Simulation Resource Module, SRM).
3. Dynamic (time-varying) Information (DI): dynamic
information (DI) are those characterized by the temporal evolution of objects in a system in terms of the
changes of states they undergo in response to interactions with other objects inside or outside the system
(Chen and Lu, 1997). Dynamic information (DI) in the
simulation (SM) is used to implement dynamic part
flow and entity interactions with resources as well as
random part arrivals to the system.
4. Interaction with External Modules (IEM): the simulation for real-time shop floor control communicates with
an execution system and interacts with the external
databases, e.g., master production schedule, process
plan, and external functions, e.g., planner, scheduler,
and error detection and recovery procedures. Currently, few simulation packages support features used for
real-time shop floor control. This is the primary motivation for the selection of Arena 3.01 RT as a target
simulation language for development with Visual Basic
Application (VBA). This selection provides a hook for
both integration and automatic control.
5. Animation (AM): the animation processor updates and
displays a graphical representation of the activities
taking place during the simulation. Animation and
dynamically updated displays and graphs provide a
visual representation of what is happening in the
model while the simulation is running.
6. Statistics Required (SR): generally, two types of statistics exist in a simulation: Observation Statistics (OS)
and Duration Statistics (DS). Observation statistics
(OS) are not time-persistent, and examples include
time in system, machining time, and queueing time.
Duration statistics (DS) are time-persistent, and examples include machine utilization and number in
queue.
4. Shop level execution model generation
4.1. Overview of execution model generation
The shop level task executor is called the BigE (Big Executor or Executor of executors). An MPSG for the BigE
is denoted as MBigE . This section presents a methodology
to automatically generate MBigE from a connectivity
graph (part of our resource model). Figure 3 contains a
reorganization of information in Fig. 2, used to generate
MBigE from a connectivity graph. In Fig. 2, the Automatic
Execution Model Generator (AEMG) is a procedure that
generates, MBigE . Given a connectivity graph CG, the
AEMG expands each arc aij 2 A CG based on the
AEMG rules (defined in Section 4.3).
4.2. Procedure for shop level MPSG generation
The conceptual procedure for the generation of MBigE
from CG is illustrated in Fig. 4. Basically, the procedure
visits each node of the connectivity graph, extending associated arcs to series of controller events based on the
34
Son et al.
0 if ni 2 VN ;
1 if ni 2
= VN :
This function determines whether the current node has
been previously visited or not.
VNstate ð QÞ ¼ fvn1 ; vn2 ; . . . ; vni g is the set of states
corresponding to VN.
Which state : VN VNstate ! VNstate is a function retrieving the state number that the AEMG has previously assigned to a node.
Arc interaction class (aij 2 A) is a function providing a
generic class of interactions between the starting node
i 2 N and the end node j 2 N . Table 1 describes this
function.
SGM (set of generated messages) is the set of information associated with each message r 2 R. Attributes
characterizing a message m 2 SGM include msg name,
#, @, control policy type, and sb message class. Formally, SGM ¼ ½msg name, #, @, control policy type,
sb message class. # is e.id where e 2 MH , and @ is
e.id where e 2 E MH .
SB message class (r 2 R) is a function providing
classes of input messages which originate from the
simulation. Table 2 describes this function.
2. Has nd visited ðni 2 N Þ ¼
3.
4.
5.
Fig. 3. Overview of coordination MPSG generation from a
connectivity graph.
rules described in Section 4.3. The following sets and
functions have been used to describe the procedure and to
make sure to visit each node and arc only once and also
to make sure to visit all the nodes and arcs of a connectivity graph:
6.
7.
1. VN N is a set of nodes that the AEMG has previously investigated. Before AEMG is initiated, VN ¼ /.
Fig. 4. Conceptual procedure for the generation of MBigE from CG.
35
Simulation-based shop floor control
Table 1. Arc interaction class function
Condition
i
i
i
i
i
˛
˛
˛
˛
˛
SPBS, j ˛ MH
MH, j ˛ SPBS
SABS, j ˛ MH
MH, j ˛ SABS
MH, j ˛ MP
Result
1
2
3
4
5
Condition
i
i
i
i
i
˛
˛
˛
˛
˛
MP, j ˛ MH
MH, j ˛ LPBS
LPBS, j ˛ MH
MP, j ˛ MP
MH, j ˛ LABS
Result
Condition
Result
6
7
8
9
10
i ˛ LABS, j ˛ MH
i ˛ MH, j ˛ PD
i ˛ PD, j ˛ MH
11
12
13
Table 2. Simulation to BigE message class function
Condition
e
e
e
e
e
=
=
=
=
=
part_enter_sb
pick_ns_sb
mv_to_mp_sb
mv_to_lpbs_sb
mv_to_spbs_sb
Result
1
2
3
4
5
Condition
e
e
e
e
e
=
=
=
=
=
mv_to_sabs_sb
put_sb
process_sb
pick_ns_sb
put_ns_sb
4.3. Automatic execution model generation rules
As shown in Fig. 1, the BigE interacts closely with the
equipment level controllers. These interactions must be
carefully considered building an MPSG for the BigE. Due
to limited space, underlying MPSGs for the equipment
level controllers are not described in this paper. These
interactions are referred as AEMG rules and are represented as a series of controller events, which will form
a part of the MPSG for the BigE. AEMG rules have been
devised for the following combinations of classes
of equipment: (i) SPBS and MH; (ii) MH and SPBS;
(iii) SABS and MH; (iv) MH and SABS; (v) MH
and MP; (vi) MP and MH; (vii) MH and LPBS; (viii)
LPBS and MH; (ix) MH and LABS; and (x) LABS and
MH.
Figure 5 shows the common series of states, controller
events, and state transitions required in the BigE MPSG
when the starting node in a connectivity graph is associated with a system-level passive buffer storage class
equipment (SPBS), and the ending node is associated
Result
6
7
8
9
10
Condition
e
e
e
e
=
=
=
=
rm_sabs_sb
return_sb
mv_to_labs_sb
rm_labs_sb
Result
11
12
13
14
with a material handling class equipment (MH). Interactions between an SPBS class equipment and an
MH class equipment is initiated when the BigE receiving a part-entering notification from the simulation
(part enter sb). When the BigE receives the part-entering
notification (part enter sb), the BigE saves the part id and
the part type, and then waits for the next message from
the simulation. The simulation then commands the BigE
to coordinate a pick task (pick ns sb). In response to this
pick message, the BigE commands the associated MH
class equipment controller to perform a pick task. Then,
the BigE waits for the completion message from the MH
class equipment. While the MH class equipment performs
material handling tasks, the BigE is unaware of what is
happening outside the scope of itself. When the BigE
receives the completion message from the MH class
equipment controller, it notifies the simulation of the
completion of the pick task (pick ok bs). Note that i may
or may not be equal to k, and j may or may not be equal
to k þ 5. This is dependent upon the specific states that
the AEMG has previously assigned for i and/or j.
Fig. 5. AEMG rules for SPBS class equipment and MH class equipment.
36
5. Shop level simulation model generation
Son et al.
1. First mode: users need to provide random part arrival
information using a distribution function. Part routing
information is read from an external database.
2. Second mode: part routing and order information is
read from an external database. The simulation reads
the external database every certain interval and releases existing orders. Scheduling is performed by default queue disciplines (first-in-first-out dispatching
rules) within the simulation model.
3. Third mode: same as with the second mode except that
schedule information is read from an external database, where schedules have been generated by Tempo.
simulation model from a Message-based Part State
Graph Summary (MPSGS) for the BigE, MSBigE ( MBigE )
(defined in the next section). Equipment in the resource
model (E R) provides a basis for deriving the static
information in a simulation model (SI SM). MSBigE
provides dynamic information for a simulation model
(DI SM). A product model and E provide information
for animation, AM. By default, Arena 3.01 provides
many of the duration statistics for the set of statistics
required (DS SR). However, the ASMG has to be
custom-built to gather the specific observation statistics
in the statistics required (OS SR). In this paper, observation statistics, OS, is not taken into account. The OS
can be easily added after automatic generation, according
to the user’s requirements. The type of interaction with
external modules, IEM, and default components, DC,
varies significantly depending on the Simulation-based
Shop Floor Control System (SSFCS) architecture that the
simulation follows. The ASMG has been designed specifically to support the SSFCS architecture associated
with this paper.
For all three modes, the simulation can be run with (realtime mode) or without (fast mode) interacting with the
shop level execution system.
5.3. Message-based part state graph summary
5.1. Scope of simulation
The requirements for a simulation model change for
different uses of the simulation. The generated simulation
model, the outcome of the methodology that will be described in this section, is capable of running in three
modes. Those three modes are as follows:
5.2. Overview of simulation model generation
The simulation information described in Section 3.2.4 can
be mapped or generated from the resource model and the
shop level execution model. Figure 6 contains details for
the information in Fig. 2, presenting an overview of
simulation model generation from a resource model and
MPSG-based execution model. The Automatic Simulation Model Generator (ASMG) generates an Arena 3.01
Fig. 6. Overview of simulation model generation from resource
model and MPSG.
As shown in Fig. 6, a Message-based Part State Graph
Summary (MPSGS) is used as input for dynamic information, DI, generation. An MPSGS is a specific subset of
the information in an MPSG. An MPSGS, MS, is formally defined as a three-tuple, MS ¼ ðQs ; Rs ; ds Þ, where
Qs Q is a finite set of states. Rs RI is a finite set of
messages. ds : Qs Rs ! Qs is a state transition function.
An MPSGS for the BigE conveys interactions between
the simulation and the BigE, and is denoted MSBigE . It
should be noted that we can interpret all possible interactions (high level tasks) between equipment by looking
at MSBigE . An MSBigE has the following properties:
1. All messages in the MPSGS for the BigE (8r 2 Rs ) end
with ‘sb’. This means that the messages originate from
the simulation and go to the BigE. Since the BigE interacts with both the Arena simulation model and the
equipment-level controllers, the MPSG for the BigE
includes those messages relevant to the simulation
model as well as those messages relevant to the
equipment controllers. Note that interactions between
the BigE and the lower level equipment controllers are
not needed in simulation model generation.
2. When the MPSG for the BigE is designed manually, it
is possible that many different MPSGS can exist for the
same system. In this research, since the MPSG is automatically generated based on identical sets of rules, it
is unique.
3. A finite set of messages in an MPSGS for the BigE,
MSBigE , is decomposed into several subsets based on the
messages’ characteristics. Formally,
37
Simulation-based shop floor control
Rs ¼ hRS PE; RS PIN ; RS MM; RS MLP ; RS MSP ; RS MSA;
RS PU ; RS PR; RS PI; RS PUN ; RS RS; RS RE; RS MLA; RS RLi
where:
RS PE ¼ frj jrj is part enter sbg;
RS PIN ¼ frj jrj is pick ns sbg;
RS MM ¼ frj jrj is mv to mp sbg;
RS MLP ¼ frj jrj is mv to lpbs sbg;
RS MSP ¼ frj jrj is mv to spbs sbg;
RS MSA ¼ frj jrj is mv to sabs sbg;
RS PU ¼ frj jrj is put sbg;
RS PR ¼ frj jrj is process sbg;
RS PI ¼ frj jrj is pick sbg;
RS PUN ¼ frj jrj is put ns sbg;
RS RS ¼ frj jrj is rm sabs sbg;
RS RE ¼ frj jrj is return sbg;
RS MLA ¼ frj jrj is mv to labs sbg;
and fRS RL ¼ frj jrj is rm labs sbg:
We can characterize these classes of messages using
English semantics, where mv stands for move and rm
stands for remove.
4. A message pertaining to an MPSGS has several attributes including # and @. Formally, r 2 Rs ¼½#;@; . . ..
# and @ are integer indexes of an item of equipment
(ei 2 E). Any two messages pertaining to an MPSGS
can be uniquely identified by # and @. Formally, 8ri ,
rj 2 Rs with i 6¼ j are uniquely identified by # and @.
For example, pick#3@2 sb is a pick message associated
with fei 2 MH E, ej 2 E MH jei :id ¼ 3, ej :id ¼ 2g.
5. The generic structure that an MPSGS always follows
is shown in Fig. 7. There are 14 basic tasks (high level
tasks) that are iteratively performed to produce finished products from raw materials.
The MPSGS for the BigE, MSBigE , can be generated
automatically from the MPSG for the BigE, MBigE . A new
algorithm to do so has been developed and is now presented:
5.4. Methods for simulation model generation
Figure 6 depicts an overview of how a simulation model
can be generated. This section presents methodologies to
generate the dynamic information, DI, and interaction
with external modules, IEM, which constitute the bulk of
the simulation model, SM. Refer to Son (2000) for
methodologies to generate other components.
Algorithm to generate MSBigE from MBigE
Step 1. Find r 2 R RS . While there is such r, go to Step
2. Otherwise, go to Step 7.
Fig. 7. Generic structure of MPSGS.
Step 2. For r, let’s set a to be b (r) and let’s set b to be e
(r) where:
• b: R ! Q is a function retrieving the start state
q 2 Q given a message r 2 R.
• e: R ! Q is a function retrieving the end state
q 2 Q given a message r 2 R.
Then, go to Step 3.
Step 3. Let R0 ¼ fr0 2 Rjbðr0 Þ ¼ g.
a And, let R00 ¼ fr00 2
00
Rjeðr Þ ¼ g.
a
Then, go to Step 4.
Step 4. For r00 2 R00 , assign eðr00 Þ to be .
b
If jR0 j ¼ 1, then go to Step 5. Otherwise, go to
Step 6. Note that jR0 j 1 all the time.
Step 5. Let R ¼ R fr00 g. Then, go back to Step 1.
Step 6. Let R000 ¼ fr000 2 R0 jeðr000 Þ 6¼ g.
b
For r000 2 R000 , assign bðr000 Þ to be .
b
Let R ¼ R fr000 g. Then, go back to Step 1.
Step 7. End.
Currently available simulation packages, including
Arena 3.01, AutoMod 10.2, ProModel 4.2, Quest, Micro
Saint, etc, have similar, but not identical, constructs.
Different software vendors have different definitions of
basic simulation constructs, e.g., queue, resource, machine, station, etc. The National Institute of Standards
and Technology (NIST) has been working to come-up
with a neutral definition of simulation constructs for the
last several years. However, there is no standard format
and definition of simulation constructs to date, and it
may be impossible to standardize these constructs across
packages until the software vendors rewrite their software
38
Son et al.
based on a certain neutral definition and description. Son
et al. (2001) presented a summary of the efforts, defining
neutral simulation constructs and generating Arena
models as well as ProModel models from neutral descriptions of simulation models.
The proposed methodology in this section expresses
dynamic information, DI, in Arena syntax, but the
methodology is not limited to Arena.
5.4.1. Overall structure of DI generation method
The dynamic information, DI, generation methodology is
partitioned into the following subsections with regard to
the requirements of the methodology (refer to Fig. 8(a–c)):
1.
2.
3.
4.
System input stations (e 2 SABS [ SPBS).
Material processing stations (e 2 MP ).
Local buffer stations (e 2 LABS [ LPBS).
System output stations (e 2 SABS [ SPBS).
Due to limited space, only the methodology for the first
case is presented in this paper. In order to model active
and passive system input buffers (e 2 SABS [ SPBS), we
only need to focus on outgoing parts from the current
system input buffers (refer to Fig. 8(a)). The material
handler that will unload a part from the current input
buffer needs to be seized (available) first before unloading
the part. The overall procedure to generate dynamic information, DI is presented below. It should be noted that
the procedure below captures the characteristics and the
configurations of a system by investigating the MPSGS.
Step 1. The purpose of this step is to capture information about system input buffers. From the
Message-based Part State Graph Summary
(MPSGS) for the BigE, MSBigE , construct a set of
part enter sb messages, RS PE. We can construct
RS PE from the MSBigE by extracting the messages
associated with the part enter class. We can
capture information about system input buffers
by investigating the RS PE. This is because
part enter sb messages must have already been
generated by the AEMG rules (refer to Fig. 5)
for the system input buffers. For example, if
there is no part enter sb message (jRS PEj ¼ 0), it
means that there is no corresponding system
input buffer in the physical system.
Step 2. The purpose of this step is to determine how
many system input buffers exist, and how many
material handling equipments can serve each
system input buffer. Classify the constructed
part enter sb messages, RS PE, into indexed subsets hRS PE1 ; . . . ; RS PEi ; . . .i where:
RS PE1 ¼ fr 2 RS PEjr@ ¼ p1 g;
//the set of ‘part enter sb’ messages whose @ attribute value is p1 . In the following sections, italic
sentences coming after the symbol ‘//’ are used to
describe the meaning of the formal procedures or
functions being developed.
RS PEi ¼ fr 2 RS PEjr@ ¼ pi g;
//the set of ‘part enter sb’ messages whose @ attribute value is pi .
p1 and pi are integer indexes of an item of
equipment (e 2 E), i is a natural number.
As mentioned in Section 5.3, a message pertaining to an MPSGS has attributes including #
and @. When two material handling equipments
(whose integer indexes are m1 and m2 ) can unload products from a system input buffer (whose
integer index is m3 ), two part enter sb messages
(part enter#m1 @m3 sb and part enter#m2 @
m3 sb) belong to the MPSGS.
Step 3. The purpose of this step is to map a series of
Arena building blocks for each system input
buffer. For each system input buffer, Arena code
to model the buffers can be generated by applying the rules presented in Fig. 9. A generic description of the simulation constructs used in the
rules along with their operands is presented in
Table 3. Note that the rules will be invoked i
times, where i is the number of part enter sb
messages in the MSBigE .
Functions used in the rules in Fig. 9 are defined below:
Fig. 8. Generic structure of: (a) each input system buffer in
simulation; (b) each processor or local buffer in simulation; and
(c) each output system buffer in simulation.
1. How many outgoing arc at SIB (r 2 RS PE) is a function
to calculate the number of equipments (e 2 E MH ) to
which the material handler (e 2 MH ) associated with
the part enter sb message, r, can potentially pass the
Simulation-based shop floor control
39
Fig. 9. Simulation generation rules for system input buffers.
parts. This function calculates this value by counting
the number of next streams from the current stream.
The way to count the number of next streams is described in the OutNs ðÞ function below. The generalstructure of MPSGS was shown in Fig. 7. According to
the structure, if a system input buffer belongs to the
SABS class, a rm sabs sb message (r 2 RS RS) follows a
part enter sb message (r 2 RS PE). In addition, a
pick ns sb message (r 2 RS PIN ) follows the rm sabs sb
message, and a return sb message (r 2 RS RE) follows
the pick ns sb message. Note that a system input buffer
and a material handler are associated with one stream
(part enter sb,rm sabs sb, pick ns sb, and return sb).
After the return sb message, there are branches to the
next stream. The number of the branches depends on
the number of equipment that the current material
handler (who picked up a product) can pass the
product. If a system input buffer belongs to the SPBS
class, the function can be similarly explained. The
function is formally defined below, and other functions
included within the function are also described.
How many outgoing arc at SIBðrÞ
8
Out Ns ðes ðnexts ðnexts ðnexts ðrÞÞÞÞÞ if
>
>
>
<
Equipment classðrÞ ¼ 3ðSABSÞ;
¼
>
Out Ns ðes ðnexts ðrÞÞÞ if Equipment classðrÞ
>
>
:
¼ 6ðSPBSÞ:
40
Son et al.
Table 3. Taxonomy of simulation constructs used in this paper (Kelton et al., 1998)
Name
General definition
Our specific usage
Operands
Station
Represents a point in
the model to which
entities are transferred
Represents a physical point
(e.g. MP or SABS physical stations) or a
logical point (e.g., place where attributes
are assigned in zero time) in the model
Station ID
Event
Sends the entity to user-coded
C function event. The
subroutine must be compiled
and linked to create a special
version of the SIMAN
executable program (e.g., DLL)
Read the process plan to determine the NC
file name and how long the operation takes
or to find the port where the part is located,
and the amount of time expected for the
part’s next operation
Event Number
Delay
Delays an entity by
duration time units
Delay for the amount of time read from
the process plan or send the message
to the executor (simulation-based shop
floor control case)
Simulation Delay Time
Message Name
Time Out Condition
Branch
Allows only a single branch
to be taken at each entity arrival
Chooses one equipment among alternatives.
If only one equipment, chooses it all of
the time
Max Number of Branches
Branch Types
Seize
Allocates units of a resource
Allocates units of a resource
Priority
Resource ID
Quantity
Route
Transfers the entity in Duration
time units to the station specified
by the operand Destination
Transfers the entity in zero time to
the station specified by the operand
Destination
Duration
Destination
Station
Release
Releases units of the resource
Releases units of the resource
Resource ID
Quantity
Assign
Allows the assignment of a value
to a SIMAN variable or entity
attribute
Assigns values of part type, number of
products in system, picture associated
with products, etc
Variable or Attribute Name
Value
Create
Generates arriving entities to a
process model
Generates entities to a model;
some entities represents physical
products, and other entities coordinates
information or control
Batch size
First creation
Time between
Max batches
Dispose
Removes an entity from the model
Removes an entity from the model
Optional
2. Equipment class (r 2 RS ) is a function to retrieve the
class of equipment that is associated with the given
message, r. The range of the function is f1; 2; 3; 4;
5; 6; 7; 8g, where each element represents MP, MH,
SABS, MT, LPBS, SPBS, LABS, and PD class, respectively.
3. es : Rs ! Qs is a function to retrieve the end state
q 2 Qs given a message r 2 Rs .
//This function returns the end state given a message.
For example, given the ‘part enter’ message in Fig. 7,
this function returns i þ 1.
4. OutNs : Qs ! N is a function to calculate the number of
messages whose start state is q 2 Qs .
// Given a state i, this function searches messages whose
state is i.
5. nexts : fq 2 Qs jOutNs ðqÞ ¼ 1g ! Qs is a function retrieving the subsequent state qn 2 Qs given a state
qnþ1 2 Qs .
//Given a state, this function returns the subsequent
state.
6. SB message class (r) has been defined previously.
7. Control policy
(r 2 RS MM [ RS MLP [ RS MLA [
RS MSP [ RS MSA) is a function that interprets system
configurations and returns the appropriate control
policy. If the control policy attribute is assigned to
one, the simulation must be configured so that a
blocking situation (if any) will remain in the current
MP class equipment. If the control policy attribute is
assigned to zero, the simulation must be configured so
that a blocking situation will not occur in the current
41
Simulation-based shop floor control
MP class equipment, and the blocking situation will be
transferred to the next MH class equipment. A tradeoff between the efficiency of the system and deadlock
avoidance has to be made depending on the nature of
the system.
The control policy attributes are determined by the
connectivity graph, which provides the configurations of
a system. The arcs whose starting node is associated with
the MH class equipment are eligible to have control
policy attributes. A new algorithm to determine control
policy attributes has been developed and is shown below.
Given a CG, find arcs, whose starting nodes are associated with the MH class equipment. Formally, find
faij je 2 MH , e corresponds to ni g.
If 9 aji 2 CG, aij Control policy attribute ¼ 1, // if nodes
i and j are associated with the arcs ði,jÞ and ðj,iÞ
Else, aij Control policy attribute ¼ 0.
Two types of control factors exist: uncontrollable (essential or minimal) factors (requirements) and controllable (user-specifiable) factors. Uncontrollable factors are
the requirements (physical constraints) that must be satisfied regardless of the control strategies chosen. For example, in a system with no queueing buffers, the robot
and the machine that parts need to visit next must be
seized together in order to avoid a deadlock.
Controllable factors are the ones that can be specified
by system designers or external modules (e.g., external
schedules). Examples of controllable requirements include the number of parts in the system and queue disciplines. In the proposed control system environment as
in Fig. 1, the simulation model is in charge of satisfying
the uncontrollable requirements. As a result, two primary
roles of the simulation model are to generate tasks and to
satisfy uncontrollable requirements. The simulation
model is configured so that the same simulation model
can deal with the various control strategies that result
from various combinations of controllable factors. Some
of the uncontrollable factors that must be satisfied are
presented as follows:
1. In a flow-shop with m machines, one robot, and no
buffers, the robot must be seized together with the
machine that the part needs to visit next. Otherwise,
deadlock can occur.
2. In a job-shop with no buffers, the robot must be seized
together with the machine that the part needs to visit
next; otherwise, deadlock can also occur.
3. If n parts are allowed in the system, and queueing
stations are used to avoid deadlock, then n 1
queueing stations are required to ensure that deadlocking does not occur. Note that MP class and MH
class equipment also can be used as queueing stations
if needed.
4. In a shop (either flow-shop or job-shop) with buffers,
two control policies are available for each robot.
When blocking (a part has been processed and the
machine that the part needs to visit next is not available) occurs, the robot can move the finished part to
the buffer (a PUSH-like control) or can wait until the
needed machine becomes available (more of a PULLlike control). Even if this kind of control policy is user
specifiable, the decision must be made before the
simulation model is constructed. This is simply because the same simulation model cannot deal with
multiple control strategies simultaneously.
5.4.2. Interaction with external modules generation
The simulation for real-time shop floor control communicates with a shop level executor and interacts with the
external databases, e.g., master production schedule and
process plan, and external schedules. Generation of three
sub-modules pertaining to IEM is summarized as follows:
1. Communication with the shop level executor: real-time
constructs supported by Arena 3.01 RT perform
communication with the shop level executor. These
real-time constructs are closely coupled with constructs associated with DI and the MPSG. Therefore,
procedures presented in Section 5.4.1 include generation of the real-time constructs.
2. Interface with external process plans: Section 5.5 discusses the interaction between the simulation and
process plans.
3. Interface with external schedules: Section 6 describes
issues related with external schedules.
5.5. Process plan versus simulation
The process plan, also called the route sheet, provides the
instructions for producing a part. The simulation constructs reading external process plans are closely coupled
with constructs associated with dynamic information, DI.
Therefore, procedures presented in Section 5.4.1 include
generation of the constructs reading the external process
plans. It should be noted that the architecture used to
represent the process plans is necessary when generating a
simulation model, not the actual process plans. Rather,
actual process plans provide information to control parts
and resources when running the generated simulation
models.
6. Method for schedule implementation in simulation
In this research, the simulation is configured so that the
sequence of parts to be processed by each MP class
equipment is maintained. Riddick (1998) termed this
sequence a dispatch list, and the term is interchangeable
42
with a work to be schedule. We define a schedule as a set of
work to be schedules for each resource. For the example
schedule shown in Fig. 10, the work to schedule for the
machine 1 is 2 5 4 1 6 3. The work to schedule
for each processor can be achieved by sorting the operations by the setup start time.
The characteristics of simulation modeling, specifically
in Arena, are summarized as follows, with a focus on
implementing the schedules based on the work to schedule:
1. Each processor is associated with a dispatch list (work
to be schedules). Ideally, parts will be added to or removed from the dispatch list dynamically during the
Son et al.
production stage. In Arena, an ‘expressions’ module,
which is an array data structure, is used to represent a
dispatch list.
2. There are m þ n logical queues in the simulation,
where m is the number of material processors and n is
the number of system input buffers. One queue is associated with each processor and system input buffer.
These queues are detached queues, meaning that parts
stay there until some other entity requests them in
order to proceed (refer to Fig. 11). The reason why
each material processor and input buffer has an associated logical queue is explained at the end of this
section (refer to Fig. 11).
Fig. 10. An example schedule (a set of work to schedules).
Fig. 11. Generated Arena simulation constructs associated with processing equipment.
43
Simulation-based shop floor control
3. One entity is created for each material processor. This
entity searches the m þ n queues for the next task that
the associated processor is supposed to process. If the
entity finds an appropriate part in a queue, it requests
that part to proceed. Otherwise, it searches again.
Figure 11 depicts an instance of the generated animation. This figure helps to explain the schedule implementation methodology that has been described. As
shown in Fig. 11, the input system buffer and two pieces
of processing equipment are associated with a logical
queue. One product sits on the logical queue associated
with processor 1. This physically implies that processor 1
has finished processing the product, and the product is
still sitting on processor 1 until another processor or
system output buffer requests it.
7. Software implementation and experiments
The software tool developed for this research is primarily in a Visual Basic Application (VBA) embedded in
Microsoft Access 97 (an ODBC and SQL compliant
database system). Detailed information on software im-
plementation and demonstration are enclosed in the
Appendix.
To test the validity and robustness of the software tool
and underlying methodologies, six manufacturing systems have been tested. Table 4 depicts the tested manufacturing systems, including the part of The Penn State
CIM lab (System ID 6). A layout of the partial CIM lab is
shown in Fig. 12, and the software demonstration in
Appendix A will be based on this system.
A total development time of high level components of a
simulation-based shop floor control system (T) is defined
formally as:
¼ TA þ TB þ TC þ TD ; where
T
TA = time taken to fill in the resource model (database
tables);
TB = time to generate coordination execution model
(MPSG for the BigE);
TC = time to generate a specific Cþþ code for the BigE
and compile it along with several default projectfiles; and
TD = time to generate a simulation model.
Figure 2 also shows the development time in each
stage. Table 4 shows the development times (TB and TD ) of
Table 4. Six manufacturing systems and associated control system development time (in seconds)
System
ID
1
2
3
4
5
6
Shop floor components
1
3
2
2
1
1
SPBS, 1 MH, and 2 MPs
SPBSs, 4 MHs, and 2 MPs
SPBSs, 3 MHs, and 2 MPs
SPBSs, 3MHs, 2 MPs, and 1 LPBS
ASRS, 3 MHs, 1 LPBS, and 2 MPs
ASRS, 3 MHs, 1 LPBS, and 4 MPs
Shop
type
Number
of nodes
Number
of arcs
TA
FMS
FMS
Flow-shop
FMS
FMS
FMS
4
9
7
8
7
9
6
11
6
8
12
16
105
157
93
114
133
220
Fig. 12. Layout of part of the Penn State CIM laboratory.
TB
(AEMG)
8
13
8
11
16
22
TC
TD
(ASMG)
»180
»180
»180
»180
»180
»180
93
107
102
149
157
273
44
controllers for the test manufacturing systems, when the
software tool described in this chapter is executed on a
Pentium 200 MHz processor with a 64 MBz memory.
Simulation models can be generated in about 2 minutes
(when the number of arcs in the connectivity graph <10)
and up to 10 minutes (when the number of arcs in the
connectivity graph <20). Execution models and interface
can be generated in 15 seconds (when the number of arcs
in the connectivity graph <10) and up to 30 minutes (when
the number of arcs in the connectivity graph <500). When
the current approach (manual generation of the execution
model and the manual generation of the simulation model)
is used to develop a simulation-based control system, TA is
not relevant because a formal resource model is not utilized in the current approach. TC values between the current approach and the proposed approach are the same;
they are nearly a constant value (about 3 minutes) for
different systems. Consequently, the reduction of a total
development time (T ) of a shop floor control system by
using the proposed approach compared with the current
approach is attributable to the time reductions in TB and
TD . This is why the TB and TD columns in Table 4 are
highlighted. It is difficult to measure exact TB and TD values
when the current manual approach is used. If a simulation
and MPSG expert were to construct a shop floor control
system manually, the summation of TB and TD would be
about a week. As a result, the time to build a high level
components (coordination execution system and simulation model) of a simulation-based shop floor control system was reduced from about a week to less than an hour
for mid-sized manufacturing systems, which is significant.
8. Conclusions
The high cost of control software development and
maintenance in the development of shop floor control
systems has been addressed as a major problem in this
paper. To resolve this problem, formal models of manufacturing resources that can be used for control have been
first presented. This research focused on developing a
resource model, a coordination execution model, and a
simulation model for use in shop floor control. On the
basis of these formal models, three methods were created:
(i) a method to extract execution model information from
a common resource description; (ii) a method to extract
simulation model information from a resource description and an execution model; and (iii) a method to implement schedules that have been generated by a finite
capacity scheduler, Tempo. Two software tools, AEMG
and ASMG, were developed based on the formal models
and the two methodologies stated above. Using these
software tools, a simulation control model was generated
from common information stored in a resource model
data file. This is the first time that complex control simulations that can be used for real-time control have been
Son et al.
produced automatically. The same database (resource
model) was also used to generate execution control software, again a first. These components represent a significant departure from standard practice.
To test the validity and robustness of the software and
underlying methodologies, a software experiment was
conducted with six sample manufacturing systems, including The Pennsylvania State University CIM laboratory (a full scale FMS). Arena simulation models for those
systems were automatically generated in 2 to 5 minutes.
The MPSG-based coordination executors were also automatically generated in less than 5 minutes. The generated
components for six manufacturing systems were verified
and validated. The results of the experiments indicated
that the generated models were valid. Finally, the time to
build high level components of a simulation-based shop
floor control system was significantly reduced from about
a week (current approach) to less than an hour (proposed
approach) for mid-sized manufacturing systems (for a
sophisticated control specialist).
As mentioned at the end of Section 1, the proposed
methodologies in this paper were limited to direct address
discrete part manufacturing systems that operate with a
single unit load. It was also assumed that the capacities of
MP and MH class equipment are one, and all the movement of parts requires material handling equipment. Extension of the methodologies that can handle indirect
address material handling systems, larger capacities, and
larger unit loads are left for future research.
References
Aytug, H. and Dogan, C. (1998) A framework and a simulation generator for kanban-controlled manufacturing systems. Computers
and Industrial Engineering, 34(2), 337–350.
Centeno, M. and Standridge, C. (1992) Databases and artificial intelligence: enabling technologies for simulation modeling. In:
Proceedings of the 1992 Winter Simulation Conference, Swain, J.,
Goldsmen, D., Wilson, J. and Grain, R. (eds), IEEE, Piscataway,
NJ, pp. 181–189.
Chen, K. and Lu, S. (1997) A Petri-net and entity-relationship diagram-based object-oriented design method for manufacturing
systems control. International Journal of Computer Integrated
Manufacturing, 10(1–4), 17–28.
Cho, H. and Wysk, R. (1995) Intelligent workstation controller for
computer-integrated manufacturing: problems and models. Journal of Manufacturing Systems, 14(4), 252–263.
Davis, W.J. and Jones, A.T. (1988) A real-time production scheduler
for a stochastic manufacturing environment. International Journal
of Computer Integrated Manufacturing, 4(4), 531–544.
Kachitvichyanukul, V., Davis, W., Pegden, C.D., Musselman, K.J.,
Ingalls, R. and Trybula, W.J. (1991) Simulation and scheduling
(panel), in Proceedings of the 1991 Winter Simulation Conference,
IEEE, Piscataway, NJ, pp. 382–391.
Doshi, K.A., Madala, S. and Sinclair, J.B. (1985) GIST: A tool for
specifying extended queueing network models. Technical report
TR8511, Department of Electrical and Computer Engineering,
Rice University, Houston, TX.
Drake, G.R., Smith, J.S. and Peters, B.A. (1995) Simulation as a planning and scheduling tool for flexible manufacturing systems, in
45
Simulation-based shop floor control
Proceedings of the 1995 Winter Simulation Conference, IEEE, Piscataway, NJ, pp. 805–812.
Ford, D. and Schroer, B. (1987) An expert manufacturing simulation
system. Simulation, 48(5), 193–200.
Harmonosky, C.M. and Robohn, S.F. (1991) Real-time scheduling in
computer integrated manufacturing: a review of recent research.
International Journal of Computer Integrated Manufacturing, 4(6),
331–340.
Heidorn, G.E. (1974) English as a very high level language for simulation programming. SIGPLAN Notices, 9, 91–100.
Hopcroft, J.E. and Ullman, J.D. (1979) Introduction to Automata Theory, Languages, and Computation, Addison-Wesley, Reading, MA.
Huang, H.P. and Chang, P.C. (1992) Specification, modeling and
control of a flexible manufacturing cell. International Journal of
Production Research, 30(11), 2512–2543.
Kasturia, E., DiCesare, F. and Desrochers, A. (1988) Real-time control
of multilevel manufacturing systems using colored Petri nets, in
Proceedings of the IEEE International Conference on Robotics and
Automation, IEEE, Piscataway, NJ, pp. 1114–1119.
Kelton, D.W., Sadowski, R.P. and Sadowski, D.A. (1998) Simulation
with Arena, McGraw Hill, Boston, MA.
Kim, M. and Kim, Y. (1994) Simulation-based real-time scheduling in
a flexible manufacturing system. Journal of Manufacturing Systems, 13(2), 85–93.
Lee, S. (1996) Automatic generation of simulation model for shop floor
control system. Master’s thesis, Department of Industrial Engineering, POSTECH, Pohang, Korea.
Manivannan, S. and Banks, J. (1991) Real-time control of a manufacturing cell using knowledge-based simulation, in Proceedings of
the 1991 Winter Simulation Conference, IEEE, Piscataway, NJ,
pp. 251–260.
Mathewson, S.C. (1984) The application of program generator software and its extensions to discrete-event simulation modeling. IIE
Transactions, 16, 3–18.
McConnell, P.G. and Medeiros, D.J. (1992) Real-time simulation for
decision support in continuous flow manufacturing systems, in
Proceedings of the 1992 Winter Simulation Conference, IEEE,
Piscataway, NJ, pp. 936–944.
Mettala, E.G. (1989) Automatic generation of control software in
computer integrated manufacturing. Ph.D. dissertation, Department of Industrial and Manufacturing Engineering, Penn. State
University, University Park, PA.
Murray, K. and Sheppard, S. (1988) Knowledge-based simulation
model specification. Simulation, 50(3), 112–119.
Oldfather, P.M., Ginsberg, A.S. and Markowitz, H.M. (1966) Programming by questionnaire: how to construct a program generator. Rand report, RM-5129-PR, IBM Corporation, Los Angeles,
CA.
Peters, B.A., Smith, J.S., Curry, J., La Jimodiere, C. and Drake, G.R.
(1996) Advanced tutorial simulation-based scheduling and control, in Proceedings of the 1996 Winter Simulation Conference,
IEEE, Piscataway, NJ, pp. 194–198.
Rahimifard, S. and Newman, S.T. (1995) The role of simulation in
operational planning and control of flexible manufacturing cells,
in Proceedings of the 1995 Winter Simulation Conference, IEEE,
Piscataway, NJ, pp. 936–944.
Riddick, F. (1998) Using simulation as a proxy for a real shop floor
and data collection system. NIST report NISTIR 6173, NIST,
Gaithersburg MD 20899.
Smith, J. (1992) A formal design and development methodology for
shop floor control in computer integrated manufacturing. Ph.D.
dissertation, Department of Industrial and Manufacturing Engineering, Penn State University, University Park, PA.
Smith, J. and Joshi, S. (1993) Message-based part state graphs (MPSG)
for shop control. Industrial and Manufacturing Engineering,
Working Paper Series, Pennsylvania State University, University
Park, PA.
Smith, J.S., Wysk, R.A., Sturrok, D.T., Ramaswamy, S.E., Smith,
G.D. and Joshi, S.B. (1994) Discrete event simulation for shop
floor control, in Proceedings of the 1994 Winter Simulation Conference, IEEE, Piscataway, NJ, pp. 962–969.
Son, Y. (2000) Simulation-based shop floor control: automatic model
generation and control interface. Ph.D. dissertation, Department
of Industrial and Manufacturing Engineering, Penn State University, University Park, PA.
Son, Y., Jones, A. and Wysk, R. (2001) Component-based simulation
modeling from neutral component libraries. Computers and Industrial Engineering, 45(3), 291–308.
Son, Y., Rodrı́guez-Rivera, H. and Wysk, R. (1999) A multi-pass
simulation-based, real-time scheduling and shop floor control
system. Transactions: The Quarterly Journal of the Society for
Computer Simulation International, 16(4), 159–172.
Steele, J., Son, Y. and Wysk, R. (2001) Resource modeling for the
integration of the manufacturing enterprise. Journal of Manufacturing Systems, 19(6), 407–427.
Thomson, M.B. (1994) Expanding simulation beyond planning and
design. Industrial Engineering, 26(10), 65–67.
Wu, D. and Wysk, R.A. (1989) An application of discrete-event simulation to on-line control and scheduling in flexible manufacturing. International Journal of Production Research, 27(9), 1603–
1623.
Wysk, R., Joshi, S.B. and Pegden, C.D. (1992) Rapid prototyping of
shop floor control systems for computer integrated manufacturing. ARPA project 8881, Department of Industrial and Manufacturing Engineering, Pennsylvania State University, University
Park, PA.
Wysk, R.A., Peters, B.A. and Smith, J.S. (1995) A formal process
planning schema for shop floor control. Engineering Design and
Automation Journal, 1(1), 3–19.
Yuan, Y., Dogan, C. and Viegelahn, G. (1993) A flexible simulation
model generator. Computers and Industrial Engineering, 24(2),
165–175.
Appendix
Software demonstration
This section describes implementation specifics and software demonstration. Figure A1(a) depicts the start page
for the software. Programming codes associated with the
buttons in Fig. A1(a) have been embedded within a Microsoft Access 97 file. For each button shown in Figure
A1(a), functions associated with each button and underlying implementation specifics are what follows:
1. The Resource Model button in Fig. A1(a) allows a user
to input a resource model or to modify a resource.
When, the button is clicked, it opens another Microsoft Access 97 application containing our resource
model. Figure A1(b) depicts sample data associated
with the manufacturing system in Fig. 12.
2. When the Generate BigE MPSG button is clicked, it
activates the AEMG (refer to Fig. 3). The AEMG is a
Visual Basic Application (VBA) program embedded in
Microsoft Access 97. The input to the AEMG is the
database containing our resource model. The output
from the AEMG is the MPSG for the BigE. The
MPSG for a BigE is represented in the database table.
46
Son et al.
Fig. A1. (a) The start page of the developed software tool; (b) data associated with manufacturing system in Fig. 12; (c) generated
MPSG (partial) for the BigE for the manufacturing system in Fig. 12; (d) MPSGS (partial) for the BigE for the manufacturing
system in Fig. 12; (e) Process plan for Gear shift product; and (f) example master production schedule.
For our example, the generated BigE in the database
table form is shown in Fig. A1(c).
3. The BigE MPSG button in Fig. A1(a) generates the .m
file for the MPSG compiler. When this button is
clicked, the textual description of the MPSG for the
BigE is opened. The use of this textual file is explained
in the next section.
4. The Generate Cþþ Codes button in Fig. A1(a) generates a Cþþ code, which will form the basis for the
BigE. Based on the text file (.m file) described in the
previous step (Step 3), the BigE can be automatically
generated by the MPSG builder that has been developed Smith and Joshi (1993).
5. The MPSG Parsing button in Fig. A1(a) is used to
activate the procedure to construct an MPSGS for the
BigE from an MPSG. The MPSGS for the BigE is
represented in the database table. For our example, the
generated MPSGS for the BigE is shown in Fig. A1(d).
6. The MPSG Summary button in Fig. A1(a) is used
to visualize the MPSGS. When this button is clicked, the
database table as shown in Fig. A1(d) is opened. This is
used as major input for simulation model generation.
47
Simulation-based shop floor control
7. When the Generate Simulation button in Fig. A1(a) is
clicked, it activates the ASMG (refer to Fig. 6). The
ASMG is a VBA program embedded in Microsoft
Access 97. The input to the ASMG is the database
table containing MPSGS for the BigE (refer to Fig.
A1(d)). The ASMG first opens the Arena 3.01 application along with a blank Arena model. The Visual
Basic Application (VBA) enables the generation of an
Arena model. The ASMG and the Microsoft Access
97 database interact with each other through the Microsoft Access 8.0 Object library and the DAO 3.5
(Data Access Objects) Object library. DAO is an Application Program Interface (API) available with Microsoft’s Visual Basic that lets a programmer request
access to a Microsoft Access Database. It is difficult to
prove that the generated simulation model is error
free. However, models generated have been verified
manually for their logical and structural correctness.
The best method to verify and validate the generated
simulation model is to run it in real-time mode along
with the physical manufacturing system. If the manufacturing system is operated as expected, then the
models are informally said to be error free. Several
experiments (for six different manufacturing systems
including Penn State CIM laboratory) with the ASMG
indicated a valid and robust ASMG.
8. The MPS and Process Plans button in Fig. A1(a) is
used to visualize the Master Production Schedule
(MPS) and Process Plans (PP). Figure A1(e) depicts
the process plan for the Gear shift product. Each row
in the process plan table is associated with either
equipment operation or decisions where alternatives
exist. For example, the rows where Time field has
been filled are associated with equipment operations.
The Equipment id field is associated with e 2 E and
specifies the equipment performing the next operation. The Port loc field is associated with e 2 E MH
and is used to specify the next station. The Robot loc
field is associated with e 2 E MH and is used to
specify the place from which a MH class equipment
picks products and to which a MH class equipment
puts products. The NC file field contains the name of
the NC file associated with the processing operation.
Finally, the Time field contains the time taken to
complete the operation. It is used when the simulation
is run in fast time mode. Figure A1(f) depicts an instance of our master production schedule. Initially
before the simulation is run, the Quantity and Quantity Left fields contain the same integer values. As the
simulation is run, the value in the Quantity Left field
is decreased while the value in the Quantity field is
kept the same. By having these two fields, it is possible to show the original order quantity and the
current status of it at the same time. While the simulation is running, the master production schedules
can be modified.
9. The Work to Schedules button in Fig. A1(a) is used to
visualize the schedule (set of work to schedules) or to
generate a schedule. If Tempo has already generated
schedules, the generated schedule will be shown.
Other-wise, it will open a Tempo application so that
we can perform scheduling activities.
10. The Schedule to Arena button in Fig. A1(a) is used to
insert the schedule to the simulation. ‘‘Expression’’
module in Arena is used to represent the work to
schedule for each equipment. It should be noted that
simulation constructs related with schedule implementation are used only when simulation is run in
mode 3. Otherwise, created entities are disposed as
soon as they are created.
11. The Close button in Fig. A1(a) is used to terminate a
session. Since the basis of the controllers have been
created at this time point (after going through 11
steps specified in this section), users directly interact
with the controller entities, including the simulation,
the BigE, Tempo, master production schedules, process plans, and equipment level controllers.
Biographies
Young Jun Son is an Assistant Professor in the Department of Systems
and Industrial Engineering at University of Arizona. He received his
BS degree in Industrial Engineering with honors from POSTECH in
Korea in 1996 and his MS and Ph.D. degrees in Industrial and Manufacturing Engineering from Penn State University in 1998 and 2000,
respectively. His research interests include shop floor control, simulation, distributed system, software engineering, and virtual manufacturing. He was the Rotary International Multi-Year Ambassadorial
Scholar in 1996, the Council of Logistics Management Scholar in 1997,
and the recipient of the Graham Endowed Fellowship for Engineering
at Penn State University in 1999. He is an Associate Editor of the
International Journal of Modeling and Simulation and a professional
member of ASME, IEEE, IIE, INFORMS, and SME.
Richard A. Wysk’s work focuses on computer integrated manufacturing, computer automated manufacturing, computer-aided process
planning and concurrent engineering. He holds the Leonhard Chair in
Engineering at Penn State University. Prior to his current position, he
was Director of the Institute for Manufacturing Systems and holder of
the Royce Wisenbaker Chair in Innovation at Texas A&M. Dr. Wysk
also served on the faculty of Virginia Tech and worked in industry as a
research analyst for the Caterpillar Tractor Company and as production control manager for General Electric. He is a decorated Vietnam
veteran. He is the author of several textbooks. Honors recognizing his
research include the Institute of Industrial Engineers, David F. Baker
Distinguished Research Award, and the Society of Manufacturing
Engineers Outstanding Young Manufacturing Engineer Award. He
holds Bachelor’s and Master’s degrees in Industrial Engineering and
Operations Research from the University of Massachusetts and a
Ph.D. in Industrial Engineering from Purdue University.
Albert T. Jones is currently heading up projects at the National Institute of Standards and Technology (NIST) to investigate the functional and integration requirements for the next generation simulation
tools. Prior to this assignment, he spent several years as Deputy Director of the Automated Manufacturing Research Facility at NIST.
During that time, he worked with various NIST and academic
48
researchers on system architectures for shop floor control, cell control,
and distributed scheduling. He received his MS in Mathematics and
Ph.D. in Industrial Engineering from Purdue University. He is currently on the Executive Boards for the Winter Simulation Conference
and the Engineering School at Loyola of Baltimore. He is Manufac-
Son et al.
turing Editor for several leading journals. He has Chaired or Cochaired several international conferences, and has served on several
proposal evaluation panels for NSF, NIST, and ARPA.
Contributed by the Facilities Layout and Material Handling Department