Model Building: Ronald Sukwadi

Model Building
Ronald Sukwadi
Introduction
 Modeling is more than knowing how to use
a simulation software tool.
 Software cannot make decisions about
how the elements of a particular system
operate and how they should interact with
each other.
 This is a role of the modeler.
Ronald Sukwadi Simulasi Sistem 2

 Modeling is an art or craft as much as a
science.
 Knowing theory behind simulation and
understanding the statistical issues are the
science part.
 Knowing how to effectively and efficiently
represent a system using a simulation tool
is the artistic part of simulation.

Converting a Conceptual Model to
Simulation Model
 The conceptual model is the result of the
data-gathering effort and is a formulation
in one’s mind of how a particular system
operates.
 Building a simulation model requires that
this conceptual model be converted to a
simulation model.

 Making this translation requires two
important transition in one’s thinking.
 The modeler must be able to think of the
system in terms of the modeling paradigm
supported by the particular modeling software
that is being used.
 The different possible ways to model the
system should be evaluated to determine the
most efficient yet effective way to represent
the system.

Modeling Paradigm
 A simulation model is a computer
representation of how elements in a
particular system behave and interact.
 How a user defines a model using a
particular simulation product is based on
the modeling paradigm of the product.
 A modeling paradigm consists of the
constructs and associated language that
dictate how the modeler should think
about the system being modeled.

 Modeling paradigms differ among
simulation products – although different
are minor.
 Historically, simulation products required
models to be defined line by line,
specifying a list of instructions like a script
for processing entities.
 Most modern products have a process
orientation and support object-based
modeling.
 Some product view a process as an
activity sequence, while others view it
from the standpoint of an entity routing.
Model Definition
 A model is simplified representation of reality.

 The exact way in which an operation is performed
is not so important as the way in which the
operation impacts the rest of the system.
 An activity should be viewed in terms of its effect
on other system elements rather than in terms of
the detailed way in which it is performed.
 The power of a model is more a function of its
simplicity rather than its complexity.
 The relationship between model complexity and
model utility is described by the Laffer curve.

Relationship between model complexity and
model utility (also known as the Laffer curve)
Complexity
Optimum level
of model complexity
Utility
Structural Elements
 Model objects represent the structural element in
a system such as machines, people, work items,
and work areas.
 The object classification employed ProModel
includes:
 Entities  the items processed in the system.
 Locations  places where entities are processed or held.
 Resources  agents used in the processing of entities.
 Paths  the course of travel for entities and resources
in the system.

 Not all simulation products provide the
same set or classification of modeling
elements,
 These elements can be further subdivided
to provide greater differentiation.
 Location, for example, could be subdivided
into: workstations, buffers, queues, and
storage areas.
 These model elements or objects have
behavior associated with them and
attributes.

Entities
 Entities are the objects processed in the model
that represent the inputs and output of the
system.
 Entities have special characteristics: speed, size,
condition, etc.
 Entities follow one or more different routings in a
system.
 Entities have processes performed on them.
 Entities may arrive from outside the system or be
created within the system.
 Usually, entities exit the system after visiting a
defined sequence of locations.

 Simulation models often extensive use of entity
attributes
 for determining where the entity gets routed in the
system
 for gathering information during the course of the
simulation
 The statistics of interest that are generally
collected for entities include:
 time in the system (flow time)
 quantity processed (output)
 value-added time
 time spent waiting to be serviced
 the average number of entities in the system

Entities to Include
 When deciding what entities to include in a
model, it is best to look at every kind of
entity that has a bearing on the problem
being addressed.
 The rule is that if you can adequately
capture the dynamics of the system
without including the entity, don’t include
it.

Entity Aggregating
 Modeling each one of entity types
individually would be a painstaking task
that would yield little, if any, benefit.
 A better approach is to treat entity types
in the aggregate whatever possible.
 If statistics by entity type are not required
and differences in treatment can be
defined using attributes or probabilities, it
makes sense to aggregate entity types
into a single generic entity and perhaps cal
it part or customer.
Treating different entity types as a single type
Type A
Type B
Type X
Type C

Entity Resolution
 Each individual item or person in the
system need not always be represented by
a corresponding model entity.
 A group of items or people can be
represented by a single entity.
 Activity times or statistics that are a
function of the size of the group can be
handled using an attribute that keeps
track of the items represented by the
single entity.
Treating multiple entities as a single entity
9 entities 1 entity

High-Rate Entity Processing
 In some system, it is common to process
entities at a rate of hundreds per minute.
 In such situations, modeling each
individual entity can significantly slow
down the simulation.
 If individual entity tracking isn’t tracking,
it may be preferable to merely track entity
production at various stages of a process
using variables or attributes.

 Simulation languages having a tank or
accumulator construct can make this
easier.
 An alternative approach is to adjust the
resolution of the entity by making a
number of entities into a single entity.
 This approach also works for continuously
flowing substances such as liquids or
granules, which can often be converted,
for simulation, into discrete units of
measures such as gallons, pounds, or
barrels.
Locations
 Locations are places in the system that
entities visit for processing, waiting, or
decision making.
 Locations have a holding capacity, and
may have certain times that they are
available.
 They may also have special input and
output: input based on highest priority or
output based on first-in, first-out (FIFO).

 In simulation, we are interested in the
average contents of a location such as the
average number of customers in a queue
or the average number of parts in a
storage rack.
 We might also be interested in how much
time entities spend at a particular location
for processing.
 There are also location state statistics that
are of interest such as utilization,
downtime, or idle time.

Location to Include
 Deciding what to model as a route location
depends largely on what happens at the
location.
 If an entity merely passes through a
location en route to another without
spending any time, it probably isn’t
necessary to include the location.

 In considering what to define as a location, any
point in the flow of an entity where one or more
of the following actions take place may be a
candidate
 Place where an entity is detained for a specified period
of time while undergoing an activity (such as
fabrication, inspection, or cleaning).
 Place where an entity waits until some condition is
satisfied (like the availability of a resource or the
accumulation of multiple entities).
 Place or point where some action takes places or logic
gets executed, even though no time is required
(splitting or destroying an entity, sending a signal,
incrementing an attribute or variable).
 Place or point where a decision is made about further
routing (a branch in conveyor or path, an area in a store
where a customers decide to which checkout counter
they will go),

Location Resolution
 Depending on the level of resolution
