Lesson 1: Entities, Events, Resources, and Queues

1 Modelling context

A discrete-event simulation models a system in which entities move through a process, competing for resources and waiting in queues. The state of the system changes only at discrete points in time, called events. Before any code is written, the system must be described in terms of these concepts. This is the specification step of the modelling cycle, and it determines the structure of everything that follows.

The vocabulary is not arbitrary. It has been developed over decades of simulation practice to capture the common structure of systems as diverse as hospital emergency departments, manufacturing lines, customer-service call centres, airport security checkpoints, and computer networks. Once the entities, events, resources, and queues are identified, the simulation is largely determined.

Identify the four, and the model is half-built

The specification step of a discrete-event simulation is the identification of its entities, events, resources, and queues. If these are correctly identified, the simulation is mostly mechanical. If they are wrong, the simulation will produce results for the wrong system.

2 Learning objectives

By the end of this lesson you will be able to

Identify the entities in a discrete-event system.
Distinguish the events that change the state of the system.
Identify the resources and their capacities.
Specify the queues and their disciplines.
Describe a discrete-event model in the four-concept vocabulary.
Recognise the modelling assumptions implied by the vocabulary.

3 Prerequisite review

Stochastic process: A family of random variables indexed by time. Introduced in Unit 5.1 and Module 4.
Queue: A waiting line. In everyday language, the term usually refers to people waiting for a service; in discrete-event simulation, it is a more general concept covering any collection of entities waiting for a resource.
Service: The activity performed by a resource on an entity. The time taken by the service is usually a random variable.
Arrival: The event of an entity entering the system. Arrival times are usually generated from a stochastic process.

4 Mathematical formulation

Entities

An entity is an object that moves through the system. In a queueing model, entities are usually customers, jobs, patients, calls, or requests. In a manufacturing model, they are parts, assemblies, or products. In a transportation model, they might be vehicles or passengers.

Each entity has a state that describes its position in the process. In a simple single-server queue, the entity states are: arriving, waiting in queue, in service, and departed. In more complex systems, entities may have many states and may move through several stages.

Events

An event is a point in time at which the state of the system changes. Events in discrete-event simulation are not necessarily the "important" events of everyday language; they are simply the moments at which something changes. The most common events are:

Arrival events. A new entity enters the system.
Departure events. An entity leaves the system or leaves a resource.
Start-of-service events. A resource begins serving an entity.
End-of-service events. A resource finishes serving an entity.
Schedule or timer events. Internal events used to track elapsed time or trigger periodic actions.

The set of event types determines what the simulation must be prepared to do at each point in simulated time. If an event type is missing, the corresponding state change cannot occur.

Resources

A resource is a facility that serves entities. Each resource has a capacity: the number of entities it can serve simultaneously. A single server has capacity 1; a multi-server facility has capacity greater than 1; a resource with unlimited capacity corresponds to a service with no queue (for example, a self-service point where there is no competition).

Resources may have additional properties: availability (whether they are operational), scheduling (when they are staffed), and service-rate characteristics (whether the service time depends on the entity or the resource state).

Queues

A queue is a waiting line for a resource. When an entity arrives and the resource is busy, the entity joins the queue. The queue discipline determines which entity is selected when the resource becomes available. Common disciplines:

FIFO (first in, first out). The entity that has waited longest is served next. The most common discipline, and the default in most systems.
LIFO (last in, first out). The most recent arrival is served next. Used in some inventory systems and in computer-science contexts.
Priority. Entities are served according to a priority attribute. Used in triage systems, emergency response, and any setting with a formal prioritisation scheme.
Shortest-processing-time-first. The entity with the shortest estimated service time is served next. Optimal for minimising average waiting time, but rarely implementable in practice because service times are not known in advance.
Random. The next entity is selected at random. Rare in practice but useful for some theoretical comparisons.

The queue discipline is a modelling decision, and it can have a substantial effect on waiting-time distributions.

Figure 5.5. Entities, events, resources, and queues in a two-server queueing system. Entities arrive, wait in the queue, are served by one of the servers, and depart.

The specification template

A complete specification of a discrete-event model in this vocabulary has the following form:

