“Customers come by car –which they park at the parking lot- or on foot to the customer (see figure below). They shop for a certain average time, some of them visit the butcher, others the infodesk. Then they choose a pay desk, wait their turn, pay and leave the supermarket.”
Suppose we want to study how much time customers spent at the
Discrete event simulation is an ideal method for this.
We start by creating a model of the supermarket
The town generates car and customer events, it serves as a source, and also as a sink: outgoing car and customer events terminate there. The entrance lp is what we call in simulation language a multiplexer (mux), it brings together several channels into one. The floor lp is modelled as a so-called delay (namely the shopping time) and it also distributes customers to the butcher and info queue. The butcher and info-desk are what we call queues: events come in, are queued and processed one by one (according to the first-in first-out priciple). The pay-desks are also queues, but are more specific: they can be turned off, the cashier leaves the pay-desk when the number of waiting customers is low. This information is send to the desk-select process, where the customers are distributed to queues of the pay-desks. This is what we call a demultiplexer (demux): one channel is broken down in multiple channels. Also the exit lp is a demultiplexer: customers with a car are sent to the parking lot, customers on foot leave the supermarket immediately.
So, what is discrete event simulation? It is the processing of the events by the logical processes and the travelling of the events along the channels. At a certain time, there will be many events spread out in the model, each with a certain timestamp, indicating at what time it arrives in the next lp and will be processed there according to the lp’s behaviour. This is what we call event-driven simulation: the systems dynamics are triggered by events.
The modeler has to choose a certain level of detail or level of abstraction. We can go more into detail, by decomposing the floor lp into detailed processes. Or we can go less into detail by leaving out the parking process and/or the butcher and info queue. This depends on what dynamics you want to study and what is important in that study.
simulation is triggered by events: no
event, no change. That’s why we have
to add a feedback trigger channel to the town lp (see figure). As
the town serves as a source, so it generates events. However, to do
it should receive an event! This chicken & egg problem is solved
a feedback channel: a trigger event comes in along the feedback
the lp generates a car event, but also sends back the trigger event to
the feedback channel to indicate the next time an event will be
In the supermarket model, there are 4 types of events: trigger, car, customer and pay-desk info.
Sources, sinks, multiplexers, demultiplexers, queues are basic lp’s, they are found in many models (see figure).
(1) The initial events.
The simulation starts with introducing initial events in the system, otherwise nothing will happen. In our model we can start the simulation with one trigger event in the feedback channel of the town lp.
(2) Event information.
All events have a timestamp, the time at which they arrive in an lp and an outputchannel, the channel at which they leave the lp.
Besides this, each event may contain specific information, which depends on the event type. The customer event should have a boolean indicating whether he is by car or on foot. This information will be used in the exit demux to send the event respectively to the parking or the town lp. The pay-desk info event contains whether the pay-desk is open or closed (boolean).
The trigger and car event contain no specific information.
(3) The logical processes.
Next, we have to implement the logical processes. Its configuration are the parameters of a specific lp instance. For example, the entrance lp is a multiplexer with 2 input channels, thus the number of input channels of a mux is a configuration parameter. The state of an lp is all dynamic its information. For example, for a queue the state is the number of queued events. The behaviour of an lp determines how an incoming event is processed.
Let’s implement the supermarket lp’s:
Queue (butcher, info)