needed for the model, a location may be
an entire factory or service facility at one
extreme, or individual positions on a desk
or workbench at the other.
 The combination of locations into a single
location is done differently depending on
whether the locations are parallel or serial
locations.

 When combining parallel locations having
identical processing times, the resulting
location should have a capacity equal to
the combined capacities of the individual
location; however, the activity time should
equal that of only one of locations.
 When combining serial locations, the
resultant location should have a capacity
equal to the sum of the individual
capacities and an activity time equal to the
sum of the activity times.

Example of combining three parallel stations into
a single station
Capacity = 1
Capacity = 1 Capacity = 1 Capacity = 1
Operation 10 Capacity = 1 Operation 30
Operation 20
1 min. each
Operation 10 Operation 20 Operation 30

1 min.
Example of combining three serial stations into
a single station
Capacity = 1 Capacity = 1 Capacity = 1 Capacity = 1 Capacity = 1
Station 1 Station 2 Station 3 Station 4 Station 5

1 min. 1 min. 1 min.
Station 1 Station 2-4 Station 5

3 min.
Resources
 Resources are the agent used to process
entities in the system.
 Resources may be either static or dynamic
depending whether they are stationary or
move about in the system.
 Dynamic resources behave much like
entities in that they both move about in
the system.
 Like entities, resources may be either
animate or inanimate.

 The primary difference between entities and
resources is that entities enter the system, have
a defined processing sequence, and in most
cases, finally leave the system.
 Resources often respond to requests for their
use, whereas entities are usually the objects
requiring the use of resources.
 In simulation, we are interested in :
 how resources are utilized
 how many resources are needed
 how entity processing is affected by resource availability
 response time for acquiring a resource

Resources to Include
 The decision as to whether a resource
should be included in a model depends
largely on what impact it has on the
behavior of the system.
 If the resource is dedicated to a particular
workstation, it is unnecessary to include in
the model.
 If the resource may not always be
available or is a shared resource, it should
be included.

Resource Travel Time
 One consideration when modeling the use
of resources is the travel time associated
with mobile resources.
 A modeler must ask whether a resources
is immediately accessible when available,
or if there is some travel time involved.
 The time for the resources to move to a
location may also be a function of the
distance.

Consumable Resources
 Depending on the purpose of the
simulation and degree of influence on
system behavior, it may be desirable to
model consumable resources.
 Consumable resources are used up during
the simulation and may include:
 Services such as electricity or compressed air
 Supplies such as staples or tooling

 Consumable resources are usually
modeled either as a function of time or as
a step function associated with some
event such as completion of an operation.
 This can be done by defining a variable or
attribute that changes value with time or
by event.

Transport Resources
 Transport resources are resources used to move
entities within the system.
 These resources are dynamic and often capable
of carrying multiple entities.
 Sometimes there are multiple pickup and drop-off
points to deal with.
 The transporter may even have a prescribed
route it follows.
 In advanced manufacturing system, the most
complex element to model is often transport or
material handling system such as conveyor
systems and automated guided vehicle system
(AGVS).

Paths
 Paths define the course of travel for entities and
resources.
 Paths may be isolated or they may be connected
to other paths to create a path network.
 Paths linked together to form path networks are
common in manufacturing and service system.
 In manufacturing systems : aisles, AGV tracks
 In service systems: hallways
 In transportation systems: roadways, tracks

Operational Elements
 Operational elements define the behavior of the
different physical elements in the system.
 These include routings, operations, arrivals,
entity and resource movement, task selection
rules, resources schedules, and downtimes and
repairs.
 Operational elements of a model can be defined
 using constructs that are specifically provided for
modeling
 requiring the special logic such as “if-then” statements
to achieve the special operating behavior

Routings
 Routing define the sequence of flow for
entities from location to location.
 When entities complete their activity at a
location, the routing defines where the
entity goes next and specifies the criterion
for selecting from among multiple possible
locations.

 A few typical rules for selecting the next
location in a routing decision:
 Probabilistic
 First available
 By turn
 Most available capacity
 Until full
 Random
 User condition

Recirculation
 Sometimes entities revisit or pass through
the same location multiple times.
 The best approach to modeling this
situation is to use an entity attribute to
keep track of the number of passes
through the location and determine the
operation or routing accordingly.

Unordered Routings
 Certain systems may not require a specific
sequence for visiting a set of locations but
allow activities to be performed in any
order as long as they all eventually get
performed.
 In unordered routing situations, it is
important to keep track which locations
have or haven’t been visited.
 Entity attributes are usually the most
practical way of tracking this information.

Entity Operations
 An entity operation define what happens to an
entity when it enters a location.
 For modeling purposes, the exact nature of the
operation is unimportant.
 What is essential is to know what happens in
terms of the time required, the resources used,
and any other logic that impacts system
performance.
 For operations requiring more than a time and
resource designation, detailed logic may need to
be defined using if-then statements, variable
assignments, or some other type of statement.
Consolidation of Entities
 Entities often undergo operations where they are
consolidated or become either physically or
logically connected with other entities.
 Examples of consolidation:
 Batching
 Stacking
 Entities are allowed to simply accumulate until a
specified quantity has been gathered, and they
are grouped together into a single unit.
 Entity consolidation may be temporary or
permanent.
 In ProModel:
 COMBINE command for permanent
 GROUP command for temporary

Consolidation of entities into a single entity
(a) Permanent consolidation
before after
(b) Temporary consolidation
before after

Attachment of Entities
 Entities can be attached to a specific entity
at a location.
 Attachment may be temporary or
permanent.
 In ProModel,
 LOAD command for temporary attachment
 JOIN command for permanent attachment
 LOAD/JOIN routings must be defined for entire
to be loaded or joined.

Attachment of one or more entities to another entity
(a) Permanent attachment
before after
(b) Temporary attachment

before after
Dividing Entities
 A single entity is converted into two or more new
entities.
 Entities are divided in one of two ways:
 the entity of split up into two or more new entities and
the original entity no longer exists.
 additional entities are created (cloned) from the original
entities, and the original entity continues to exists.
• In ProModel, entities are split using
• SPLIT statement
• CREATE statement

Multiple entities created from a single entity
(a)The entity splits into multiple entities
(the original entity is destroyed)
before after
(b) The entity creates one or more entities

(the original entity continues)
before after
Entity Arrivals
 Entity arrivals define the time, quantity,
