Aus PLC-Simulationsherausforderungen lernen: Ein praktischer Leitfaden

Diese umfangreiche Aussage aus einer Dissertation von Herrn Roland Schulz aus dem Jahr 2002 fasst die Thematik insgesamt gut zusammen.

Kurz gesagt: „Versuchen und Testen hilft, Fehler zu finden.“

Hier geht es nicht um die Simulation ganzer Produktionsanlagen, sondern das Prinzip wird auf einzelne Einheiten (Komponenten) heruntergebrochen, wie Automatisierungsprogramme oder Anwenderprojekte.

Früher, als junger Mitarbeiter bei Phoenix Contact, musste ich auch Programmieren lernen und hätte mich über eine Simulation des Controllers gefreut. Einfach, um durch „Versuch und Irrtum“ mehr über die Funktionsweise der Bausteine oder Programme zu erfahren. Leider gab es das damals nicht, und die spätere PLC-Simulation war sehr begrenzt. IEC 61131-3-Code konnte gut simuliert werden, aber es fehlte die Unterstützung spezieller Geräte oder das unterschiedliche Verhalten von Code zwischen Intel-, ARM- oder Motorola-basierten Systemen.

Mit diesen Gedanken und den Erinnerungen an die Probleme mit der „klassischen“ PLC-Simulation machten wir uns auf die Suche nach etwas mit echtem Mehrwert, ohne riesigen Aufwand – weder in der Entwicklung der Simulation noch in deren späterer Nutzung.

Als Anwender möchte ich mein Projekt per Mausklick an einen PLC oder an eine Simulation senden können. Ich möchte nicht auf Prozessorarchitekturen achten müssen, und ich möchte sicher nicht gezwungen sein, Funktionen in meinem Code zu verstecken oder gar zu entfernen, die von der Simulation nicht unterstützt werden.

Was liegt näher, als die echte Firmware in der Simulation zu verwenden, die auch auf der echten Steuerungshardware läuft? Genau das wurde umgesetzt.

Heutzutage gibt es vollwertige Systememulationen, die nicht nur verschiedene Betriebssysteme unter Windows ausführen lassen. Sie ermöglichen auch die Emulation verschiedener Prozessorarchitekturen und deren Eigenschaften.

Es ist kein Geheimnis, dass unsere Controller auf Linux basieren. Für die Codeentwicklung ist aber wichtig, dass hier auch unterschiedliche Prozessorarchitekturen zum Einsatz kommen.

In der Engineering-Umgebung, in unserem Fall PLCnext Engineer, sollte der Kunde per Mausklick zwischen der IP-Adresse des Controllers oder der Simulation wählen können – ohne sich um weitere Code-Anpassungen oder Binärcode-Kompatibilität kümmern zu müssen.

Was daraus wurde

Wir entdeckten die Systememulation QEMU und nutzen sie zur Simulation unserer Controller. QEMU ist eine „Open-Source-Maschinenemulation“ und bietet genau das, wonach wir suchten.

Die Firmware wird „einfach“ darin ausgeführt, und QEMU emuliert das komplette Linux-System der PLCnext Technology, einschließlich der ARM-Prozessorarchitektur einiger PLCnext-Controller – und die PLCnext-Simulation war geboren. Zugegeben, wir haben einige wenige Einschränkungen eingebaut. PROFINET-Kommunikation oder andere Kommunikationsprotokolle sind deaktiviert. Der OPC-UA-Server hingegen ist nicht betroffen.

Dennoch konnten alle Besonderheiten der PLCnext Technology erhalten bleiben. So können auch C/C++-, C#- oder Matlab-Simulink-Programme und -Komponenten an die Simulation gesendet werden. Auch Apps, die man für bestimmte Anwendungen im Store findet, können so zur Ausführung gebracht werden.

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

Und nun habe ich sie endlich, eine Simulation – oder je nach Definition sogar eine Emulation – meines Controllers. Leider musste ich ohne sie Programmieren lernen, und jetzt programmiere ich nicht mehr so viel.