Discrete-event model specification
Concept	Content
Entities	What are they, and what attributes do they carry?
Events	What events can occur, and what state changes do they cause?
Resources	What are the resources, and what is the capacity of each?
Queues	How many queues, and what is the discipline of each?
Arrival process	How are entities generated? (Rate, distribution, non-stationarity)
Service process	How is service time distributed? (Distribution, dependence on entity)
Routing	After service, where does the entity go? (Depart, join another queue, be reworked)
Termination	When does the simulation stop? (Time, event count, condition)

This template can be applied to any discrete-event system. Filling it in is the modelling step of the simulation project.

5 Worked example

Specifying an emergency department model

An emergency department wants to model patient flow to estimate waiting times under different staffing configurations. We specify the model using the four-concept vocabulary.

Step 1 — Identify the entities.

Entities are patients arriving at the emergency department. Each patient carries attributes:

Arrival time.
Triage category (1–5, with 1 being most urgent).
Service time at each stage (determined at the time of service).

Step 2 — Identify the events.

Arrival. A new patient enters the department.
Triage start. A triage nurse begins assessing the patient.
Triage end. Triage assessment is complete; the patient enters the treatment queue.
Treatment start. A physician begins treating the patient.
Treatment end. Treatment is complete; the patient departs or is admitted.
Departure. The patient leaves the department.

Step 3 — Identify the resources.

Triage nurses. Capacity 2. Serve patients in order of arrival.
Physicians. Capacity determined by scenario (3, 4, or 5).
Treatment beds. Capacity 10. A patient must have a bed while being treated.

Step 4 — Identify the queues.

Triage queue. FIFO. Patients wait for a triage nurse.
Treatment queue. Priority by triage category, then FIFO within category. Patients wait for a physician and bed.

Step 5 — Arrival process.

Patient arrivals follow a non-homogeneous Poisson process with rate varying by hour of day, estimated from historical records. The triage category is drawn from a categorical distribution estimated from the same records.

Step 6 — Service process.

Triage time: log-normal with parameters estimated from observation, differing by triage category.
Treatment time: log-normal with parameters estimated from observation, differing by triage category.

Step 7 — Routing.

After triage, the patient joins the treatment queue. After treatment, the patient departs with probability p or is admitted (leaves the simulation with a different disposition) with probability 1 − p. The admit/discharge decision is modelled as a Bernoulli draw with p estimated from records.

Step 8 — Termination.

The simulation runs for 30 simulated days. For each day, the first 8 hours are discarded as warm-up (see Lesson 3), and statistics are collected from the remaining 16 hours.

The specification is now complete. Every subsequent decision — how to represent the state, how to advance the clock, what to record — follows from this specification. The implementation is mechanical, given the specification.

6 Verification check

Checks to perform on your specification

Is every entity type accounted for? If the system handles more than one kind of entity, the specification should mention each and describe the differences.
Is every state-changing event listed? Walk through the lifecycle of an entity and identify each moment at which the system state changes. Each is an event.
Are all resources and their capacities specified? Including any resource that is shared between entity types or between process stages.
Is the queue discipline of each queue clear? "Priority" is ambiguous without specifying how ties are broken.
Is the arrival process fully specified? Rate, distribution, and whether it is stationary or time-varying.
Is the service process fully specified? Distribution, parameters, and dependence on entity attributes.
Is the routing specified for every outcome? What happens at the end of each service? Does the entity depart, re-enter a queue, or transfer to another resource?
Is the termination condition stated? Time, event count, or a rule.

7 Interpretation

The four-concept vocabulary is not merely a description; it is a modelling choice. Two analysts describing the same system may identify different entities, events, resources, and queues, and the resulting models will differ. The choice depends on the question the model is meant to answer.

Three interpretive points:

Entity choice matters. If the question is about patient waiting times, patients are the entities. If it is about physician utilisation, the entities might still be patients, but the resource focus changes.
Event definition determines state resolution. A model that treats "start of service" and "end of service" as separate events captures the service duration explicitly. A model that treats only "arrival" and "departure" as events treats the service as instantaneous from the resource's perspective.
Queue discipline is a modelling decision. FIFO, priority, and LIFO produce different waiting-time distributions. The choice should be justified in terms of the real system, not adopted by default.

The specification is part of the deliverable

A discrete-event model without a documented specification is not auditable. The four-concept specification should be part of the model documentation, alongside the implementation and the results.

8 Uncertainty and limitations

The specification captures a model of the system, not the system itself. Several sources of uncertainty are inherited by the specification.

