a brief introduction to discrete-event simulation modeling and analysis ming zhou, phd., associate...

A Brief Introduction to Discrete-Event Simulation Modeling and Analysis

Ming Zhou, PhD., Associate Professor

Indiana State University, Terre Haute, IN 47809, USA

(812)237-3983; [email protected]

Introduction to Simulation

Systems and models of a system Concept of a system (input, output, process,

resources, behavior, performance measures) Interest of studying a system (design, planning,

control, improvement, and optimization) Models of a system: representation of real systems

Physical modelsLogical or mathematical models

System and models of system

System

Study/experiment with the

actual system

Study/experiment with a model of

the system

Physicalmodel

Mathematical orlogical model

Simulationmodel

Analyticalmodel

Studying a system via analytical model v.s. simulation model (prescriptive v.s. descriptive models)

Analytical model Performance measures are expressed as mathematical functions of input parameters, result is exact and close form solution, applicable only to simple problems.

Simulation model a logical model that is evaluated (numerically) over a time period of interest, Performance measures are estimated from model-generated data with statistical procedures, applicable to systems of any complexity.

Slide 2: Introduction to Simulation

Introduction to Simulation

Why use simulation models?

It is often of interest to study a real-world system to generate knowledge on its behavior or dynamics. However it is usually necessary to use a simulation model for the following reasons:

Experimentation with the real system is often disruptive (e.g. study of a flow-line manufacturing process)

Experimentation with the real system is not cost-effective (e.g. study of large logistic/distribution center)

Experimentation with the real system is simply impossible (e.g. study of space rocket launching operations)

Definition of simulation

The process of designing and creating a computerized model of a real or proposed system for the purpose of numerical experiment to develop better understanding of the behavior/dynamics of that system under a given set of conditions.

Simulation is a powerful tool for design, modeling, analysis, and optimization of systems. It is one of the target technologies for the 21st century identified by the NRC, NIST, NSF, IIE, SME, ASME and many others …


Types of simulation Static v.s. dynamic (Is time a factor?) Continuous v.s. discrete (nature of change along time) Deterministic v.s. stochastic (Is randomness

important?)

Application of simulation (See demos of application)

- Manufacturing - Logistics & transportation system- Healthcare - Service systems- Military systems - Telecommunication- Entertainment - Robotics simulation


Application of simulation (in terms of decision making)

- System design and evaluation

- Process/system improvement and optimization

- Policy or strategy evaluation (“What-if” analysis)

Limitations of simulation: Simulation cannot:

- Provide exact solutions

- Find optimal solutions (in exact form)

- Compensate for inadequate data or poor management decisions

- Provide fast and easy solutions to complex problems


Implementation of simulation By hand (for small problems, e.g. Buffon Needle

problem) By computers with software (3 levels of

abstraction): Programming in general-purpose language

(e.g., C/C++,Pascal, Fortran) Simulation language (SIMAN, GPSS, SLAM) High level simulators (GUI based, menu-driven,

such as ARENA©, AutoMod©, ProModel©) Issues of modeling efficiency, flexibility and ease of implementation, hierarchical structure.


Issues related to level of modeling constructs: modeling efficiency versus modeling flexibility

Level of modeling abstraction hierarchy

Modeling efficiency

Modeling flexibility

Consider a simple example:

Simulation of a single server processing system (e.g., an M/M/1 queuing system)

System components and their relations (needs for abstraction)

System states and constraints Problem statement (goal of the study: what

output/performance measures to be collected or computed?)


Introduction to SimulationA graphical model of a M/M/1 system

Arrivals

Waiting line

(queue)

ServerDepartures

Arrival time and service time are random variables

Elements of a simulation model:

Entities: items being processed by and flow through the system, e.g. parts, cars, customers

Attributes: properties/characteristics assigned to entities, e.g. part types, time arrived in a queue

Variables: changeable quantities defined to reflect the characteristics of the system, e.g. we may define two state variables for a M/M/1 system: Server status (states): idle or busy Number of items waiting in queue


Events: an event is an occurrence of something that changes the state of the system (e.g. arrival or departure of a customer in a M/M/1 system)Resources: means by which to process entities (e.g. machines, operators, fork-trucks)Queues (buffers, waiting lines): storage space for entities waiting for required resource)Activities/processes: an activity is a period of time during which an entity (entities) is serviced (e.g. processed or transferred). The duration of an activity is known a priori, and can be scheduled (e.g. processing time, transfer time)