frequency, and location of entities entering
the system.
 Entities may arrive in one or several ways:
 Periodic
 Scheduled
 Fluctuating
 Event triggered
 Entities can arrive individually or in
batches.

Periodic Arrivals
 Periodic arrivals occur more or less at the
same interval each time.
 They may occur in varying quantities, and
the interval is often defined as a random
variable.
 Periodic arrivals are often used to model
the output of an upstream process that
feeds into the system being simulated.
 Periodic arrival are defined in ProModel by
using the arrivals table.

Scheduled Arrivals
 Scheduled arrivals occur when entities
arrive at specified times with possibly
some defined variation (i.e., a percentage
will arrive early or late).
 Scheduled arrivals may occur in quantities
greater than one.
 Scheduled arrivals sometime occur at
intervals.
 Each arrival occurs independently of the
previous arrival.

Fluctuating Arrivals
 Entities are arrive at a rate that fluctuates
with time.
 In ProModel, fluctuating arrivals are
specified by defining an arrival cycle
pattern for a time period.

Event-Triggered Arrivals
 Entities are introduce to the system by
some internal trigger.
 In ProModel, entity arrival can be
triggered using an ORDER statement.

Entity and Resource Movement
 Entities move through the system from location
to location for processing.
 Resources move to different locations where they
are requested for use.
 Resources frequently move or escort entities in
the system.
 Movement can be defined in three basic ways:
 Ignore the movement
 Model the move using a simple move time (which may
also defined by speed and distance)
 Model the move using a path network that requires the
moving entity or resource to contend the traffic.

 A path network essentially imitates the network
of aisles or hallways found on plant floor and in
office facilities.
 A path network reduces the number of paths that
need to be defined if there are a lot of different
routings yet all movement shares common path
segments.
 The decision as to which method to use depends
on the level of detail needed for a valid model.
 The following rules may be useful:
 If the move time is negligible compared to activity
times, or if it makes sense to simply include it as a part
of the operation time, it may be ignored.
 If move times are significant but traffic congestion is
light, a simple move time should be defined.
 If move times are significant and traffic congestion is
heavy, a path network should be defined.

Accessing Locations and Resources
 Much of the activity in a simulation is
governed by how entities are able to
access locations and resources for
processing.
 Entities may be given priorities when
contending with other entities for a
particular location or resource.
 The location or resource might also be
given decision-making capability for
selecting from among multiple items
awaiting input.
Use of Priorities
 In ProModel, locations and resources may
be requested with a particular priority.
 Priorities range from 0 to 999 with higher
values having higher priority.
 If no priority is specified, it is assumed to
be 0.
 For simple prioritizing, you should use
priorities from 0 to 99.
 Priorities greater than 99 are for
preempting entities and downtimes
currently in control of a location or
resource.
Preemption
 Sometimes, it is desirable to have a
resource or location respond immediately
to a task, interrupting the current activity
it is doing.
 This ability to bump another activity or
entity that is using a location or resource
is referred to as preemption.
 Preemption is achieved by specifying a
preemptive priority (100 to 999) for
entering the location or acquiring the
resource.
Task Selection Rule
 Locations and resources are often
discriminating with respect to which
waiting entity or activity they next select
to service.
 Task selection rules determine which
entities waiting for a location or resource
is actually granted permission to use the
location or resource when it becomes
available.

 Task selecting plays a crucial role in
simulation-based scheduling.
 Rules ranges from simple priority rules
such as shortest processing time, critical
ratio, or earliest due date to combinatorial
rules and user-defined decision logic.
 User-defined decision logic provides the
most flexible means for defining task
selection.
 By default locations and resources in
ProModel respond to highest-priority
request that has been waiting the longest.

Resource Scheduling
 Resources frequently have scheduled times
during which they are unavailable including off-
shift periods, breaks, and preventive
maintenance.
 Some of issues that need to be addressed
include:
 Deciding what to do with a task that is only half
completed when the end of a shift occurs.
 Making sure that resource statistics are based only on
scheduled available time and not on the entire
simulation run.
 Deciding what to do with arrivals that occur at a location
that is off shift.

Going off Schedule in the Middle of a Task
 It is common when running a simulation with
work schedules to have a resource go off
schedule in the middle of a task.
 For longer tasks that may take hours, it usually
isn’t desirable to keep the resource until the task
is completed.
 There are at least three options:
 Don’t start the task in the first place.
 Interrupt the task and go off schedule.
 If the task is nearly complete, go ahead and finish the
task.

Basing Resource Statistics on
Scheduled Time
 It is desirable to gather statistics on the
resource such as utilization statistics,
based on the scheduled time available, not
on total simulation time.
 ProModel automatically excludes off-
scheduled time when calculating statistics.

Handling Activities during Off-Shift Times
 It is usually desirable to prevent arrivals from
occurrence during off-schedule times.
 To turn off arrivals during off-shift times, the
possible solutions include:
 to try synchronize the arrivals with the work schedule.
 to have the arrivals enter a preliminary location where
they test whether the facility is closed and, if so, exit
the system.
 In ProModel, if a location where entities are
scheduled to arrive in unavailable at the time of
an arrival, the arriving are simply discarded.

Downtimes and Repairs
 It is common for resources and locations
to unexpectedly go down or become
unavailable for one reason or another such
as a mechanical failure or a personal
interruption.
 Downtimes usually occur periodically as a
function of total elapsed time, time in use,
or number of times used.

Downtimes Based on Total Elapsed
Time
 Examples of a periodic downtime based on
elapsed clock time might be:
 a worker who takes a break every two hours.
 scheduled maintenance
 The calculation of the interval between
downtimes takes into account not only
busy time, but also idle time and
downtime.

 Sometimes it may be desirable to use elapsed
time to define random equipment failures that is
especially true if this is how historical data were
gathered on the downtime.
 When using historical data 、 it is important to
determine if the time between failure was based
on:
 the total elapsed time from one failure to the next.
 the time between the repair of one failure to the time of
the next failure (operational time between failures).
 the time that the machine was actually in operation
(operating time between failures).

Resource downtime occurring every 20 minutes
based on total elapsed time
Start Interrupt Interrupt
6 10 4 6 14
Idle Busy Idle Down Busy

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　
Time (minutes)

Downtimes Based on Time in Use
 Most equipment and machine failures occur only
when the resource is in use.
 A mechanical or tool failure, for example,
