Chapter 14
Chapter 14
Chapter 14
CHAPTER 14
Simulation of
Manufacturing Systems
14.1
INTRODUCTION
There continues to be widespread use of simulation to design and optimize manufacturing systems. As a matter of fact, it could arguably be said that simulation is
more widely applied to manufacturing systems than to any other application area.
Some reasons for this include the following:
Increased competition in many industries has resulted in greater emphasis on
automation to improve productivity and quality. Since automated systems are
more complex, they typically can only be analyzed by simulation.
The cost of equipment and facilities can be quite large. For example, a new semiconductor manufacturing plant can cost a billion dollars or even more.
The cost of computing has decreased dramatically as a result of faster and
cheaper PCs.
Improvements in simulation software (e.g., graphical user interfaces) have reduced
model-development time, thereby allowing for more timely manufacturing
analyses.
The availability of animation has resulted in greater understanding and use of
simulation by manufacturing managers.
The remainder of this chapter is organized as follows. In Sec. 14.2 we discuss
the types of manufacturing issues typically addressed by simulation. Section 14.3
gives brief descriptions of FlexSim and ProModel, which are popular manufacturingoriented simulation packages. A simulation model of the small factory considered
14-1
14-2
EXAMPLE 14.1.
EXAMPLE 14.2.
chapter fourteen
14-3
Number, type, and layout of machines for a particular objective (e.g., production
of 1000 parts per week)
Requirements for material-handling systems and other support equipment (e.g.,
pallets and fixtures)
Location and size of inventory buffers
Evaluation of a change in product volume or mix (e.g., impact of new products)
Evaluation of the effect of a new piece of equipment (e.g., a robot) on an existing
manufacturing line
Evaluation of capital investments
Labor-requirements planning
Number of shifts
Performance evaluation
Throughput analysis
Time-in-system analysis
Bottleneck analysis [i.e., determining the location of the constraining resource(s)]
Evaluation of operational procedures
Throughput
Time in system for parts (cycle time)
Times parts spend in queues
Times parts spend waiting for transport
Times parts spend in transport
Timeliness of deliveries (e.g., proportion of late orders)
Sizes of in-process inventories (work-in-process or queue sizes)
Utilization of equipment and personnel (i.e., proportion of time busy)
Proportions of time that a machine is broken, starved (waiting for parts from a
previous workstation), blocked (waiting for a finished part to be removed), or
undergoing preventive maintenance
Proportions of parts that are reworked or scrapped
14-4
14.3
SIMULATION SOFTWARE
FOR MANUFACTURING APPLICATIONS
The simulation-software requirements for manufacturing applications are not fundamentally different from those for other simulation applications, with one exception. Most modern manufacturing facilities contain material-handling systems,
which are often difficult to model correctly. Therefore, in addition to the software
features discussed in Chap. 3, it is desirable for simulation packages used in manufacturing to have flexible, easy-to-use material-handling modules. Important classes
of material-handling systems are forklift trucks, AGVS with contention for guide
paths, transport conveyors (equal distance between parts), accumulating (or queueing)
conveyors, power-and-free conveyors, automated storage-and-retrieval systems
(AS/RS), bridge cranes, and robots. Note that just because a particular software
package contains conveyor constructs doesnt necessarily mean that they are appropriate for a given application. Indeed, real-world conveyor systems come in a
wide variety of forms, and different software packages have varying degrees of
conveyor capabilities.
In Chap. 3 we defined general-purpose and application-oriented simulation
packages, and then we discussed three general-purpose packages in some detail.
General-purpose packages usually offer considerable modeling flexibility and
are widely used to simulate manufacturing systems. Furthermore, some of these
products (e.g., Arena and ExtendSim) provide modeling constructs (e.g., conveyors)
specifically for manufacturing. There are also many simulation packages designed
specifically for use in a manufacturing environment. In Secs. 14.3.1 and 14.3.2
we give descriptions of FlexSim and ProModel, respectively, which are, at the
time of this writing, two popular manufacturing-oriented simulation packages. In
each case, we also show how to build a model of the small factory considered in
Sec. 3.5. Section 14.3.3 lists some additional manufacturing-oriented simulation
packages.
14.3.1 FlexSim
FlexSim [see Beaverstock et al. (2013) and FlexSim (2013)] is a true objectoriented simulation package for manufacturing, material handling, warehousing,
and flow processes marketed by FlexSim Software Products (Orem, Utah). A
model is constructed by dragging and dropping objects into the Model View
and then editing their parameters using dialog boxes. FlexSim can model a wide
variety of manufacturing configurations, since existing objects can be fully customized to meet specific requirements. These customized objects can then be
placed in the library for reuse in current or future modeling applications. A model
can also have an unlimited number of levels of hierarchy and use all aspects of
object-oriented technology (i.e., encapsulation, inheritance, and polymorphism, as
discussed in Sec. 3.6).
chapter fourteen
14-5
FIGURE 14.1
FlexSim model for the manufacturing system, as shown in the orthographic view.
14-6
FIGURE 14.2
Dialog box for the FlexSim Source object PartsArrive.
for the Source object named PartsArrive (the left-most object in Figure 14.1)
is shown in Fig. 14.2; here we specify that the interarrival times of parts (called
flowitems in FlexSim) are exponentially distributed with a mean of 1 (and a location parameter of 0) and use random-number stream 1 (see Chap. 7). (The time unit
for the simulation model is set to minutes at the beginning of the model-building
process.) The statistical-distribution dialog box displays a histogram of 1000 generated interarrival times.
The next object is a Queue object named MachineQ, whose dialog box is
shown in Fig. 14.3. The dialog box for the Processor object named Machine is
chapter fourteen
14-7
FIGURE 14.3
Dialog box for the FlexSim Queue object MachineQ.
shown in Fig. 14.4, where we specify that processing times are uniformly distributed
with a minimum value of 0.65 and a maximum value of 0.70, and we use randomnumber stream 2.
The dialog box for the Queue object named InspectorQ is similar to that
for the MachineQ object and is not shown. The dialog box for the Processor
14-8
FIGURE 14.4
Dialog box for the FlexSim Processor object Machine.
object named Inspector, which is similar to that for the Machine object, is
shown in Fig. 14.5. Here we specify that inspection times are uniformly distributed with a minimum value of 0.75 and a maximum value of 0.80, and we use
random-number stream 3. Also, if we click on the Flow tab near the top of the
screen, we can access the dialog box shown in Fig. 14.6. Here we specify that
chapter fourteen
14-9
FIGURE 14.5
Dialog box for the FlexSim Processor object Inspector.
90percent of the flowitems (i.e., those that are good) go to output port 1 (using
random-number stream 4), which is connected to the Sink object named
PartsDepart (its dialog box is not shown). The remaining 10 percent of the
parts (i.e., those that are bad) go to output port 2, where they are sent back to the
MachineQ object to be reworked. The simulation run length is specified to be
14-10
FIGURE 14.6
FlexSim dialog box for specifying the routing of parts from Inspector.
100,000 time units by using a dialog box (see Fig. 14.7) that is accessed from the
Run Time pull-down menu at the top of the screen. The results from running
the simulation model are shown in Table 14.1, and a perspective-projection view
is given in Fig. 14.8.
chapter fourteen
14-11
FIGURE 14.7
FlexSim dialog box for specifying the
simulation run length.
14.3.2 ProModel
ProModel [see Harrell et al. (2012) and ProModel (2013)] is a manufacturingoriented simulation package developed and marketed by ProModel Corporation
(Orem, Utah). The following are some of the basic modeling constructs, the first
four of which must be in every model:
Locations
Entities
Arrivals
Processes
Resources
A model can be constructed graphically (e.g., routings for parts can be defined
by clicking on graphical locations), by filling in data fields, and by programming
with an internal pseudo-language. It is also possible to call external subroutines
written in, say, C or C++. Customized front- and back-end interfaces can be developed
using ProModels ActiveX capability. For example, an Excel interface can easily be
set up for creating or modifying models. ProModel provides two-dimensional animation, which is created automatically when the model is developed. Three-dimensional
animation is available using ProModels 3D Animator.
TABLE 14.1
Observed value
4.42
0.75
0.86
1.01
1.12
1.52
1.68
14-12
FIGURE 14.8
FlexSim model for the manufacturing system, as shown in perspective-projection view.
Material-handling capabilities in ProModel include manual handling, transport conveyors, accumulating conveyors, forklift trucks, AGVS, and bridge cranes.
ProModel also has a tank construct for modeling continuous-flow systems. ProModel
includes a costing feature that allows one to assign costs to locations, resources, and
entities that are then tracked over time.
There are 100 different random-number streams available in ProModel. Furthermore, the user has access to 15 standard theoretical probability distributions and also to
empirical distributions. The time to failure of a machine may be based on busy time,
calendar time, the number of completed parts, or a signal from another part of the model.
There is a Scenario Manager that can be used to automatically make independent replications for each of a number of different scenarios. The results from the
simulation runs are displayed in ProModels Output Viewer in the form of tables
and graphs, including state graphs (e.g., whether a machine is busy, idle, down,
etc.), time plots, histograms, and pie charts. Point estimates and confidence intervals for performance measures of interest can also be displayed. Custom reports can
be created that display a specific set of tables and graphs.
In addition to providing the ability to export data to Excel, ProModel also links
and integrates with Minitab to provide users with a Six Sigma analysis capability.
For each scenario of interest, two charts are automatically generated in Minitab for
each Six Sigma metric, namely, the Capability Analysis Chart and the Capability
Sixpack Chart. The SimRunner optimization module is also included with ProModel.
ProModel Corporation also develops and markets the MedModel, ServiceModel,
and ProcessSimulator (a Microsoft Visio add-in) simulation packages.
chapter fourteen
14-13
FIGURE 14.9
Locations Module for ProModel.
The ProModel model for the manufacturing system uses Locations, Entities, Arrivals, and Processes modeling constructs. Locations, which will be
used to represent the machine, the inspector, and their queues, are selected from
the Build drop-down menu, or by selecting the Locations icon on the toolbar.
The resulting Locations Module, which consists of three windows, is shown in
Fig. 14.9. The Locations Graphics window is shown in the lower-left portion of
the screen, the Locations Edit table across the top of the screen, and the Layout
window in the lower-right portion of the screen. For each desired model location, a
location icon is selected from the Locations Graphics window and placed in the
Layout window. A new record corresponding to this location is automatically added
to the Locations Edit table, whose fields (Name, Capacity, etc.) can then be edited
in an appropriate way. The Locations Edit table and Layout window for the manufacturing system are shown in Fig. 14.10. In particular, the fields for the Machine
record in the Edit table are as follows:
Cap.
Units
DTs
Stats
Rules
The capacity of the Machine location (i.e., the number of parallel machines) is 1.
The number of separate units of this location (each having the same characteristics) is 1.
There are no downtimes for this location.
Only Basic statistics (i.e., machine utilization and average processing
time) will be computed for this location.
The Machine, when available, will pick that part in the queue that has been
waiting the longest (i.e., the Oldest).
The horizontal rectangles in the Layout window represent the machine and the
inspector queues. Below each queue is a counter, which displays the current number
of parts in the queue as the model is running.
14-14
FIGURE 14.10
Locations Edit table and Layout window for the ProModel model.
Entities, which are used to represent parts in this model, are selected from the
Build menu, or by selecting the Entities icon on the toolbar. This results in the display of the Entities Module, which consists of an Entities Graphics window, an
Entities Edit table, and the Layout window. An entity is specified graphically by
selecting an icon from the Entities Graphics window and then editing the record that
automatically appears in the Entities Edit table. The Entities Edit table for this model
is shown in Fig. 14.11. The Speed of an entity is not relevant for this model.
Arrivals, which are used to specify how entities arrive to the system, are also
selected from the Build menu or from the toolbar. This results in the display of the
Arrivals Module, which consists of an Arrivals Tools window, an Arrivals Edit
table, and the Layout window. To specify the manner in which an entity arrives,
select the desired entity (Part for this model) from those listed in the Arrivals
Tools window, and click in the Layout window on the location at which entities are
to arrive (MachineQ for our model). The Arrivals Edit table for the model is
shown in Fig. 14.12. The E(1,1) in the Frequency field specifies that parts have
exponentially distributed (denoted E) interarrival times with a mean of 1 minute
(the default time unit), and that random-number stream 1 is being used (see Chap. 7).
FIGURE 14.11
Entities Edit table for the ProModel model.
FIGURE 14.12
Arrivals Edit table for the ProModel model.
chapter fourteen
14-15
FIGURE 14.13
Layout window showing the route from MachineQ to Machine for the ProModel model.
The Logic field could be used to execute certain logic at the instant that each entity
arrives (e.g., assigning attribute values to the entity).
Selecting Processing from the Build menu (or selecting its icon on the toolbar)
displays the Processing Module, which consists of the Process Edit table, the
Routing Edit table, the Process Tools window, and the Layout window. To specify
the routing (processing) of an entity graphically, complete the following steps:
1. Select an entity (Part for our model) from the entity list in the Process Tools
window. The record for the location at which the entity arrives (MachineQ for
our model) is highlighted in the Process Edit table.
2. Click on this location in the Layout window and a rubber-banding routing line
appears starting at this location.
3. Click on the destination (succeeding) location for the entity (Machine for our model).
The Layout window for the simulation model after the routing from MachineQ to
Machine has been specified is shown in Fig. 14.13. The corresponding Process Edit
table and Routing Edit table are shown in Fig. 14.14. For our model, Part is both the
entity arriving to and departing from the MachineQ location. (In a more complicated
model, a raw-material entity could arrive to a machine and a completed-part entity
could depart from the machine.) After the modeling for MachineQ is completed, the
routing from Machine to InspectorQ is specified in a similar manner. For the Machine
record in the Process Edit table (see Fig. 14.15), we must specify that processing times
(see the Operation field) are uniformly distributed on the interval [0.65, 0.70] minute,
which is denoted by WAIT U(0.675, 0.025, 2). (The random-number stream is 2.)
The routing from InspectorQ to Inspector is then specified in a similar manner.
Finally, we must specify the routing out of the Inspector location, which is a
little bit more complicated. The Process Edit table and Routing Edit table for this
step are shown in Fig. 14.15. There are two routes out of Inspector. Either parts
FIGURE 14.14
Process Edit table and Routing Edit table with the MachineQ record selected for the
ProModel model.
14-16
FIGURE 14.15
Process Edit table and Routing Edit table with the Inspector record selected for the
ProModel model.
FIGURE 14.16
Routing Rule dialog box for the ProModel model.
chapter fourteen
14-17
FIGURE 14.17
Simulation Options dialog box for the ProModel model.
FIGURE 14.18
Entity Summary table for the ProModel model of the manufacturing system.
14-18
14.4
MODELING SYSTEM RANDOMNESS
In Chap. 6 we presented a general discussion of how to choose input probability
distributions for simulation models, and those ideas are still relevant here. We now
discuss some additional topics related to modeling system randomness that are
particularly germane to manufacturing systems, with our major emphasis being the
representation of machine downtimes.
14.4.1 Sources of Randomness
We begin with a discussion of common sources of randomness in manufacturing
systems. In particular, the following are possible examples of continuous distributions in manufacturing:
Note that in some cases the above quantities might be constant. For example, processing times for an automated machine might not vary appreciably. Also, automobile engines might arrive to a final assembly area with constant interarrival times of
1 minute.
There are actually two other common ways in which parts enter a manufacturing system. In some systems (e.g., a subassembly manufacturing line), it is often
assumed that there is an unlimited supply of raw parts or materials in front of the
lines first machine. Thus, the rate at which parts enter the system is the effective
processing rate of the first machine, i.e., accounting for downtimes, blockage, etc.
Jobs or orders may also arrive to a system in accordance with a production schedule,
which specifies the time of arrival, the part type, and the order size for each order.
In a simulation model, the production schedule might be read from an external file.
Histograms of observed processing (or assembly) times, times to failure, and
repair times each tend to have a distinctive shape, and examples of these three
types of data are given in Figs. 14.19 through 14.21. Note that the times to failure in
Fig. 14.20 have an exponential-like shape, with the mode (most likely value) near
zero. However, the exponential distribution itself does not provide a good model for
these data; see the discussion in Sec. 14.4.2. Observe also that the other two histograms have their mode at a positive value and are skewed to the right (i.e., the right
tail is longer).
Discrete distributions seem, in general, to be less common than continuous distributions in manufacturing systems. However, two examples of discrete distributions
chapter fourteen
14-19
h(x)
0.30
0.25
0.20
0.15
0.10
0.05
0.00
1.00
5.00
9.00
13.00
17.00
21.00
25.00
29.00 x
FIGURE 14.19
Histogram of 52 processing times for an automotive manufacturer.
h(x)
0.40
0.35
0.30
0.25
0.20
0.15
0.10
0.05
0.00
3.50
18.50
33.50
48.50
63.50
78.50
93.50
FIGURE 14.20
Histogram of 1603 times to failure for a household-products manufacturer.
14-20
0.20
0.15
0.10
0.05
0.00
12.50
87.50
162.50
237.50
312.50
387.50
FIGURE 14.21
Histogram of 88 repair times for an aluminum-products manufacturer.
are the outcome of inspecting a part (say, good or bad), and the size of an order
arriving to a factory (the possible values are 1, 2, . . .).
14.4.2 Machine Downtimes
The most important source of randomness for many manufacturing systems is that
associated with machine breakdowns or unscheduled downtime. Random downtime results from such events as actual machine failures, part jams, and broken
tools. The following example illustrates the importance of modeling machine downtime correctly.
E X A M P L E 1 4 . 3 . A company is going to buy a new machine tool from a vendor who
claims that the machine will be down 10 percent of the time. However, the vendor has
no data on how long the machine will operate before breaking down or on how long it
will take to repair the machine. Some simulation analysts have accounted for random
breakdowns by simply reducing the machine processing rate by 10 percent. We will see,
however, that this can produce results that are quite inaccurate.
Suppose that the single-machine-tool system (see, for example, Example 4.32) will
actually operate according to the following assumptions when installed by the purchasing
company:
Jobs arrive with exponential interarrival times with a mean of 1.25 minutes.
Processing times for a job at the machine are a constant 1 minute.
The times to failure for the machine have an exponential distribution (based on calendar
time, as discussed later) with mean 540 minutes (9 hours).
chapter fourteen
14-21
TABLE 14.2
Measure of performance
Average throughput per week*
Average time in system*
Maximum time in system
Average number in queue*
Maximum number in queue
Breakdowns
mean 5
540 minutes
Breakdowns
mean 5
54 minutes
No
breakdowns
1908.8
35.1
256.7
27.2
231.0
1913.8
10.3
76.1
7.3
67.0
1914.8
5.6
39.1
3.6
35.0
The repair times for the machine have a gamma distribution (shape parameter equal
to 2) with mean 60 minutes (1 hour).
The machine is, thus, broken 10 percent of the time, since the mean length of the
updown cycle is 10 hours.
In column 2 of Table 14.2 are results from five independent simulation runs of
length 160 hours (20 eight-hour days) for the above system; all times are in minutes. In
column 4 of the table are results from five simulation runs of length 160 hours for the
machine-tool system with no breakdowns, but with the processing (cycle) rate reduced
from 1 job per minute to 0.9 job per minute, as has sometimes been the approach in
practice.
Note first that the average weekly throughput is almost identical for the two simulations. [For a system with no capacity shortages (see Prob. 14.1) that is simulated for a
long period of time, the average throughput for a 40-hour week must be equal to the
arrival rate for a 40-hour week, which is 1920 here.] On the other hand, note that measures of performance such as average time in system for a job and maximum number of
jobs in queue are vastly different for the two cases. Thus, the deterministic adjustment
of the processing rate produces results that differ greatly from the correct results based
on actual breakdowns of the machine.
In column 3 of Table 14.2 are results from five simulation runs of length 160 hours
for the machine-tool system with breakdowns, but with a mean time to failure of 54 minutes and a mean repair time of 6 minutes; thus, the machine is still broken 10 percent of
the time. Note that the average time in system and the maximum number in queue are
quite different for columns 2 and 3. Therefore, when explicitly accounting for breakdowns in a simulation model, it is also important to have an accurate assessment of
mean time to failure and mean repair time for the actual system.
This example also shows that the required amount of model detail depends on the
desired measure of performance. All three models produce accurate estimates of (expected) throughput, but this is clearly not the case for the other performance measures.
Despite the importance of modeling machine breakdowns correctly, as demonstrated by the above example, there has been little discussion of this subject in the
simulation literature. Thus, we now discuss modeling random machine downtimes
in some detail. Deterministic downtimes such as breaks, shift changes, and scheduled maintenance are relatively easy to model and are not treated here.
14-22
U1
W1
U2
R1
End of
cycle 1
D2
W2
R2
Time
End of
cycle 2
FIGURE 14.22
Updown cycles for a machine.
A machine goes through a sequence of cycles, with the ith cycle consisting of
an up (operating) segment of length Ui followed by a down segment of length Di.
During an up segment, a machine will process parts if any are available and if the
machine is not blocked. The first two updown cycles for a machine are shown in
Fig. 14.22. Let Bi and Ii be the amounts of time during Ui that the machine is busy
processing parts and that the machine is idle (either starved for parts or blocked by
the current finished part), respectively. Thus, Ui 5 Bi 1 Ii. Note that Bi and Ii may
each correspond to a number of separated time segments and, thus, are not represented in Fig. 14.22.
Let Wi be the amount of time from the ith failure of the machine until its subsequent repair begins, and let Ri be the length of this ith repair time. Thus, Di 5 Wi 1 Ri,
as shown in Fig. 14.22.
We will assume for simplicity that cycles are independent of each other and are
probabilistically identical. This implies that each of the six sequences of random
variables defined above (e.g., U1, U2, . . . and D1, D2, . . .) are IID within themselves
(see Prob. 14.2). We will also assume that Ui and Di are independent for all i (see
Prob. 14.3).
We now discuss how to model machine-up segments in a simulation model assuming that appropriate breakdown data are available. The following two methods
are widely used (see also Prob. 14.4):
Calendar Time
Assume that the uptime data U1, U2, . . . are available and that we can fit a standard probability distribution (e.g., exponential) FU to these data using the techniques of Chap. 6. Alternatively, if no distribution provides a good fit, assume that
an empirical distribution is used to model the Uis. Then, starting at time 0, we
generate a random value u1 from FU and 0 1 u1 5 u1 is the time of the first failure
of the machine in the simulation. When the machine actually fails at time u1, note
that it may either be busy or idle (see Prob. 14.5). Suppose that d1 is determined to
be the first downtime (to be discussed below) for the machine. Then the machine
goes back up at time u1 1 d1. (If the machine was processing a part when it failed
at time u1, then it is usually assumed that the machine finishes this parts remaining
processing time starting at time u1 1 d1.) At time u1 1 d1, another value u2 is
randomly generated from FU and the machine is up during the time interval [u1 1 d1,
u1 1 d1 1 u2 ). If d2 is the second downtime, then the machine is down during the
time interval [u1 1 d1 1 u2, u1 1 d1 1 u2 1 d2 ), etc.
chapter fourteen
14-23
There are two drawbacks of the calendar-time approach. First, it allows the
machine to break down when it is idle, which may not be realistic. Also, assume that
the machine in question is part of a larger system and has machines both upstream
and downstream of it. If we simulate two different versions of the overall system
using the FU distribution to break down the specified machine (and also synchronize
the downtimes), then the machine will break down at the same points in simulated
(calendar) time for both simulations. However, due to different amounts of starving
from the upstream machines and blocking from the downstream machines in the
two simulation runs, the specified machine could have significantly less actual busy
time for one configuration than for the other. This also may not be very realistic.
Busy Time
Assume that the busy-time data B1, B2, . . . are available and that we can fit a
distribution FB to these data. (Alternatively, an empirical distribution can be used.)
Then, starting at time 0, we generate a random value b1 from FB. Then the machine
is up until its total accumulated busy (processing) time reaches a value of b1, at which
point the busy machine fails. (For example, suppose that b1 is equal to 60.7 minutes
and each processing time is a constant 1 minute. Then the machine fails while processing its 61st part.) If f1 is the simulated time at which the machine fails for the
first time ( f1 $ b1) and d1 is the first downtime, then the machine goes back up at
time f1 1 d1, etc.
In general, the busy-time approach is more natural than the calendar-time approach. We would expect the next time of failure of a machine to depend more on
total busy time since the last repair than on calendar time since the last repair. However, in practice, the busy-time approach may not be feasible, since uptime data
(U1, U2, . . .) may be available but not busy-time data (Bl, B2, . . .). In many factories,
only the times that the machine fails and the times that the machine goes back up
(completes repair) are recorded. Thus, the uptimes U1, U2, . . . may be easily computed, but the actual busy times B1, B2, . . . may be unknown (see Prob. 14.6). (In
computing the Uis, time intervals where the machine is off, e.g., idle shifts, should
be subtracted out.) Note that if a machine is never starved or blocked, then Bi 5 Ui
and the two approaches are equivalent.
There is a third method that is sometimes used to model machine-up segments
in a simulation model, namely, the number of completed parts. For example, after a
machine has completed 100 parts, it might be necessary to perform maintenance on
the machine.
We now discuss how to model machine-down segments, assuming that factory
data are available. Assume first that the waiting time to repair, Wi , for the ith cycle
is zero or negligible relative to the repair time Ri (for i 5 1, 2, . . .). Then we fit a
distribution (e.g., gamma) FD to the observed downtime data D1, D2, . . . . Each time
the machine fails, we generate a new random value from FD and use it as the subsequent downtime (repair time).
Suppose that the Wis may sometimes be large, due to waiting for a repairman
to arrive. If only Dis are available (and not the Wis and Ris separately), as is often
the case in practice, then fit a distribution FD to the Dis and randomly sample from
FD each time a downtime is needed in the simulation model. The reader should be
14-24
aware, however, that FD is a valid downtime distribution for only the current number of repairmen and the maintenance requirements of the system from which the
Dis were collected.
Finally, assume that the Wis may be significant and that the Wis and Ris are
individually available. Then one approach is to model the waiting time for a repairman as a maintenance resource with a finite number of units and to fit a distribution
FR to the Ris. If a repairman is available when the machine fails, the waiting time is
zero unless there is a travel time, and the repair time is generated from FR. If a
repairman is not available, the broken machine joins a queue of machines waiting
for a repairman, etc.
Suppose that factory data are not available to support either the calendar-time
or busy-time breakdown models previously discussed. This often occurs when simulating a proposed manufacturing facility, but may also be the case for an existing
plant when there is inadequate time for data collection and analysis. We now present
a tentative model for this no-data case, which is likely to be more accurate than
many of the approaches used in practice (see Example 14.3).
We will first assume that the amount of machine busy time, B, before a failure
has a gamma distribution with shape parameter aB 5 0.7 and scale parameter bB to be
specified. Note that the exponential distribution (gamma distribution with aB 5 1.0)
does not appear, in general, to be a good model for machine busy times, even though
it is often used in simulation models for this purpose.
E X A M P L E 1 4 . 4 . In Fig. 14.23 we show the histogram of machine times to failure
(actually busy times) from Fig. 14.20 with the best-fitting exponential distribution superimposed over it. It is visually clear that the exponential distribution does not provide
h(x), f (x)
0.40
0.35
0.30
0.25
0.20
0.15
0.10
0.05
0.00
3.50
18.50
33.50
48.50
63.50
78.50
93.50
FIGURE 14.23
Density-histogram plot for the time-to-failure data and the exponential distribution.
chapter fourteen
14-25
a very good fit for the data, since its density lies above the histogram for moderate
values of x. Furthermore, it was rejected by the goodness-of-fit tests of Sec. 6.6.2.
We chose the gamma distribution because of its flexibility (i.e., its density can
assume a wide variety of shapes) and because it has the general shape of many busytime histograms when aB # 1. (The Weibull distribution could also have been used,
but its mean is harder to compute.) The particular shape parameter aB 5 0.7 for the
gamma distribution was determined by fitting a gamma distribution to seven different sets of busy-time data, with 0.7 being the average shape parameter obtained.
In only one case was the estimated shape parameter close to 1.0 (the exponential
distribution). The density function for a gamma distribution with shape and scale
parameters 0.7 and 1.0, respectively, is shown in Fig. 14.24.
We will assume that machine downtime (or repair time) has a gamma distribution with shape parameter aD 5 1.3 and a scale parameter bD to be determined. This
particular shape parameter was determined by fitting a gamma distribution to 11 different sets of downtime data, with 1.3 being the average shape parameter obtained.
The density function for a gamma distribution with shape and scale parameters 1.3
and 1.0, respectively, is shown in Fig. 14.25. This density function has the same
general shape as downtime histograms often experienced in practice (see Fig. 14.21).
In order to complete our model of machine downtimes in the absence of data,
we need to specify the scale parameters bB and bD. This can be done by soliciting
f (x)
6
FIGURE 14.24
Gamma(0.7, 1.0) distribution.
14-26
f (x)
0.6
0.5
0.4
0.3
0.2
0.1
0.0
0.0
1.0
2.0
3.0
4.0
5.0
6.0
7.0
8.0 x
FIGURE 14.25
Gamma(1.3, 1.0) distribution.
mB
mB 1 mD
where mB 5 E(B) is the mean amount of machine busy time before a failure. If the
machine is never starved or blocked, then mB 5 mU 5 E(U) and e is the long-run
proportion of time during which the machine is processing parts. Using the values
of mD and e (and also the fact that the mean of a gamma distribution is the product
of its shape and scale parameters), it is easy to show that the required scale parameters are given by
bB 5
emD
0.7(1 2 e)
and
bD 5
mD
1.3
chapter fourteen
14-27
Thus, our model for machine downtimes when no data are available has been completely specified.
We have discussed above models for the breaking down and repair of machines.
However, in practice there are a number of additional complications that often
occur, such as multiple independent causes of machine failure. Some of these complexities are discussed in the problems at the end of this chapter.
14.5
AN EXTENDED EXAMPLE
We now illustrate how simulation can be used to improve the performance of a
manufacturing system. We will simulate a number of different configurations of a
system consisting of workstations and forklift trucks, with the simulation output
statistics from one configuration being used to determine the next configuration to
be simulated. This procedure will be continued until a system design is obtained
that meets our performance requirements.
14.5.1 Problem Description and Simulation Results
A company is going to build a new manufacturing facility consisting of an input/
output (or receiving/shipping) station and five workstations as shown in Fig. 14.26.
The machines in a particular station are identical, but the machines in different
stations are dissimilar. (This system is an embellishment of the job-shop model in
Sec. 2.7.) One of the goals of the simulation study is to determine the number of
machines needed in each workstation. It has been decided that the distances (in feet)
Workstation 2
Workstation 3
Workstation 4
Forklift truck
6
In
Workstation 1
Out
Receiving/shipping
FIGURE 14.26
Layout for the manufacturing system.
Workstation 5
14-28
1
2
3
4
5
6
0
150
213
336
300
150
150
0
150
300
336
213
213
150
0
150
213
150
336
300
150
0
150
213
300
336
213
150
0
150
150
213
150
213
150
0
between the six stations will be as shown in Table 14.3 (the input/output station is
numbered 6).
Assume that jobs arrive at the input/output station with interarrival times that
are independent exponential random variables with a mean of 1/15 hour. Thus, 15 jobs
arrive in a typical hour. There are three types of jobs, and jobs are of types 1, 2,
and 3, with respective probabilities 0.3, 0.5, and 0.2. Job types 1, 2, and 3 require 4,
3, and 5 operations to be done, respectively, and each operation must be done at a
specified workstation in a prescribed order. Each job begins at the input/output station, travels to the workstations on its routing, and then leaves the system at the
input/output station. The routings for the different job types are given in Table 14.4.
A job must be moved from one station to another by a forklift truck, which
moves at a constant speed of 5 feet per second. Another goal of the simulation study
is to determine the number of forklift trucks required. When a forklift becomes
available, it processes requests by jobs in increasing order of the distance between
the forklift and the requesting job (i.e., the rule is shortest distance first). If more
than one forklift is idle when a job requests transport, then the closest forklift is
used. When the forklift finishes moving a job to a workstation, it remains at that
station if there are no pending job requests (see Prob. 14.12).
If a job is brought to a particular workstation and all machines there are already
busy or blocked (see the discussion below), the job joins a single FIFO queue at that
station. The time to perform an operation at a particular machine is a gamma random variable with a shape parameter of 2, whose mean depends on the job type and
the workstation to which the machine belongs. The mean service time for each job
type and each operation is given in Table 14.5. Thus, the mean total service time averaged over all jobs is 0.77 hour (see Prob. 14.13). When a machine finishes processing
TABLE 14.4
Workstations in routing
3, 1, 2, 5
4, 1, 3
2, 5, 1, 4, 3
chapter fourteen
14-29
TABLE 14.5
Mean service time for each job type and each operation
Job type
1
2
3
a job, the job blocks that machine (i.e., the machine cannot process another job)
until the job is removed by a forklift (see Prob. 14.14).
We will simulate the proposed manufacturing facility to determine how many
machines are needed at each workstation and how many forklift trucks are needed
to achieve an expected throughput of 120 jobs per 8-hour day, which is the maximum possible (see Prob. 14.15). Among those system designs that can achieve the
desired throughput, the best system design will be chosen on the basis of measures
of performance such as average time in system, maximum input queue sizes, proportion of time each workstation is busy, proportion of time the forklift trucks are
moving, etc.
For each proposed system design, 10 replications of length 920 hours will be
made (115 eight-hour days), with the first 120 hours (15 days) of each replication
being a warmup period. (See Sec. 14.5.2 for a discussion of warmup-period determination.) We will also use the method of common random numbers (see Sec. 11.2)
to simulate the various system designs. This will guarantee that a particular job will
arrive at the same point in time, be of the same job type, and have the same sequence
of service-time values for all system designs on a particular replication. Job characteristics will, of course, be different on different replications.
To determine a starting point for our simulation runs (i.e., to determine system
design 1), we will do a simple queueing-type analysis of our system. In particular,
for workstation i (where i 5 1, 2, . . . , 5) to be well defined (have sufficient processing
capacity) in the long run, its utilization factor ri 5 li y(si vi) (see App. 1B for notation) must be less than 1. For example, the arrival rate to station 1 is l1 5 15 per hour,
since all jobs visit station 1. Using conditional probability [see, for example, Ross
(2003, chap. 3)], the mean service time at station 1 is
0.3(0.15 hour) 1 0.5(0.20 hour) 1 0.2(0.35 hour) 5 0.215 hour
which implies that the service rate (per machine) at station 1 is v1 5 4.65 jobs per
hour. Therefore, if we solve the equation r1 5 1, we obtain that the required number
of machines at station 1 is s1 5 3.23, which we round up to 4. (What is wrong with
this analysis? See Prob. 14.16.) A summary of the calculations for all five stations is
given in Table 14.6, from which we see that 4, 1, 4, 2, and 2 machines are supposedly
required for stations 1, 2, . . . , 5, respectively.
We can do a similar analysis for forklifts. Type 1 jobs arrive to the system at a
rate of 4.5 (0.3 times 15) jobs per hour. Furthermore, the mean travel time for a
type 1 job is 0.06 hour (along the route 631256). Thus, 0.27 forklift will be
required to move type 1 jobs. Similarly, 0.38 and 0.24 forklift will be required for
14-30
Arrival rate
(jobs/hour)
Service rate
[(jobs/hour)/machine]
Required number
of machines
1
2
3
4
5
15.0
7.5
15.0
10.5
7.5
4.65
8.33
3.77
6.09
4.55
3.23 S 4
0.90 S 1
3.98 S 4
1.72 S 2
1.65 S 2
Arrival rate
(jobs/hour)
Required number
of forklifts
4.5
7.5
3.0
0.06
0.05
0.08
0.27
0.38
0.24
0.89 S 1
TABLE 14.7
type 2 and type 3 jobs, respectively. Thus, a total of 0.89 forklift is required, which
we round up to 1. (What is missing from this analysis? See Prob. 14.17.) A summary
of the forklift calculations is given in Table 14.7, from which we see that the mean
travel time averaged over all job types is 0.06 hour.
A summary of the 10 simulation runs for system design 1, which was specified
by the above analysis, is given in Table 14.8 (all times are in hours). Note, for example, that the average utilization (proportion of time busy) of the four machines in
TABLE 14.8
0.72
0.21
3.68
32.00
0.74
0.26
524.53
1072.00
0.83
0.17
519.63
1026.00
0.73
0.27
569.23
1152.00
0.66
0.33
32.54
137.00
Performance measure
Proportion machines busy
Proportion machines blocked
Average number in queue
Maximum number in queue
Average daily throughput
Average time in system
Average total time in queues
Average total wait for transport
Proportion forklifts moving loaded
Proportion forklifts moving empty
94.94
109.20
107.97
0.42
0.77
0.22
chapter fourteen
14-31
250
Number in queue 2
200
150
100
50
40
80
120
160
200
Hours
FIGURE 14.27
Number in queue 2 in time increments of 1 hour for system design 1 (replication 1).
station 1 (over the 10 runs) is 0.72, the time-average number of jobs in the queue
feeding station 1 is 3.68, and the maximum number of jobs in this queue (over the
10 runs) is 32. More important, observe that the average daily throughput is 94.94,
which is much less than the expected throughput of 120 for a well-defined system;
it follows that this design must suffer from capacity shortages (i.e., machines or
forklifts). The average time in system for a job is 109.20 hours (107.97 hours for all
queues visited and 0.42 hour for all transporter waits), which is excessive given that
the mean total service time is less than 1 hour. Note that the total forklift utilization
is 0.99. The high forklift utilization along with the large machine-blockage proportions strongly suggest that one or more additional forklifts are needed. Finally, observe that stations 2, 3, and 4 are each either busy or blocked 100 percent of the time,
and their queue statistics are quite large. (See also Fig. 14.27, where the number in
queue 2 is plotted in time increments of 1 hour for the first 200 hours of replication 1.)
We will therefore add a single machine to each of stations 2, 3, and 4. (We will not add
a forklift at this time, although it certainly seems warranted; see system design 3.)
The results from simulating system design 2 (4, 2, 5, 3, and 2 machines for stations 1, 2, . . . , 5 and 1 forklift) are given in Table 14.9. The average daily throughput has gone from 94.94 to 106.77, but is still considerably less than that expected
for a well-defined system. Likewise the average time in system has been reduced
from 109.20 to 55.84 hours. Even though we added three machines to the system,
the queue statistics at station 5 have actually become considerably worse. (Why?
See Prob. 14.20.) In fact, station 5 is now busy or blocked 100 percent of the time.
Also, the blockage proportions have increased for four out of the five stations.
14-32
TABLE 14.9
0.75
0.25
106.04
364.00
0.45
0.26
0.53
11.00
0.76
0.23
46.15
182.00
0.54
0.30
1.17
17.00
0.66
0.34
747.33
1521.00
Performance measure
Proportion machines busy
Proportion machines blocked
Average number in queue
Maximum number in queue
Average daily throughput
Average time in system
Average total time in queues
Average total wait for transport
Proportion forklifts moving loaded
Proportion forklifts moving empty
106.77
55.84
54.34
0.69
0.84
0.16
This example reinforces the statement that it may not be easy to predict the effect of
local changes on systemwide behavior. Since the total forklift utilization is 1.00, we
now add a second forklift to the system.
The results from simulating system design 3 (4, 2, 5, 3, and 2 machines and
2 forklifts) are given in Table 14.10. The average daily throughput is now 120.29,
which is not significantly different from 120 as shown in Sec. 14.5.2. Thus, system
design 3 is apparently stable in the long run. In addition, the average time in system has been decreased from 55.84 to 1.76 hours. Notice also that the average total
utilization of the two forklifts is an acceptable 0.71 (see Prob. 14.21), and the station blockage proportions are now small. Finally, the statistics for all five stations
TABLE 14.10
0.81
0.06
3.37
39.00
0.45
0.06
0.24
10.00
0.80
0.04
2.18
27.00
0.58
0.06
0.47
17.00
0.83
0.07
6.65
85.00
Performance measure
Proportion machines busy
Proportion machines blocked
Average number in queue
Maximum number in queue
Average daily throughput
Average time in system
Average total time in queues
Average total wait for transport
Proportion forklifts moving loaded
Proportion forklifts moving empty
120.29
1.76
0.86
0.08
0.44
0.27
chapter fourteen
14-33
Number in queue 2
40
80
120
160
200
Hours
FIGURE 14.28
Number in queue 2 in time increments of 1 hour for system design 3 (replication 1).
seem reasonable (see also Fig. 14.28), with the possible exception of the maximum
queue sizes for stations 1 and 5. Whether queue sizes of 39 and 85 are acceptable
depends on the particular application. These maximum queue sizes could be made
smaller by adding additional machines to stations 1 and 5, respectively. Finally,
note that average time in system (1.761) is equal to the sum of average total time
in queues (0.861), average total wait for transport (0.075), average transport time
(0.059), and average total service time (0.766)the last two times are not shown
in Table 14.10.
In going from system design 1 to system design 2, we added machines to stations 2, 3, and 4 simultaneously. Therefore, it is reasonable to ask whether all three
machines are actually necessary to achieve an expected throughput of 120. We first
removed one machine from station 2 for system design 3 (total number of machines
is now 15) and obtained an average daily throughput of 119.38, which is significantly different from 120 (see Sec. 14.5.2 for the methodology used). Thus, two
machines are required for station 2. Next, we removed one machine from station 3
for system design 3 (total number of machines is 15) and obtained an average daily
throughput of 115.07, which is once again significantly different from 120. Thus,
we need five machines for station 3. Finally, we removed one machine from station 4
for system design 3 and obtained system design 4, whose simulation results are
given in Table 14.11. The throughput is unchanged, but the average time in system
has increased from 1.76 to 2.61. This latter difference is statistically significant as
shown in Sec. 14.5.2. Note also that the average and maximum numbers in queue
for station 4 are larger for system design 4, as expected.
14-34
TABLE 14.11
0.81
0.06
2.89
32.00
0.45
0.06
0.25
11.00
0.80
0.04
1.88
27.00
0.87
0.08
14.31
90.00
0.83
0.07
6.50
81.00
Performance measure
Proportion machines busy
Proportion machines blocked
Average number in queue
Maximum number in queue
Average daily throughput
Average time in system
Average total time in queues
Average total wait for transport
Proportion forklifts moving loaded
Proportion forklifts moving empty
120.29
2.61
1.72
0.07
0.44
0.27
System designs 3 and 4 both seem to be stable in the long run. The design that
is preferable depends on factors such as the cost of an additional machine for station 4 (design 3), the cost of extra floor space (design 4), the cost associated with a
larger average time in system (design 4), and the cost associated with a larger average
work-in-process (design 4).
We now consider another variation of system design 3. It involves, for the
first time, a change in the control logic for the system. In particular, jobs waiting
for the forklifts are processed in a FIFO manner, rather than shortest distance first
as before. The results for system design 5 are given in Table 14.12. Average time
TABLE 14.12
0.81
0.08
4.77
51.00
0.45
0.08
0.29
11.00
0.80
0.06
2.70
33.00
0.58
0.08
0.58
17.00
0.83
0.08
8.28
95.00
Performance measure
Proportion machines busy
Proportion machines blocked
Average number in queue
Maximum number in queue
Average daily throughput
Average time in system
Average total time in queues
Average total wait for transport
Proportion forklifts moving loaded
Proportion forklifts moving empty
120.33
2.03
1.11
0.10
0.44
0.31
chapter fourteen
h(x)
0.30
14-35
0.25
0.20
0.15
0.10
0.05
0.00
0.25
1.25
2.25
3.25
4.25
5.25
6.25
7.25 x
FIGURE 14.29
Histograms of time in system for system designs 3 and 5.
in system has gone from 1.76 to 2.03 hours, an apparent 15 percent increase.
(Histograms of time in system for system designs 3 and 5, based on all 10 runs
of each, are given in Fig. 14.29.) The queue statistics for station 1 have also
increased by an appreciable amount, and the forklifts now spend more time
moving empty. It takes a forklift more time to get to a waiting job, since the closest one is not generally chosen. We therefore do not recommend the new forkliftdispatching rule.
Finally, we discuss another variation of system design 3 (shortest-distance-first
forklift-dispatching rule), where certain machines break down. In particular, we
assume that each machine in stations 1 and 5 breaks down independently with an
efficiency of 0.9 (see Sec. 14.4.2). The amount of busy time that a machine operates
before failure is exponentially distributed with a mean of 4.5 hours, and repair times
have a gamma distribution with a shape parameter of 2 and a mean of 0.5 hour. The
simulation output for the resulting system design 6 is given in Table 14.13. The
average daily throughput is now 119.88, but this is not significantly different from
120 (see Sec. 14.5.2). On the other hand, average time in system has gone from 1.76
to 5.31, an increase of 202 percent. The queue statistics for stations 1 and 5 are also
appreciably larger. Thus, breaking down only stations 1 and 5 caused a significant
degradation in system performance; breaking down all five stations would probably
have an even greater impact. In summary, we have once again seen the importance
of modeling machine breakdowns correctly.
14-36
TABLE 14.13
0.81
0.06
0.09
16.55
111.00
0.45
0.06
0.00
0.25
11.00
0.80
0.04
0.00
2.15
32.00
0.58
0.06
0.00
0.49
14.00
0.82
0.07
0.09
46.73
262.00
Performance measure
Proportion machines busy
Proportion machines blocked
Proportion machines down
Average number in queue
Maximum number in queue
Average daily throughput
Average time in system
Average total time in queues
Average total wait for transport
Proportion forklifts moving loaded
Proportion forklifts moving empty
119.88
5.31
4.37
0.07
0.44
0.27
1.20
or120.29 6 0.63
B 10
which contains 120. Similarly, we get the following 90 percent confidence interval
for the steady-state mean daily throughput for system design 6, n6:
119.88 6 t9, 0.95
0.60
or119.88 6 0.45
B 10
chapter fourteen
14-37
Yi (20)
20
15
l 120
10
60 120 180 240 300 360 420 480 540 600 660 720 780 840 900 i
FIGURE 14.30
Moving average (w 5 20) of hourly throughputs for system design 3.
using the replication/deletion approach (see Example 10.5), where n9i is the steadystate mean time in system for system design i (where i 5 3, 4). We get
20.85 6 t9, 0.95
0.22
or20.85 6 0.27
B 10
which does not contain 0. Thus, n93 is significantly different from n94.
The results presented in Sec. 14.5.1 (and here) assume a warmup period of
120 hours or 15 days. This warmup period was obtained by applying Welchs procedure (Sec. 9.5.1) to the 920 hourly throughputs in each of the 10 replications
for system design 3 (where Yji is the throughput in the ith hour of the jth run). The
moving average Yi (20) (using a window of w 5 20) is plotted in Fig. 14.30, from
which we obtained a warmup period of l 5 120 hours. We performed similar
analyses for system designs 4, 5, and 6, and a warmup period of 120 hours seemed
adequate for these systems as well.
14.6
A SIMULATION CASE STUDY OF A METAL-PAR TS
MANUFACTURING FACILITY
In this section we describe the results of a successful simulation study of a manufacturing and warehousing system [see Law and McComas (1988)]. The facility described is fictitious for reasons of confidentiality, but is similar to the system actually
14-38
Completed
products
to shipping
Warehouse
Conveyors
from
subassembly
manufacturing
Loaders
Empty
Full
Empty
Full
containers containers
Unloaders/assembler
Full
Empty
FIGURE 14.31
Layout of the system.
modeled for a Fortune 500 company. The project objectives, the simulation steps,
and the benefits that we describe are also very similar to the actual ones.
14.6.1 Description of the System
The manufacturing facility (see Fig. 14.31) produces several different metal parts,
each requiring three distinct subassemblies. Subassemblies corresponding to a
particular part are produced in large batches on one of two subassembly manufacturing lines, and then moved by conveyor to a loader where they are placed into
empty containers. Each container holds only one type of subassembly at a time.
The containers are stored in a warehouse until all three of the part subassemblies
are available for assembly. Containers of the three subassemblies corresponding
to a particular part are brought to an unloader/assembler (henceforth called the
assembler), where they are unloaded and assembled into the final product, which
is then sent to shipping. The resulting empty containers are temporarily stored in
a finite-capacity accumulating conveyor (not shown in the figure) at the back of
the assembler. They are then taken to the loaders, if needed; otherwise, they are
transported to the warehouse. Full and empty containers are moved by forklift
trucks.
The assembler operates only 5 days a week, while the remainder of the system
is in operation three shifts a day for 7 days a week. Also, the subassembly lines, the
loaders, and the assembler are subject to random breakdowns.
14.6.2 Overall Objectives and Issues to Be Investigated
The subassembly lines already existed at the time of the study. However, the loaders, the warehouse, and the assembler were in the process of being designed. (They
chapter fourteen
14-39
14-40
Distribution type
Empirical
Empirical
Triangular
Empirical
Lognormal
Weibull
Lognormal
Uniform
complexity was necessitated by a complicated set of rules (not described here) for
each part that specify when its corresponding subassemblies are sent to the assembler.
14.6.4 Model Verification and Validation
Verification is concerned with determining if the simulation computer program is
working as intended, and the initial verification efforts included the following:
Theoretical efficiency
Simulation efficiency
1
2
0.732
0.724
0.741
0.727
chapter fourteen
14-41
TABLE 14.16
Historical efficiency
Simulation efficiency
1
2
0.738
0.746
0.741
0.727
Five independent simulation runs were made for each scenario, with each run
being 23 weeks in length and having a 3-week warmup period during which no
statistics were gathered. The length of the warmup period was determined by plotting
the average number of empty containers (over the five runs) in time increments of
1 hour for scenario 1, which is shown in Fig. 14.32; initially, all containers were empty.
Note that this empty-containers stochastic process does not have a steady-state
14-42
Forklift trucks
Queue sizes
Assembler shifts
1
2
3
4
5
6
7
3
3
2
3
3
3, 2 (weekend)
3
2
2
2
1
3
2
2
3
2
3
3
3
3
2 (all 7 days)
distribution for scenarios 1 through 6 because the assembler does not operate on
weekends. What about scenario 7 (see Prob. 14.25)?
A summary (average across the five runs) of the seven sets of simulation runs
appears in Table 14.18. Note that the throughput (in parts per week) for scenario 2
(two shifts) is considerably less than that for scenario 1 (three shifts). Also, scenario
2 has a high starvation proportion for the loaders. These results are due to a shortage
of empty containers for scenario 2 caused by the assembler not operating enough.
Observe for scenario 3 (two forklift trucks) that the throughput is again less than
that for scenario 1 and, in addition, the blockage proportion is high for the assembler. This is due to the unavailability of forklift trucks to remove empty containers
from the assemblers conveyor caused by the nonoptimal priority rule (i.e., pick up at
the assembler has the lowest priority); see Table 14.20. Note that queue sizes of one
(scenario 4) cause a small degradation in throughput. Finally, the high forklift-truck
3000
1229
504
3864
Hours
FIGURE 14.32
Average number of empty containers (over the five runs) in time increments of 1 hour
for scenario 1.
chapter fourteen
14-43
TABLE 14.18
Avg. empty
containers
Parts
per week
Loader
starved
Assembler
blocked
Forklift
idle
1
2
3
4
5
6
7
1229
241
442
1218
1233
1234
1123
15,019
11,405
13,109
14,666
15,050
15,050
15,079
0.000
0.157
0.050
0.001
0.000
0.000
0.000
0.001
0.001
0.133
0.001
0.001
0.001
0.001
0.370
0.489
0.210
0.381
0.386
0.317
0.369
idle proportions in Table 14.18 are caused by the periods of inactivity for the loaders
and the assembler.
The system description and simulation results described above were presented
to approximately 20 of the companys employees including the plant manager. As a
result of this meeting, it was decided to simulate the six additional scenarios described in Table 14.19. Each of these scenarios had queue sizes of 2, three assembler
shifts, and the same run length and number of runs as before.
A summary of the simulation results for these scenarios (and also scenario 1
from Table 14.18) is given in Table 14.20. Note that the throughput does not change
significantly when the number of containers is varied between 2250 and 3000. This
can be seen more clearly in Fig. 14.33, where throughput is plotted as a function of
the number of containers. Observe also that the shortest-distance-first dispatching
rule (scenario 13) gives somewhat better results for two forklift trucks than the
original rule (compare scenarios 13 and 3).
14.6.6 Conclusions and Benefits
Based on the simulation results presented above and several conversations with the
client, the following project conclusions were reached:
The company will probably buy 2250 containers rather than the 3000 containers
originally budgeted.
Three assembler shifts (Monday through Friday) are required.
TABLE 14.19
Number of containers
Forklift trucks
8
9
10
11
12
13
2750
2500
2250
2000
1750
3000
3
3
3
3
3
2*
14-44
TABLE 14.20
Avg. empty
containers
Parts
per week
Loader
starved
Assembler
blocked
Forklift
idle
1
8
9
10
11
12
13
1229
941
640
402
209
80
1410
15,019
14,959
14,798
14,106
11,894
8758
14,306
0.000
0.006
0.014
0.053
0.192
0.374
0.005
0.001
0.001
0.001
0.001
0.000
0.000
0.002
0.370
0.379
0.384
0.411
0.487
0.597
0.265
Two or three forklift trucks are required for Monday through Friday (further investigation is needed), and two are required for Saturday and Sunday.
Two containers should be staged in the input queues of the loaders and the
assembler.
The output queues of the loaders should have a capacity of two.
The system can achieve the desired throughput with the above specifications.
The company received several definite benefits as a result of the simulation
study. First, they gained the assurance (before building the system) that the proposed design for the loaders, warehouse, and assembler would actually meet their
15,000
10,000
1750
2000
2250
2500
Number of containers
2750
3000
FIGURE 14.33
Throughput (parts per week) as a function of the number of containers.
chapter fourteen
14-45
PROBLEMS
14.1. For the system with no breakdowns in Example 14.3, show that the machine tool has
sufficient processing capacity.
14.2. Consider a machine with uptimes U1, U2, . . . and downtimes D1, D2, . . . as described
in Sec. 14.4.2. Is it completely correct to assume that the Uis and the Dis are each
IID within themselves? Why or why not?
14.3. For the machine in Prob. 14.2, is it completely correct to assume that Ui and Di are
independent? Why or why not?
14.4. Consider a machine that operates continuously until a part jams; i.e., it is never
starved or blocked. Suppose that a part has a probability p of jamming, independently
of all other parts. What is the probability distribution of the number of parts produced
before the first jam and what is its mean? Thus, if the average number of parts produced before a jam is known for an actual machine, the above model can be used to
specify p for a simulation model.
14.5. Consider the calendar-time approach for modeling the up segments of a machine in
Sec. 14.4.2. Suppose that a machine breaks down when it is starved. (Perhaps it was
idling at the time.) Do you think that the breakdown would be discovered immediately
(and repair begun) or when the next part actually arrives? Assume that availability of
a repairman is not an issue.
14.6. Consider a machine that operates 24 hours a day for 7 days a week. The uptimes
U1, U2, . . . and downtimes D1, D2, . . . are available, but not the corresponding busy
times B1, B2, . . . . Suppose, for simplicity, that an exponential distribution fits the Uis.
The average number of parts produced per 8-hour shift is known, as well as the average processing time for parts. Assuming that the exponential distribution is also a
good model for the Bis, what mean should be used for a machine-breakdown model
based on busy time?
14.7. Consider a machine that is never starved or blocked. Suppose shop-floor personnel
estimate that the machine has an efficiency e 5 0.9 and typically fails twice in an
8-hour shift. What values of E(U) and E(D) should be used in modeling this machine?
14-46
14.8. Suppose that a machine will fail when either of two independent components fails.
Describe how you would model breakdowns for the machine for each of the following two cases:
(a) The uptime of each machine is based on busy time.
(b) The uptime of each machine is based on calendar time.
14.9. Consider a machine that is never starved or blocked. It will fail when either component A or component B fails. These components fail independently of each other, and
one component does not age while the other component is down. The mean busy
time before failure and the mean repair (down) time for these components (in hours)
are as follows:
Component
A
B
46.5
250.0
1.5
6.0
chapter fourteen
14-47
14.18. Why is the plot of Fig. 14.27 approximately linear? Give an expression for the slope.
14.19. What would you expect a moving average for system design 1s hourly throughputs
(Sec. 14.5) to look like? See Fig. 14.30 for a similar type of plot.
14.20. For system design 2 (Sec. 14.5), why did the congestion level at station 5 get worse?
14.21. For system design 3 (Sec. 14.5), the proportion of forklifts moving loaded is 0.443
(to three decimal places). Thus, the average number of forklifts moving loaded is
0.886. Does this number look familiar?
14.22. Suppose for system design 3 (Sec. 14.5) that jobs arrive exactly 4 minutes apart. The
arrival rate is still 15 per hour. Will the expected throughput be less than, equal to, or
greater than 120? What will happen to the expected time in system?
14.23. For system design 3 (with exponential interarrival times), suppose that a jobs service
time is a constant equal to the mean service time in the original problem. For example, the service time of a type 1 job at station 3 is always 0.25 hour. How will the
expected throughput and the expected time in system compare to the comparable
performance measures for the original version of system design 3?
14.24. Perform a 2622
IV fractional factorial design (see Sec. 12.3) for the manufacturing system of Sec. 14.5, using the following factors and levels:
Factor
Machines in station 1
Machines in station 2
Machines in station 3
Machines in station 4
Machines in station 5
Forklift trucks
4
2
5
3
2
2
5
3
6
4
3
3
The response of interest is the average time in system. For each of the 16 design
points, make 10 replications of length 920 hours, with the first 120 hours of each
replication being a warmup period; use common random numbers (see Sec. 11.2).
Compute point estimates for the expected main effects and two-factor interaction
effects. What are your conclusions?
14.25. Does the empty-containers stochastic process discussed in Sec. 14.6.5 have a steadystate distribution for scenario 7? Why or why not?