DISCRETE-EVENT SYSTEM SIMULATION

PE 222

Modules 1 & 2
 Course Objectives

This course enables the students to:

 To learn the terminology, concepts and applications of discrete-
event system simulation
 To understand the various types of simulation models and practical
use
 To solve various discrete-event simulation problems of queuing and
inventory systems
 To know about software for modeling and simulation in various
application areas
 Understand the statistical aspect of simulation, verification and
validation approaches for simulation models
 Course Outcomes
After the completion of this course, students will be
able to:
• CO1 Develop model frameworks for discrete-event system
simulation
• CO2 Apply pseudo-random number based manual simulation
to discrete-event systems
• CO3 Construct models for manufacturing, logistics and
queuing problems for software application
• CO4 Generate pseudo-random number distributions for
queuing systems
• CO5 Analyze the simulation output for statistical verification
and validation
 SYLLABUS

• Module 1 [8]
• Introduction to modeling and simulation concepts,
System analysis and components, Simulation
terminology, Model of a system and types of models,
Discrete verses continuous systems, Static and Dynamic
System simulation, Pros and cons of simulation
• Module 2 [9]
• Event verses activity, General principles of event-driven
simulation, Steps in simulation study, Areas of
application, Use of Pseudo-Random numbers in
simulation of queuing systems, manufacturing systems,
inventory systems and other examples
• Module 3 [8]
• Simulation of manufacturing and material handling systems,
Modeling downtime and failures, Case studies, Introduction to
simulation software and languages for manufacturing and
material handling: ProModel, Witness and Arena.
• Module 4 [9]
• Mathematical and statistical models in simulation, Terminology
and concepts, Useful statistical models: Discrete and
continuous distribution, Poisson, Uniform, Exponential and
Normal distribution, Empirical distribution, Random number
generation
• Module 5 [8]
• Verification and validation of simulation models, Input-output
validation using historical data, stochastic nature of output,
Analysis of simulation results, Steady-State behavior, Output
analysis and Replication method for steady-state simulation
Books:
• Text books:
• 1. Discrete-Event System Simulation by Jerry Banks,
Carson and Nelson, Prentice Hall of India Pvt. Ltd.
(T1)

• Reference books:
• 1. Simulation Modelling and Analysis by Law and
Kelton, McGraw Hill, New York.
 Module 1
Introduction to modeling and simulation concepts

• Simulation is the imitation of the operation of real-world

process or system over time.
• A model construct a conceptual framework that describes
a system
• The behavior of a system that evolves over time is studied
by developing a simulation model.
The model takes a set of expressed assumptions:
• 􀂅􀂅 Mathematical, logical
• 􀂅􀂅 Symbolic relationship between the entities
 • Model: construct a conceptual framework that describes a
system
• It is necessary to consider those accepts of systems that affect
the problem under investigation (unnecessary details must
remove)

Types of Models
Model Taxonomy
 Goal of modeling and simulation
• A model can be used to investigate a wide verity of
“what-if” questions about real-world system.
• Potential changes to the system can be simulated
and predicate their impact on the system.
• So simulation can be used as
􀂅􀂅 Analysis tool for predicating the effect of changes
􀂅􀂅 Design tool to predicate the performance of new
system
􀂄􀂄 It is better to do simulation before Implementation.
 When Simulation Is the Appropriate Tool
• Simulation enable the study of internal interaction of a subsystem
with complex system
• Informational, organizational and environmental changes can be
• simulated and find their effects
• A simulation model help us to gain knowledge about improvement
of
• system
• Finding important input parameters with changing simulation inputs
• Simulation can be used with new design and policies before
implementation
• Simulation models designed for training make learning possible
• without the cost disruption
• A plan can be visualized with animated simulation
• The modern system (factory, wafer fabrication plant, service
• organization) is too complex that its internal interaction can be
treated only by simulation
 Some advantages of simulation are
1. New policies, operating procedures, decision rules,
information flows, organizational procedures, and so on can
be explored without disrupting ongoing operations of the
real system.
2. New hardware designs, physical layouts, transportation
systems, and so on can be tested without committing
resources for their acquisition.
3. Hypotheses about how or why certain phenomena occur can
be tested for feasibility.
4. Time can be compressed or expanded to allow for a speed-
up or slow-down of the phenomena under investigation.
5. Insight can be obtained about the interaction of variables.
6. Insight can be obtained about the importance of variables to
the performance of the system.
7. Bottleneck analysis can be performed to discover where
work in process, information, materials, and so on are being
delayed excessively.
8. A simulation study can help in understanding how the system
operates rather than how individuals think the system
operates.
9. "What if' questions can be answered. This is particularly useful
in the design of new systems.
 Some disadvantages of simulation are