generally happens only when a machine is
running, not while a machine is idle.
 The interval between downtimes would be
defined relative to actual machine operation time.
 Any idle times and downtimes are not included in
determining when the next downtime occurs.
 Because downtimes usually occur randomly, the
time to failure is most accurately defined as a
probability distribution.

Resource downtime occurring every 20 minutes
based on operating time
Start Interrupt
12 8
Idle Busy Idle Busy

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　
Idle
Time (minutes)

Downtimes Based on the Number of Time
Used
 Downtimes occur based on the number of
times a location was used.

Downtimes Resolution
 Data are rarely available on equipment
downtime.
 Data are often recorded overall downtime and
seldom broken down into number of times down
and time between failures.
 Depending on nature of the downtime
information and degree of resolution required,
downtimes can be treated as follows:
 Ignore the downtime.
 Simply increase processing time to adjust for downtime.
 Use average values for mean time between failures
(MTBF) and mean time to repair (MTTR).
 Use statistical distributions for time between failures
and time to repair.

Ignoring Downtime
 Several situations where it might make
sense to ignore downtimes:
 No data are available on downtimes.
 The downtimes are extremely infrequent and
not likely affect model performance for the
period of the study.
 The occasional downtimes are very small
compared to activity times.

Increasing Processing Times
 A common way of treating downtime is to
simply reduce the productive capacity of
the machine by the downtime percentage.
 This spreads the downtime across each
machine cycle so that both the mean time
between failures and the mean time to
repair are very small and both are
constant.
 No consideration is given for the variability
in both time between failures and time to
repair.
MTBF/MTTR
 Two parts to any downtime should be
defined:
 Time between failure, defines the interval
between failure.
 Time to repair, defines the time required to
bring a resource back online.
 Downtimes are defined in terms of:
 mean time between failure (MTBF).
 mean time to repair (MTTR).
 Using average times, it fails to account
variability.

Using Statistical Distribution
 Time between failures and time to repair is
represented by statistical distributions that
reflect the variation that is characteristic
of these elements.
 Studies have shown that:
 the time until failure tends to follow a Weibull
distribution.
 repair times often follow a lognormal
distribution.

Elapsed Time or Usage Time?
 When determining the distribution for time to
failure, a distinction should be made between
 downtime events that can occur anytime whether the
resource is operating or idle
 downtime events that occur only when a resource is in
use
 Downtimes that can occur anytime should be
defined as a function of clock time.
 If the resource goes down only while in operation,
it should be defined as a function of time in use.

Handling Interrupted Entities
 When a resource goes down, there might be entities that
were in the middle of being processed that are now left
dangling (i.e., they have been preempted).
 Several alternatives may be chosen by modeler to decide
what to do with these entities:
 Resume processing the entity after downtime is over.
 Find another available resource to continue the process.
 Scrap the entity.
 Delay start of the downtime until the entity is processed.
 The last option is the easiest way to handle downtimes and
may be adequate in situations where either the processing
times or downtimes are relatively short.
 If the entity resumes processing later using either the same
or another resource, a decision must be made as to
whether only the remaining process time is used or if
additional time must be added.
 By default, ProModel suspends processing until the location
or resource returns to operation.

Use of Programming Logic
 Sometimes the desired model behavior
can’t be achieved using a “canned”
construct provided by the software.
 It is necessary to use programming logic
that tests probabilities, variables, and
attributes to make behavioral decisions.

Using Probabilities to Model
Probabilistic Behavior
 Sometimes operational elements
(routings, operations, or others) exhibit
random behavior.
 To model a routing that occurs randomly,
it is easy just to select a probability
routing rule and specify the probability
value.

 For operation that occur randomly at a
particular location, however, a probability
function must be used in connection with
if-then logic.

 At an inspection and rework station, for example,
suppose that a product is defective 10 percent of
the time and requires 3  1 minutes (uniformly
distributed) to correct the defect; then the code
for defining this behavior might be as follows:
if rand () <= .10

then wait U(3, 1) min
rand() is a function that return a random value

between 0 and 1.

 When a machine goes down, 30 percent of
the time it takes Triangular(0.2, 1.5, 3)
minutes to repair, and 70 percent of the
time it takes Triangular(3, 7.5, 15)
minutes, the logic for the downtime
definition might be:
if rand () <= .30

then wait T(0.2, 1.5, 3) min
else wait T(3, 7.5, 15) min

 Another example is a multidistribution
activity (called as a call center) that
handles three different types of calls that
it is designated as A, B, and C. The time to
handle calls is exponentially distributed,
but the mean time is different depending
on type of call.
Call Type Probability of Occurrence Service Time (minutes)

A 0.20 E(5)
B 0.50 E(8)
C 0.30 E(12)

The code might be
// set a real variable (rValue) to random number

real rValue = rand()
// test for call type
if rValue <= 0.20
then wait E(5) min
else if rValue <=0.70
then wait E(8) min
else wait E(12) min
The “//” is used to make a comment line

Using Attributes to Model Special
Decision Logic
 Sometimes an item that has passed
through the same location a second time
requires less time to be reworked than it
took for the initial operation.
 An attribute of the entity should be the
basis of the decision because it is needed
to test how many times that particular
entity has visited the location.

 If a normal operation takes five minutes
but a rework operation takes only two
minutes, the following code would be
entered in the operation logic for the
location:
// increment the value of Pass by one

INC Pass
if Pass = 1
then wait 5 min
else wait 2 min
Using Global Variables to Gather Statistics
 Global variables are placeholders for values that
may change during the simulation.
 They are accessible from any place in the model
by any object in the model.
 They exist during the entire simulation.
 Global variables are defined by the user for user-
defined purposes.
 For example, a variable may be defined to keep
track of the total number of entities in a certain
area of the system (work in process) that is
increased when the entity enters the area and
decreased when the entity leaves.
 Statistics of the global variables can be either the
simple or time-weighted average value.
 A time series report showing all of the changes in
the variable over time can also be reported.
Using Local Variable for Looping
 Local variable are variables that are declared
within the logic itself, either right before the point
of use or at the beginning of the logic block.
 A local variable exists only for the current object
executing the block of logic.
 A local variable can be thought of as a temporary
attribute of the object executing the logic.
 Local variables are useful primarily for executing
a logic loop.

 Suppose, for example, that you want to assign
