What a load of nonsense! That is how some colleagues react when the conversation turns to 3D simulation, digital twins or virtual commissioning in control engineering. The truth is that many of those colleagues do not actually know what lies behind 3D simulation and what it offers a PLC programmer. The possibilities are groundbreaking — if you dare to take the step…
How I came to simulation
I worked for a long time as a control systems engineer for precision measuring instruments. Anyone who does closed-loop control seriously simulates, and does so long before a single line of code is written. First you build mathematical models of the controlled system. Only those models make it possible to design efficient control loops with the help of clever algorithms. And because both the controller and the controlled system exist as mathematical models, simulating the entire control loop is the obvious next step: the controller is simulated — that is, tested — against the model of the controlled system. And testing means torpedoing the simulated control loop with every conceivable disturbance, pushing model parameters to their limits, trying out start-up behaviour under the widest range of conditions, even testing the effect of rounding errors inside the controller. Only once you are truly certain that the control loop behaves as intended is code written and tested on the real system.
And now guess what: the control loop then actually works in reality! Of course, in most cases the control parameters still need fine-tuning, because a mathematical model usually only approximates reality. But the structure of the controller, the start-up behaviour, the response to disturbances — all of that works!
Mathematical modelling of a machine?
Control engineering tasks rarely require a mathematical model. What they call for is engineering skill and logical thinking. Control engineers know their machine and are perfectly capable of writing PLC programs for the most complex machines from a functional specification and a wiring diagram. And because programming usually runs in parallel with the mechanical manufacturing of the machine, the control program can only be tested rudimentarily while it is being developed. The real testing happens during in-house commissioning or, if there is no other way, at the customer’s site.
Stop. At the customer’s site? Let that sink in.
Is it really true that we can only test PLC programs right at the very end, once the machine has been fully assembled? Many conversations with control engineers and their managers have confirmed one thing to me: nobody voluntarily touches an existing, working PLC program, least of all one that has grown over the years. Precisely because changes and their consequences can only be tested on the machine itself. And yet that is exactly what we have to do.
Why is that the case?
Testing control software completely is anything but trivial. Mechanical manufacturing and assembly usually take a long time, which means the control programming starts before the machine is actually available. The machines are often large and can be set up in-house only partially, if at all. And in a retrofit of an existing plant — upgrading its control components — downtime has to be kept to an absolute minimum, so testing is only possible to a limited extent.
It would be wrong to claim that control programs are not tested today. Quite the opposite! Control engineers are creative, and they have built all sorts of simulation modes and blocks into their code. The problem? These are usually structures that are not based on the laws of physics, which makes them hard to extend and, unfortunately, very error-prone.
Let me give you an example. Take a conveyor belt with a light barrier at each end. The direction of the belt is supposed to reverse whenever a bottle interrupts the corresponding light barrier. A simple approach to testing this function would be to program a simulation block that switches the light barrier signals after a fixed period of time. But what happens when the size of the bottles changes? What if there are two bottles on the belt?
You can see where this is going, can’t you? To test PLC programs realistically, what we ultimately need is the machine. We have to be able to drive actuators with real setpoints, and we need realistic feedback from sensors.
Physics-based simulation in 3D
Or would a simulated machine do the job just as well — one that behaves exactly like the real machine from the controller’s point of view? Actually, yes! Modern simulation software makes precisely that possible. Without any specialist simulation know-how, we can bring machines to life digitally and in 3D and connect them to the real controller. Even safety signals work with the simulated machine. So machine simulation gives us the opportunity to test our PLC program completely. Simulation flags and special adaptations to the program are no longer necessary. Some call it virtual commissioning, others a digital twin. I see it as a new era in control engineering.
Do we really have to act now?
In my opinion, a very clear YES! The machines we build become more efficient with every generation. Looking through our project archive, I came across a machine whose first generation is now ten years old. A comparison with the current generation looks like this:
| What | Change |
|---|---|
| Cycle time | 100 % more throughput |
| Number of mechanical degrees of freedom | 100 % added |
| Quality assurance | 100 % inspection with machine vision |
| Reduced set-up time through automated sequences | Newly added |
| Operator support in the event of a fault | Newly added |
| Production data acquisition | Newly added |
| Number of functions and function blocks in the PLC program | 200 % added |
| Safety program in the PLC | Newly added |
Why am I showing this example? Because it makes one thing absolutely clear, and I am sure you will agree: machines keep evolving. They become more efficient. The software takes on more tasks. It becomes more complex.
And that brings us right back to simulation. If we want to write good control software sustainably, we have to change our thinking — we need a paradigm shift. We have to start testing control software while we are writing it. Not at in-house commissioning, and certainly not at the customer’s site! The goal must be to begin commissioning with control software that has been fully tested. Of course parameters will still need adjusting afterwards — simulation only ever reflects an idealised version of reality. But at the start of commissioning we know that the sequences, the fault messages, the recipe management and so on all work. And believe me, you sleep an awful lot better knowing that :-)
