Designing simulation experiments
The final stage in analyzing a system with simulation is to
optimize over the system parameters in such a way as to
optimize performance. As stated earlier, simulations is
fundamentally a descriptive tool, not a prescriptive tool. With
care and a lot of computer time, it is possible to optimize
with simulation. In many ways, optimizing with simulation is
very similar to nonlinear optimization.
Designing simulation experiments
First, let's suppose we have a single quantity to optimize
over. This might be the number of machines to place in a
plant, the number of units at which to reorder in an inventory
system, or the number of dollars to put into a particular
portfolio. Let this quantity be denoted x. Suppose you have
a simulation that will determine the performance given x,
denoted .
Designing simulation experiments
If was deterministic, you would simply optimize over x by
any of the techniques covered in your Intro (like binary
search, golden section search, and so on). The only
difference in simulation is that is not deterministic, but
rather it is stochastic. This means that sufficient runs must
be made in order to ensure that the choices ( is better
than ) are made correctly. Because these tests must be
made repeatedly, either the allowance for error must be
very, very small, or some allowance for making an error
must devised.
Designing simulation experiments
This is particularly true when working with more than
one parameter. In this case, it is not even clear how to
use nonlinear algorithms. After all, such things as
derivatives are not available. In this case, you begin at a
particular point. For each parameter, you look at
increasing it a bit and decreasing it a bit. If there are n
parameters, there are possibilities, so you get .
Designing simulation experiments
You then choose the best and that is the next point you
examine. This is continued until you reach a point
where no increase or decrease improves your solution.
This can be sped up somewhat by using factor
analysis, and factorial design, which reduces the
possibilities to a more manageable number.
Designing simulation experiments
Consider the following data points, giving the
simulation results of two different systems (each data
point is the aggregation of the results of a single run):
X: 10, 16, 22, 2, 46, 23, 14, 89, 32, 12
Y: 11, 33, 83, 12, 21, 41, 3, 19, 15, 8
Y-X : 1, 17, 61, 10, -25, 18, -11, -70, -17, -4
Analyze the above data to determine if the expected
value of X is greater than the expected value of Y by
subtracting each X value from the corresponding Y value.
Can you distinguish the systems?
Do the same for the following sets of data. Now can you
distinguish the data? Note that the numbers are the same:
why does this lead to a different conclusion?
X: 10, 16, 22, 2, 46, 23, 14, 89, 32, 12
Y: 8, 15, 19, 3, 41, 21, 12, 83, 33, 11
Y-X : -2, -1, -3, 1, -5, -2, -2 ,-6, 1, -1
Bank Simulation Example
Description of the System
A bank with five tellers opens its doors at 9 a.m. and closes its doors at
5 p.m., but operates until all the customers in line by 5 p.m. have been
served.
Each teller has a separate queue. An arriving customer joins the
shortest line. If two queues have the same length, the customer joins
the leftmost queue (the one closest to the door). When a customer at
the end of a line notices a departure that makes another line shorter
than the customer’s present one, the customer can change to the
shorter line.
Bank Simulation Example
Questions to be Answered About this System
The bank’s management is concerned about the quality of service
currently provided to customers and is thinking of adding one or more
new tellers. How many tellers should they add?
Why is simulation necessary?
Simulation will be used to answer this question because hiring one or
more new tellers, training them, and then watching to see how the
system is effected would be impractical and expensive.
Bank Simulation Example
High-level Model of the System
Pictorial Representation:
The customer being served by teller 3 completes service, causing the
customer from the tail of queue 2 to jockey.
Bank Simulation Example
Input to the System
The inter-arrival times of customers are exponential random variables
with mean 1 minute.
The service times of customers are exponential random variables with
mean 4.5 minutes.
Output Statistics to be Gathered
For each case, n = 5, 6, and 7 tellers,
• Average number of customers in the queue
• Average delay in the queue
• Maximum delay in the queue
Bank Simulation Example
Notes on jockeying:
Let ni be the total number of customers (in the queue plus in service) in
front of teller i at a particular instant. If the completion of a customer’s
service at teller i causes nj > ni + 1 for some teller j, then the customer
from the tail of queue j jockeys to the tail of queue i.
If there are two or more such tellers j (i.e., customers wanting to
move), the customer corresponding to the closest queue to the left
of teller i will jockey.
Bank Simulation Example
Simulation Design and Implementation
•Event description •Event type
•Arrival of a customer to the bank •1
•Departure of a customer upon completion of service
•2
•Bank closes its doors at 5 p.m. •3
Bank Simulation Example
Simulation Design and Implementation
Data Structures Needed
•Event list (one)Storing for each entry:
• Event time• Event type•Teller number if event type 2
•Teller lists (for each teller) Storing for each entry:
•Time of arrival to queue
•Teller busy bit (for each teller)
Subprogram Purpose
Arrive Processes type 1 events.
Depart (Teller_Num) Processes type 2 events, where Teller_Num is the number of the teller completing service.
Jockey(Teller_Num) Jockeys a customer from one queue to another where Teller_Num is the number of the teller completing service.(Jockey is called from Depart and is not an event routine.)
Bank_Closes Cancels the next scheduled arrival, thus preventing any future arrivals.
Report Generates a report and is called from the main program when the simulation ends.
Flowchart for subroutine Arrive
Flowchart for Subroutine Depart
Flowchart for Subroutine Jockey
Sample Output From the Simulation
Languages & Simulators
Possible features to consider in software selection include
the following
•Input
•Processing
•Output
•Environment
•Vendor
•Cost
Languages & Simulators
Warning 1 : Know which features are appropriateCertain features in certain simulation software are not needed to perform the simulation for your system. Then do not chose the software or buy it without the feature included.
Warning 2 : Don’t make judgments on the basis “yes” or “no”. For instances the software you want to buy has the ability to model conveyers. You need software that can model conveyers, but you still need to ask whether the software can model your system’s conveyer. This is crucial as the aspect being model in the software might not be equivalent to the aspect needed for your conveyer system model.
Languages & Simulators
Input considerations
•Point and click capability
•Importing file
•Exporting a file
•Syntax
•Interactive run controller (IRC)
•Interactive to other languages
•Input data analysis capabilities
Languages & Simulators
Processing considerations
•Powerful constructs
•Speed
•Run-Time Flexibility
•Random variate generator
•Reset
•Independent replication
•Attributes and global variables
•Programming
•Portability
Languages & Simulators
Output considerations
•Standardized report
•Customized report
•Business graphic
•Database maintenance
•Collection of Mathematical desired
•Custom performance Measures
•Write to file
Languages & Simulators
Environment considerations
•Ease of use
•Ease of learning
•Quality of documentation
•Animation capability
•Run-only version
•Stability
•History
•Track record
•Support
Languages & Simulators
As noted earlier, there are two basic approaches to
developing simulation models, either use a programming
language or a programming system. The two basic
approaches can be categorized as:
Languages - e.g. SLAM, ECSL, SIMAN. These are high
level programming languages which allow rapid
development compared with C++, Pascal, FORTRAN. It
is a relatively slow approach to building models but
extremely versatile.
Languages & Simulators
Simulators - e.g. Witness, ProModel, TaylorII. These are
data driven systems with little or no programming required.
This approach is fast, easy but more limited in application.
Some simulators are now incorporating virtual reality (VR)
technology into their software. Witness now has a VR plug-
in whilst Deneb market a package called Quest.
Languages & Simulators
A third approach can be derived from these two:
Hybrid systems - Arena combines the flexibility of a
simulation language (SIMAN) with the user-
friendliness of a data driven system. The user
exploits speed and flexibility of the different parts
Languages & Simulators
So which approach to choose? A lot depends on the language you
plan to implement your system in. There are essentially three
types of languages you can use: general purpose languages,
simulation specific languages, and general languages designed
for simulation.
Languages & Simulators
In the first class are languages like FORTAN, C, Pascal, and so on.
These are languages used for many applications. There are a
number of advantages to implementing simulations in general
languages: they tend to be very fast, there are few limitations on
what can be done, programmers are easily found, and simulations
can be done on a number of different computers (due to
standardization of language).
The disadvantage of this approach is cost. Simulations based on
general languages take knowledge of simulation implementation
and are generally very large, intricate programs. The time needed to
design, code, and verify such a system may be overwhelming.
Languages & Simulators
The second class of languages are simulation specific, and include GPSS,
SIMAN, and SLAM. These languages take most of the work out of
creating a simulation. All these systems can do all the queue
manipulation needed in a single line.
The main disadvantages of these languages are in their limited domain. It is
difficult, but not impossible, to create a financial portfolio planner in
SIMAN. It is just not designed for it. On the other hand, another
specialized simulation language can easily handle it within a 123
spreadsheet. It is also difficult to use other programs in the simulation.
Imagine trying to put in a network optimizer in a transportation simulator
if you are required to use SIMAN. Although there is the ability to link in
your own FORTRAN programs, the methods are cumbersome and
inefficient.
Languages & Simulators
The final class includes such languages as SIMSCRIPT.
SIMSCRIPT is a general language in the sense that things like
network optimization and linear programming can be written in
the language. It is also a simulation language, for it has
commands to generate entities and manipulate queues. In many
ways, it is the best of both worlds, and its lack of popularity
surprises me. Perhaps by including everything, it has become
to complicated to be popular.
Languages & Simulators
In most cases, simulation these days is done by an appropriate
special system, although there are still a substantial number of
holdovers from the general language school. If a reasonable
library of routines has been built up, then a general language
can have most of the advantages of the specialized language.
On the other hand, I have yet to see a set of libraries that make
FORTRAN as easy as SIMAN.
Practical issues
This section briefly identifies a number of practical issues surrounding the
use of discrete event simulation.
Current costs. Currently costs are very high.
Future costs. The introduction of cheaper systems may make simulation
more accessible and used not just when the risks are high.
Time for use. The time require to build, verify, validate, experiment and
analyze results can be lengthy and can put many off using simulation. In
practice, however, it is noted that users acquire a great knowledge and
understanding of their own manufacturing system.
Practical issues
Training. With the advent of easier to use commercial simulation systems
the issue of training is less significant, however, users must still
understand the basics of using simulation as well as using particular
simulation software.
Penetration. According to a survey by the UK’s Department of Trade and
Industry (DTI) (Simulation Study Group, 1991) the use of simulation is
low compared with CAD, MRP, etc. This is surprising since it is in
contrast with the high level of satisfaction expressed with those who
have used simulation.
Developments & trends
This section briefly discusses some developments in simulation and
speculates on future trends.
With the interesting demands for user-friendly software and the greater
availability of software libraries for creating them simulation user-
interfaces will become increasingly easier to use. There is an increase in
the use of graphical displays in which icons are dragged from a library
into the model. There is also a trend towards integration with other
software, hence in many package data export facilities exist to enable
the data to be easily moved, for example, to a spreadsheet.
Developments & trends
As noted earlier the costs of simulation software are likely to fall. The
increasing awareness of simulation and the increasing ease of use will
open up simulation to a wider audience and could result in lower prices
due to economies of scale. Also the advent of cheap packages such as
SIMUL8 could cause prices to fall.
There may also be a change in the way simulation models are built. It is
fair to say that the way in which discrete event simulation models are
built is different to many other approaches to building models. There are,
however, flow charting tools which have simulation capabilities
embedded within them. Hence there is a change here towards
embedding simulation into more traditional modeling tools thus requiring
less of a conceptual jump for new users.
Example :
Sample on Special Purposed Languages : GPSS
• First publish in 1961. Was developed for the express purpose of the
discrete systems.
• The system to be simulated is represented by a set of blocks
connected by lines.
• Each block represent an activity and each line represent the path to
the next activity.
• Entities that pass through the system are called transactions.
• The attributes are represented as parameter.
• Each block diagram is unique thus providing a ready interpretation
of the block diagram.
Example :
Sample on Special Purposed Languages : GPSS
Among the symbols used :
• GENERATE
• ADVANCE
A,B C,D,E,F,G
A,B
• TERMINATE
• TRANSFER
• ENTER
A
S
A
• SEIZE
• RELEASE
• LEAVE
A
A
A
QUEUE DEPART
MARK TABULATE
A AB B
A
A
B
Top Related