the value of 4 to the first 10 elements of an array
called NumOfBins that was defined in the Array
module. To do this within operation logic (or in
any other logic), you would enter something like
the following, where Count is defined as a local
variable:
int Count = 1
while Count < 11 do
{
NumOfBins[Count] = 4
inc Count
}
The braces “{“ and “}“ are the ProModel notation for
starting and ending a block of logic (“begin” and “end”).

Miscellaneous Modeling Issues
 This section addresses special issues that
may be encountered in simulation.
 Modeling rare occurrence
 Large-scale modeling
 Cost modeling

Modeling Rare Occurrences
 Often there exist situations in the real world that
occur only rarely.
 In simulation analysis, we are generally
interested in the normal behavior of the system,
not extremely rare behavior.
 It is advisable to ignore rare situations and
exclude them from the simulation model.
 This approach not only reduces modeling time
but also simplifies the model and helps maintain
the focus of everyone involved in the model on
the key input variables.

 But some rare situations have a significant
impact on the operation of the system.
 If the focus of interest is to evaluate the
effects of the rare occurrence, then it
makes sense to include the rare
occurrence in the model.
 The easiest way to model a rare event is
to continuously run until the event occurs.

Large-Scale Modeling
 It may be desirable to model a large
system such as an entire factory or the
entire activity in an international airport.
 It is always a good idea to partition the
model into several submodels and tackle
the problem on a smaller scale first.
 Each submodels can be merged into a
larger composite model either as a single
monolithic model or a hierarchical model.

 Three of the most common ways for
integrating submodels are:
 Integrate all of the submodels just as they
have been built.
 Use only the recorded output from one or more
of the submodels.
 Represent the output of one or more of the
submodels as statistical distributions.

Cost Modeling
 It is desirable to include cost in a model to
determine the most cost-effective solution
to a design problem.
 Two approaches to modeling cost are:
 to include cost factors in the model itself and
dynamically update cost collection variables
during the simulation
 to run a cost analysis after the simulation,
applying cost factors to collected cost drivers
such as resource utilization or time spent in
storage.

 The first method is best when it is difficult
to summarize cost drivers.
 The preferred way to analyze cost is to do
a postsimulation analysis and to treat cost
modeling as a follow-on activity to system
modeling rather than as a concurrent
activity.

Simulation Procedure
 Step 1: Define objective, scope, and
requirements
 Step 2: Collect and analyze system data
 Step 3: Build the model
 Step 4: Validate the model
 Step 5: Conduct experiments
 Step 6: Present the results

Defining the Objective
 The objective of a simulation defines the purpose
or reason for conducting the simulation study.
 It should be realistic and achievable, given time
and resource constraints.
 Simulation objectives can be grouped into the
following categories:
 Performance analysis
 Capacity/constraint analysis
 Configuration comparisons
 Optimization
 Sensitivity analysis
 Visualization

 Naturally, a simulation project may have
multiple objectives and therefore fall
under two or more of the categories.
 Sometimes the objectives change or
expand as the project progress.
 Defining objectives for a simulation study
should take into account the ultimate
intended use of the model.

 A List of Sample Questions in Design Decisions
 What division and sequence of processing activities
provide the best flow?
 What is the best layout of offices, machines,
equipment, and other work areas for minimizing travel
time and congestion?
 How many operating personnel are needed to meet
required production or service levels?
 What level of automation is the most cost-effective?
 How many machines, tools, fixtures, or containers are
needed to meet throughput requirements?
 What is the least-cost method of material handling or
transportation that meets processing requirements?
 What are the appropriate number and location of
pickup and drop-off points in a material handling or
transportation system that minimizes waiting times?
 What are the optimum number and size of waiting
areas, storage areas, queues, and buffers?
 What is the effect of localizing rather than centralizing
material storage, resource pools, and so forth?
 What is the automation control logic provides the best
utilization of resources?
 What is the optimum unit load or batch size for
processing?
 Where are the bottlenecks in the system, and how can
they be eliminated?
 How many shifts are needed to meet a specific
production or service level?
 What is the best speed to operate conveyors and other
handling or transportation equipment to meet move
demands?
 A List of Sample Questions in Operational
Decisions
 What is the best way to route material, customers, or
calls through the system?
 What is the best way to allocate personnel for a
particular set of tasks?
 What is the best schedule for preventive maintenance?
 How much preventive maintenance should be
performed?
 What is the best priority rule for selecting jobs and
tasks?
 What is the best schedule for producing a mix of
products or customers?
 What is the best inventory replenishment policy?
 How much raw material and work-in-process inventory
should be maintained?
 What is the best production control method (kanban,
for example)?
 What is the optimum sequence for producing a
particular set of jobs or processing a given set of
customers?
Ronald  How many personnelSimulasi
Sukwadi should
Sistem be scheduled for a 104
particular shift?
 To be effective, an objective should be one that
 Has high potential impact (reduce throughput rate
costs, not reduce backtraveling)
 Is achievable (20 percent inventory reduction, not
zero-inventory)
 Is specific (reduce waiting time in a particular queue,
not eliminate waste)
 Is quantifiable (reduce flow time by 40 percent, not
reduce flow time)
 Is measurable (increase yields by 10 percent, not
improve morale by 10 percent)
 Identifies any relevant constraints (reduce turnarround
time by 20 percent without adding resources, not just
reduce turnarround time by 20 percent)

 Example of Well-Stated Objectives
 Find the lowest-cost solution to reduce patient
waiting time in an emergency room so that no
more than 10 percent of patients wait longer
than 15 minutes.
 Increase the throughput rate of an assembly
line by an average of 20 percent without
additional capital expenditure.

Defining the Scope of Work
 With a realistic, meaningful, and well-defined
objective established, a scope of work can be
defined for achieving the stated objective.
 The scope of work is important for guiding the
study as well as providing a specification of the
work to be done upon which all can agree.
 The scope is essentially a project specification
that helps set expectations by clarifying to other
exactly what the simulation will include and
exclude.

 An important part of the scope is a specification
of the models that will be built.
 For reengineering or process improvement, two-
phase modeling approach are recommended:
 Modeling “as-is” model
 Modeling “to-be” model
 To ensure that the budget and schedule are
realistic, a detailed specification should include:
 Model scope
 Level of detail
 Data-gathering responsibilities
 Experimentation
 Form of results
Determining Model Scope
 Model scope refers to what system elements