Statistical accumulators: variables that collect and keep track of statistics during the progress of simulation to obtain required output performance measures.Simulation clock: a mechanism to keep track of current (simulated) time in a simulation. It lurches from the time of one event to the time of next event.


arrival2 arrival3 departure1

t1 t2 t3

Jumps of simulation clock

Event-driven simulation: simulation is centered around events that occur as a consequence of activities or delays. Simulation keeps track of events that are assumed to occur in (simulated) future, and update system states and move the simulation clock as events occur sequentially. Need a mechanism to determine and control: What type of event to occur ? (adding new event) Which event should be scheduled to occur next? What to do when an event occurs? (e.g. updating

system states and statistical accumulators)


Event transition/interaction diagram

Event-driven simulation logic flow chart


Arrival Departure

Process-oriented simulation: this approach emulates the flow of an entity through the system, i.e. centers on the process that the entity undergoes. Consider main steps that an entity goes through a single server M/M/1 simulation process: Create itself (mark the time-in) Wait in queue for a resource Seize the resource (take itself out of the queue) Delay a duration equal to its service time Release the resource Increment production-counter/accumulator and

tally flow time Dispose itself and leave the system


Process-oriented method is intuitive and simple for understanding, and is popularly used in modeling.

Most simulation combines both approaches: using an event-scheduling approach to control the execution but allowing user to model the system in process-oriented front-end (user interface), e.g. ARENA©.

Randomness in simulation

- Random input and therefore random output

- Replications of random experiment


General steps in a simulation study

Understand the system Define problem (goals/objectives, constraints, scope) Formulate a simulation model (conceptual design) Implement the model (translate into modeling software) Verify and Validate the model (Pilot runs) Design the experiments Run the experiments (Production runs) with the model Analyze outputs/results Interpret, document, present and implement the results


Simulation with ARENA©

What is ARENA©?

Arena is a Microsoft Windows based application package for simulation modeling and analysis. It is a product of Rockwell Software, Inc.

Current version: 7.0 (2003)

ARENA’s User interface: GUI, interactive and menu driven.

Structure of an ARENA simulation model: an ARENA simulation model consists of two types of modules (i.e. fundamental building blocks): Logic modules (flowchart modules): perform logical

functions of a simulation model, and control the logic of how entities flow through the system

Data modules: define the characteristics of process elements (e.g. Entities and Resources), specify and implement experimental conditions of simulation models (number of replications, run length, etc.)

Modules are placed in groups called “panels”

Slide 19: Simulation with ARENA©

Some logic modules in the Basic Process Panel:

Create module: Create entities (generate arrivals of entities) and define characteristics of entity arrivals (time between arrivals, entity type, batch size, etc.)

Process module: Process entities through required operations. This module includes a resource, its queue and a processing time.

Dispose module: Represent entities leaving the system and dispose the entities. It also accumulates basic statistics for output reporting.

Slide 20: Simulation with ARENA

Some Data modules Entity data module: define detailed properties

associated with an entity type Resource data module: define characteristics of a

resource (capacity, capacity change pattern) Queue data module: define characteristics of a queue

associated with a resource (e.g. queuing discipline FIFO, LIFO, etc.)

Connection of logic modules: logic modules must be connected in right order through two types of connection: Connect: instant transfer of entities between modules (zero travel time), or Route: model non-zero travel time transfer of entities


Animation utilities: ARENA© provides utilities to animate entity flows and resources used in a simulation model.

Dynamic plots (graphical representation of output performance measures): select data object select information type select display mode

Set up running conditions of a simulation model through Run/Setup dialogue window


Generating (output) summary report on the results of a simulation: 3 types of information/statistics are collected and reported: Tally variables (e.g., flow/cycle-time, wait-in-queue

time, etc., time intervals) Discrete-Change Variables: time-persistent

statistics such as resource utilization, time-average number in queue, etc.

Counters: integral counts by part status (e.g. number of salvaged parts)


Output performance measures: Total production Average and maximum waiting time in queue Average and maximum flow time (cycle time) of

entities Average queue length (time-average number of

parts in queue) Maximum queue length Utilization of the machine (proportion of time busy)


Simulation with ARENA

Establishing modelingPurpose/objectives

ModelAnalyzeoutputs

System

data

Modeler

Decisions

Policies

Problem Model-based Problem solving