1. Model building requires special training. It is an art that is
learned over time and through experience. Furthermore, if
two models are constructed by different competent
individuals, they might have similarities, but it is highly
unlikely that they will be the same.
2. Simulation results can be difficult to interpret. Most
simulation outputs are essentially random variables (they
are usually based on random inputs), so it can be hard to
distinguish whether an observation is a result of system
interrelationships. or of randonmess.
3. Simulation modeling and analysis can be time consuming
and expensive. Skimping on resources for modeling and
analysis could result in a simulation model or analysis that is
not sufficient to the task.
4. Simulation used in some'cases when an analytical solution
is possible, or even preferable.
 Areas of application
• Manufacturing Applications
• Semiconductor Manufacturing
• Construction Engineering and project management
• Military application
• Logistics, Supply chain and distribution application
• Transportation modes and Traffic
• Business Process Simulation
• Health Care
• Automated Material Handling System (AMHS)
• Test beds for functional testing of control-system software
• Risk analysis
• Insurance, portfolio,...
• Computer Simulation
• CPU, Memory,…
• Network simulation
• Internet backbone, LAN (Switch/Router), Wireless, PSTN (call center),.
 Application Examples
• Dynamic modeling of continuous manufacturing systems,
using analogies to electrical systems
• Benchmarking of a stochastic production planning model in a
simulation test bed
• Automobile assembly
• Modeling for quality and productivity in steel manufacturing
• Neutral information model for simulating machine shop
operations
• Constant time interval production planning with application to
work-in-process control
• Accelerating products under due-date oriented dispatching
rules
• Design framework for automated material handling systems
• Building a virtual shop model for steel fabrication
• Simulation of the supply chain
 Application Examples
• Modeling and simulation of military operations in urban terrain
• Inventory analysis in a manufacturing environment
• Comparison of bottleneck detection methods for AGV systems
• Semiconductor supply-network simulation
• Analysis of international departure passenger flows in an
airport terminal
• Application of discrete simulation techniques to supply chains
• Online simulation of pedestrian flow in public buildings
• Simulating aircraft-delay absorption
• Runway schedule determination by simulation optimization
• Modeling ambulance service
• Simulation modeling in support of emergency firefighting
• Modeling ship arrivals in ports
• Optimization of a transportation system
 Discrete and Continuous Systems
• A discrete system is one in which the state variables change
only at a discrete set of points in time : Bank example
• A continuous system is one in which the state variables
change continuously over time: Head of water behind the
dam
 Systems and System Environment
• A system is defined as a groups of objects that are joined together in
some regular interaction toward the accomplishment of some
purpose.
• An automobile factory: Machines, components parts and workers
operate jointly along assembly line
• A system is often affected by changes occurring outside the system:
system environment.
• Such changes are said to occur in the system environment. In
modelling systems, it is necessary to decide on the boundary between
the system and the environment. This decision may depend on the
purpose of the study.
• In the case of the factory system for example, the factory controlling
the arrival of orders may be considered to be outside the influence of
the factory and therefore part of environment.
• However, if the effect of supply on demand is to be considered, there
will be relationship between factory output and arrival of orders, and
this relationship must be considered an activity of the system.
• Banks : arrival of customers
 Components of system
• Entity
An object of interest in the system : Machines in factory
• Attribute
The property of an entity : speed, capacity
• Activity
A time period of specified length :welding, stamping
• State
A collection of variables that describe the system in any time, relative to the
objective of the study: status of machine (busy, idle, down,…). For example, In
the study of a bank, possible state variables are the number of busy tellers, the
number of customers waiting in line or being served, and the arrival time of the
next customer.
• Event
An instantaneous occurrence that might change the state of the system: e.g
arrivals, breakdown
• Endogenous
Activities and events occurring with the system
• Exogenous
Activities and events occurring with the environment
In the bank study, the arrival of a customer is an exogenous event, and the
completion of service of a customer is an endogenous event.
Exercise:
Name entities, attributes, activities, events, and state variables for
the following systems:
(a) University library
(b) Bank
(c) Call center
(d) Hospital blood bank
(e) Departmental store
(f) Fire service station
(g) Airport
(b) Software organization
 DES Model Development
