Storage in GPSS and Manufacturing Shop Simulation

STEP 1 - EXTRACT: Given Data

• Part production rate: one part every $5$ minutes (deterministic inter-arrival time)
• Inspection time: $10 \pm 3$ minutes (uniform distribution, range $7$ to $13$ minutes)
• Rejection rate: $10%$ of parts rejected
• Simulation length: $500$ parts
• Modelling requirement: use the facility concept
• Theory requirement: define storage and describe storage-related blocks

All data required is present and readable.

STEP 2 - SOLVE

Part 1: Storage in GPSS

Definition

A storage in GPSS represents a resource that can be occupied by more than one transaction at the same time, up to a fixed capacity $N$. Whereas a facility is a single-server resource that only one transaction can hold at a time, a storage is a multi-server resource (a pool of $N$ identical servers). It is used to model things like a group of machines, a set of parking spaces, a bank of clerks, or a buffer of finite size.

Blocks Associated with Storage

If the amount k is omitted, it defaults to $1$.

Supporting blocks commonly used with storage

• QUEUE / DEPART to gather waiting-line statistics before ENTER and after LEAVE
• ADVANCE to represent the holding (service) time inside the storage

Facility vs Storage

Part 2: Manufacturing Shop Simulation (using a Facility)

System logic

Machine (1 part / 5 min) --> Queue --> Inspector (10±3 min) --> TRANSFER
                                                                    |
                                            90% ACCEPTED   <---+---> 10% REJECTED
                                            TERMINATE            TERMINATE

Since there is only one inspector, the inspector is modelled as a facility using SEIZE/RELEASE.

GPSS Program

*  ============================================
*  MANUFACTURING SHOP INSPECTION SIMULATION
*  Machine: 1 part every 5 minutes
*  Inspector: 10 +/- 3 minutes, rejects 10%
*  Run for 500 parts
*  ============================================

        SIMULATE

*  --- MACHINE GENERATES PARTS ---
        GENERATE    5,0         ; one part every 5 min (deterministic)

*  --- INSPECTOR (FACILITY) ---
        QUEUE       INSPQ       ; join inspection queue
        SEIZE       INSP        ; seize the single inspector
        DEPART      INSPQ       ; leave the queue
        ADVANCE     10,3        ; inspection time 10 +/- 3 (7..13)
        RELEASE     INSP        ; free the inspector

*  --- DECISION: 10% REJECTED, 90% ACCEPTED ---
        TRANSFER    .100,ACC,REJ  ; prob 0.100 -> REJ, else ACC

*  --- ACCEPTED PARTS ---
ACC     TERMINATE   1

*  --- REJECTED PARTS ---
REJ     TERMINATE   1

*  --- RUN CONTROL ---
        START       500
        END

Explanation of Each Block

Verification of numeric values

• ADVANCE range: $10 - 3 = 7$ minimum, $10 + 3 = 13$ maximum. Correct uniform interval $[7,13]$.
• TRANSFER probability operand .100 corresponds to $10%$ of parts routed to the reject branch, matching the stated $10%$ rejection.
• Since each TERMINATE carries a count of $1$, the run stops after $500$ parts (accepted + rejected) have passed through, matching "run for 500 parts."

Expected proportions after 500 parts

• Accepted $\approx 0.90 \times 500 = 450$ parts
• Rejected $\approx 0.10 \times 500 = 50$ parts

These are the expected counts (subject to random variation of the RNG); the actual GPSS report gives the exact simulated figures.

Two Main Properties of Random Numbers and Autocorrelation Test

Part 1: Two Main Properties

1. Uniformity: The random numbers $R_i$ are uniformly distributed on $[0,1]$. Each value is an independent draw from a continuous uniform distribution with pdf $$f(x)=\begin{cases}1 & 0\le x\le 1\ 0 & \text{otherwise}\end{cases}$$ giving $E(R)=\tfrac12$ and $Var(R)=\tfrac{1}{12}$.

2. Independence: Successive random numbers are statistically independent; the current value has no correlation with previous ones.

Part 2: Autocorrelation Test

Given Data

30 numbers, 1-indexed:

Test: 3rd, 7th, 11th, ... → starting index $i=3$, lag $m=4$. $Z_{0.025}=1.96$, $\alpha=0.05$.

Step 1: Determine M

Standard formula (Banks/Carson): $M$ = largest integer such that $i + (M+1)m \le N$, with $N=30$.

$$3 + (M+1)\cdot 4 \le 30 \Rightarrow (M+1)\cdot4 \le 27 \Rightarrow M+1 \le 6.75 \Rightarrow M+1=6 \Rightarrow M=5$$

So we use indices $3, 7, 11, 15, 19, 23$: that is $M+1 = 6$ values forming $M+1 = 6$ terms... let me apply the standard autocorrelation formula precisely.

The autocorrelation estimator: $$\hat\rho_{im}=\frac{1}{M+1}\left[\sum_{k=0}^{M}R_{i+km},R_{i+(k+1)m}\right]-0.25$$

