Conceptualizing a Model

Building simulation models requires critical thinking skills.  This article’s three sections is for those interested in improving their skills at Conceptualizing a Model (from a real system).

Section One – It’s a Queue-Server World

Simulation, as an analytical tool, is an outgrowth of Queuing Theory.  Queuing Theory provides analysis of a single queue-server combination, while Simulation provides analysis of systems composed of many queue-server combinations, interacting randomly over time.

For any system you model, you will need to document the process being modeled.  Every step in the process (where value is added) will have an associated queue.  Thus, all steps in our process will need to be reflected in the simulation model with a bunch of queue-servers.

For Example:  The coffee shop you like to visit seems to have the most inefficient process you have ever seen.  You’re buddies with the owners and decide to build a simulation model to help them streamline their processes.  You decide to model the customer’s process:  Customer walks in and waits in line (queue) before they give their order to the cashier (server).  Then they wait for their drink (queue) while it is being made by the barista (server).

Another Example:  We expand this thinking to any process, and we start seeing queue-servers everywhere.  A major airline wants to improve customer experience at their hub, and builds a model of their customers’ processes to identify how to further streamline them.

Customers arrive to rental car lot to drop off car and wait (queue) for receipt from rental car agent (server), then wait (Q) for rental car shuttle (server), wait (Q) to drop off bags (server), wait (Q) to go through security (server), and wait (Q) to get on the plane (server).  As modelers we need to see that it’s a Queue-Server World.

Section Two – Choosing Our Entity

Entity Defined An entity is the item/person/thing driving model behavior, as the entity moves thru various steps in the model.  Choosing entities is one of the most important decisions a modeler makes.  In most instances, it is also an easy decision.  For example:
Patients are the entity for a hospital emergency room
Customers are the entity for a restaurant
Products are the entity for a manufacturer
Packages are the entity for a warehouse
Paperwork are the entity for a back-office process
etc.
Below are concepts for modelers to digest as they choose entities.

Attributes – Attributes are variable-like used to store information. Attributes contain unique values for each individual entity, and the entities use the attribute values to make decisions as they flow through the model.  For example:

For a hospital emergency room, with patient as the entity, a useful attribute is acuity (urgency of patient’s needs).  Thus, a patient entity arriving with critical needs would have an acuity (attribute) value of High.  And this entity will use this attribute value to control its flow to avoid stopping at the registration desk, and go directly to a doctor.

# Entities In Not Equal # Entities Out – As entities flow through model, there are places when entity composition changes, and we need to pay attention to requirements for these changes.  For example:

Assembly:  An entity will go thru an assembly operation & is assembled with another entity.  2 or more entities enter and 1 exits.

Combining:  A quantity of entities goes through a boxing-like operation.  Many entities enter and 1 exits.

Splitting:  An entity goes through an unboxing-like operation.  1 entity enters and many exit.

Language Varies by Software – In this article we use the traditional simulation language of Entity & Attribute.  Other terms used by simulation software include:

Entity    =   FlowItem   =     Object    =       Item        =   Token   =   etc.

Attribute  =      Label     =   Properties   =   etc.

Section Three – Queue, Seize, Delay, Release, Transport (Repeat)

At each station it stops at in a model, an entity will repeat the same conceptual logic: Queue, Seize, Delay, Release, and Transport.  As we apply this conceptual logic, for every station in our model, we need to consider:

Queue:  – Is the queue capacity limited?  What happens when entity balks?
– Does the queue prioritize who exits first? i.e. doctor office where clients with appointments are prioritized.
– Do multiple queues support same server?  i.e. airport where an agent serves both first class and coach queues.
– Do entities leave queue if they have been waiting “too long”?  What triggers reneging?
– Do entities change queue as they wait?  i.e. Jockeying amongst grocery store checkout lines.

Seize:  Queues reflect an entity waiting until a station is available.  Seize is when an entity requires additional resources during processing.  For example, an operator is required for starting the process, a fixture is required for change-over, etc.  If no resources are needed, then there is no need to Seize.

Delay:  Entities delay for processing at each station.  Manual stations require the modeler to use select a statistical distribution to reflect randomness.  Automated stations require the modeler to explore modeling downtime frequency and repair time.  Time to change over a station to support a different product is another delay to consider.

Release:  After the Delay process, an entity needs to Release any resource(s) it Seized.

Transport:  Transport time can be modeled as a constant or a Uniform distribution.  If the model is utilized to analyze material handling systems, then modeler will need to reflect conveyors, forklifts, cranes, guided vehicles, etc.

Repeat:  The Q-Seize-Delay-Release-Transport process is repeated by the entity at each station it encounters, until the entity exits the model.

Note that different simulation software may use different language for the Q-Seize-Delay-Release-Transport process.  The process still applies.

Video for Guided Vehicle Network simulation – 2D Birds-eye View