How to develop a model:
1) Determine the goals and objectives
2) Build a conceptual model
3) Convert into a specification model
4) Convert into a computational model
5) Verify
6) Validate
Typically an iterative process
 Model Development
• Conceptual
o Very high level
o How comprehensive should the model be?
o What are the state variables, which are dynamic,
and which are important?
• Specification
o On paper
o May involve equations, pseudocode, etc.
o How will the model receive input?
• Computational
o A computer program
o General-purpose PL or simulation language?
 Model Development
• Verification
o Computational model should be consistent with
specification model
o Did we build the model right?
• Validation
o Computational model should be consistent with the
system being analyzed
o Did we build the right model?
o Can an expert distinguish simulation output from
system output?
• Interactive graphics can prove valuable
insights.
 DES Model Development
1) Goals and Objectives:
— Find number of technicians for max profit
— Extremes: one techie, one techie per machine
2) Conceptual Model:
— State of each machine (failed, operational)
— State of each techie (busy, idle)
— Provides a high-level description of the system
at any time
3) Specification Model:
— What is known about time between failures?
— What is the distribution of the repair times?
— How will time evolution be simulated?
 Model Development
4) Computational Model:
— Simulation clock data structure
— Queue of failed machines
— Queue of available techies
5) Verify:
— Software engineering activity
— Usually done via extensive testing
6) Validate:
— Is the computational model a good
approximation of the actual machine shop?
— If operational, compare against the real thing
 Steps in
Simulation Study
 STEPS IN A SIMULATION STUDY
• Figure shows a set of steps to guide a model builder in a thorough and sound
simulation study. The steps in a simulation study are as follows:
Problem formulation:
• Every study should begin with a statement of the problem. If
the statement is provided by the policymakers, or those that
have the problem, the analyst must ensure that the problem
being described is clearly understood. If a problem statement
is being developed by the analyst, it is important that the
policymakers understand and agree with the formulation.
Although not shown in Figure, there are occasions where the
problem must be reformulated as the study progresses. In
many instances, policymakers and analysts are aware that
there is a problem long before the nature of the problem is
known.
• Setting of objectives and overall project plan:
• The objectives indicate the questions to be answered
by simulation.
• At this point, a determination should be made
concerning whether simulation is the appropriate
methodology for the problem as formulated and
objectives as stated.
• Assuming that it is decided that simulation is appropriate,
the overall project plan should include a statement of
the alternative systems to be considered and of a
method for evaluating the effectiveness of these
alternatives. It should also include the plans for the study
in terms of the number of people involved, the cost of
the study, and the number of days required to
accomplish each phase of the work, along with the
results expected at the end of each stage.
Model conceptualization.
• The construction of a model of a system is probably as much
art as science.
• The art of modeling is enhanced by an ability to abstract the
essential features of a problem, to select and modify basic
assumptions that characterize the system, and then to enrich
and elaborate the model until a useful approximation results.
• Thus, it is best to start with a simple model and build toward
greater complexity. However, the model complexity need not
exceed that required to accomplish the purposes for which
the model is intended. Violation of this principle will only add
to model-building and computer expenses. It is not necessary
to have a one-to-one mapping between the model and the
real system. Only the essence of the real system is needed.
• It is advisable to involve the model user in model
conceptualization. Involving the model user will both enhance
the quality of the resulting model and increase the
confidence of the model user in the application of the model.
Data collection:
There is a constant interplay between the construction of
the model and the collection of the needed input data. As
the complexity of the model changes, the required data
elements can also change. Also, since data collection
takes such a large portion of the total time required to
perform a simulation, it is necessary to begin it as early as
possible, usually together with the early stages of model
building.
• The objectives of the study dictate, in a large way, the
kind of data to be collected. In the study of a bank, for
example, if the desire is to learn about the length of
waiting lines as the number of tellers change, the types
of data needed would be the distributions of inter-arrival
times (at different times of the day), the service-time
distributions for the tellers, and historic distributions on the
lengths of waiting lines under varying conditions.
Model translation
Most real-world systems result in models that require a
great deal of information storage and computation, so the
model must be entered into a computer-recognizable
format. We use the term "program" even though it is
possible to accomplish the desired result in many instances
with little or no actual coding.
The modeler must decide whether to program the model in
a simulation language, such as GPSS, or to use special-
purpose simulation software. For manufacturing and
material handling, Arena®, AutoMod , Extend , Flexsirn,
MicroSaint, ProModel®, Quest®, SIMUL8®, and WITNESS .
Simulation languages are powerful and flexible. However, if
the problem is amenable to solution with the simulation
software, the model development time is greatly reduced.
Furthermore, most of the simulation-software packages
have added features that enhance their flexibility.
Verified?
• Verification pertains to the computer program
prepared for the simulation model. Is the computer
program performing properly? With complex
models, it is difficult, if not impossible, to translate a
model successfully in its entirety without a good
deal of debugging; if the input parameters and
logical structure of the model are correctly
represented in the computer, verification has been
completed.
Validated?
• Validation usually is achieved through the
calibration of the model, an iterative process of
comparing the model against actual system
behavior and using the discrepancies between the
two, and the insights gained, to improve the model.
• This process is repeated until model accuracy is
Judged acceptable.
• In the example of a bank, data was collected
concerning the length of waiting line under current
conditions.
• Does the simulation model replicate this system
measure? This is one means of validation.
• Experimental design
• The alternatives that are to be simulated must be
determined. Often, the decision concerning which
alternatives to simulate will be a function of runs
that have been completed and analyzed. For each
system design that is simulated, decisions need to
be made concerning the length of the initialization
period, the length of simulation runs, and the
number of replications to be made of each run.
• Production runs and analysis
• Production runs, and their subsequent analysis, are
used to estimate measures of performance for the
system designs that are being simulated. the
analysis of simulation experiments. Software to use
in this step, including AutoStat (in AutoMod),
OptQuest, SimRunner (in Pro Model), and WITNESS
Optimizer (in WITNESS).
• More Runs?
• Given the analysis of runs that have been
completed, the analyst determines whether
additional runs are needed and what design those
additional experiments should follow.
• Documentation and reporting.
• There are two types of documentation: program
and progress.
• Program documentation is necessary for numerous
reasons. If the program is going to be used again by
the same or different analysts, it could be necessary
to understand how the program operates. This Will
create confidence in the program, so that model
users and policymakers can make decisions based
on the analysis.
• Also, if the program is to be modified by the same
or a different analyst, this step can be greatly
facilitated by adequate documentation.
• Another reason for documenting a program is that
model users can change parameters at will in an
effort to learn the relations between input
parameters and output measures
• Progress reports provide the important, written
history of a simulation project. It gives a chronology
of work done and decisions made. This can prove
to be of great value in keeping the project on
course. Frequent reports (monthly, at least) so that
even those not involved m the day-to-day
operation can keep abreast.
 Use of Pseudo-Random numbers in
