Lesson 4: System Definition

Overview:
This lesson covers system classifications, basic high-level flowchart, components and events to
model, data to be included in the model and output data.

Objective:
 To identify different system classifications
 To convert system inputs to outputs
 To distinguish the data to be modelled

A. System Classifications
1. Discrete vs. Continuous vs. Combined Systems
 As a review, discrete systems, changing values of certain state at some discrete
point of time where the events occur. Events will only occur at the defined activity
time and delays. While in continuous event systems, some event is always
occurring. This means that the status of some component in the system is
continuously changing with respect to time.

Combined event models contain both discrete and continuous components.

Combined event systems are typically the most difficult type of system to model. You
have to handle not only the increased complexity of the continuous event modeling
but also the transformation to discrete entities. You must also decide how to handle
the output measures of performance.

2. Terminating vs. Nonterminating System

Terminating simulation is one in which the simulation starts at a defined state or
time and ends when it reaches some other defined state or time. Nonterminating or
ready-state simulation is one in which the steady-state behaviour of the system is
being analyzed. This means that the simulation never ends nor does it mean that the
system being simulated has no eventual termination.

B. High-level Flowchart Basics

An essential tool for defining the system is a high-level flow chart. A high-level flow chart
helps to obtain a fundamental understanding of the system logic. It graphically depicts
how the major components and events interact. It also illustrates how the input and
output data play a role in the model.

Standard Flowchart Symbols

1. Oval
Used to define the start and end processes.

2. Rectangle
Used to represent general-purpose processes that are not specifically covered by
any of the other flow chart symbols.

3. Tilted Parallelogram
Used for processes that involve some sort of input or output.

4. Diamond
Used to represent a decision in the flow chart logic.

C. Components and Events to Model

1. Components
Simulation model components is a component that is meant to be used as part of
a simulation model representing a sub-system with a predefined reduction and
generalization.

Some common system components to be modeled.

 Personnel
  Machines
 Transporters
 Conveyors

2. Processes and Events

You must also decide what system events should be included in the model. One way
of determining which processes to model is to include any process that is capable of
being performed differently over time.

Process is a series of steps and decision in the way work is completed.

Event is an important happening especially one that out of and is connected with
previous happenings.

In the event and process, queuing procedures occur to give way one event or
process to be finished first. Queuing can be either parallel or single snake.
Parallel queues are found in systems that have multiple server resources while
single snake queue is often used to model complex systems.

Both parallel and single snake queues may also exhibit different types of queue
behaviour: queue priorities and queue entity behaviour.

Queue priority means that the order of the entities in the queue may change
according to the priority scheme.
a. First-In, First-Out (FIFO)
b. Last-In, First-Out (LIFO)
c. Shortest Processing Time (SPT)
d. Longest Processing Time (LPT)
e. Lowest Value First (LVF)
f. Highest Value First (HVF)
g. User-Defined Rules

Queue entity behavior involves the actions of the entities with respect to entering
and remaining in the system queues.
a. Balking
Balking occurs when a customer enters the system but leaves before entering a
queue. Balking is the result of facing a long queue wait or limited queue capacity.

b. Reneging
Reneging is when an entity enters the line but leaves before being processed.
This would correspond to a customer who is tired of waiting in line and leaves.
The decision to renege is also an individual decision.

c. Jockeying
 Jockeying is associated only with parallel queues. This is when an entity
switches between two different queues. The decision to jockey is usually
triggered by the end of a service period with the resource related to the other
queue.

D. Data to be Included in the Model

1. Input Data
Before going to simulate a model, you must identify the types of input data that
affects the system’s output data performance.
a. Input Data Collection Principles
A fundamental concept in this process is to break down the types of data into as
many different independent types as possible.

b. Types of Input Data

There are two categories of input data: related to the concept of system entities
which are the elements that are processed by the system; and system resources
that are the parts of the system that process the system entities.

c. Interarrival Times
These are the amount of time that passes between the arrivals of batches or
groups of entities into the system.

d. Batch Sizes
Involve the number of individual entities that arrive at the same time to be
processed by a system.

e. Queue Entity Behaviour

Balking, Reneging, Jockeying

f. Classifications
Include types or priorities of entities arriving in the system.

g. Service Times
Include processing times that a job or customer undergoes.

h. Failure Rates
Involve the frequency of process failure or resource unavailability.
i. Scheduled Maintenance
This involves reducing the availability of resources such as machines to perform
preventive maintenance to reduce the probability of equipment failures.

j. Break Times
Primarily pertain to system resources such as operators and clerks.

k. Movement Times
Include the duration for an entity to travel between areas of a system.
 2. Input Data Considerations
The importance of collecting accurate and complete input data cannot be overemphasized.
However, you may be interested in a high-level model and may have only limited project time. In
this situation, collecting an exhaustive amount of data may not be in the best interest. When this
occurs, you should make note of what input data collection compromises were necessary.
These compromises should be clearly documented under the assumptions and limitations
section of the project report.
 Lesson 5: Input Data Collection and Analysis