should be represented in the model.
 Determining the scope of a model should be
based on how much impact a particular activity
has on achieving the objectives of the simulation.
 One decision regarding model scope relates to
the model boundaries.
 The determination of what elements can be
eliminated should be based on their relevance to
the objectives of the study.

Deciding on Level of Detail
 Where model scope is concerned more with
model breath, the level of detail determines the
depth of a model.
 It defines the granularity or resolution of the
model.
 Determining the appropriate level of detail is an
important decision.
 Too much detail makes it difficult and time-
consuming to develop and debug the model; too
little detail may make the model unrealistic by
oversimplifying the process.
 The level of detail is determined largely by the
degree of accuracy required in the results.
Assigning Data-Gathering
Responsibilities
 In any simulation project, data gathering is
almost always the most difficult and time-
consuming task.
 Identifying data requirements and who will be
responsible for gathering the data is essential if
this activity is to success.
 If the modeler is responsible for gathering data, it
is important to have the full cooperation of those
who posses the data, including equipment
vendors, engineers, technicians, direct labor
personnel, and supervisors.

 It is also a good idea to get those
individuals involved who have a stake in
the results such as managers and possibly
even customers.
 Nearly all models are based partially on
assumptions, simply because complete
and accurate information is usually
lacking.
 The project team, in cooperation with
stakeholders in the system, will need to
agree on the assumptions to be made in
the model.
Planning the Experimentation
 The number and nature of the scenarios or
alternative configurations to be evaluated should
be planned from the outset to ensure that
adequate time is allotted.
 Often this decision itself is influenced by the time
constraints of the study.
 Where only slightly different scenarios are being
evaluated, a single model can be developed and
modified appropriately to run each scenarios.
 If alternative configurations are significantly
different, separate models may need to be built.

 For studies considering improvements of an
existing system, it is often helpful and effective to
model the current system as well as the proposed
system.
 The basic premise is that it cannot ready to
improve a system until how the current system
operates is understood.
 Once a model of the current system is built, it is
easier to visualize what changes need to be made
for the modified system.
 During the final presentation of the results, being
able to show both the as-is and to-be versions of
the system effectively demonstrates the
differences in performance.
Determining the Form of Results
 The form in which the result are to be presented
can affect the time and effort.
 The key to determining the kind and quantity of
information to present to the decision maker or
stakeholder is to ask what decision is being made
with the simulation and what the background is
of the person(s) who will be making decisions.
 Attention should be focused on providing
adequate information and effective visualization
to enable the right decision to be made.

 Another effective use of animation in
presenting the results is to run two or
more scenarios side by side, displaying a
scoreboard that shows how they compare
on one or two key performance measures.
 Most decision makers such as managers
need to have only a few key items of
information for making the final decision.
 Every effort should be made to help the
decision maker clearly understand the
options and their associated
consequences.
Defining Project Requirements
 With the scope of work defined, resource,
budget, and time requirements can be
determined for the project.
 The primary task is to develop a budget
and schedule for the project.
 The time to perform a simulation project
will vary depending on the size and
difficulty of the project.

 A simulation schedule should be based on
realistic projections of the time requirements,
keeping in mind that
 Data gathering and analysis can take over 50 percent of
the overall project time.
 Model building usually takes the least amount of time
(10 – 20 percent).
 Once a base model is built, several additional weeks
may be needed to conduct all of the desired
experiments, especially if the purpose of the project is
to make system comparisons.
 At least several days must be allowed to clean up the
models and develop the final presentation.
 Simulation projects follow the 90-10 rule, where first 90
percent takes 10 percent of time, and the last 10
percent takes the other 90 percent.

Reasons Why Simulation Projects Fail
 Unclear objectives
 Unskilled modelers
 Unavailable data
 Unmanaged expectations
 Unsupportive management
 Underestimated requirements
 Uninvolved process owner(s)

Data-Gathering Phase
 The result  a conceptual or mental model
of how the system is configured and how it
operates.
 Forms of the conceptual model: written
description, flow diagram, simple sketch.
 The conceptual model  the basis for the
simulation model that will be created
 Data collection  the most challenging
and time-consuming task

Guidelines for Data Gathering
 Identify triggering events
 Focus only on key impact factors
 Isolate actual activity times
 Look for common groupings
 Focus on essence rather than substance
 Separate input variables from response
variables

 The Steps to Gathering Data
 Step 1: Determine data requirements
 Step 2: Identify data sources
 Step 3: Collect the data
 Step 4: Make assumptions where necessary
 Step 5: Analyze the data
 Step 6: Document and approve the data

Determining Data Requirements
 Determine the data required for building
the model
 Be dictated primarily by the model scope
and level of detail
 System data can be categorized into:
 Structural data
 Operational data
 Numerical data

Structural Data
 All objects in the system to be modeled.
 Elements:
 entities (products, customers, etc.)
 resources (operators, machines, etc.)
 locations (waiting areas, workstations)
 Describe the layout or configuration of the system
as well as identify the items that are processed
 All relevant component that affect the behavior of
the system.

Operational Data
 How the system operates – when, where
and how events and activities take place.
 All logical or behavioral information about
the system such as routings, schedules,
downtime behavior, and resource
allocation.

Numerical Data
 Quantitative information about the system
 Examples:
 capacities
 arrival rates
 activity times
 time between failures

Use of a Questionnaire
 Help for focusing data gathering efforts on
the right information and ensuring
productive meetings with others
possessing model information.

 List of questions in system description questionnaire
 What types of entities are processed in the system?
 What is the routing sequence (each stopping or decision point)
for each entity type?
 Where, when, and in what quantities do entities enter the
system?
 What are the time and resource requirements for each
operation and move?
 In what quantities are entities processed and moved? (Define
for each location.)
 What triggers entity movement from location to location
(completion of the operation, accumulation of a batch, a signal
from a downstream location, etc.)?
 How do locations and resources determine which job to do
next (oldest waiting, highest priority, etc.)?
 How are alternative routing and operation decisions made
(percentage, condition, etc.)?
 How often do interruptions occur (setups, downtimes, etc.)
and what resources and time are required when they happen?
 What is the schedule of availability for location and resources
(define in terms of shifts, break times, scheduled maintenance,
intervals, etc.)?
Identifying Data Sources
 Information needed to build a model is
rare from a single source.
 It is the results of reviewing reports,
