Virtuelle Inbetriebnahme von SPS-Applikationen

Der Bau einer neuen Maschine läuft in der Regel folgendermaßen ab: Nach Anforderungsanalyse, Machbarkeitsbetrachtung und dem Angebot erhält der Maschinenbauer den Auftrag. Anschließend startet der Entwicklungsprozess. Die Maschinen- und Anlagensequenzen werden entworfen, die dafür erforderlichen elektrischen und elektromechanischen Bauteile ausgesucht und im CAD/ CAE-System hinterlegt. Alle elektrischen und mechanischen Komponenten wie Sensoren, Aktoren, Motoren, Antriebe, Steuerungen und E/A-Knoten samt den dafür erforderlichen Maschinenteilen werden zusammengestellt und geordert.

Anschließend wird der Herstellungsprozess mit seinen Bearbeitungsschritten entworfen. Die Entwicklung der Steuerungsapplikation startet bereits während der Konstruktion und berücksichtigt auch die Be und Verarbeitung des Werkstücks inklusive eventueller Probleme wie Verbiegungen, Schwingen, Brechen oder Kippen.

Verfügbare Hilfsmittel für eine virtualisierte Inbetriebnahme

IEC-61131-3-Tools wie Codesys bieten im Standardumfang wertvolle Möglichkeiten für Entwickler der SPS-Applikation, ihr Steuerungsprojekt vorab für eine Inbetriebnahme vorzubereiten:

• Simulationsmodus/SoftSPS: Die reine SPSLogik wird in einer simulierten Steuerung ausgeführt – ohne Steuerungshardware, Feldbus oder reale E/A. Alternativ: Ausführung der Steuerungsapplikation auf einer Windows-SoftSPS direkt auf dem PC, auf dem das Entwicklungssystem selbst läuft. Optimalerweise sind auf diese Weise generische Applikationsteile fertig und manuell getestet, bevor die Maschine oder deren Bestandteile physisch überhaupt existieren.
• Automatisierte Tests: Werden Programmteile über einen längeren Zeitraum weiterentwickelt, dann ist das wiederholte, manuelle Testen mühsam. Abhilfe schaffen automatisierte Tests anhand von Testskripten. Sie führen die Programmbausteine aus, übergeben dabei Soll- und Istwerte und überprüfen diese auf die zu erwartende Ergebnisse. Die Entwicklung solcher Testskripte ist zwar aufwendig, der Aufwand amortisiert sich bei wiederkehrenden Tests jedoch sehr schnell. Gleichzeitig entstehen automatisch generierte Testreporte als Dokumentation für Maschinen- und Anlagenbauer und deren Auftraggeber.
• Online-Konfigurationsmodus: Stehen die erforderlichen Ein- und Ausgänge bereits zur Verfügung, so lassen sie sich komfortabel in Codesys konfigurieren. Dafür bringt das Tool die entsprechenden Konfiguratoren für klassische und Ethernet-basierte Feldbussysteme mit. In einem speziellen Online-Modus können Anwender die so konfigurierten E/A-Module im Feldbus mit einer generischen Applikationssoftware prüfen. Damit werden typische Fragen beantwortet, wie: Sind alle E/A physikalisch korrekt adressiert und richtig verdrahtet beziehungsweise verfahren Antriebe im gewünschten Bereich und sind die Grenzen für Geschwindigkeit oder Ruck korrekt gesetzt?
• Übernahme von Simulationsmodellen: Wurden Fertigungsschritte mit entsprechenden Tools wie Matlab/ Simulink bereits vormodelliert, so lassen sich dafür erzeugte Algorithmen direkt in das Steuerungsprojekt übernehmen. Dazu wird in der Regel IEC-61131-3-Code (meist ST) erzeugt, der in Tools wie Codesys problemlos importiert und weiterverwendet werden kann.

Einsatz von spezialisierten Simulationstools

So hilfreich die beschriebenen Möglichkeiten bereits sind – eine vollständige Inbetriebnahme der Steuerung mit ihrer Applikation ersetzen sie nicht. Können sie auch gar nicht, weil die Physik der Maschine, der Werkstücke und deren Interaktion noch nicht berücksichtigt wird. Um die Applikation gegen ein reales Testszenario zu testen, gibt es verschiedene Ansätze:

• Eine zweite Steuerung, die als Gegenpart die Physik der Maschine/Anlage simuliert. Diese Möglichkeit ist zwar einfach zu realisieren, hat aber einen entscheidenden Nachteil: Durch die Programmierung der zweiten Steuerungsapplikation wird wirklich nur das nachgebildet, was über das angenommene physikalische Verhalten der Maschine vorab bekannt ist. Auch ist der so erzeugte Code für eine spätere Nutzung kaum hilfreich.
• Einsatz von spezialisierten Simulationstools, die eine detaillierte Modellierung der Maschine und Fertigungsabläufe erlauben.

Der Aufwand für die Modellierung der spezialisierten Simulationstools kann bei entsprechender Detailtiefe nahezu beliebig groß werden. Aber dem steht ein großer Vorteil gegenüber: Das Modell nähert sich sukzessive der Realität an – bis die Simulation eine reale Inbetriebnahme nahezu vollständig ablöst. Insbesondere, wenn das physikalische Verhalten berücksichtigt werden soll, führt kein Weg an Modellierungen in solchen Simulationstools vorbei.

Steuerungsapplikation mit Simulation verbinden

Bei der Simulation des Fertigungsprozesses gibt es zwei typische Vorgehensweisen:

• Nutzung einer modellierten beziehungsweise nachgebildeten Steuerungslogik sowie
• Nutzung der realen Steuerungsapplikation auf der realen SPS.

Da es sich bei der Steuerungsapplikation und dem darunterliegenden SPS-Kern um Software handelt, kann die reale Applikation auch ohne die spätere SPS-Hardware in den Simulationsprozess eingebunden werden. Auch so erreicht man eine realistische Simulation. Die entscheidende Frage: Wie können Steuerungsapplikation und Simulationstool miteinander kommunizieren, um realistische Tests zu gewährleisten? Es gibt nur eine Möglichkeit: Im Steuerungsprojekt müssen die physikalischen Ein- und Ausgänge samt Variablen so „umgebogen“ werden, dass sie im Simulationstool genutzt beziehungsweise bedient werden können. Schließlich sollen in der Steuerung die Eingänge auf den von der simulierten Sensorik erfassten Istzustand reagieren und dann die simulierten Aktoren entsprechend ansteuern.

Dies umzusetzen, bedeutete bislang aufwendige Handarbeit: Abhängig davon, welche Schnittstellen in den Simulationstools zur Verfügung stehen, mussten die E/A-Daten manuell in der Applikation auf die verfügbare Schnittstelle weitergeleitet werden. Ist die Inbetriebnahme mit dem Simulationstool abgeschlossen, muss die so erzeugte Umleitung auch wieder zurückgebaut werden. Weiterleitung und Rückbau im Steuerungsprojekt bergen ein nicht unbeträchtliches Risiko für das Gesamtsystem – vom Aufwand ganz abgesehen.