SIMULATION LAB (EX-804) - Unit 1 Short Notes

UNIT 1: INTRODUCTION TO SIMULATION & FUNDAMENTAL CONCEPTS

1.1 Introduction to System Simulation

Definition & Purpose:

• Simulation is the process of creating a computer-based model of a real-world system and conducting experiments with this model to understand system behavior or evaluate strategies for system operation.

• Purpose: To analyze complex systems where analytical solutions are impossible, real-world experiments are too costly/dangerous, or to predict performance under varying conditions.

When to Use Simulation (vs. Other Methods):

Key System Components (Building Blocks):

• Entities: Active objects that move through the system (e.g., customers, parts, jobs). Have attributes (e.g., priority, type).

• Resources: Passive objects that provide service to entities (e.g., machines, servers, workers). Have capacity.

• Queues: Holding areas where entities wait for resources (First-In-First-Out is default).

• Variables & Statistics: Track system state (e.g., number in queue, total time in system).

Types of Systems:

[!TIP] Exam Focus: Be ready to classify a given system (e.g., a hospital emergency room is Stochastic, Dynamic, Discrete). Know the difference between discrete and continuous state changes.

1.2 The Simulation Study Process

A structured, iterative cycle for a credible study:

1. Problem Identification & System Definition: Clearly state the objective (e.g., "reduce average waiting time by 15%"). Define system boundaries and scope.

2. Conceptual Model Formulation: Create a logical, abstract representation of the system using flowcharts, diagrams, and assumptions. This is the "blueprint."

3. Data Collection & Input Analysis: Gather data on arrival rates, service times, etc. Fit probability distributions to this data (e.g., Exponential, Normal, Triangular).

4. Model Translation (Coding): Implement the conceptual model in simulation software (Arena, Simio, etc.).

5. Verification & Validation (V&V): CRITICAL STEP.

   • Verification: "Are we building the model right?" → Debugging the code. Does the software implementation match the conceptual model? (Use trace debugging, modular testing).

   • Validation: "Are we building the right model?" → Checking model accuracy. Does the model's behavior adequately represent the real-world system? (Use sensitivity analysis, compare to historical data, expert review).

6. Experiment Design & Output Analysis: Run the model under different scenarios. Analyze output data (use statistical methods, confidence intervals). Determine optimal solutions.

7. Documentation & Implementation: Document the entire process, results, and recommendations. Present findings and propose implementation.

[!TIP] Common Pitfall: Students often confuse Verification (code correctness) and Validation (realism). Remember: Verification = Verbatim (code matches design). Validation = Veracity (model matches reality).

1.3 Fundamentals of Discrete-Event Simulation (DES)

Core Mechanism:

DES models a system by simulating the sequence of events that change the system's state over time. Time advances from one event to the next.

Key Concepts:

1. Event: An instantaneous occurrence that changes the system state (e.g., "Customer Arrival," "Service Completion").

2. Event List (Future Event List - FEL): A priority queue (usually sorted by time) that holds scheduled future events.

3. Clock: Tracks simulation time. Advances in jumps from current event time to next earliest event time in FEL.

4. State Variables: Variables that describe the system at any time t (e.g., NumberInQueue, ServerStatus). State changes only at event times.

Basic DES Algorithm (Loop):

Initialize (t=0, schedule initial events)

While (t < SimulationEndTime) {

    Remove event with smallest time from FEL → CurrentEvent

    t = CurrentEvent.time

    Execute event logic (update state variables, schedule new events)

}

Event Logic: For a "Service Completion" event: Server.Status = Idle, Schedule next arrival if any.

Random Variables & Distributions:

• Inputs (interarrival times, service times) are modeled as random variates from fitted probability distributions.

• Common Distributions: Exponential (memoryless, Poisson arrivals), Uniform, Normal, Triangular (bounded, defined by min, mode, max), Empirical (from data).