conducting personal interviews, making
personal observations, and making lots of
assumptions.
 The types of sources: simulating an
existing or new systems.

 Goods sources of data include
 Historical records
 System documentations
 Personnel observation
 Personnel interviews
 Comparison with similar systems
 Vendor claims
 Design estimates
 Research literature
 Factors in deciding to use a particular data
sources:
 reliability
 accessability

Collecting the Data
 Continue through the end of the
simulation project as objectives change
and information that was unavailable ay
the beginning of the project begins to
materialize.
 Sequence of data collection:
 Define the overall entity flow
 Develop a description of operation
 Define incidental details and firm up data
values
Defining the Entity Flow
 Define the basic entity flow through the
system.
 Establish a skeletal framework to which
additional data can be attached.
 Be defined by the entity movement
through the system.
 Be described by using an entity flow
diagram or by superimposing the entity
flow on an actual layout of the system.

 Entity flow diagram vs process flowchart
 Process flowchart  shows the logical sequence of
activities through which entities go and defines what
happens to entity, not where it happens.
 Entity flow diagram  a more of routing chart that
shows the physical movement of entities through the
system.
 Entity flow diagram
 should depict any branching that may occur such as
routings to alternative work centers or rework loops
 purpose is to document the overall flow of entities in the
system and to provide a visual aid for communicating
the entity flow to other.
 easy to understand and gets everyone thinking in the
same way about the system.
 can easily be expanded as additional information is
gathered
Entity flow diagram

Entity flow diagram for patient processing at a doctor
office

Developing a Description of Operation
 Develop a description of operation that explains how
entities are processed through the system.
 Forms of the description of operation:
 step-by-step, brief narrative form
 tabular form
 A description of operation should include:
 the time and resource requirements of the activity or operation
 where, when, and in what quantities entities get routes next
 the time and resource requirement for moving to the next
location
 The description of operation provides the details of the
entity flow diagram.
 The entity flow diagram, together with the description of
operation, provides a good data document that can be
expanded as the project progresses.
Defining Incidental Details and
Refining Data Values
 Once a basic model has been constructed
and tested, additional details of the
process such as downtimes, setups, and
work priorities can be added.
 This information is not essential to getting
running model, but is necessary for a
complete and accurate model.

Making Assumptions
 A simulation model can run with incorrect data, but it can’t
run with incomplete data.
 Complete, accurate, and up-to date information is rarely
obtainable, especially when modeling a new system.
 One way to assess the influence of an assumption on the
validity of a model  sensitivity analysis
 a range of values are tested for potential impacts on model
performance
 A simple approach to sensitivity analysis
 a “best” or most optimistic case
 a “worst” or most pessimistic case
 a “most likely” or best-guess case

Statistical Analysis of Numerical Data
 To be use in a simulation model, raw data
must be analyzed and interpreted so that
the system operation is correctly
represented in the model.
 Prior to developing a representation of the
data, the data should be analyzed to
ascertain their suitability for use in the
simulation model
 independence
 homogeneity
 stationarity
 A descriptive analysis
 Mean
 Median
 Mode
 Standard deviation
 Variance
 Coefficient of variation
 Skewness
 Kurtosis
 Range
 A descriptive analysis  key characteristics about
the data, but not how suitable for use in a
simulation model.
 It needs to specify a theoretical distribution to
sample data set requiring that must be
 independent
 identically distributed

Test of Independence
 Data are independent if the value of one
observation is not influenced by the value of
another observation.
 When the value of an observation is dependent
on the value of a previous observation, the data
is said to be correlated.
 Techniques are used to determine data
dependence or correlation
 Scatter plot
 Autocorrelation plot
 Runs test

Scatter Plot
 This is a plot of adjacent points represents
a pair of consecutive observations (Xi, Xi+1)
for i = 1, 2, ..., n-1.
 If the Xi’s are independent, the points will
be scattered randomly.
 If, however, the data are dependent on
each other, a trend line will appear.
 A scatter plot is a simple way to detect
strongly dependent behavior.

Autocorrelation Plot
 If observation in a sample are independent, they
are also uncorrelated.
 Correlated data are dependent on each other and
are said to be autocorrelated.
 A measure of the autocorrelation, rho (), can be
calculated using the equation
 xi  x   xi  j  x 
n j
 
i 1   n  j
2
where j is the lag or distance between data

points;  is the standard deviation of the
population (approximated by the standard
deviation of the sample); x is the sample mean.
 The calculation of autocorrelation assumes that
the data are taken from a stationary process, i.e.,
the data would appear to come from the same
distribution regardless of when the data were
sampled.
 In this case of time series, this implies that the
time origin may be shifted without affecting the
statistical characteristics of the series.
 Thus the variance for the whole sample can be
used to represent the variance of any subset.
 The autocorrelation values varies between 1 and
-1.
 If the autocorrelation is near either extreme, the
data are autocorrelated.
Runs Tests
 The runs test looks for runs in the data that
might indicate data correlation.
 A run in a series of observations is the occurrence
of an interrupted sequence of numbers showing
the same trend.
 Two types of runs tests:
 median test
 turning point test
 Too many or too few runs, the randomness of
series is rejected.

Tests for Identically Distributed Data
 When collecting sample data, often it is necessary
to determine whether the data in a single data
set come from the same population or whether
they represent multiple populations.
 In other instances, it is desirable to determine
whether two or more data sets can be treated as
having come from the same population or
whether they need to be kept as separate
populations.
 Ways to determine whether data come from the
same distribution  tests for homogeneity

 Examples of data sets that tend to be
nonhomogeneous:
 Activity times that are longer or shorter
depending on the type of entity to be
processed
 Interarrival times that fluctuate in length
depending on the time of day or day of the
week
 Time between failures and time to repair where
the failure may result from a number of
different causes.
 One way to test homogeneity data
 to inspect the distribution to see if it has more
than one mode

 The second case is to see whether two
sets of data come from the same
population or are identically distributed.
 Examples
 Interarrival times for different days
 Activity times for two different operators
 Time to failure on four machines
 To see whether two or more sets of data
have the same distribution
 to perform goodness-of-fits test for each set

Distribution Fitting
 Sample numerical data can be represented
in a simulation model in one of three
ways:
 the data can be used exactly the way they
were recorded
 an empirical distribution can be used that
characterized the data
 to select a theoretical distribution that best fits
the data

 Problems in using the data exactly as they
