|
|
The simulator uses two simulation concepts to simulate the world and the vehicles: **tick-based (continuous) simulation** and **(discrete-) event-simulation**.
|
|
|
|
|
|
- [Wikipedia on Continuous Simulation](https://en.wikipedia.org/wiki/Continuous_simulation)
|
|
|
- [Wikipedia on Discrete-Event Simulation](https://en.wikipedia.org/wiki/Discrete-event_simulation)
|
|
|
|
|
|
## Tick-based (continuous) simulation
|
|
|
|
|
|
This simulation method tries to compute *continuous processes* (such as vehicle physics) by performing *temporal discretization*.
|
|
|
The processes are approximated at discrete *time-steps* with methods such as the *Euler Method* for the physics.
|
|
|
|
|
|
TODO visual example
|
|
|
|
|
|
This method is implemented by
|
|
|
|
|
|
TODO "implemented by..." + see below
|
|
|
|
|
|
## Discrete-Event-Simulation
|
|
|
|
|
|
The discrete-event approach simulates behavior by looking at *events*.
|
|
|
It always takes the *next event in time* and computes it.
|
|
|
Events can then trigger new events that are queued (and ordered in time) in the simulator.
|
|
|
|
|
|
This method is used for processes that can be *computed at discrete time-moments* and where stepping through each time-steps of the process would be useless *from a computation perspective*.
|
|
|
|
|
|
Take for example sending a *single* message on a bus without interruption.
|
|
|
We can know *at the start of the transmission* how much time this would take (if the model for the transmission is deterministic).
|
|
|
If the next useful computation in the simulation only happens when the message has fully reached its destination, computing any steps in between would be useless.
|
|
|
This is exactly the *event approach*.
|
|
|
Our two events are "(Starting to) send the message" and "Message fully received".
|
|
|
Everything in between can be computed beforehand.
|
|
|
That is, when we reach the computation of the send event, we can *already compute* the next moment in time where a new computation will be required (the time of the second event).
|
|
|
|
|
|
TODO visual example
|
|
|
|
|
|
TODO "implemented by..." + see below
|
|
|
|
|
|
## Interaction between Ticks and Discrete-Events
|
|
|
|
|
|
Discrete-Event and continuous simulations can interact in two directions:
|
|
|
|
|
|
- **Tick-controlled**: The overall simulation is governed by looping and calling `update()` ticks. The discrete-event simulation is then also "updated" for the tick. That is, events are processed until the next event would happen *after* the new time of the time-step.
|
|
|
- **Event-controlled**: Repeating (update) tick-events are introduced in the event-simulation. The discrete-event-simulator then processes its events normally until it reaches a tick-event, which triggers the computation of the next continuous-simulation tick.
|
|
|
|
|
|
The simulator currently uses the **first method** (tick-controlled) even though the second might be conceptually simpler.
|
|
|
At the time of writing, here are the reasons to use the first method:
|
|
|
|
|
|
- From a control flow perspective, an event approach requires to insert *interrupt events* (or highjack recurring events such as tick events) in order to have continuous interaction with the simulation. This is for example how the *basic-simulator* runs and visualizes simulation: it runs tick updates for some time (which also triggers events according to the method described above) then reads the simulation for visualization and repeats. However, in an asynchrone simulation-visualization (which [might be the way to go](https://git.rwth-aachen.de/monticore/EmbeddedMontiArc/simulators/basic-simulator/-/issues/3)), having "observer callbacks" as events that send the data to a visualization would be no problem at all.
|
|
|
- The second reason, which is to be discussed and more researched, is that is seems having a tick-based control flow would allow for easier synchronization in a parallel setting. However parallelization of the simulation and the event-system overall is a non-trivial problem to be explored.
|
|
|
|
|
|
TODO visual example
|
|
|
|
|
|
## Implementation: Update ticks
|
|
|
|
|
|
TODO
|
|
|
|
|
|
- TimeUpdate, Interfaces, update tree
|
|
|
- control by simulationloop, vis, basic-sim
|
|
|
|
|
|
## Implementation: Discrete-event simulation
|
|
|
|
|
|
- EventSimulator (Queue), events, event-targets |