Overview:
This lesson covers sources of data, how to collect data, classification of data, input data
distributions, how to analyse data and how much data to be collected.

Objectives:
 To identify the sources of data
 To classify data collected
 To differentiate data distributions
 To analyse data collected
A. Sources of Data
1. Historical Records
If the base system or a similar base system has been in existence for some time, it is
likely that some form of historical records is available. Because the records are
already in existence and will not require real-time data collection, this approach may
appear to be a very attractive option to the practitioner.

2. Manufacturer’s Specifications
Obviously, most manufacturers will be providing a theoretically based specification
for their equipment. Whether or not these claims can actually be achieved in a real
environment has to be proven.

3. Vendor Claims
The vendor or distributor claims will probably fall between the manufacturer’s
specifications and reality. The vendor or distributor should already have some
experience with the type of system that is being considered

4. Operator Estimates
Operators of existing equipment can be a valuable data resource when the
practitioner does not have the time or data collection resources to collect actual data.
If the operator is knowledgeable about the system, it may be possible to obtain some
performance estimates that can be used as input data.

5. Management Estimates
You may also consider soliciting managers or engineers associated with the system.
Though these individuals probably do not have the same proximity relationship to the
process, their input may be helpful when an experienced operator is not available for
input.

6. Automatic Data Capture

It may be possible to set up some sort of automatic data capture system. Electronic
access or other information-based systems may also be able to capture the type of
data that the practitioner needs for the simulation model.

7. Direct Observations
The most physically and mentally demanding form of data collection is direct
observation. This is where you or another individual actually goes to the location of
the system and visually collects data. The data are collected by pen and pad or
perhaps with some technological assistance. If the low-tech pen-and-pad approach
is used, the practitioner may want to develop some sort of data collection form to
keep the process as organized as possible.

B. Collecting Input Data

1. Data Collection Devices
 If input data are collected in real time, it may be collected either manually or with the
assistance of electronic devices. If data are collected manually with a timing device,
it may be helpful to create a form to help keep the data collection process as
organized as possible. You can keep things organized by easily securing the
mechanical or electronic stopwatch to a clipboard for unobtrusive data collection.

2. Time Collection Mode and Units

An important issue for simulation input data concerning time intervals is the time unit
that should be used. Novice practitioners can be frequently observed recording the
absolute time or clock time of when different entities arrive into the system. If this
approach is taken, extra work will be necessary to convert the absolute time to a
relative time so that interarrival times may be calculated. It is usually less labor
intensive to collect the data correctly in the first place using a relative, interarrival
time approach.

A second time collection issue is what types of units to use. For calculation
purposes, it may be difficult to use as small a time unit as seconds. It is more easily
understood when a simulation run is performed for either 8 hours or 480 minutes, not
28,800 seconds.

In addition, as a data collector you need to be unbiased and avoid data process
destructions.

C. Classifications of Data
1. Probabilistic vs. Deterministic Data
Deterministic data mean that the event involving the data occurs in the same
manner or in a predictable manner each time. This means that this type of data
needs to be collected only once because it never varies in value.

A probabilistic data do not occur with the same type of regularity. In this case, the
process will follow some probabilistic distribution. Thus, it is not known with the same
type of confidence that the process will follow an exactly known behavior.

2. Discrete vs. Continuous Data

Discrete-type data can take only certain values. Usually this means a whole
number.
Continuous can take any value in the observed range. This means that fractional
numbers are a definite possibility.

D. Input Data Distributions

1. Bernoulli Distribution
The Bernoulli distribution is used to model a random occurrence with one of two
possible outcomes. These are frequently referred to as a success or failure.

2. Uniform Distribution
A uniform distribution means that over the range of possible values, each individual
value is equally likely to be observed.
 3. Exponential Distribution
The exponential distribution is commonly utilized in conjunction with interarrival
processes in simulation models because the arrival of entities in many systems has
been either proven or assumed to be a random or Poisson process.

4. Normal Distribution
The time duration for many service processes follows the normal distribution. The
reason for this is that many processes actually consist of a number of subprocesses.

5. Triangular Distribution
The triangular distribution may be used in situations where the practitioner does not
have complete knowledge of the system but suspects that the data are not uniformly
distributed.

6. Beta Distribution
The beta distribution holds the distinction of being able to cover only the range
between 0 and 1.

7. Gamma Distribution
The gamma distribution is another distribution that may be less common to the
practitioner. The gamma distribution can also be somewhat intimidating.

8. Weibull Distribution
The Weibull distribution is often used to represent distributions that cannot have
values less than zero. This situation frequently exists with symmetric distributions like
the normal distribution that represent service or process times.

E. Analysing Input Data

There are four methods to analyse the data.
1. Graphic Approach
The most fundamental approach to attempting to fit input data is the graphic
approach. This approach consists of a visual qualitative comparison between the
actual data distribution and a theoretical distribution from which the observed data
may have come.