were recorded
 data set is not large enough to represent the
population
 the problem in running multiple replications for
a simulation experiment
 Problems in using an empirical distribution
 an insufficient sample size may create an
artificial bias or “choppiness” in the distribution
 empirical distributions are based on a limited
sample size that often fail to capture rare
extreme values

 Representing the data using a theoretical
distribution involves fitting a theoretical
distribution to the data.
 During the simulation, random variates
are generated from the probability
distribution to provide the simulated
random values.
 Fitting a theoretical distribution to sample
data smooth artificial irregularities in the
data set and ensures that extremes values
are included.

Frequency Distributions
 Regardless of whether an empirical or theoretical
distributions is used, it is a good idea to construct
a frequency distribution to get a summary view of
the data.
 Then a fitness test can be conducted to evaluate
whether a standard theoretical distribution fits
the data.
 Frequency distributions may be either discrete or
continuous.
 Frequency distributions can be graphically shown
usiong a histogram.

Theoretical Distributions
 Theoretical distributions can be defined by
a simple set of parameters usually
defining dispersion and density.
 Theoretical distributions are either
continuous or discrete.

Common Continuous Theoretical
Distributions
 Uniform distribution
 Exponential distribution
 Erlang distribution
 Gamma distribution
 Weibull distribution
 Normal distribution
 Lognormal
 Beta distribution
 Pearson 5 distribution
 Pearson 6 distribution
 Triangular distribution

Common Discrete Theoretical
Distributions
 Discrete uniform binomial
 Bernoulli
 Binomial
 Negative binomial
 Geometric
 Poisson

Fitting Theoretical Distribution to Data
 Fitting a theoretical distribution to data is an
attempt to identify the underlying distribution
from which the data were generated.
 Distribution fitting is largely a trial-and-error
process.
 The basic procedure
 one or more distributions are selected as candidates
 estimates of the parameters for each distribution must
be calculated
 goodness-of-fit are performed to ascertain how well
each distribution fits the data

 Choosing a distribution that appears to be a good
fit to the sample data requires a basic knowledge
of the types of distributions available and their
properties.
 Creating a histogram of the data can reveal
important characteristics about the distribution of
the data.
 Parameter estimates calculated using moment
equations or the maximum likelihood equation.
 A goodness-of-fit test measures the deviation of
the sample distribution from the inferred
theoretical distribution.
 Three common tests:
 Chi-square test
 Kolmogorov-Smirnov test
 Anderson-Darling test

Chi-Square Test
 Analyze the data and hypothesize an underlying
distribution
 Create a frequency distribution of the data with
equiprobable cells based on the hypothesized distribution
 Calculate the expected frequency for each cell
 Adjust cells if necessary so that all expected frequencies
are at least 5.
 Calculate the chi-square statistic
 Determine the number of degree of freedom (k – 1)
 Choose a desired level of significance ()
 Find the critical chi-square value from the chi-square table
 Reject the distribution if the chi-square statistic exceeds
the critical value

Model Building: Ronald Sukwadi

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Model Building: Ronald Sukwadi

Uploaded by

Copyright:

Available Formats

Model Building

Ronald Sukwadi Simulasi Sistem 2

Ronald Sukwadi Simulasi Sistem 3

Ronald Sukwadi Simulasi Sistem 4

Ronald Sukwadi Simulasi Sistem 5

Ronald Sukwadi Simulasi Sistem 6

 A model is simplified representation of reality.

Ronald Sukwadi Simulasi Sistem 8

Ronald Sukwadi Simulasi Sistem 10

Ronald Sukwadi Simulasi Sistem 11

Ronald Sukwadi Simulasi Sistem 12

Ronald Sukwadi Simulasi Sistem 13

Ronald Sukwadi Simulasi Sistem 14

Ronald Sukwadi Simulasi Sistem 16

Ronald Sukwadi Simulasi Sistem 18

Ronald Sukwadi Simulasi Sistem 19

Ronald Sukwadi Simulasi Sistem 21

Ronald Sukwadi Simulasi Sistem 22

Ronald Sukwadi Simulasi Sistem 23

Ronald Sukwadi Simulasi Sistem 24

Ronald Sukwadi Simulasi Sistem 25

Ronald Sukwadi Simulasi Sistem 26

Capacity = 1 Capacity = 1 Capacity = 1

Operation 10 Capacity = 1 Operation 30

Capacity = 1 Capacity = 3 Capacity = 1

Operation 10 Operation 20 Operation 30

Capacity = 1 Capacity = 1 Capacity = 1 Capacity = 1 Capacity = 1

Station 1 Station 2 Station 3 Station 4 Station 5

Capacity = 1 Capacity = 3 Capacity = 1

Station 1 Station 2-4 Station 5

Ronald Sukwadi Simulasi Sistem 29

Ronald Sukwadi Simulasi Sistem 30

Ronald Sukwadi Simulasi Sistem 31

Ronald Sukwadi Simulasi Sistem 32

Ronald Sukwadi Simulasi Sistem 33

Ronald Sukwadi Simulasi Sistem 34

Ronald Sukwadi Simulasi Sistem 35

Ronald Sukwadi Simulasi Sistem 36

Ronald Sukwadi Simulasi Sistem 37

Ronald Sukwadi Simulasi Sistem 38

Ronald Sukwadi Simulasi Sistem 39

Ronald Sukwadi Simulasi Sistem 40

Ronald Sukwadi Simulasi Sistem 41

Ronald Sukwadi Simulasi Sistem 43

(a) Permanent consolidation

(b) Temporary consolidation

Ronald Sukwadi Simulasi Sistem 44

Ronald Sukwadi Simulasi Sistem 45

(b) Temporary attachment

Ronald Sukwadi Simulasi Sistem 46

Ronald Sukwadi Simulasi Sistem 47

(b) The entity creates one or more entities

Ronald Sukwadi Simulasi Sistem 48

Ronald Sukwadi Simulasi Sistem 49

Ronald Sukwadi Simulasi Sistem 50

Ronald Sukwadi Simulasi Sistem 51

Ronald Sukwadi Simulasi Sistem 52

Ronald Sukwadi Simulasi Sistem 53

Ronald Sukwadi Simulasi Sistem 54

Ronald Sukwadi Simulasi Sistem 55

Ronald Sukwadi Simulasi Sistem 59

Ronald Sukwadi Simulasi Sistem 60