1

Modelling Service Stations in

AnyLogic

Dr. Salman Sagheer Warsi

 Some Basic Definitions

▪ Entities: are things that move through the process. They go

through a sequence of operations before they emerge at the end.
Examples: patients in a hospital, cars in a car wash, packages in a
sorting facility, customers in a restaurant
▪ May not represent physical objects (like orders/requests)
▪ Center focus and the main things in a flow system
▪ Entity’s behavior: can Wait, can Balk, can Renege, can be Jockey

▪ Resources: dedicated to assisting entities flow through the

process; resources are used when entities might need other things
to help them to move forward.
Examples: Clerk working on file, worker working on an object
▪ Entity requests the resource, not the opposite
▪ We usually build a pool of a specific resource 3
 Some Basic Definitions

▪ The calling population: is the population that the entities passing

through the process are coming from. May be finite or infinite
depending on the definition of the arrival rate.

▪ Service time (Delay): the time an entity needs to wait before it

can move to the next step in the flow.
▪ Can be constant or random variable
▪ This time is associated only when the task/service being done

▪ Queue: is a line (which can be physical or implied) of entities

waiting in some order to be attended to or to proceed forward.
▪ FIFO
▪ LIFO
▪ Priority based 4
Modeling service stations in AnyLogic

▪ We could model an entire process at the highest level of

abstraction:
▪ with one queue and one or more servers.
▪ In queueing theory terminology, we call this combination a
service station, or service for short
▪ More than one service (that is, a combination of several
service stations) is known as a queueing network.

A generic service station (arrivals + queue + server(s) + departures)

5
 Approach-1
▪ A queue and a delay as the main building blocks with no explicit
server(s)/resource unit(s). Following PML Blocks are used:

▪ Source: represents the arrival process (e.g., arrivals that are a

Poisson process); the starting point in the process

▪ Queue: Space that lets entities amass if there’s no immediate

server available to start serving them. Can have capacity.

▪ Delay: Service time of each server. Capacity of the delay is like

the number of parallel servers in the service station.

▪ Sink: represents the moment that the entities leave the

process, and thus we stop following them
Approach 1: Delay represents the server/servers,
without explicit modeling of resources

▪ Resource units are not modelled explicitly

▪ Although some form of resource is helping to serve the entities
▪ We’re only concerned about time associated with the service
▪ Not time related to downtimes / calculation of resource utilization
Approach-2: Explicitly Modeling of Resources
(process in detail)
Approach-2: Explicitly Modeling of Resources
(process in detail)
▪ Source: same as in approach 1

▪ Seize: Internally is composed of a Queue block + mechanism

that requests and grabs available resources to start the service.
▪ Internal queue’s capacity to limit the number of entities inside.

▪ Delay: time each server needs to serve the entity

▪ Seize block (along with ResourcePool) handles which and how
many servers are used
▪ Capacity of Delay is set to infinity (maximum)
▪ Delay does not represent the number of servers.
▪ ResourcePool’s capacity (number of resource units)
represents the number of available servers
Approach-2: Explicitly Modeling of Resources
(process in detail)
▪ Release: Disassociates the resource unit and the entity
▪ Frees the resource unit
▪ Returns it back to the available resource pool

▪ Sink: used same as approach 1.

▪ ResourcePool: represents a pool of resource units (or servers)

▪ 1 or more units taken from here by entities in the Seize block
▪ Later returned in Release blocks
Approach-3: Explicitly Modeling of Resources
(Using Single AnyLogic Block)
Approach-3: Explicitly Modeling of Resources
(Using Single AnyLogic Block)
▪ All Blocks are used the same way Except Service.

▪ Service: A compact representation of an entire service station

▪ A combination of a Seize, Delay, and Release block
▪ As previously, Delay has a maximum capacity
▪ Number of servers is set by the capacity in the ResourcePool
General Comments on the 3 Approaches

▪ Concise approach is the simplest approach that does not

