2.1 The Lexicon of Simulation: Core Terminology

To build, interpret, and communicate about models correctly, one must have a firm grasp of the field’s specialized terminology. The following concepts are the fundamental entities that constitute any simulation study, providing a shared language for analysts and stakeholders.

• System: A system is the specific object or process of interest that exists in the real world and is being studied. For example, a university’s entire course registration process could be the system.
• Object: An object is an entity that exists within the system being studied. Within the university registration system, an individual student, a specific course, or a professor would be considered objects.
• Base Model: This is a hypothetical explanation of the properties and behaviors of the objects within the system. It contains the core logic and rules that are assumed to be valid across the entire model. For the registration system, the base model would include rules like “a course has a maximum capacity” and “a student cannot register for two courses at the same time.”
• Experimental Frame: This defines the specific conditions under which a system is studied. It sets the boundaries for the simulation experiment, including the objectives and the specific aspects of the system that are of interest. For the registration system, an experimental frame might be: “Analyze the average student waiting time during the first week of the semester for first-year students.”

The Experimental Frame is a critical concept that connects the model to the real system. It is composed of two key sets of variables:

• Frame Input Variables: These match the inputs that are applied to the real system. In our example, this could be the number of students trying to register or the number of available courses.
• Frame Output Variables: These match the output values or performance metrics that are measured from the real system. This could be the average registration completion time or the percentage of students who successfully registered for all their desired courses.

Three other crucial terms define the quality and scope of a model:

• Lumped Model: An exact, often simplified, explanation of a system that is valid only under the specific conditions of a given Experimental Frame.
• Verification: The process of ensuring that the simulation program (the code) is a correct implementation of the conceptual model. It is about confirming the model’s internal consistency and accuracy.
• Validation: The process of comparing the simulation model’s results with the behavior of the real system to ensure the model is an accurate representation.

The distinction between verification and validation is so critical to establishing a model’s credibility that we will explore it in much greater depth later in this lecture. First, however, we must understand how to represent a system’s state at any given moment.

2.2 Describing the System: State Variables and Components

The system state variables are a collection of data that provides a complete “snapshot” of the system at any single moment in time. The dynamic behavior of the entire system is defined by how these variables change over the course of the simulation.

The behavior of these state variables differs fundamentally depending on the type of model:

• In a discrete-event model, state variables remain constant for periods of time and change their values only at specific, discrete moments known as “event times.”
• In a continuous model, state variables change constantly over time, with their behavior typically described by a set of differential equations.

The primary types of components that constitute the system state are:

• Entities & Attributes: An entity is an object that moves through the system, such as a customer in a bank or a part on an assembly line. An entity’s value can be dynamic or static. Attributes are the local values or properties associated with a specific entity. To illustrate using a hospital emergency room simulation: a patient is an Entity. That patient’s Attributes might include their arrival time, injury severity, and insurance status.
• Resources: A resource is an entity that provides a service to entities. It is often static and has a finite capacity. In our hospital ER, a doctor, a nurse, an X-ray machine, or a private room would all be Resources. An entity (the patient) requests service from a resource (the doctor).
• Lists: Lists are used to represent queues, or waiting lines, within the system. When an entity requests a resource that is busy, it often joins a list to wait its turn. The ER would have a List of patients waiting to see a doctor, and another List of patients waiting for an available X-ray machine. These lists can be managed using different rules, such as first-in, first-out (FIFO).
• Delay: A delay represents a duration of time during which an entity’s progress is paused for a specific reason. This is not necessarily time spent waiting in a queue for a resource. In our ER example, after a patient has seen a doctor and had a blood sample taken, they might experience a Delay while they wait for the lab results to come back before proceeding to the next step of their treatment.

Understanding these internal components is crucial, but to select the right simulation approach, we must first classify the overall system based on its fundamental characteristics.

2.3 A Taxonomy of Simulation Models

No single type of model is suitable for all problems. A critical first step in any simulation study is to classify the system being analyzed to select the most appropriate simulation paradigm. This classification is typically done across several key dichotomies.

Discrete vs. Continuous Systems This is one of the most fundamental classifications. A discrete system is one where the state variables change only at distinct, separate points in time. A bank is a classic example: the system state (number of customers in line, status of tellers) only changes when a customer arrives or a customer finishes their transaction. In contrast, a continuous system is one where the state variables change constantly over time. The level of water in a reservoir behind a dam, which changes smoothly as water flows in and out, is a prime example of a continuous system.

Stochastic vs. Deterministic Systems In our field, the distinction between stochastic and deterministic systems is fundamental. A stochastic system is one that incorporates elements of randomness, meaning its output is a random variable even for the same set of initial conditions. A simulation of a call center where customer arrival times are random is a classic stochastic model. In contrast, a deterministic system contains no randomness. For a given set of inputs, it will always produce the exact same output. A simulation of planetary orbits based on the laws of physics is a deterministic model.

It is critical to note that some introductory materials, including the guide these notes are based on, have been known to erroneously reverse these definitions. For all academic and professional purposes, you must adhere to the definitions provided here: stochastic systems involve randomness, and deterministic systems do not.

Static vs. Dynamic Simulation This distinction is based on the role of time in the model. A static simulation is one that does not represent the evolution of a system over time. These models represent a system at a particular point in time and are often used to solve problems involving uncertainty. The Monte Carlo method is a prime example of a static simulation. A dynamic simulation, on the other hand, explicitly represents the system’s behavior as it evolves over time. Most operational models, like simulations of supply chains or factories, are dynamic.

Now that we have established these foundational concepts and classifications, the next logical step is to explore the structured process for building and using these models effectively.