Painful memories of PLC simulations

Simulation can be used as a method of forecasting to examine the behavior of the mapped real system on the model of a production system and to test alternative actions ex-ante to remedy future deficiencies.

This bulky statement from a dissertation by Mr. Roland Schulz from 2002 sums it up quite well on the whole.

In short: "Trying and testing helps to find errors".

Now I am not writing here about the simulation of entire production plants, but break the principle down further to individual units (components), such as automation programs or user projects.

In the past, as a young employee at Phoenix Contact, I also had to learn programming and would have been happy about a simulation of the controller. Simply to find out more about the operation and function of the blocks or programs by "try and error". Unfortunately, it did not exist at that time and the PLC simulation that followed was very limited.  IEC61131-3 code could be simulated well, but it lacked the support of special devices or simply the different behavior of code between Intel and ARM or Motorola based systems.

With these thoughts in mind and the memories of the pain we had with the "classic" simulation of a PLC, we set out to really find something with added value without creating huge efforts. Efforts on the one hand in the development of a simulation and efforts that could arise later in the use of it.

As a user, I want to be able to send my project to a PLC or to a simulation, at best with a mouse click. I don't want to pay attention to processor architectures, and I certainly don't want to be forced to hide or, worse, remove functions in my code that are not supported by the simulation.

What could be more obvious than to use the real firmware in the simulation, which is also used on the real control hardware? And that is exactly what happened.

Nowadays there are full-fledged system emulations that not only allow to run various operating systems under Windows. They also allow emulation of various processor architectures and their characteristics.

It is not a secret that our controllers are based on Linux. But it is important for the development of code that here also different processor architectures are used.

In the engineering, in our case the PLCnext Engineer, the customer should be able to choose between the IP address of the controller or the simulation - with one mouse click without worrying about further code adaptations or binary code compatibility.

What came out of those thoughts?

We found the system emulation QEMU and use it to simulate our controllers. QEMU is an "open source machine emulation" and offers exactly what we were looking for.

"Just" run the firmware in it and QEMU emulates the complete Linux system of PLCnext Technology, including the ARM processor architecture of some PLCnext controllers -- and the PLCnext simulation was born. Admittedly, we did include a few minor limitations. PROFINET communication or other communication protocols are disabled. But the OPC UA server, for example, is not affected.

However, all the special features of PLCnext Technology could be preserved. So I can also send my C/C++, C# or Matlab Simulink programs and components to the simulation. Also APPs, which I can find for certain applications in the Store, can be brought so to the execution.

Some further limitations are obvious - determinism is not to be expected from such a simulated system. And depending on the load of my Windows system, there may be one or the other watchdog on the PLCnext simulation. But in such cases I can always give the simulation process a higher priority in the Windows system and then the watchdog errors are quickly resolved.

And now I finally have it, a simulation, or maybe even depending on the definition, an emulation of my controller. But unfortunately I had to learn programming without it, and now I don't program that much anymore.