A basic simulation modeling approach:

Dividing system into sub-models (functions or module design to capture all the logical activities)

Developing a control/flow logic to define interactions and the configuration of the modules

Specify input distribution and data structures Selecting ARENA modules to model the activities of

the system at proper level of details. Connecting logic modules in right order to establish

the logic flow of the simulation model Selecting data module(s) to specify and implement

experimental conditions, data structure definitions, and output requirement


An example: Simulation of an electronic assembly and test system (EAT):

Two part types with different arrival rates Two part types share one Sealer station, the

processing time at this station depends on part type

Parts are transferred between stations with nonzero travel time

Parts are routed (after Sealer or Rework station) to different destinies based on inspection result (pass or fail according to certain probabilities)


Part A Prep


Part B Prep

Sealer

ReworkPart A

Part B

Expo(5)

Expo(30)Batch 4

9%

Part A TRIA(1,3,4)

Part B WEIB(2.5,5.3)

Scrapped

Salvaged and shipped

Shipped

91%

20%

80%

Example: an electronic assembly and testing system

Tria(1,4,8)

Tria(3,5,10)

Expo(45)

ARENA concepts

Attributes and assignment of attributes: attributes are properties that can be defined to characterize an entity type through a logic construct called Assign module (e.g. we can define an attribute called Sealer processing time for each part type, then use the value of this attribute as processing time when the part arrives in Sealer station)Decision making: for simple binary decision making (only two results possible), we can use a Decide module to model the needs of routing parts based on the result of a pass/fail inspection.


Decision making: route entities based on condition v.s. based on probability; two-way v.s. N-way decision makingModeling strategy for the EAT system: Use two Create modules to model the two streams

(one for each part type) of arriving parts Use Assign module to define Sealer processing time

as an attribute for each part type created Use Decide module to model the binary decision

making after Sealer and Rework operations (routing parts based on inspection result: pass or fail with specified probabilities)


Demonstration

Constructing simulation model (Model4-01)

Running the model

Viewing results and some discussion


Enhanced Resource Representation

Assumptions about resource

Fixed capacity (single resource with capacity of 1) Resource is 100% reliable (no failure/downtime)

Practical characteristics of resource (e.g. machines)

Capacity changes over time (e.g. number of operators per shift, scheduled breaks …)

Failures/breakdown of resources (e.g. machine failures that occur randomly)

Advanced resource representation:

Schedule: an ARENA’s built-in construct that allows modeler to vary the capacity of a resource over time, i.e. to model planned capacity changes.

A schedule is defined by a sequence of time-dependent capacity changes.

A resource schedule can be defined in either Resource or Schedule data module.

States: ARENA’s built-in constructs to represent the status of a resource in terms of capacity, particularly to model Failures and Downtimes.

Slide 33: Enhanced Resource Representation

ARENA defines a resource with 4 states: Idle: no entity has seized the resource, it is

available. Busy: some entity seizes the resource, it is not

available. Inactive: the resource is made unavailable for

allocation, e.g. scheduled break-time (capacity decreases to zero)

Failed: resource is unavailable and requires a repair time


Failures of a resource can also be modeled as a sequence of characterized random time intervals , e.g. we can define a capacity of 1 for the uptimes and 0 for repair or downtimes (both are random intervals)


Capacity

1

0

uptime

downtime Time

Random failures (where uptime and downtime are random variables) of a resource can be modeled using “Failure” construct, a data module used to model the random events that cause the resource become unavailable (e.g. machine breakdown) Count-based v.s. time-dependent failures (e.g.

tooling/bulb failures, machine breakdowns) Uptime v.s. downtime distributions: time between

machine breakdowns is usually a random variable following a probability distribution. We have to use either a theoretical or an empirical distribution to model the behavior of downtime (uptime).


Modify the example EAT system to incorporate resource schedules: Define a resource Schedule for Rework station to

model the planned change of capacity (1 for first shift and 2 for second shift)

Use a Failure data module to model the random failures of the resource at Sealer station (fail every expo(120) with a repair time expo(4) minutes)

Demonstration with Model 4-02

Data and information collection


Saving statistical data/information Needs for saving and post-processing data

generated from simulation runs. Mechanism: Statistics module a data module

(from Advanced Process panel) that defines statistical data to be collected and saved into files (for post-analysis).

Three types of data file (.dat files):

Time-persistent (or Discrete-Change) statistics Tally observation data Counters and frequency data