• Generating Random Variates: Software uses a Random Number Generator (RNG) (e.g., linear congruential) to produce uniform U(0,1), then transforms it via the inverse transform method or other techniques for the target distribution.

Input Modeling:

• Goal: Identify the correct probabilistic model for each input random variable.

• Steps: 1) Collect data, 2) Choose candidate distribution, 3) Fit distribution (using software tools like Stat::Fit, or chi-square/K-S tests), 4) Validate the fit.

1.4 Simulation Software Landscape & Environment Setup

Common Software (Paradigms):

[!TIP] For EX-804 Lab: Identify the specific software used in your lab (e.g., Arena, Simio). This is a sure short question.

Environment Setup & Navigation:

• Workspace: Main drawing/canvas area.

• Modules/Toolbars: Palettes containing building blocks (e.g., Create, Process, Dispose, Resource).

• Properties Panel: Used to configure selected module (e.g., arrival rate, resource capacity, routing logic).

• Paradigm Understanding: Know if your software is flowchart-based (connect modules with arrows) or object-oriented (place objects that interact on a canvas).

1.5 Building a Basic Simulation Model (Hands-On Foundation)

Standard Process Flow (The "Hello World" of DES):

Source → Process (using Resource) → Sink (Often with a Queue automatically created before the resource).

Step-by-Step Construction:

1. Create Entities: Define an entity type (e.g., "Customer") and its attributes (e.g., Type, Priority).

2. Add Source Module: Configure to create entities.

   • Arrival Mode: Arrival Rate (e.g., Exponential(Mean=5) min) or Arrival Schedule.

3. Add Process Module: Defines a processing operation.

   • Assign a Resource (e.g., "Server1").

   • Set Processing Time (e.g., Triangular(Min=2, Mode=4, Max=6) min).

4. Configure Resource: In the resource's properties, set Capacity (number of identical units, e.g., 1 or 2).

5. Add Sink Module: Entities are disposed here after processing.

6. Connect Modules: Use connecting arrows (routing logic) to define flow: Source → Process → Sink.

7. Run Simulation: Set Run Length (e.g., 8 hours = 480 minutes). Warm-up period is often needed (see 1.6).

8. View Animation: Watch entities move, queues form, resources busy/idle.

[!TIP] Common Error: Forgetting to assign a resource to a Process module. Without a resource, the process is instantaneous (zero time).

1.6 Introduction to Output Analysis & Reporting

Types of Output Data:

• Time-Persistent (Steady-State): Measures system performance over time (e.g., average queue length, resource utilization). Calculated as: (Sum of instantaneous values over time) / (Total simulation time).

• Time-Dependent (Transient): Measures per-entity statistics (e.g., time-in-system, waiting time). Calculated as: (Sum of individual entity times) / (Number of entities).

Key Performance Indicators (KPIs):

Critical Analysis Concepts:

• Warm-up Period (Transient Removal): Initial period of simulation where system is "filling up" and statistics are not representative of steady-state. Must be discarded from output analysis. (Detected visually via time-series plots or methods like Welch's procedure).

• Statistical Reliability:

  • Replication (Independent Runs): For stochastic models, run the simulation multiple times (e.g., 30-50 replications) with different RNG seeds to get a distribution of outputs.

  • Confidence Interval (CI): Provides a range likely to contain the true mean. Narrower CI = more precise estimate.

$$ \bar{X} \pm t_{\alpha/2, n-1} \frac{S}{\sqrt{n}} $$

    Where $\bar{X}$ = sample mean, $S$ = sample std dev, $n$ = # replications, $t$ = t-value.

*   **Goal:** Ensure CI is **narrow enough** for decision-making (e.g., difference between scenarios is greater than half the CI width).

[!TIP] Exam Trap: Warm-up period is for STEADY-STATE analysis only. If your simulation run length is short or you're analyzing a transient system (e.g., a one-day special event), you may not discard initial data. Always state your assumption.