sacrifice model accuracy (like Approach #3)
▪ It all depends upon what we intend to model.
▪ For detailed recording of performance metrics, we’ll use
approach 2.
▪ Queueing Networks (?) can be easily modelled with Service
block
▪ So the choice of approach depends upon the situation
Use of resources in a process

The Seize block can only work

in conjunction with a
ResourcePool
Use of resources in a process
Use of resources in a process

▪ Concise approach is the simplest approach that does not

sacrifice model accuracy (like Approach #3)
▪ It all depends upon what we intend to model.
▪ For detailed recording of performance metrics, we’ll use
approach 2.
▪ Queueing Networks (?) can be easily modelled with Service
block
▪ So the choice of approach depends upon the situation
Building the flowchart process of one line and
one seller (without an explicit resource)

▪ Build a model of a flow system that uses a Queue and a Delay

1. On the File menu, click New.
2. Drag a Source block from the Process Modeling Library (PML)
onto the Main graphical editor, and then release the mouse button.

3. On the Properties view, set the Arrival rate to 2 per second

Building the flowchart process of one line and
one seller (without an explicit resource)

4. Drag a Queue block from the PML on to the graphical editor and
then release the mouse button so it is near the Source block.
5. On the Properties tab, select the Maximum capacity checkbox
to set its capacity to infinite.
 Building the flowchart process of one line and
one seller (without an explicit resource)
6. Drag a Delay block from the PML onto the graphical editor
▪ Keep the default delay time distribution: a triangular distribution
with a minimum of 0.5, maximum of 1.5 and mode of 1 second.
▪ The delay’s default capacity is 1: serve one customer at a time.
▪ This is the same as having one ticket seller in the booth
 Building the flowchart process of one line and
one seller (without an explicit resource)
7. Drag a Sink block from the PML onto the graphical editor

8. In the Projects panel (on the left), select the Simulation experiment
in your model.
9. In the Properties panel (default on the right) that displays, under
Model time, set the Stop time to 3600 (one hour, in seconds)
Building the flowchart process of one line and
one seller (without an explicit resource)

10. On the Properties panel, in the Randomness area, make sure the
random number generation (RNG) is set to Fixed seed
 Building the flowchart process of one line and
one seller (without an explicit resource)
11. Run the simulation experiment, setting the time speed to virtual
mode; wait until the one‐hour process (in simulation time) is complete
12. Click the source, queue, and delay blocks to open their inspection
windows

Check: “in” (the number of people who entered the block),

“out” (the number of people who exited the block)
Other attributes such as the block’s capacity and current contents
▪ We need more than 1 seller if we want to keep 𝑳𝒒 < 𝟏𝟎𝟎.
▪ In Queue block:
▪ 3593 people after one hour of sales
▪ Average Queue Length 1762
▪ 7173 people came to purchase a ticket
▪ only 3579 people received their ticket and departed
Building the flowchart process of one line and
one seller (without an explicit resource)
▪ In step 10, we made sure the random number generation (RNG)
had a fixed seed.
▪ Random numbers AnyLogic generated for the arrival and the delay
times would be the same for each run.
▪ Helpful when we need reproducible data,
▪ Change the Random number generation value to ensure each run
produces a different result.
▪ Run the simulation experiment wait until the one‐hour process (in
simulation time) is complete
13. On the Properties panel, in the Randomness area, set the
random number generation (RNG) to Random seed
14. Run the simulation experiment again, set the time speed to virtual
mode

Run 1

Run 2

Run 3
 Building the flowchart process of one line and
one seller (without an explicit resource)
# # Arrivals Queue Length at time = 1hr Average queue length
Run 1 7202 3599 1817.187
Run 2 7315 3703 1864.164
Run 3 7097 3478 1754.625

▪ Remember “Queue Length” is continuously varying over time

▪ Here, we focus on the “average queue length (𝑳𝒒 )” for analysis
▪ Value of 𝑳𝒒 is far from requirement of queue length of under 100
Cross Checking Some Simulation Results
 Building the flowchart process of one line and
one seller (without an explicit resource)
# # Arrivals Queue Length at time = 1hr Average queue length
Run 1 7202 3599 1817.187
Run 2 7315 3703 1864.164
Run 3 7097 3478 1754.625

Cross Checking Some Simulation Results

▪ How many tickets we sold? Here, 𝝀 > 𝝁
▪ The ticket seller is always busy with
1 1
𝑇ℎ𝑟𝑜𝑢𝑔ℎ𝑝𝑢𝑡 = = =1
𝑎𝑣𝑒 𝑝𝑟𝑜𝑐𝑒𝑠𝑠𝑖𝑛𝑔 𝑡𝑖𝑚𝑒 1
 Building the flowchart process of one line and
one seller (without an explicit resource)
# # Arrivals Queue Length at time = 1hr Average queue length
Run 1 7202 3599 1817.187
Run 2 7315 3703 1864.164
Run 3 7097 3478 1754.625

Cross Checking Some Simulation Results

𝑇𝑜𝑡𝑎𝑙 𝑎𝑟𝑟𝑖𝑣𝑎𝑙𝑠
= 𝐶𝑢𝑠𝑡𝑜𝑚𝑒𝑟𝑠 𝑖𝑛 𝑡ℎ𝑒 𝑞𝑢𝑒𝑢𝑒
+ 𝑡ℎ𝑜𝑠𝑒 𝑤ℎ𝑜 𝑎𝑟𝑒 𝑤𝑎𝑖𝑡𝑖𝑛𝑔 𝑓𝑜𝑟 𝑡𝑜 𝑔𝑒𝑡 𝑡ℎ𝑒𝑖𝑟 𝑡𝑖𝑐𝑘𝑒𝑡
+ 𝑡ℎ𝑜𝑠𝑒 𝑤ℎ𝑜 𝑙𝑒𝑓𝑡 𝑎𝑓𝑡𝑒𝑟 𝑟𝑒𝑐𝑒𝑖𝑣𝑖𝑛𝑔 𝑡ℎ𝑒𝑖𝑟
▪ For Run # 3:
𝑇𝑜𝑡𝑎𝑙 𝑎𝑟𝑟𝑖𝑣𝑎𝑙𝑠 𝟕𝟎𝟗𝟕
= 𝐶𝑢𝑠𝑡𝑜𝑚𝑒𝑟𝑠 𝑖𝑛 𝑡ℎ𝑒 𝑞𝑢𝑒𝑢𝑒 𝟑𝟒𝟕𝟖
+ 𝑡ℎ𝑜𝑠𝑒 𝑤ℎ𝑜 𝑎𝑟𝑒 𝑤𝑎𝑖𝑡𝑖𝑛𝑔 𝑓𝑜𝑟 𝑡𝑜 𝑔𝑒𝑡 𝑡ℎ𝑒𝑖𝑟 𝑡𝑖𝑐𝑘𝑒𝑡 𝟏
+ 𝑡ℎ𝑜𝑠𝑒 𝑤ℎ𝑜 𝑙𝑒𝑓𝑡 𝑎𝑓𝑡𝑒𝑟 𝑟𝑒𝑐𝑒𝑖𝑣𝑖𝑛𝑔 𝑡ℎ𝑒𝑖r(𝟑𝟔𝟏𝟖)
Building the flowchart process of one line and
one seller (without an explicit resource)
Increasing the Number of Sellers
▪ How to reduce the average queue length from 3600 to 100?
▪ There are only two solutions:
1. Reduce the service time (increasing the service rate) or
2. Increase the sales staff (resources).
▪ Service time is already 1 sec, focus on number of resources
▪ Increase the Delay’s Capacity to 2. (Two Servers)
2 Servers (Random Seed) Simulations

Run 1

Run 2

Run 3

𝑳𝒒 has reduced to
39.44. 26.3 & 24.12
Building the flowchart process of one line and
one seller (without an explicit resource)

▪ Here 𝜆 = 𝜇 (2 customers/second)
▪ Question # 1: why is our “average queue length > zero” ?
▪ The answer lies in variability.
▪ We know 𝜆 =2 customers/second
▪ After 100 seconds, expected number of arrivals is 200
▪ However, actual (realized) value might be 198, 200, 205, or 210
▪ The same is true for the service time
▪ Although 𝜇 =1, the actual value for each transaction might differ
 Building the flowchart process of one line and
one seller (without an explicit resource)

▪ Outputs from the Delay block’s triangular (0.5, 1.5, 1) distribution

▪ Many service times are above and below that one second average

▪ Variability in the arrivals and service times almost always has

a negative effect on the system’s throughput.
 Building the flowchart process of one line and
one seller (without an explicit resource)
▪ Question # 2: Why is there a difference between the average
queue length and the number of entities in the queue when
the simulation ends?
# Average queue length Queue length at the end (1 hr)
Run 1 39.44 34
Run 2 26.3 5
Run 3 24.12 24

▪ The answer depends on the time the delay overflows into the
queue.
▪ Build up effect in beginning has greater effect than at the end
▪ Another important factor is Utilization of a server.
▪ For 1 server, Utilization was straight forward (100 %)
▪ For 2 servers, we need to change our modelling approach.
Modifying the process flowchart (two explicit
resource units)
▪ Click Save As to save a copy with a different name
▪ To modify the model, do the following:
1. Delete the Queue block.
2. Drag a Seize block from the PML on to the graphical editor, and
then release the mouse button to place it before the Delay block.
3. Add a Seize block before and a Release block after the Delay.
4. Add a ResourcePool and set its capacity to 2 to represent two
sellers.
5. Click the Seize block and do the following:
a. Change Seize policy to units of the same pool.
b. Select the ResourcePool block in the resource pool drop‐down
menu.
c. Check the Maximum queue capacity checkbox to set the
embedded queue’s capacity to infinity
Modifying the process flowchart (two explicit
resource units)
5. Click the Delay block and check the Maximum queue capacity
checkbox to make sure the delay doesn’t limit the entities the
resources can serve in parallel
menu.
This setting makes the ResourcePool capacity the controlling
constraint and sets the number of parallel servers.
Modified model with explicit resources
 Modifying the process flowchart (two explicit
resource units)
▪ We’re ready to run the modified model and compare the outputs
▪ The original (implicit) model’s Queue block has an internal
statistics object that automatically records the queue’s length.
▪ The embedded queue inside the Seize block doesn’t have an
internal statistics object.
▪ We can’t monitor the average queue length without manually
adding it to the model.
▪ In the modified model, we can see the utilization of resource units.
▪ Utilization of two sellers were 99%, 97%, and 99%.
▪ A persistent high utilization of a resource is a sign the resource is
near its capacity
Run 1

Run 2

Run 3
 Modifying the process flowchart (two explicit
resource units)
▪ A persistent high utilization of a resource is a sign the resource is
near its capacity
▪ A good chance the lack of resources will slow or block the system
▪ Blocked or Slow points (bottlenecks) limit the flow of entities in a
process
▪ Sellers are working at max capacity (only having 1‐2% idle time)
▪ We can add 1 more resource.
▪ Utilization dropped below 70% and people were served with almost
no line!
Run 1

Run 2

Run 3
Modifying the process flowchart (two explicit
resource units)
Some Important Questions to Ask:
1. Can we predict the system’s behavior before we run the
simulation? Is there an analytical solution for our problem?
2. How long should the simulation run? Will the model show similar
behavior if it runs longer?
3. Besides the average queue length, which metrics should we use
to gauge system performance?
4. How do some metrics influence others? Can we use one metric to
estimate another?
5. How should we handle the randomness in the simulation outputs?
We saw each run’s output was different. How can we be confident
about our claims when the outputs are random? Were three runs
enough to claim the other runs will be similar?
6. Are there archetype queueing systems we can learn from?
M/M/1/∞/∞
M/M/2/∞/∞
Queue with Truncation (Capacity=9)
Queue with Truncation (Erlang Loss)
M/M/c/∞/d (finite‐source queues)
M/M/c/∞/d (finite‐source queues)
M/M/c/∞/d (finite‐source queues)