Wie koppeln Sie SPS-Plattformen an den digitalen Zwilling und die virtuelle Inbetriebnahme?

Virtuelle Inbetriebnahme ist eine Methode, bei der die Steuerungslogik der Maschine gegen ein repräsentatives Modell geprüft wird, bevor die Anlage fertig gebaut und verdrahtet ist. Die SPS führt Sequenzen, Verriegelungen, Betriebsarten und HMI-Befehle aus. Der digitale Zwilling bildet Bewegungen, Sensoren, Materialfluss und Bedienerkontext ab.

Mitten in einem Maschinenprojekt die SPS-Familie zu wechseln, nur um eine bestimmte Simulationsfunktion zu bekommen, ist selten realistisch. Deshalb geht es darum, wie die vorhandene Plattform in eine Testumgebung mit Unity eingebunden werden kann.

B&R, Beckhoff, Siemens und Rockwell unterscheiden sich darin, wie weit Sie auf einem Engineering-PC kommen, wie die Runtime über neexo Gateway an Unity gekoppelt wird, und wann eine physische Steuerung für Netz, I/O oder Feldbus weiterhin nötig ist. Andere Anbieter können am selben Testsystem teilnehmen, wenn Runtime oder Hardware die vereinbarten Signale austauschen können.

Eine SPS-Simulation kann Logik, Alarme und HMI-Abläufe ohne 3D-Modell prüfen. Zur virtuellen Inbetriebnahme wird es, wenn dieselbe SPS-Logik zusätzlich gegen ein Modell getestet wird, das das Maschinenverhalten und die Signale abbildet, die das SPS-Programm erwartet.

neexo Gateway ist die Integrationsschicht zwischen SPS-Plattform, weiteren Datenquellen und dem Unity-Modell. Unity übernimmt Geometrie, Kinematik, Physik, Sensoren, Materialfluss und Bedienerkontext. Das Gateway steuert den Signalaustausch zwischen Modell und Automatisierungssystem.

Praktisch liest das Gateway Befehle und Statuswerte aus der SPS, übersetzt sie in die vereinbarten Datentypen und sendet sie an das Unity-Modell. Das Modell berechnet das relevante Maschinenverhalten und liefert zum Beispiel Sensorstatus, Positionsrückmeldung, Materialpräsenz oder Fehlerzustände an die SPS zurück.

Das Gateway ist der dokumentierte Vertrag zwischen Steuerungs-Team und Zwillings-Team. Dort werden Signalnamen, Datentypen, Lese- und Schreibrichtung, erzwungene Signale, Quellenpriorität und die Versionsführung der Zuordnung festgelegt.

So können mehrere Datenquellen dasselbe Unity-Modell speisen. Ein Maschinenabschnitt kann von einer physischen SPS gesteuert werden, während ein benachbartes Modul auf einer simulierten SPS-Runtime läuft. Roboter, Datenbanken, Testwerkzeuge und emuliertes Fremdgerät können als weitere Quellen hinzukommen, wenn ihre Rolle im Testsystem klar definiert ist.

Das Unity-Modell ersetzt die SPS-Logik nicht. Es bildet Prozess und physisches Maschinenverhalten ab. Das SPS-Programm bleibt verantwortlich für Sequenzen, Verriegelungen und Bedienfunktionen.

B&R Automation Studio enthält Automation Runtime Simulation, häufig ARsim genannt, sowie ACOPOS Simulation für relevante Motion-Szenarien. Damit lassen sich SPS-Anwendung und Teile der Motion-Logik auf einem Engineering-PC ausführen, bevor Steuerung und Schaltschrank bereitstehen.

ARsim eignet sich für frühe Tests von Sequenzen, Alarmen, Betriebsarten und HMI-Logik. Das Unity-Modell kann im selben Ablauf Endlagen, Sensorrückmeldungen, Materialfluss und das räumliche Verhalten abbilden, von dem das SPS-Programm abhängt. B&R beschreibt ARsim und ACOPOS Simulation als Teil der modellbasierten Entwicklungs- und Simulationsumgebung. Siehe B&Rs Seite zu Modeling and simulation.