This requires indices up to $i+(M+1)m$. With $i=3,m=4$: $3+(M+1)4\le30\Rightarrow M+1\le6.75\Rightarrow M=5$.

Indices needed: $3,7,11,15,19,23,27$ (from $k=0$ to $M+1=6$).

Values: $R_3=0.23,\ R_7=0.64,\ R_{11}=0.99,\ R_{15}=0.91,\ R_{19}=0.75,\ R_{23}=0.05,\ R_{27}=0.19$

Step 2: Products $R_{i+km}R_{i+(k+1)m}$, k = 0..M (=0..5)

$$\sum = 2.4112$$

Step 3: Compute $\hat\rho$

$$\hat\rho=\frac{1}{M+1}(2.4112)-0.25=\frac{2.4112}{6}-0.25=0.40187-0.25=0.15187$$

Step 4: Standard deviation

$$\sigma_{\hat\rho}=\frac{\sqrt{13M+7}}{12(M+1)}=\frac{\sqrt{13(5)+7}}{12(6)}=\frac{\sqrt{72}}{72}=\frac{8.4853}{72}=0.11785$$

Step 5: Test statistic

$$Z_0=\frac{\hat\rho}{\sigma_{\hat\rho}}=\frac{0.15187}{0.11785}=1.289$$

Step 6: Decision

Critical value $Z_{0.025}=1.96$.

Since $|Z_0| = 1.289 < 1.96$, we fail to reject the null hypothesis of independence.

Conclusion: There is no significant autocorrelation among the 3rd, 7th, 11th, ... numbers. They can be considered independent.

Common mistake: using $M = 6$ pairs and dividing by $M-1 = 5$, and then applying $\sigma = \frac{\sqrt{13M+7}}{12M}$ with that wrong $M$. The Banks-Carson convention gives $M = 5$, $\hat\rho = 0.1519$, $\sigma = 0.1179$ and $Z_0 \approx 1.29$. The conclusion (not autocorrelated) is the same, but the intermediate values are not.

Steps Involved in a Simulation Study

A simulation study is a systematic process of building, validating, and using a simulation model to analyze a real-world system. The following are the 12 key steps involved:

1. Problem Formulation

Clearly state and define the problem to be studied. This involves understanding what the system does, what questions need to be answered, and what the scope of the study is.

2. Setting of Objectives and Overall Project Plan

Define the goals of the simulation study and plan how to approach the problem. This includes deciding what performance measures to evaluate and setting timelines and resources.

3. Model Conceptualization

Establish a reasonable conceptual model of the system. This involves identifying the components, entities, events, and relationships that are important to represent the real system.

4. Data Collection

Collect all necessary data required to run the simulation, such as:

• Arrival rates and arrival processes
• Service rates and service time distributions
• System capacity and other parameters

5. Model Translation

Convert the conceptual model into a programming language or simulation software (e.g., SIMSCRIPT, GPSS, Arena). This produces the computerized representation of the model.

6. Verification

Check whether the program works properly as intended. The goal is to ensure that the computerized model correctly reflects the conceptual model. Techniques include:

• Having the code reviewed by someone other than its developer
• Checking output for reasonableness under various input settings

7. Validation

Check whether the simulation model accurately represents the real system. This ensures that the model behaves like the actual system under study, often by comparing simulation output with real-world data.

8. Experimental Design

Plan the simulation experiments by deciding:

• How many runs to perform
• How long each run should last
• What input variations (scenarios) to test

9. Production Runs and Analysis

Actually run the simulation, collect the output data, and analyze the results to draw conclusions about the system's behavior and performance.

10. Repetition

If the results are not satisfactory or more information is needed, repeat the experiments with modified parameters or a refined model.

11. Documentation and Reporting

Document the entire simulation study and report the findings. This includes the model description, assumptions made, results obtained, and conclusions drawn.

12. Implementation

If the simulation results show that a new system or policy is advantageous, implement the simulated system in the real world. The simulation study thus serves as a decision-support tool.

Summary Diagram

Problem Formulation
        |
Setting Objectives & Plan
        |
Model Conceptualization
        |
Data Collection
        |
Model Translation
        |
Verification --> (fix errors) --> loop back
        |
Validation --> (not valid) --> loop back
        |
Experimental Design
        |
Production Runs & Analysis
        |
Repetition (if needed)
        |
Documentation & Reporting
        |
Implementation

These steps ensure that the simulation study is carried out in a structured, reliable, and meaningful manner, producing results that can be trusted for real-world decision making.

Verification and Validation: Definition and Model Verification Process

Definitions

Verification

Verification is the process of checking whether the computerized/programmed representation of the conceptual model works properly and correctly. In other words, it ensures that the simulation program is a correct implementation of the conceptual model.

"Verify the model by checking if the program works properly."

Validation

Validation is the process of checking whether the simulation model accurately represents the real system it is intended to model. It ensures that the right model has been built.

"Check if the system accurately represents the real system."

Key Difference:

Process of Model Verification

The purpose of model verification is to satisfy that the conceptual model is reflected accurately in the computerized representation. The following common-sense steps are used in the verification process:

1. Independent Code Review

