Excursion: Discrete events and simulation time
This is an excursion from the tutorial into the theory of discrete events and simulation time. If you are familiar with these concepts, you can proceed straight to the next page.
There are two types of simulators (well, there are more, but let's focus on what matters for us most):
Real-time simulation: Real-time is used to simulate events and the development of a system. Often combined with emulation, real-world hardware, etc.
Discrete Event-based simulation: Events of a system are ordered in a simulated time and processed in order. (Markov chain)
Let's take an example of a blinking lamp. Your simulation is supposed to turn on and off a lamp every 10 minutes, letting the lamp be on for 10 seconds. In real-time simulation, you would exactly follow this pattern with a time factor. If your time factor is 1, then your simulation will exactly mimic reality and turn on/off the lamp every 10 minutes. When the lamp is off in-between, nothing is happening and your simulation is simply idling/waiting. With a higher time factor, e.g. 600, the simulation will run 600 times faster and blink the lamp every second and the lamp will be on for only approx. 16 msec (very short, but you will be able to see it). The times when your simulation is idling are now shorter, but they are still there.
Real-time simulation is very important when building digital twins of real hardware, e.g. rocket engines or industrial robots. However, when a more abstract simulation is desired, where hardware delays are ignored and very large simulations are needed, the idling time starts becoming a problem, as it simply blocks your system and slows down the execution of the simulation.
Thus, discrete events were invented. Here, we only focus on the events: turn the lamp on or off. In-between nothing is happening and the time is simply skipped (no blocking, no idling, no waiting, just GONE). Here, we abstract from real-time completely and focus on the events - in our case, turning the lamp on and off. The time in between is simply skipped and not modeled in any way.
Event scheduling must adhere to some rules:
- Anybody can schedule events
- All events get ordered by their firing/execution time
- The kernel calls the events one by one and executes them
- One event is completely processed before another can start
- One event takes 0 simulated time to process completely
- No scheduling back in time!
The simulation terminates when there are no more events scheduled.
The list to keep all events ordered is called the Event Queue. Here is an illustration of an abstract simulation kernel and how it manages events (OMNeT++ is working just like this):
In our example, all we would see is that the lamp is constantly off, as the time between the events is simply skipped. However, if we exchange the lamp with something more meaningful like sending messages to other nodes, then we will see all of these messages being sent one after another, even if the events were scheduled for very different times.