neexo Gateway kann die B&R-Anwendung über eine projektdefinierte Schnittstelle an Unity koppeln, zum Beispiel über von der SPS bereitgestellte Daten oder B&Rs PVI-Schnittstelle. In manchen Architekturen kommt OPC UA hinzu, wenn die SPS-Seite die relevanten Tags bereitstellt.

Entscheidend ist, dass die Zuordnung auf derselben verbindlichen Variablenliste wie das SPS-Projekt beruht. Signale für Befehle, Sensoren, Achszustände, Quittungen und Fehler brauchen einen klaren Eigentümer. Unity sollte nur die Signale zurückgeben, die das Modell tatsächlich abbildet.

Eine physische B&R-Steuerung ist relevant, wenn der Test die konkrete Netzwerkanbindung der Steuerung, die Feldbus-Konfiguration, physische I/O oder die Kommunikation mit Fremdgerät umfasst. ARsim reicht oft für die tägliche Entwicklung und frühe Regressionstests. HIL wird typischerweise für ausgewählte Läufe vor virtueller FAT oder physischer FAT eingesetzt.

TwinCAT 3 Usermode Runtime kann dasselbe SPS-Programm auf einem Engineering-PC ausführen, ohne EtherCAT und ohne die deterministischen Eigenschaften einer normalen Echtzeit-Runtime. Das reicht für tägliche Sequenz-, Alarm- und HMI-Tests gegen ein Unity-Modell. Es reicht nicht, wenn physische EtherCAT-I/O, hardwareabhängige Schleifen oder Echtzeitverhalten Teil des FAT-Risikos sind.

Die Beckhoff-Dokumentation zur TwinCAT 3 Usermode Runtime beschreibt unter anderem Engineering-, External-Control- und Fast-as-possible-Szenarien. TwinCAT eignet sich, SPS-Sequenzen und HMI-Abläufe zusammen mit einem Unity-Modell zu fahren, während die mechanische Antwort im Modell simuliert wird. Kinematik, Sensoren, Kollisionserkennung und Materialfluss müssen weiterhin bewusst modelliert werden. Siehe Beckhoffs Produktseite zur TwinCAT 3 Usermode Runtime.

neexo Gateway kann TwinCAT und Unity über ADS verbinden, die native Kommunikationsschicht von Beckhoff, oder über OPC UA, wenn das Projekt eine stärker standardisierte Schnittstelle braucht. ADS ist oft sinnvoll, wenn das Unity-Modell eng an eine TwinCAT-Installation gekoppelt wird. OPC UA kann praktischer sein, wenn mehrere Systeme dieselben SPS-Variablen lesen sollen.

Das Gateway sammelt die Signale in einer gemeinsamen Zuordnung, sodass Unity die konkrete TwinCAT-Struktur nicht kennen muss. Dadurch lässt sich eine softwarebasierte Runtime gegen physische Hardware tauschen, ohne das Unity-Modell zu ändern oder die Zuordnung neu aufzubauen.

Die TwinCAT 3 Usermode Runtime hat keinen Zugriff auf EtherCAT und liefert nicht dieselben deterministischen Eigenschaften wie eine normale Echtzeit-Runtime. HIL ist deshalb relevant, wenn das Projekt physische EtherCAT-I/O, hardwareabhängige Rückführkreise, konkrete Netzkomponenten oder echtzeitabhängiges Verhalten prüfen muss. Typisch ist Usermode Runtime für den Alltag und eine physische Beckhoff-Steuerung für die Testfälle, in denen Hardware und Netz zum Risiko gehören.

Siemens bietet S7-PLCSIM und S7-PLCSIM Advanced für die softwarebasierte Simulation der S7-Steuerung. S7-PLCSIM Advanced ermöglicht mehrere virtuelle Steuerungen und die Anbindung externer Test- und Simulationswerkzeuge.

Für viele Projekte ist SPS- und HMI-Simulation der natürliche erste Schritt. Das Team kann Sequenzlogik, Alarme, Rezepte und Bedienabläufe prüfen, ohne ein fertiges Maschinenmodell zu haben. Wird Unity gekoppelt, lässt sich dieselbe SPS-Logik gegen repräsentative Sensor- und Prozessrückmeldungen des digitalen Zwillings testen. Siehe Siemens-Übersicht zu S7-PLCSIM Advanced.

