Schmerzhafte Erinnerungen an SPS-Simulationen

Diese sperrige Aussage aus einer Dissertation von Herrn Roland Schulz aus dem Jahr 2002 bringt es im Großen und Ganzen ganz gut auf den Punkt.

Kurz gesagt:„Ausprobieren hilft, Fehler zu finden“.

Nun schreibe ich hier nicht über die Simulation ganzer Produktionsanlagen, sondern breche das Prinzip weiter herunter auf einzelne Einheiten (Komponenten), wie zB Automatisierungsprogramme oder Anwenderprojekte.

Früher musste ich als junger Mitarbeiter bei Phoenix Contact auch Programmieren lernen und hätte mich über eine Simulation der Steuerung gefreut. Einfach durch „Try and Error“ mehr über die Bedienung und Funktion der Bausteine ​​oder Programme erfahren. Leider existierte es damals noch nicht und die darauf folgende SPS-Simulation war sehr begrenzt. IEC61131-3-Code konnte gut simuliert werden, aber es fehlte die Unterstützung spezieller Geräte oder einfach das unterschiedliche Verhalten des Codes zwischen Intel- und ARM- oder Motorola-basierten Systemen.

Mit diesen Gedanken im Hinterkopf und der Erinnerung an den Schmerz, den wir mit der „klassischen“ Simulation einer SPS hatten, machten wir uns daran, ohne großen Aufwand wirklich etwas mit Mehrwert zu finden. Aufwände einerseits bei der Entwicklung einer Simulation und Aufwände, die später bei der Nutzung entstehen könnten.

Als Anwender möchte ich mein Projekt am besten per Mausklick an eine SPS oder an eine Simulation schicken können. Ich möchte nicht auf Prozessorarchitekturen achten und schon gar nicht gezwungen sein, Funktionen in meinem Code zu verstecken oder, schlimmer noch, zu entfernen, die von der Simulation nicht unterstützt werden.

Was liegt da näher, als in der Simulation die echte Firmware zu verwenden, die auch auf der realen Steuerungshardware zum Einsatz kommt? Und genau das ist passiert.

Heutzutage gibt es vollwertige Systememulationen, die es nicht nur ermöglichen, diverse Betriebssysteme unter Windows auszuführen. Sie ermöglichen auch die Emulation verschiedener Prozessorarchitekturen und ihrer Eigenschaften.

Es ist kein Geheimnis, dass unsere Steuerungen auf Linux basieren. Wichtig für die Codeentwicklung ist aber, dass hier auch unterschiedliche Prozessorarchitekturen zum Einsatz kommen.

Im Engineering, in unserem Fall dem PLCnext Engineer, soll der Kunde zwischen der IP-Adresse der Steuerung oder der Simulation wählen können – mit einem Mausklick, ohne sich um weitere Code-Anpassungen oder Binärcode-Kompatibilität kümmern zu müssen.

Was kam aus diesen Gedanken heraus?

Wir haben die Systememulation QEMU gefunden und verwenden sie, um unsere Controller zu simulieren. QEMU ist eine "Open-Source-Maschinenemulation" und bietet genau das, wonach wir gesucht haben.

"Nur" Führen Sie die Firmware darin aus und QEMU emuliert das komplette Linux-System von PLCnext Technology, einschließlich der ARM-Prozessorarchitektur einiger PLCnext-Controller – und die PLCnext-Simulation war geboren. Zugegeben, wir haben ein paar kleinere Einschränkungen eingebaut. Die PROFINET-Kommunikation oder andere Kommunikationsprotokolle sind deaktiviert. Aber der OPC-UA-Server ist beispielsweise nicht betroffen.

Alle Besonderheiten der PLCnext Technology konnten jedoch erhalten bleiben. So kann ich auch meine C/C++, C# oder Matlab Simulink Programme und Komponenten an die Simulation schicken. Auch APPs, die ich für bestimmte Anwendungen im Store finden kann, lassen sich so zur Ausführung bringen.

Einige weitere Einschränkungen sind offensichtlich – Determinismus ist von einem solchen simulierten System nicht zu erwarten. Und je nach Auslastung meines Windows-Systems gibt es den einen oder anderen Watchdog auf der PLCnext-Simulation. Aber in solchen Fällen kann ich dem Simulationsprozess im Windows-System immer eine höhere Priorität geben und dann sind die Watchdog-Fehler schnell behoben.

Und jetzt habe ich ihn endlich, eine Simulation oder je nach Definition vielleicht sogar eine Emulation meines Controllers. Aber leider musste ich das Programmieren ohne lernen und programmiere jetzt nicht mehr so ​​viel.