... | ... | @@ -8,11 +8,9 @@ The simulator uses two simulation concepts to simulate the world and the vehicle |
|
|
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
|
|
|
![Time-step example](/img/dev-docs/sim-methods-timestep.svg)
|
|
|
|
|
|
This method is implemented by
|
|
|
|
|
|
TODO "implemented by..." + see below
|
|
|
This method is implemented by the `update()` tree inside the simulation. See the implementation details below.
|
|
|
|
|
|
## Discrete-Event-Simulation
|
|
|
|
... | ... | @@ -30,9 +28,12 @@ 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
|
|
|
The following figure *illustrates* how the discrete-event simulation works.
|
|
|
The setup used is simplified for the example.
|
|
|
|
|
|
![Discrete Event Simulation example](/img/dev-docs/sim-methods-events.svg)
|
|
|
|
|
|
TODO "implemented by..." + see below
|
|
|
This method is implemented by the `DiscreteEventSimulator` class and different `DiscreteEvent` classes. More implementation details are shown below.
|
|
|
|
|
|
## Interaction between Ticks and Discrete-Events
|
|
|
|
... | ... | @@ -47,7 +48,13 @@ 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
|
|
|
The following figure shows how a *tick-controlled* interaction between discrete-event and time-step based simulation works. This is what is used right now in the simulator.
|
|
|
|
|
|
![Tick-controlled timestep-event interaction](/img/dev-docs/sim-methods-timestep-event.svg)
|
|
|
|
|
|
This next figure shows how the other way would work. The discrete-event simulation also calls the tick updates.
|
|
|
|
|
|
![Tick-controlled timestep-event interaction](/img/dev-docs/sim-methods-events-timestep.svg)
|
|
|
|
|
|
## Implementation: Update ticks
|
|
|
|
... | ... | @@ -58,4 +65,6 @@ TODO |
|
|
|
|
|
## Implementation: Discrete-event simulation
|
|
|
|
|
|
TODO
|
|
|
|
|
|
- EventSimulator (Queue), events, event-targets |