neexo Gateway kann Siemens über S7-Kommunikation per TCP/IP, die S7-PLCSIM-Advanced-API oder OPC UA koppeln, abhängig von SPS-Typ, Netzaufbau und gewünschter Testarchitektur. Die Wahl sollte sich danach richten, welche Daten ausgetauscht werden, wie viele virtuelle Steuerungen beteiligt sind und ob das Unity-Modell im selben Netz wie die SPS-Runtime läuft.

Das Gateway soll die Grenze zwischen SPS und Modell sichtbar halten. Die SPS kann Befehle an einen Förderer oder eine Roboterzelle senden, während Unity Sensoren, Positionsstatus und Materialpräsenz zurückgibt. Im Testplan muss stehen, welche Signale echtes Maschinenverhalten abbilden und welche vorübergehend Gerät ersetzen, das nicht im Modell enthalten ist.

HIL mit einer physischen Siemens-Steuerung ist relevant, wenn der Test PROFINET-Geräte, Kommunikation zwischen physischen Steuerungen, physische I/O oder eine kundenspezifische Netzkonfiguration umfasst. Dasselbe gilt, wenn Risiko in hardwareabhängigen Modulen oder Verbindungen zu Fremdgerät liegt. S7-PLCSIM Advanced ist stark für frühe Logiktests, ersetzt aber nicht die physische Validierung von Netz, Safety-Hardware oder Prozessgerät. Das Unity-Modell kann in beiden Fällen genutzt werden, wenn die Signalzuordnung über Runtime und physische SPS hinweg stabil bleibt.

Rockwell Automation bietet FactoryTalk Logix Echo zur Emulation von Logix-Steuerungen. Damit lassen sich Logix-Anwendungen testen, bevor die physische Steuerung bereitsteht. Das eignet sich für frühe Prüfungen von Sequenzen, Alarmen und HMI-Logik.

Rockwell hat mit Emulate3D außerdem eine eigene 3D-Simulationslösung. Das ist in Rockwell-Projekten wissenswert, aber ein Unity-basierter digitaler Zwilling kann über neexo Gateway an die Logix-Anwendung gekoppelt werden, ohne an Rockwells 3D-Umgebung gebunden zu sein. Siehe Rockwells Produktseite zu FactoryTalk Logix Echo.

neexo Gateway kann Unity an physische oder emulierte Logix-Steuerungen über CIP-basierte Tag-Kommunikation per EtherNet/IP oder andere im Projekt vereinbarte Schnittstellen koppeln. Das Gateway liest die Tags, die das SPS-Programm nutzt, und tauscht nur die Signale, die das konkrete Maschinenmodell braucht.

Damit kann dasselbe Unity-Modell in einem softwarebasierten Testlauf und in einem HIL-Aufbau genutzt werden. Das SPS-Programm behält seine Logix-Struktur, während das Unity-Team mit einer klaren Zuordnung zwischen Steuerungs-Tags und Modellsignalen arbeitet.

Eine physische Rockwell-Steuerung ist relevant, wenn der Test physische EtherNet/IP-Kommunikation, I/O-Module, Antriebe, Sicherheitskomponenten oder die Integration mit weiterem Rockwell- und Kundengerät umfasst. FactoryTalk Logix Echo ist ein guter Einstieg für frühe Tests der Anwendungslogik, dokumentiert aber allein nicht das gesamte Hardware- und Netzverhalten.

Software-in-the-Loop, oft SIL genannt, ist in der Regel der beste Startpunkt. Der SPS-Code läuft auf einem Engineering-PC oder in einer virtuellen Runtime, und das Unity-Modell liefert die Signale zurück, die die SPS von der physischen Maschine erwartet. Die Iterationen bleiben kurz, weil eine Änderung am SPS-Programm schnell erneut getestet werden kann.

SIL eignet sich besonders für Sequenzlogik, Verriegelungen, Alarme, Betriebsarten, HMI-Abläufe und wiederholbare Regressionstests. Hier findet das Projekt auch Fehler in der Signalzuordnung, bevor physische Hardware und Kundenzeit im Spiel sind.

