Game engines, discrete event simulation, path-based simulation and continuous simulation

Game engines will play an increasingly important role in the simulation and visualization of industrial processes in the future and partially replace established software solutions. This is mainly due to powerful 3D visualization and the popularity and openness of game engines.

Our Game4Automation is based on Unity and is an example of this new class of simulation solutions. Game4Automation can be used for simulation and virtual commissioning in classical mechanical engineering and, with the complementary Conveyor Library, also for simulation and virtual commissioning of intralogistics systems. I myself used discrete-event simulation systems like Plant Simulation from Siemens in many projects for many years. In the past, discrete-event simulation was also the only option for material flow simulation. The computing power and 3D engines were nowhere near capable of what Unity can do today. There is also the question of what the differences are between such a discrete-event simulation and the continuous system based on Unity, and when it is best to use what? There are also several options for continuous simulation in Unity, path-based and physical. By continuous in this context, I mean time that runs continuously, not jumping to the next event as in a discrete-event system, but progressing continuously. The speed itself can be increased by a factor in game engines. The inner logic in game engines assumes a fixed physical cycle and frame rates that are as stable as possible. The update methods, which are the basis of most functions, are called in these fixed cycles. Now, what does this difference mean for the user? I would like to briefly share my findings here.

Unity and Game4Automation can be accelerated up to 100 times.

In my test models, continuous simulation, especially in the so-called "headless" mode, could be increased up to a factor of 100. And this with stochastically reproducible results (on the identical computer).

A continuous simulation is closer to reality and easier to implement for the end-user.

In a simulation in Unity, the structure of the model and the implementation of the logic is very close to reality. The PLC cycle is in an update method, which is called continuously and is practically identical to the real PLC control. Sensors in Unity are used like real sensors, sensors in Unity are permanent collisions. This results in a very realistic simulation that can be applied to the real world. In discrete-event simulation models, especially for detailed problems, very often it is not easy to match the abstracted model with reality, and the way the logic is implemented differs greatly from reality.

A path-based continuous simulation is slower than a physical simulation.

In the context of our tests with our conveyor library, the question arose as to which is the more performant approach. Is it worthwhile to replace the purely physical transport processes based on the Nvidia PhysX engine with Unity with calculated spline-based movements? As a result, it turned out that the physical simulation is at least twice as fast as the physics-based simulation. Therefore, path-based simulation is not useful for classical conveyors and is likely to be useful only for AGV systems, for example, unless an implementation very close to the sensor system of the AGV is chosen directly.

Summary

In summary, continuous simulation is quite sufficient for many applications and has the great advantage of working closer to reality. This also has the great advantage that the methods implemented in the simulation model and the knowledge gained from them can be more easily transferred to reality. It is also possible to use the simulation model directly for virtual commissioning without modifications. For very large facilities, such as entire distribution centers, the performance of continuous simulation is certainly not sufficient. But here, too, it would be possible to integrate a discrete event engine in Unity. However, with this you also get the disadvantages of the traditional discrete event engines again.