Uncertainties in a discrete-event specification
Source	Effect
Arrival rate estimation	If the historical rate is not representative, the model's arrivals are wrong
Service time distribution	If the distribution is misspecified, waiting times may be biased
Entity simplification	Treating all entities as identical loses information that may matter
Routing assumptions	The probabilities of rework or transfer may not match reality
Resource capacity	Nominal capacity may differ from effective capacity due to breaks, breakdowns, etc.

Simplification is necessary; forgetting it is not

Every discrete-event model simplifies reality. The simplification is not a defect. What matters is that the simplifications are documented and their effects assessed. A model whose simplifications are hidden is a model whose conclusions cannot be trusted.

9 Common implementation errors

Watch for these

Confusing resources and entities. A resource serves entities; it is not served. If your specification has resources moving through the system, the identification is wrong.
Missing event types. If a state change can occur, there must be an event to trigger it. Missing events produce states that never change.
Over-simplifying the queue discipline. Defaulting to FIFO without justification may misrepresent the system, especially in healthcare and emergency settings where priority rules matter.
Ignoring resource unavailability. Real resources have breaks, shifts, and breakdowns. If these matter to the question, they must be modelled.
Treating non-homogeneous arrivals as homogeneous. If arrivals vary by hour of day, a constant-rate Poisson process will misrepresent both the peak and the off-peak behaviour.
Not documenting the specification. A model without a written specification is not reproducible, because the specification exists only in the analyst's head.
Confusing the specification with the implementation. The specification says what the model is; the implementation says how it is computed. Both should be documented, but they are different documents.

10 Independent modelling task

Your turn

Choose a system that can be modelled as a discrete-event process. A service facility, a manufacturing line, a transportation hub, or an emergency service are all suitable.
Identify the entities. State what they are and what attributes they carry.
Identify the events. List every state-changing event, in the order they occur over the lifecycle of an entity.
Identify the resources. For each, state the capacity.
Identify the queues. For each, state the discipline and justify it in terms of the real system.
Specify the arrival process, the service process, the routing, and the termination condition.
Write the specification in the tabular format used in this lesson.

This exercise forms part of Laboratory 10 and the specification component of Assignment 5.

11 Reflection prompt

Reflect before continuing

Two analysts specify the same emergency department. One identifies only arrival and departure as events; the other identifies triage and treatment events as well. How do the two specifications differ in what they can model?

Two or three sentences. Consider the role of events in representing the state of the system.

12 Lesson summary

Key takeaways

Discrete-event systems are described by entities, events, resources, and queues. Identifying these is the specification step of the modelling cycle.
Entities are the objects that move through the system. They carry attributes that determine their behaviour.
Events are the points in time at which the state of the system changes. Every state change corresponds to an event type.
Resources serve entities. Each has a capacity and may have availability and scheduling rules.
Queues are waiting lines. Their discipline is a modelling decision and affects waiting-time distributions.
The specification is part of the deliverable. A model without a specification is not auditable.

Coming next

Lesson 2 develops the event calendar and clock advancement mechanism that turns a specification into a working simulation.

§ Self-quiz, practice, and homework

Practice exercises

For a single-server bank teller system, identify the entities, events, resources, and queues.
For a two-stage manufacturing line (cutting, then assembly), identify the stages, the resources at each stage, and the queues between them.
Describe the difference between a model with a single server and a model with three parallel servers. What changes in the specification?
For a triage system with three priority categories, describe the queue discipline. How does it differ from FIFO?
Write a one-paragraph specification for a system of your choice, using the four-concept vocabulary.

Homework problems

Specification document. Choose a system of your choice and produce a complete specification using the tabular format from this lesson. Include entities, events, resources, queues, arrival process, service process, routing, and termination. Justify each choice. 500–700 words.
Comparison of specifications. For the same system, sketch two different specifications using different choices of entities (e.g. patients vs. treatments). Discuss how the two differ in what they model and what questions each can answer.
Queue discipline analysis. For a system with heterogeneous entities (e.g. patients with different urgency), compare the outcomes of FIFO and priority disciplines in a qualitative sense. What waiting-time distributions do you expect?

Mini project

Produce a specification document for the discrete-event model you will build in Laboratory 10. Include all eight components of the specification. Justify each modelling choice in one sentence. Submit the specification and a short narrative describing how the model's simplifications relate to the system. This is the basis for Assignment 5.