• Have the computerized representation checked by someone other than its developer.
• A fresh reviewer can catch logical errors or coding mistakes that the original developer may overlook.

2. Construct a Detailed Flow Diagram

• Make a flow diagram which includes each logically possible action a system can take when an event occurs.
• This ensures all branches, conditions, and event sequences are correctly programmed and no case is missed.

3. Examine Output for Reasonableness

• Closely examine the model output for reasonableness under a variety of settings of input parameters.
• For example, if arrival rate is increased, the queue length should also increase. If the output does not behave as expected, there is likely a programming error.

4. Self-Documenting Code

• Make the computerized representation as self-documenting as possible (use comments, meaningful variable names, etc.).
• This makes it easier to trace logic and identify errors during verification.

5. Animation Verification

• If the computerized representation is animated, verify that what is seen in the animation imitates the actual system.
• Visual inspection through animation helps detect errors in model logic that may not be obvious from numerical output alone.

Summary

Verification is essentially a debugging and correctness-checking phase in the simulation study (Step 6 of the 12-step simulation process). It must be completed successfully before proceeding to validation, because validating an incorrectly programmed model would produce meaningless results.

Calling Population, Arrival Process, and Service Process in a Queue

Calling Population

The calling population (denoted as K in Kendall Notation) refers to the source of customers (entities) that may arrive and demand service in a queuing system. It represents the total pool of potential customers who can join the queue.

• If the calling population is infinite (K = ∞), the arrival rate is not affected by the number of customers already in the system. This is the most common assumption.
• If the calling population is finite, the arrival rate decreases as more customers are already in the system (since fewer potential customers remain in the source pool).

In Kendall Notation (A/B/C/D/N/K), K denotes the calling population. If not specified, K = ∞ is assumed by default.

Arrival Process in a Queue

The arrival process describes how customers (entities) arrive into the queuing system over time.

Key characteristics include:

Important points:

• In most standard models, arrivals follow a Poisson process, meaning inter-arrival times are exponentially distributed (M).
• For batch arrivals, multiple customers can arrive at the same time instant, modeled using a point process where arrival times may coincide: t₀ ≤ t₁ ≤ t₂ ≤ ...
• The arrival rate is denoted λ (lambda).

Service Process in a Queue

The service process describes how customers are served once they reach the server.

Key characteristics include:

Important points:

• The system is stable only if the arrival rate is less than the service rate, i.e., λ < μ (utilization ρ = λ/μ < 1).
• The server utilization ρ represents the average proportion of time the server is occupied.
• The queuing discipline (D) (e.g., FIFO, LIFO) determines the order in which waiting customers are served.

Summary Relationship

$$\text{Queuing System} = \text{Calling Population} \rightarrow \text{Arrival Process} \rightarrow \text{Queue (Waiting Line)} \rightarrow \text{Service Process} \rightarrow \text{Departure}$$

A system is considered a queuing system when entities arrive, possibly wait in a line, and are served. The combination of all entities being served and waiting constitutes the queuing system.

Monte Carlo Simulation Method

Definition

Monte Carlo simulation is a computerized mathematical technique that generates random sample data based on some known distribution for numerical experiments. It is applied to risk quantitative analysis and decision making problems, and is used by professionals in finance, project management, energy, manufacturing, engineering, research & development, transportation, and other fields.

Key Characteristics

Monte Carlo method has three important characteristics:

1. The output must generate random samples
2. The input distribution must be known
3. The result must be known while performing an experiment

Flowchart for Monte Carlo Simulation

        Start
          |
          v
  Define the Problem
          |
          v
  Identify Input Variables
  (with known distributions)
          |
          v
  Generate Random Numbers
          |
          v
  Simulate the Experiment
  (compute output for each sample)
          |
          v
  Repeat N times
          |
          v
  Aggregate and Analyze Results
          |
          v
        Stop

Example: Estimating the Value of π

Problem: Use Monte Carlo simulation to estimate the value of π.

Approach:

• Consider a unit square of side 1 and a quarter circle of radius 1 inscribed in it.
• Area of quarter circle = π/4
• Area of square = 1

Steps:

1. Generate random points (x, y) where x and y are uniformly distributed between 0 and 1.
2. Check if the point falls inside the quarter circle using the condition:

$$x^2 + y^2 \leq 1$$

3. Count the number of points inside the circle (M) out of total points (N).
4. Estimate π as:

$$\pi \approx 4 \times \frac{M}{N}$$

Numerical Illustration:

• Total points N = 5
• Points inside circle M = 3

$$\pi \approx 4 \times \frac{3}{5} = 4 \times 0.6 = \mathbf{2.4}$$

Note: As N increases (more random samples), the estimate converges closer to the true value of π ≈ 3.14159.

Applications

• Financial risk analysis
• Project scheduling and management
• Engineering design optimization
• Manufacturing process simulation
• Transportation and logistics planning

Summary

Monte Carlo simulation is a powerful technique that uses repeated random sampling to obtain numerical results. The more iterations performed, the more accurate and reliable the result becomes. It is especially useful when analytical solutions are difficult or impossible to obtain.