Hardware-in-the-Loop, HIL, nutzt eine physische Steuerung, während Prozess und ein Teil der I/O digital bleiben. HIL wählen Sie, wenn der Test die konkrete Ausführung der Steuerung, Netzverbindungen, Feldbus, Hardwareschnittstellen oder das Zusammenspiel mit Fremdgerät betrifft.

Viele Projekte kombinieren beides. SIL begleitet die laufende Entwicklung, HIL die gezielten Testfälle vor der virtuellen FAT. Unity-Modell und neexo Gateway sollten in beiden Umgebungen dieselben sein, damit der Wechsel keine neue manuelle Zuordnung und keine parallele Variablenliste erzeugt.

Die Tabelle ist eine technische Übersicht, kein Ersatz für eine Integrationsklärung. Der konkrete SPS-Typ, Softwarestand, Lizenzmodell, Netzarchitektur und das Risikoprofil der Maschine entscheiden über die endgültige Wahl.

Die Signalzuordnung verbindet SPS-Logik und Nutzen des digitalen Zwillings. Ändert ein SPS-Tag Name, Datentyp oder Funktion, muss die Änderung im Unity-Projekt erkennbar und behandelbar sein. Sonst läuft das Team Tests mit Signalen, die richtig aussehen, aber nicht mehr zum SPS-Programm passen.

Eine verbindliche Signalquelle sollte sowohl das SPS-Projekt als auch die Gateway-Zuordnung speisen. Das kann ein Tag-Export, eine strukturierte I/O-Liste oder ein anderes kontrolliertes Projektartefakt sein. Vermeiden Sie eine separate Kopie der Signale in Tabellen, E-Mails oder lokalen Notizen. Die Zuordnung sollte festhalten, ob ein Signal gelesen oder geschrieben wird, welchen Datentyp es hat, welche SPS- oder Datenquelle es besitzt und welcher Teil des Unity-Modells es nutzt. Bei mehreren Datenquellen muss außerdem stehen, welche Quelle im aktuellen Testdurchlauf Vorrang hat.

Maschinen laufen selten isoliert. Eine Verpackungsmaschine muss vielleicht Signale von Upstream- und Downstream-Geräten, Robotern, Vision-Systemen, Förderern oder der vorhandenen Liniensteuerung des Kunden verarbeiten. Die gesamte Produktionslinie zu modellieren ist nicht immer sinnvoll oder möglich. neexo Gateway kann mehrere Quellen sammeln und dem Unity-Modell über dasselbe strukturierte Signalmodell anbieten. Ein bestandenes Virtual-Commissioning-Szenario ist nur glaubwürdig, wenn simulierte Antwortzeiten, Quittungen und Fehlerzustände realistisch genug für das sind, was geprüft werden soll.

Ändert ein SPS-Stand die Tag-Struktur, sollten Gateway und Unity-Modell sichtbar fehlschlagen statt still mit einer unvollständigen Zuordnung weiterzulaufen. So wird Drift zu einer Engineering-Frage, bevor daraus ein falsches Testergebnis wird.

Ein digitaler Zwilling kann einen großen Teil der Testarbeit nach vorn ziehen. Die endgültige physische Validierung ersetzt er nicht. Safety-Funktionen, Sicherheitssteuerung, Performance Level, SIL-Anforderungen, elektromechanische Performance und tatsächliche Prozesseigenschaften müssen weiterhin an der echten Maschine geprüft werden. Dasselbe gilt für mechanische Toleranzen, Kabelbewegungen, pneumatisches und hydraulisches Verhalten, echte Produktstreuung und Prozessbedingungen, die das Modell nicht abbildet.

Beginnen Sie bei den Testfeldern mit dem größten FAT-Risiko: sicherheitsbezogene Sequenzen, Betriebsartenwechsel, kritische Maschinenzyklen, zentrale HMI-Abläufe und Schnittstellen zu anderem Gerät. Vereinbaren Sie, wie detailliert das Unity-Modell sein muss, und definieren Sie die Architektur: softwarebasierte Runtime oder physische Hardware, wie das Gateway die Steuerung erreicht und welche Datenquellen beteiligt sind. Bevor der Kunde zur virtuellen FAT eingeladen wird, sollte das Projektteam eine interne Generalprobe mit SPS-Verantwortlichem, HMI-Bediener, Zwillingsverantwortlichem und Testverantwortlichem durchführen.