simulation of queuing systems
• Pseudo-Random numbers
• A set of values or elements that is statistically
random, but it is derived from a known starting point
and is typically repeated over and over. It is called
"pseudo" random, because the algorithm can
repeat the sequence, and the numbers are thus not
entirely random.
• For example: Random Numbers generated through
calculators, computer programs etc.
 Queuing systems
A queuing system can be described as a system
consisting of one or several servers at which units of
some kind (generically called “customers”) arrive for
service; whenever there are more units in the system
than the service facility can handle simultaneously, a
queue (or waiting line) develops.
For example: Queue at ticket counter, Jobs in waiting
in jobshop, cars in car wash station, a printer
processing jobs sent to it from different computers,
etc.
Queuing systems
System Customers Server(s)
Reception desk People Receptionist
Repair facility Machines Repairperson
Garage Trucks Mechanic
Hospital Patients Nurses
Warehouse Pallets Fork-lift Truck
Airport Airplanes Runway
Production line Cases Case-packer
Road network Cars Traffic light
Grocery Shoppers Checkout station
Job shop Jobs Machines/workers
The Calling Population
• The population of potential customers, referred to as
the calling population, may be assumed to be finite
or infinite.
• For example, consider a group of five machines that
are curing tires. After an interval of time, a machine
break down and must be attended by a worker who
removes the tire. The machines are the "customers;'
who "arrive" at the instant they break down.
• The worker is the "server," who "serves" machine as
soon as possible. The calling population is finite and
consists of the five machines.
• In systems with a large population of potential
customers, the calling population is usually assumed
to be infinite. Examples of infinite populations include
the potential customers of a restaurant, bank, or other
similar service facility.
 Queue Behaviour and Queue Discipline

• Queue behaviour refers to the actions of customers