Practice with enhanced model (Model 4-02)

Results of running enhanced model (Summary report from)

Output analyzer: post-run analysis of simulation data. It analyze, display and draw statistical conclusions based on the simulation results.


Modeling Entity Type Dependent Flow

A small manufacturing system example with new characteristics: Different part types flow through the same system Entities flow based on their types (e.g. parts are routed

by different processing plans) Multiple resources with different capacities in the same

workstation Entities transfer between stations with nonzero transfer

time

Study objectives: Average flow time (cycle time) of each part type, resource utilization, time and number in queue.


Parts

arrival

Cell 1 Cell 2

Cell 4 Cell 3

Departure

A small manufacturing system

Characteristics of this system:

Three different part types. Each has a different sequence of station visitation (i.e. follow different process plans)

Cell 3 has two machines that are NOT identical (multiple resource with different capacity at the same station)

Different Part routings (process plans):

Part type 1: Cell 1 Cell 2 Cell 3 Cell 4

Part type 2: Cell 1 Cell 2 Cell 4 Cell 2 Cell 3

Part type 3: Cell 2 Cell 1 Cell 3

Entity transfers with a nonzero time between stations

Slide 42: Modeling Entity Type Dependent Flow

Performance measures

- Cycle times of three part types

- Utilization of resources

- Work-in-process (WIP) of parts


New modeling concept: Create different entity/part types using a Discrete distribution To create several types of entities according to

certain probabilities, ARENA assign each new entity to an attribute called “Part Index” (or part type) that follows a discrete distribution.

Example: to create 3 part types according to probabilities 0.31, 0.44, and 0.25, we randomly assign Part Index 1, 2, and 3 to each arriving entity according to a probability distribution:

DISC (0.31, 1, 0.75, 2, 1.0, 3) Enter values in pairs: cumulative probability and

part type


New modeling concept/construct: Sequence

Sequence is a data module that can route entities according to a predetermined sequence of station visitations. We use Sequence to model parts flow with different process plans.

Sequence consists of a list of destination stations and

optional assignment of attributes (e.g. processing time) at each station in the sequence.


New modeling concept: Stations and station transfers. To model the sequence dependent flow, we need to clearly define the boundary of a workstation (e.g. entry and leaving points of a station) and a mechanism to route entities between stations based on their sequencing requirements.

Station module (Advanced Transfer panel): model the physical location of a process and define an entry point for the station so that it can be recognized by different entity routings (i.e. sequences) in a simulation model.

Route module (Advanced Transfer panel): model entity routings based different sequencing requirements with nonzero transfer time.


How to implement Sequence dependent flow? Define Stations for all processes using Station

modules. Define sequences for all entity/part types using a

Sequence module. Associate each sequence (i.e. a process plan)

with each arriving entity through the assignment of an entity attribute, i.e. assigning each entity a sequence attribute (use an Assign module).

Route entities between stations using a Route module.


Each work cell will be modeled as a

Station-Process-Route module sequence.


Cell 1 Station(entry point)

Cell 1 ProcessCell 1 Route

(leaving point)

Example: logic modules for Cell 1 (also see Model5-01)

How to model a station that has multiple machines of the same type with different processing time? (e.g. Cell 3)

Use a Set of resource, not a single resource. Define a resource set “Cell 3 Machines” with two members (New machine and Old machine) for Cell 3. Default rule for resource selection is “cyclical”.

Assign each machine an index and define a variable Factor as a function of machine index.

Define processing time as variable using expressions, e.g. Process time = ProcessingTime * Factor(Index), where ProcessTime is defined through Sequence.

In Process module, select “Resource Set”


Practice and demonstration with an Example:

Small Manufacturing System (Model 6-02) Define logic modules: part arrivals, stations/cells,

part departures; Define data modules: use Sequence module to

control parts flow; use a Record module and a Set module to collect part cycle times.

Define experimental conditions; Run the simulation model and discuss results.

Show BLOCK diagram of Model



Arrival

Cell 1 Cell 2

Cell 4

Member 1 Cell 3 New

Member 2 Cell 3 Old

Depart

Cell 3

Resourceset: Cell 3 machinesA block diagram

model of SMS

a brief introduction to discrete-event simulation modeling and analysis ming zhou, phd., associate...

Documents

simulation systems

simulation model prescriptive

application of simulation

system input

definition of simulation

proposed system

system concept

realworld system