Appearance
FOR EDUCATORS
Sketch of a 3-Week Course on the free demo
Discrete-Event Simulation by Building
A hands-on introduction to discrete-event simulation through interactive model construction. Students build queueing models from scratch in their browsers, observe their behavior, and connect what they see to the analytical theory of queueing systems. Runnable entirely on Quisim's free demo.
Each session is built around a single arc: students start with an obviously-broken model, identify what's wrong by observing it run, and fix it incrementally. The fixes introduce new concepts (queueing, stochastic service, multiple servers, prioritization) in the order that the broken model demands them. Students learn DES the way it was historically developed — by encountering problems that simpler models can't solve.
Week 1: From blocking to queues to multi-server systems
Goal: Understand why queueing exists, what a queue does, and how multiple servers change system behavior.
The session is interactive — students build alongside the lecturer in their browsers.
The naive model (5 min)
Start with the simplest possible flow: an Arrive block connected directly to a Leave block. Add a NumberInput for interarrival time, connect it to the Arrive block via a RandomExponential. Activate animation mode and run it.
Entities arrive, immediately leave. No congestion, no waiting. The system is trivial.
Discussion: what's missing? Real systems have service. Customers don't just arrive and disappear — they're processed.
Add a server, observe blocking (10 min)
Insert a Perform block between Arrive and Leave. Add a NumberInput for service duration (D = a deterministic time).
Observe what happens: when an entity is being served, the next arriving entity has nowhere to go. The system blocks. The Arrive block can't release its entity because Perform is busy.
Discussion: this is a blocking system. Real-world examples: a doctor's office where patients are turned away if the doctor is busy. A phone line that gives a busy signal. Systems exist where this is acceptable, but most of the time it isn't.
Question to students: how would you fix this?
M/D/1 — the classic single-server queue (15 min)
Delete the connection from Arrive, then insert a Queue block between Arrive and Perform. Now the model is Arrive → Queue → Perform → Leave.
Observe: entities now wait when the server is busy. The system handles arrivals smoothly. With deterministic service time D and exponential interarrivals with rate 1/λ, this is M/D/1.
Add a Chart block and a Statistics block to the Queue LW (last waiting time) and the Leave LD (last dwell time) outputs. Students adjust 1/λ and D and observe how the waiting and sojourn time change.
Show the Monitor tab: students see the event list — the actual sequence of events the simulator processes. This is what discrete-event simulation is.
Discussion: when does the queue grow without bound? When λ × D > 1, i.e., when the server can't keep up with arrivals on average.
M/M/1 — adding stochastic service (10 min)
Replace the deterministic service duration with a RandomExponential connected to the Perform block's duration input. Now both interarrivals and service times are exponentially distributed.
Compare to M/D/1 with the same mean service time. Observe: the queue is longer, waiting times are higher. Variability matters. Even with the same average service rate, randomness in service time makes the system worse.
Discussion: this is a real surprise for students. The same average service rate produces different system behavior depending on whether service is deterministic or random. This is why M/D/1 and M/M/1 have different formulas.
M/M/k — multi-server systems (10 min)
Set the Perform block's capacity to k > 1 via a NumberInput. The Perform block now serves k entities in parallel.
Observe how doubling servers affects waiting time. It's not a linear improvement — going from k=1 to k=2 helps a lot; going from k=2 to k=3 helps less.
Open the Monitor tab during a run. With multiple servers, the event list becomes more interesting: simultaneous service completions, parallel processing, the actual mechanics of multi-server queueing become visible.
Discussion: this is the foundation of capacity planning. How many servers do you need? More than one is much better than one; the marginal benefit decreases.
End of week 1
Students have built M/D/1, M/M/1, and M/M/k from scratch. They've observed blocking, the role of queues, the effect of variability, and the diminishing returns of additional servers. All by building and running.
Take-home: explore the M/M/k model with different parameters. Find the smallest k for which the system is stable when λ × D = 0.9 (utilization 90%).
Week 2: Statistical thinking — replications and confidence intervals
Goal: Understand why a single simulation run isn't enough, and how to extract statistical confidence from multiple runs.
Reopen and recap (5 min)
Open the M/M/k example scenario. Run it once. Note the average sojourn time the model reports.
Run it again and observe that the result is different. Sometimes meaningfully different.
Discussion: which run is the "true" answer? Neither, or both. Stochastic simulations produce stochastic results. We need statistics.
Multiple replications (15 min)
Switch to a scenario with built-in replication support. Show the Erlang C scenario. This scenario runs the simulation R times and reports the mean sojourn time across replications, plus a 95% confidence interval.
Set R = 5. Observe the spread. Set R = 20. Observe the tightening of the CI. Set R = 100 (if feasible). Observe the CI tightening further.
Discussion: each replication gives one estimate of the true mean. Multiple replications give us a sample of estimates, which is approximately normally distributed (Central Limit Theorem). From the sample mean and standard deviation, we compute a 95% CI for the true mean.
The Erlang C connection (15 min)
The Erlang C scenario also computes the analytical Erlang C formula for the same parameters (using Jagerman's approximation method). Compare the simulation's CI to the analytical value.
Most of the time, the analytical value falls within the CI. Sometimes (about 5% of the time, if everything is correctly calibrated) it doesn't — that's what "95% confidence" means.
Discussion: simulation and analysis agree. The simulation isn't just a black box producing numbers; it's converging on the same answer the math gives, but it can be applied to systems where closed-form solutions don't exist.
This is the moment where students see why simulation matters. Erlang C works for M/M/k. But what about systems where service times aren't exponential? Where there are priorities? Where customers renege? For those, you need simulation.
Sample size, variance, and confidence (15 min)
Hands-on exploration: how does R affect the CI width?
Students work in their own browsers. Run the Erlang C scenario at R = 5, 10, 20, 50. Plot the CI width against R. Observe the CI width is proportional to 1/√R.
Discussion: the cost of high precision is many replications. Doubling precision requires 4× more runs. This is a fundamental limit of sampling-based methods, and it's why simulation studies need to be designed thoughtfully.
End of week 2
Students understand why one simulation run isn't enough, how to compute confidence intervals from multiple replications, the connection between simulation and analytical queueing theory, and the practical cost of precision.
Take-home: for an M/M/2 system at 80% utilization, how many replications are needed to get a 95% CI of half the mean's width?
Week 3: Beyond simple queues — priorities and triage
Goal: Understand how priorities change system behavior, and see a realistic application that breaks the simple queueing model.
Why priorities matter (10 min)
Open a discussion: not all customers are equal. Hospital triage prioritizes patients by severity. Phone systems prioritize emergency calls. Computer systems prioritize interrupt handlers.
In a simple FIFO queue, everyone waits in arrival order. With priorities, urgent cases jump ahead.
Question: what should happen to total system performance under priority scheduling? Better for urgent cases, presumably — but at what cost to others?
The Triage scenario (15 min)
Open the Triage scenario. The structure: 3 arrival streams (minor, urgent, critical), 3 queues, and a server that serves preferentially — critical first, then urgent, then minor.
Each arrival stream has its own interarrival time (NumberInput-controlled). Service capacity k and service time can be set. The scenario reports sojourn time per class plus an overall weighted average.
Run it with all three streams at equal arrival rates. Observe the per-class waiting times: critical patients are served quickly, minors wait longest.
Comparing to the No-Triage scenario (15 min)
Open the No-Triage scenario. Same arrival streams, same server capacity, but a single FIFO queue — everyone waits in arrival order.
Run with the same parameters as the Triage version. Compare results.
Discussion: what changed? Per-class waiting times: critical patients now wait much longer (no priority). Minor patients now wait less (no one jumping ahead). Overall mean sojourn time may be similar or slightly different.
This is the key insight: priority scheduling redistributes waiting time without necessarily reducing total waiting. It serves urgent cases at the explicit cost of non-urgent ones. Whether this trade-off is worth it depends on the cost of delay to each class.
Capacity and arrival mix (15 min)
Hands-on: students adjust the arrival rates and service capacity in the Triage scenario. Find the conditions where:
- Triage clearly wins (high stakes for urgent cases, low cost for minor delays)
- Triage doesn't help much (when system has plenty of capacity for everyone)
- Triage creates serious harm to non-urgent cases (when urgent stream saturates the server)
Discussion: triage is a policy choice, not a free improvement. It encodes judgments about whose time matters more. This is true of every priority-scheduling decision in real systems.
Closing reflection (10 min)
What we've covered:
- Discrete-event simulation as a method (event lists, state changes, time advancement)
- Single-server queues and the role of buffering
- The effect of variability on system performance
- Multi-server systems and capacity decisions
- Statistical thinking — replications and confidence intervals
- The connection between simulation and analytical queueing theory
- Priorities and the policy choices they encode
What we haven't covered (and would be in a longer course):
- Networks of queues
- More complex routing — load balancing, parallel processing, tandem queues
- Batching
- Resource sharing
Regarding analysis methods:
- Steady-state vs. transient analysis
- Variance reduction techniques
- Sensitivity analysis
- Simulation optimization
These are real topics that simulation handles well, and that distinguish DES from analytical queueing theory.
Take-home / final reflection: identify a system in your work or daily life that involves queueing with priorities. What classes of customer/job exist? What would the priority structure look like? What trade-offs would the priority policy create?
Notes for the lecturer
The 10s simulation window keeps runs fast even when the animation mode is on. So students can iterate quickly. With interarrival times in the range 50-200 ms and service durations similar, this gives 50-200 entities per run, which is enough for a first mean value. The Erlang-C scenario runs 100s over several runs to deliver meaningful statistics.
The whole module is designed to build understanding through observation. Students should be encouraged to make predictions before running simulations: "if I double k, what will happen to mean waiting time?" Then run and see. Wrong predictions are valuable; they're where learning happens.
Erlang C is mentioned as one analytical formula students can compare against. If time permits, the lecturer can show the formula explicitly and walk through its assumptions. The point is not to teach Erlang C as such, but to demonstrate that simulation and analysis converge — and why simulation is still necessary for systems where the analysis doesn't exist.
The Triage example in week 3 is deliberately chosen because it's emotionally familiar (everyone has been a hospital patient) and because it shows simulation's power to evaluate policies that have real consequences. Students who finish this module should understand that DES isn't just queue mathematics — it's a tool for thinking about systems that affect people.