while in a queue waiting for service·to begin. In
some situations, there is a possibility that incoming
customers will balk (leave when they see that the
line is too long), renege (leave after being in the line
when they see that the line is moving too slowly), or
jockey (move from one line to another if they think
they have chosen a slow line).
Queue discipline refers to the logical ordering of customers in a queue
and determines which customer will be chosen for service when a
server becomes free. Common queue disciplines include first-in-first-
out (FIFO); last-in-first-out (LIFO); service in random order (SIRO);
shortest processing time first (SPT); and service according to priority
(PR). In a job shop, queue disciplines are sometimes based on due
dates and on expected processing time for a given type of job.

Queuing discipline or the rules of the queue:

1) FIFO (First In First Out) also called FCFS (First Come
First Serve) - orderly queue.
2) LIFO (Last In First Out) also called LCFS (Last Come
First Serve) - stack.
3) SIRO (Serve In Random Order).
4) Prioritized (Based on some criteria)
• Queuing theory uses notation to classify the
different types of queuing systems. Queuing systems
are classified using the notation A/S/c/K/N/D
where:

• A is the arrival process

• S is the mathematical distribution of the service time
• c is the number of servers
• K is the capacity of the queue, omitted if unlimited
• N is the number of possible customers, omitted if
unlimited
• D is the queuing discipline, assumed first-in-first-out if
omitted
• For example, an ATM

• It can serve: one customer at a time; in a first-in-first-

out order; with a randomly-distributed arrival
process and service distribution time; unlimited
queue capacity; and unlimited number of possible
customers.
• Queuing theory would describe this system as a
M/M/1 queue (“M” here stands for Markovian, a
statistical process to describe randomness).
General principles of event-driven simulation

Some questions that need answers before programming

include:
• How does each event affect system state, entity
attributes, and set contents?
• How are activities defined (i.e., deterministic,
probabilistic, or some other mathematical equation)?
• What event marks the beginning or end of each
activity?
• Which events trigger the beginning (and end) of each
type of delay?
• What is the system state at time 0? What events should
be generated at lime 0 to get the simulation started?
Flowcharts for various cases
 Unit entering system flow diagram

System state: LQ(t), LS(t)

LQ(t) is the number of customers
in the waiting line
LS(t) is the number being served
(0 or 1) at time t
Events:
Arrival (A);
Departure (D);
Stopping event (E)
Service just completed flow diagram
 For Programming purpose
• List: A collection of (permanently or temporarily)
associated entities, ordered in some logical fashion
(such as all customers currently in a waiting line,
ordered by "first come, first served," or by priority).
• Event notice: A record of an event to occur at the
current or some future time, along with any
associated data necessary to execute the event; at
a minimum, the record includes the event type and
the event time.
• Event list: A list of event notices for future events,
ordered by time of occurrence; also known as the
future event list (FEL ).
 For Programming purpose
• Different simulation packages use different
terminology for the same or similar concepts-for
example, lists are sometimes called sets, queues, or
chains. Sets or lists are used to hold both entities
and event notices.
• The entities on a list are always ordered by some
rule, such as first-in-first-out or last-in-first-out, or are
ranked by some entity attribute, such as priority for
due date.
• The future event list (FEL) is always ranked by the
event time recorded in the event notice.
• To keep track of activities and their expected completion
time, at the simulated instant that an activity duration begins,
an event notice is created having an event time equal to the
activity's completion time. For example, if the current
simulated time is CLOCK = 100 minutes and an inspection time
of exactly 5 minutes is just beginning, then an event notice is
created that specifies the type of event (an end-of-inspection
event), and the event time (100 + 5 =105 minutes).
• In contrast to an activity, a delay's duration is not specified by
the modeler ahead of time, but rather is determined by
system conditions. Quite often, a delay's duration is measured
and is one of the desired outputs of a model run.
• Typically, a delay ends when some set of logical conditions
becomes true or one or more other events occur. For
example, a customer's delay in a waiting line may be
dependent on the number and duration of service of other
customers ahead in line as well as the availability of servers
and equipment.
• A delay is sometimes called a conditional wait, an activity an
unconditional wait.
• The systems considered here are dynamic, that is,
changing over time. Therefore, system state, entity
attributes and the number of active entities, the
contents of sets, and the activities and delays
currently in progress are all functions of time and are
constantly changing over time. Time itself is
represented by a variable called CLOCK.
 Example: Single-Channel Queue