2. Chi-Square Test
The chi-square test is commonly accepted as the preferred goodness of fit
technique. Like the graphic comparison test, the chi-square test is based on the
comparison of the actual number of observations versus the expected number of
observations.

3. Kolmogorov-Smirnov Test
 The KS test should be utilized only when the number of data points is extremely
limited and the chi-square test cannot be properly applied. The reason for this is that
it is generally accepted that the KS test has less ability to properly fit data than other
techniques such as the chi-square test. A final limitation of the KS test is that some
references recommend against using the KS with discrete distributions.

4. Square Error
The square error approach utilizes the same previously describe equal-interval or
equal-probability approach to determine the number of cells and cell boundaries. As
the name implies, the square error approach uses a summed total of the square of
the error between the observed and the theoretical distributions. The error is defined
as the difference between the two distributions for each individual data cell. The
square error approach is commonly used as a means of assessing the relative
suitability of a variety of different theoretical distributions to represent the observed
distribution.

F. How Much Data Need to be Collected?

1. Right Data
2. Data Representation
3. Data to Perform Goodness of Fit Test
 Lesson 6: Model Translation

Overview:
This lesson covers simulation program selection, model translation section content, and
program organization.

Objectives:
 To determine the components of the system
 To translate system into computer model
 To organize the simulation program
A. Simulation Program Selection
1. Advances in the Computer Hardware
a. Graphic Capabilities
Advances, particularly in the areas of computing power and graphics displays,
have had a tremendous impact on the acceptance of simulation modeling.

b. Speed
Increasing the speed tends to decrease the accuracy and conversely increasing
accuracy deceases speed. To make the model real-time capable, maintain a
balance between speed and accuracy.

2. Software Cost
Cost helps to determine if your model is likely to cause an overrun when simulate it
in real-time processor.

3. Developers’ Preferences
To help decide which approach is more appropriate whether to use general
programming language or simulation-specific software package.

B. Model Translation Section Content

1. Getting Started
The most difficult part of programming the simulation is getting started. At this point
in the simulation program, a high-level flow chart should already exist.

2. Version Management
To help assist the practitioner in creating and maintaining an organized program file
system.
 Project subdirectories
 Saving simulation programs
 File version management techniques
 Backing up simulation project files

3. Programming Commenting
As with any other computer program, a simulation program can benefit greatly from
liberal commenting. Liberal commenting helps not only while you are developing the
program but also when you attempt to look at and understand the program years
from now.

4. Program Organization
 You must conduct an endless battle to keep the simulation program as organized as
possible.

5. Mnemonic Naming Conversion

The mnemonic naming convention should describe the exact nature of the
component as well as what type of component it is. You will find that these
mnemonic techniques will greatly speed the rate at which the program can be
developed.

6. Advanced Program Planning

Most simulation models usually end up being modified in some manner in order to
represent different experimental alternatives. Because the model may eventually be
recycled, it is almost always of benefit to attempt to build as much flexibility into the
model as is reasonably possible.

7. Multiple Program Development

Under some circumstances, you may need the assistance of other developers in
order to complete the programming component of a simulation project.

C. Ways to Organize Program

1. Graphic Spaghetti Code
Spaghetti code was the result of the excess use of “goto” statements in a program. It
is impossible to follow individual strands of spaghetti, it was impossible to follow
spaghetti code that jumped in and out of this and that part of a program.

2. Subroutine Views
In attempting to keep the program organized, you should keep in mind the different
levels that can be used to view the program. You should attempt to keep all like
components or components that are associated with each other in the same view.

3. Program Hot Keys

Hot keys enable the practitioner to associate a particular view of the model with a
key on the computer keyboard. So any time the practitioner wants to navigate to a
particular area, all that is necessary is to press the key corresponding to that part of
the model.

4. Mnemonic Name Conversion

If you fail to use mnemonic techniques, you will be continuously forced to refer to
other parts of the program.
References:
Chung, Christopher A., Simulation and Modeling Handbook: A Practical Approach, 2004, CRC
Press

Hildebrand, D.K. and Ott, L. (1991), Statistical Thinking for Managers, PWS-Kent, Boston.
Johnson, R.A., Freund, J.E., and Miller, I. (1999), Miller and Freund’s Probability and Statistics
for Engineers, Pearson Education, New York.

Kelton, D.W., Sadowski, R.P., and Sadowski, D.A. (2002), Simulation with Arena, 2nd ed.,
McGraw-Hill, New York.
Law, A.M. and Kelton, D.W. (2000), Simulation Modeling and Analysis, 3rd ed., McGraw-Hill,
New York.

Heisel, Maritta, Uhrmacher, Adelinde, Lüthi, Johannes, Valentin, Edwin, A Description Structure
for Simulation Model Components (n.d)

https://www.promodel.com

https://www.processmodel.com

https://www.mathworks.com