Types of Models & Simulation Systems: Classification, Phases & Tools

TAKEAWAYS:

• Models are classified by type (physical/abstract) and behavior (static/dynamic), each suited to specific problems (e.g., a static map for route planning vs. a dynamic traffic simulator for congestion).
• Simulation systems are discrete-event (e.g., customer arrivals in Daraz) or continuous (e.g., temperature changes in a room), with trade-offs in granularity and computational cost.
• The simulation lifecycle (conceptual → data → model → verification → validation → output analysis) mirrors real projects like Ncell’s network load testing or NTC’s traffic signal optimization.
• Kendall’s notation (e.g., M/M/1) standardizes queuing systems, while traffic intensity (ρ) determines stability (ρ < 1 = stable).
• Verification checks if the model matches the code, while validation checks if the model matches reality—critical for tools like GPSS’s MARK/TABULATE blocks.
• GPSS (General Purpose Simulation System) uses blocks like GENERATE, ADVANCE, and QUEUE to model real systems, e.g., a coffee shop’s barista service time as a M/M/1 queue.

1. Classification of Models

Models are abstractions of real-world systems. They are classified based on type and behavior:

A. By Type: Physical vs. Abstract Models

B. By Behavior: Static vs. Dynamic Models

Worked Example: Static vs. Dynamic in Banking

• Static Model: A bank’s loan eligibility calculator (fixed interest rates, no time-dependent factors).
• Dynamic Model: A loan repayment simulator that adjusts interest rates based on inflation (time-dependent).

2. Classification of Simulation Systems

Simulation systems replicate real-world processes. They are categorized by time representation:

A. Discrete-Event Simulation (DES)

• Definition: Models a system where state changes occur at distinct events (e.g., arrivals, departures).
• Key Features:
  • Time advances only when an event occurs (e.g., a customer arrives at a bank).
  • Uses event lists to track future events.
• Example: Khalti’s transaction processing (events: payment initiation, verification, completion).
• Advantages:
  • Efficient for sparse events (e.g., customer arrivals in a queue).
  • Easy to implement in tools like GPSS, SimPy, or AnyLogic.
• Disadvantages:
  • Cannot model continuous processes (e.g., temperature changes).

Mermaid Diagram: Discrete-Event Simulation Flow

flowchart LR
    A["Start"] --> B["Event List: Empty"]
    B --> C["Event 1: Customer Arrives\nTime = 0"]
    C --> D["Update System State:\nQueue Length = 1"]
    D --> E["Schedule Next Event:\nServer Starts at Time = 2.5 min"]
    E --> F["Event 2: Server Finishes\nTime = 2.5 min"]
    F --> G["Update State:\nQueue Length = 0"]
    G --> H["End or Loop"]

B. Continuous Simulation

• Definition: Models systems that change continuously over time (e.g., fluid flow, temperature).
• Key Features:
  • Time advances in small increments (e.g., 1-second steps).
  • Used for differential equations (e.g., physics-based models).
• Example: NTC’s air pollution dispersion model (how exhaust spreads over time).
• Advantages:
  • Captures smooth transitions (e.g., melting ice, chemical reactions).
• Disadvantages:
  • Computationally expensive for large systems.

Comparison Table: DES vs. Continuous Simulation

3. Simulation Lifecycle: Phases of a Simulation Study

The process of building and using a simulation model follows 5 key phases:

flowchart TD
    A["1. Problem Formulation"] --> B["2. Model Conceptualization"]
    B --> C["3. Data Collection"]
    C --> D["4. Model Translation"]
    D --> E["5. Verification & Validation"]
    E --> F["6. Experimental Design"]
    F --> G["7. Output Analysis"]
    G --> H["8. Implementation"]

Phase Breakdown

1. Problem Formulation

   • Define the objective (e.g., "Reduce wait time at a bank").
   • Identify key variables (e.g., arrival rate, service time).

2. Model Conceptualization

   • Choose model type (static/dynamic, physical/abstract).
   • Example: A dynamic abstract model for Pathao’s driver dispatch system.

3. Data Collection

   • Gather real-world data (e.g., customer arrival times at a Daraz outlet).
   • Example: Record 100 customer service times at a coffee shop.

4. Model Translation

   • Convert the conceptual model into a computational form (e.g., GPSS code, Python script).

5. Verification & Validation (V&V)

   • Verification: Does the model match the code?
     • Example: Check if a GPSS QUEUE block correctly increments length.
   • Validation: Does the model match reality?
     • Example: Compare simulated vs. real Ncell call drop rates.

6. Experimental Design

   • Plan scenarios to test (e.g., "What if service time increases by 20%").

7. Output Analysis

   • Analyze results (e.g., average wait time = 5.2 minutes).

8. Implementation

   • Deploy the model (e.g., optimize NTC traffic signals based on simulation).

Worked Example: Coffee Shop Simulation (M/M/1 Queue) Scenario: A coffee shop with:

• Arrival rate (λ) = 1 customer every 3 minutes (λ = 20 customers/hour).
• Service rate (μ) = 1 customer every 2.5 minutes (μ = 24 customers/hour).
• Traffic intensity (ρ) = λ/μ = 20/24 = 0.833 (stable, since ρ < 1).

Steps:

1. Model: M/M/1 queue (Markovian arrivals, Markovian service, 1 server).
2. Performance Metrics:
   • Lq (avg. queue length) = ρ² / (1 − ρ) = (0.833)² / (1 − 0.833) ≈ 4.44 customers.
   • Wq (avg. wait time) = Lq / λ = 4.44 / 20 ≈ 0.222 hours (13.33 minutes).

Real-World Tie-In:

• Khalti’s transaction queue can be modeled similarly:
  • λ = 500 transactions/hour.
  • μ = 600 transactions/hour (ρ = 0.833).
  • Expected wait time = 0.222 hours ≈ 13.33 seconds per transaction.

4. Queuing Systems: Kendall’s Notation and Performance Metrics

Queuing systems are fundamental to service industries (banks, hospitals, e-commerce).

A. Kendall’s Notation

Standardizes queuing systems as A/B/c/K/N:

• A: Arrival process (M = Markovian, D = Deterministic, G = General).
• B: Service time distribution.
• c: Number of servers.
• K: Queue capacity (∞ = unlimited).
• N: Population size (∞ = unlimited).

Example:

• M/M/1/∞/∞: Single-server queue (e.g., Ncell customer service call center).
• M/D/3: 3 servers with deterministic service (e.g., Daraz’s order packing line).

B. Performance Metrics

Worked Example: Bank ATM Queue

• λ = 15 customers/hour.
• μ = 20 customers/hour (single ATM).
• ρ = 15/20 = 0.75.
• Lq = (0.75)² / (1 − 0.75) = 3 customers waiting.
• Wq = 3 / 15 = 0.2 hours (12 minutes).

Real-World Tie-In:

• eSewa’s transaction queue during Dashain:
  • λ = 1000 transactions/hour.
  • μ = 1200 transactions/hour (ρ = 0.833).
  • Expected wait time = 0.222 hours ≈ 13.33 seconds (matches earlier Khalti example).

5. Simulation Tools: GPSS Basics

GPSS (General Purpose Simulation System) is a block-based simulation language for DES.

Key Blocks

Worked Example: Coffee Shop in GPSS

START      GENERATE 3, 1       // Arrive every 3 min, 1 customer at a time
          QUEUE COFFEE        // Join coffee queue
          SEIZE BARISTA       // Take the barista
          ADVANCE 2.5         // Service time = 2.5 min
          RELEASE BARISTA     // Free the barista
          TERMINATE           // Leave the system
          TABULATE COFFEE     // Record queue stats
          MARK 10             // Mark time = 10 min
END

Output Interpretation:

• TABULATE COFFEE would show:
  • Average queue length (Lq).
  • Maximum queue length (e.g., 5 customers at peak).
• MARK 10 would log system state at t=10 minutes.

Real-World Tie-In:

• Pathao’s driver dispatch system could use GPSS to model:
  • GENERATE → New ride requests.
  • QUEUE → Riders waiting for a driver.
  • SEIZE → Driver assigned to ride.

6. Verification, Validation, and Accreditation (VV&A)

Critical for ensuring a model is useful and reliable.

Process Flow:

flowchart LR
    A["Model Built"] --> B["Verification:\nDoes code match design?"]
    B -->|"Yes"| C["Validation:\nDoes model match reality?"]
    C -->|"No"| D["Recalibrate Model"]
    C -->|"Yes"| E["Accreditation:\nApproved for use"]

Worked Example: NTC Traffic Signal Validation

1. Build a model of a busy intersection in Kathmandu.
2. Verify: Check if the simulation code correctly updates traffic light timings.
3. Validate: Compare simulated vs. real traffic jam durations.
4. Calibrate: Adjust signal timings until simulation matches real data.
5. Accredit: NTC approves the model for new signal plans.

In the Real World

1. eSewa’s Transaction Queue (M/M/c System)

   • Idea Used: Kendall’s notation (M/M/c) to model multiple servers (e.g., 5 payment processors).
   • How: During Dashain, eSewa scales servers to keep ρ < 1 (e.g., λ = 2000 transactions/hour, μ = 2500/hour per server → c = 5 servers needed).

2. Pathao’s Driver Dispatch (Discrete-Event Simulation)

   • Idea Used: GPSS-like event scheduling for ride requests.
   • How: When a rider requests a ride (GENERATE event), Pathao’s system assigns the nearest available driver (SEIZE/RELEASE blocks).

3. NTC’s Traffic Signal Optimization (Continuous + DES Hybrid)

   • Idea Used: Dynamic traffic assignment (combines continuous flow models with discrete vehicle arrivals).
   • How: Simulates 10,000 vehicles/hour through Kathmandu’s Thapathali intersection, adjusting signal timings to minimize Wq (wait time).

Exam Tip

1. Definitions Are Key:

   • Memorize Kendall’s notation (M/M/1, M/D/c) and performance metrics (Lq, W, ρ).
   • ρ = λ/μ is the most tested formula—always check if ρ < 1 for stability.

2. Compare Static vs. Dynamic Models:

   • Static: Use for one-time analysis (e.g., a map for route planning).
   • Dynamic: Use for time-dependent systems (e.g., stock prices, traffic).

3. GPSS Blocks:

   • GENERATE, QUEUE, SEIZE, ADVANCE, TERMINATE are high-yield for short-answer questions.
   • TABULATE and MARK are used for output analysis.

4. V&V Confusion:

   • "Building a model right" = Verification (code correctness).
   • "Building the right model" = Validation (matches reality).
   • Always link to real examples (e.g., "Like how NTC validates traffic models before implementation").

5. Worked Examples:

   • Always show calculations for ρ, Lq, Wq in queuing problems.
   • Tie to Nepal: Use eSewa, Khalti, or NTC for queuing examples; NEPSE or banks for dynamic models.

6. Diagrams in Exams:

   • Draw Kendall’s notation as a table.
   • Sketch a simple queueing system (arrivals → queue → server → departure).
   • For GPSS, show a flowchart with blocks like GENERATE → QUEUE → SEIZE.