• A small grocery store has only one checkout
counter. Customers arrive at this checkout counter
at random times that are from 1 to 8 minutes apart.
Each possible value of inter-arrival time has the
same probability of occurrence, as shown in Table.
The service times vary from 1 to 6 minutes, with the
probabilities shown in Table. The problem is to
analyze the system by simulating the arrival and
service of 100 customers.
Manual simulation using pseudo-
random numbers
• The essence of a manual simulation is the
simulation table.
• These tables are designed for the problem
at hand, with columns add to answer the
questions posed.
• The first customer is assumed to arrive at
time 0.
• Using the queue discipline and flow
diagrams for arrival and departure,
simulation is progressed till fulfilling the
condition for stopping
Service Time Cumulative Random Digit
(Minutes) Probability Probability Assignment
1 0.10 0.10 01-10
2 0.20 0.30 Il -30
3 0.30 0.60 31 -60
4 0.25 0.85 61-85
5 0.10 0.95 86-95
6 0.05 1.00 96-100

Random digits are converted to random numbers between 0-1 by placing a

decimal point appropriately
Time between
Arrivals(Minutes) Probability Cumulative Probability Random Digit Assignment
I 0.125 0.125 001-125
2 0.125 0.250 126-250
3 0.125 0.375 251-375
4 0.125 0.500 376-500
5 0.125 0.625 501-625
6 0.125 0.750 626-750
7 0.125 0.875 751 -875
8 0.125 1.000 876-1000

Random digits are converted to random numbers between 0-1 by placing a

decimal point appropriately
 Some manual simulation problems
Problem 1. The daily demand for a product is found to
follow the distribution as
Demand Probability
10 0.25
11 0.35
12 0.30
13 0.10
Determine the total demand for the next 10 days.
 Problem 2. A baker is trying to figure out how many cakes to bake
each day. The probability distribution of the number of customers is as
follows:
Number of Customers/Day Probability
8 0.35
10 0.30
12 0.25
14 0.10
Customers order I, 2, 3, or 4 cakes according to the following
probability distribution
Number of Cakes Ordered/Customer Probability
1 0.4
2 0.3
3 0.2
4 0.1
Cakes sell for INR 400 per piece. They cost INR 300 to make. All cakes not
sold at the end of the day are sold at half-price to a local grocery store.
Based on 5 days of simulation, how many cakes should be baked each
day?
Problem 3. Three random variables K1, K2, and K3 are
distributed as
Kl : 20 ± 10
K2 : 12 ± 10
K3 : 5 ± 4
M= (2Kl + K2)/K3
Simulate 10 values of random variable M and
compute the average value.
(Static Simulation Example)
Problem 4. Students arrive at the university library counter with
inter-arrival times distributed as

Time between arrivals (Minutes) Probability

5 0.1
6 0.4
7 0.3
8 0.2

The time for a transaction at the counter is distributed as

Transaction time (Minutes) Probability
2 0.15
3 0.5
4 0.2
5 0.15
If more than two students are in the queue, an arriving student goes
away without joining the queue. Simulate the system and determine
the balking rate of the students.
For Deterministic Inventory model
• Economic order quantity is given by
SIMULATION OF STOCHASTIC INVENTORY SYSTEMS
 SIMULATION OF INVENTORY SYSTEMS
• An important class of simulation problems involves
inventory systems. A simple inventory system is shown in
Figure.
• This inventory system has a periodic review of length N,
at which time the inventory level is checked.
• An order is made to bring the inventory up to the level M.
At the end of the first review period, an order quantity Q1
is placed.
• In this inventory system, the lead time (i.e., the length of
time between the placement and receipt of an order) is
zero.
• Demands are not usually known with certainty, so the
order quantities are probabilistic. Demand is shown as
being uniform over the time period in Figure.
• In actuality, demands are not usually uniform and
do fluctuate over time. Another is that the lead time
is random of some positive length.
• Notice that, in the second cycle, the amount in
inventory drops below zero, indicating a shortage.
• These units are backordered; when the order
arrives, the demand for the backordered items is
satisfied first. To avoid shortages, a buffer, or safety,
stock would need to be carried.
• Carrying stock in inventory has an associated cost
attributed to the interest paid on the funds
borrowed to buy the items (this also could be
considered as the loss from not having the funds
available for other investment purposes). Other
costs can be placed in the carrying or holding cost
column: renting of storage space, hiring of guards,
and so on.
• An alternative to carrying high inventory is to make
more frequent reviews and, consequently, more
frequent purchases or replenishments. This has an
associated cost: the ordering cost.