Wie verbindet man eine SPS mit einem digitalen Zwilling?

Eine Demo mit einer SPS kann fertig wirken: eine Variable bewegt einen Zylinder in Unity, einige Signale wechseln den Zustand, und die Verbindung scheint zu laufen. Die eigentliche Arbeit beginnt, wenn dieser Aufbau SPS-Änderungen, mechanische Anpassungen und Varianten an einer realen Maschine überstehen muss.

Wenn das Unity-Modell konkrete OPC-UA-NodeIds, Verbindungsparameter und plattformspezifische Adressen kennt, ist die 3D-Anwendung an genau diese Steuerung gebunden. Eine Änderung im SPS-Projekt wird dann zur Änderung in Unity. Automatisierung und 3D-Anwendung brauchen eine klarere Grenze.

Als Nächstes kommt die Fehlersuche. Reagiert ein Ventil in der virtuellen Maschine nicht, muss das Team sehen können, ob die Ursache in der SPS-Logik, der Verbindung, der Signalzuordnung oder im Modell liegt. Steckt dieses Wissen nur im Unity-Code, hängt der Support an der Person, die die erste Version gebaut hat.

Maschinenbauer mit mehreren Steuerungsplattformen oder Varianten merken das schneller. Siemens, B&R, Beckhoff, Rockwell und Robotersteuerungen bieten nicht dieselben Laufzeit- und Integrationsmöglichkeiten. Diese Unterschiede gehören in eine Integrationsschicht, nicht in einen digitalen Zwilling, der für jede Steuerung neu gebaut wird.

Dieselbe Integrationsaufgabe ist uns in Projekten mit digitalen Zwillingen und virtueller Inbetriebnahme immer wieder begegnet. Ein projektspezifischer Connector kann die erste Maschine in Gang bringen und wird bei der nächsten zur Altlast.

neexo Gateway ist unser Produkt für diese Schicht. Es läuft lokal zwischen Maschinensteuerung und Unity und bündelt Verbindungen, Variablen, Signalzuordnungen, Laufzeitwerte und Diagnose an einer Stelle.

Auf der Unity-Seite arbeitet unser PowerTools-Client mit stabilen Variablennamen und IDs statt mit rohen OPC-UA-NodeIds. Unity muss nicht alle Details der zugrunde liegenden SPS-Verbindung kennen. Maschinensteuerung und 3D-Anwendung bleiben auf gegenüberliegenden Seiten einer stabilen Schnittstelle.

Für den Kunden muss die Integration sichtbar und wartbar bleiben, damit die nächste Maschine sie wiederverwenden kann. Projektspezifischer Code, den nur der ursprüngliche Entwickler versteht, übersteht diesen Wechsel nicht.

Im Gateway Cockpit wird die Maschinenverbindung eingerichtet. Dort lassen sich mehrere Verbindungen anlegen, von den Steuerungen bereitgestellte Variablen durchsuchen, Tags auswählen, Signalzuordnungen erstellen und aktuelle Werte prüfen. Die lokale Runtime übernimmt anschließend den laufenden Datenaustausch mit Unity.

Eine Maschinenkonfiguration kann mehrere Steuerungsverbindungen unter derselben aktiven Maschine bündeln. Unity arbeitet dann gegen eine Echtzeitschnittstelle statt gegen eine eigene Integration je SPS, Roboter oder Simulator. Das spielt eine Rolle bei Maschinen und Linien, deren Steuerungstechnik nicht von einem einzigen Hersteller stammt.

Gateway bietet heute Verbindungen unter anderem für OPC UA, Siemens S7 und PLCSIM Advanced, Beckhoff TwinCAT ADS, FactoryTalk Logix Echo, Universal Robots und MQTT. Diese Wege haben nicht alle denselben Validierungsstand an physischer Hardware. Deshalb unterscheiden wir klar zwischen implementierter Funktion und dem, was bereits an einer realen Installation verifiziert wurde.

Für die Fehlersuche bietet Gateway Diagnosefunktionen, Laufzeitstatus, lokale Logs und Werkzeuge zum Sammeln von Supportdaten. Die lokale Runtime zwischen SPS und Unity ist weniger sichtbar als das 3D-Modell, entscheidet aber oft darüber, ob eine Lösung nach der ersten Demo gut betreut werden kann.

Gateway kann zusammen mit einem Unity Digital Twin als lokale Windows-Komponente ausgeliefert werden. Es lässt sich als Teil der Lösung starten und kann bei dauerhafteren Installationen auch als Windows-Dienst betrieben werden.

Die Zuständigkeit wird klarer. Das SPS-Programm enthält die Maschinenlogik. Der digitale Zwilling bildet virtuelles Verhalten und Visualisierung ab. Gateway verbindet beide Seiten.

Teile des Aufbaus lassen sich dann bei der nächsten Maschine wiederverwenden. Eine neue Variante kann weiterhin neue Signale und neues Modellverhalten brauchen, aber die gesamte Verbindung muss nicht jedes Mal neu erfunden werden.

Auch die Zusammenarbeit zwischen Automatisierung, Software und Mechanik wird konkreter. Das Team kann Verbindung, Variable und aktuellen Wert prüfen, statt allgemein zu fragen, ob Unity die richtigen Daten bekommt. Das verkürzt den Weg vom Symptom zur tatsächlichen Ursache.

Es gibt außerdem eine kommerzielle Seite. Ein digitaler Zwilling lässt sich leichter als Engineering-Leistung verkaufen, wenn der Kunde versteht, wie er mit der vorhandenen Maschinensteuerung verbunden wird und wie diese Verbindung später betrieben und betreut werden kann.

Was neexo liefern soll, ist ein Aufbau, in dem Automatisierung, HMI, Simulation und digitales Maschinenmodell zusammenarbeiten, und den auch das Team des Maschinenbauers nachvollziehen kann.

Eine aktive Maschinenkonfiguration kann mehrere Steuerungsverbindungen bündeln, auch von unterschiedlichen Herstellern, sofern jede Verbindung einen unterstützten Connector hat.

Das entspricht dem Aufbau vieler Maschinen und Produktionslinien. Ein System kann eine Haupt-SPS, eine separate Steuerung für ein Teilsystem und eine Robotersteuerung enthalten. Sie müssen nicht vom selben Hersteller stammen.

Herstellerunabhängigkeit heißt hier: Die Unity-Seite hängt nicht von konkreten Steuerungsadressen und Protokollen ab. Die Steuerungsseite bleibt spezifisch. Siemens S7, TwinCAT ADS, OPC UA, Logix Echo, Universal Robots und MQTT werden nicht identisch eingerichtet, und nicht jede SPS ist Plug-and-play.

Für den Maschinenbauer kann dieselbe Unity-Simulation und Modellstruktur über gemischte Steuerungen und Maschinenvarianten hinweg genutzt werden. Die Signalzuordnung muss weiterhin stimmen. Die Integrationsarchitektur muss nicht jedes Mal neu erfunden werden.

Bei der virtuellen Inbetriebnahme gibt es die Verbindung, damit die reale Maschinenlogik gegen ein Modell getestet werden kann, das kontrolliert und nachvollziehbar reagiert.

Setzt die SPS einen Ausgang, muss die virtuelle Maschine reagieren. Ändert ein simulierter Sensor seinen Zustand, muss die SPS den entsprechenden Eingang erhalten. Stoppt eine Sequenz, sollte das Team sowohl den Zustand der Steuerung als auch die Reaktion der virtuellen Maschine nachvollziehen können.

Gateway legt eine feste Grenze zwischen Steuerung und digitalem Zwilling. Das Unity-Modell arbeitet mit Variablennamen und Signalzuordnungen, während die konkrete Verbindung zur Steuerung separat behandelt wird. Das hilft, wenn ein Projekt von einer frühen Simulation zu realitätsnäheren Testaufbauten übergeht.

Gateway ergänzt unsere Arbeit mit SPS-Integration, Motion Control, HMI und Unity-basierten digitalen Zwillingen. Diese Disziplinen brauchen weiterhin ihr eigenes Engineering. Gateway ist der Ort, an dem sie zusammenkommen.

Gateway ersetzt keine SPS-Entwicklung. Ein schlecht aufgebauter Ablauf wird dadurch nicht besser, und ein Modell wird nicht genauer als die Daten und das Verhalten, die darin abgebildet wurden.

Gateway ersetzt auch keine Safety-Validierung und keine physische Inbetriebnahme. Verriegelungen und sichere Zustände lassen sich als Logik testen, die reale Maschine muss aber weiterhin mit der tatsächlichen Sicherheitstechnik, Mechanik, Sensorik und Installation geprüft werden.

Gateway ist außerdem kein universeller Feldbus-Emulator. Timing, Netzwerkverhalten und Hardwareeffekte, die auf der realen Anlage entscheidend sind, müssen in einem Aufbau geprüft werden, der genau diese Eigenschaften nachweisen kann. Emulation verfolgen wir als separates Entwicklungsthema, getrennt von der Produktaufgabe, die Gateway heute löst.

Gateway ist dann interessant, wenn ein digitaler Zwilling mit der tatsächlichen Maschinensteuerung arbeiten soll, nicht nur mit Visualisierung. Besonders relevant wird das, wenn die Lösung über mehrere Maschinen, Varianten oder Projekte hinweg wiederholt werden soll und der Kunde die Integration selbst verstehen und betreuen können muss.

Gateway kann Teil einer Lösung für virtuelle Inbetriebnahme, eines Unity Digital Twin oder eines Entwicklungsaufbaus sein, in dem Automatisierungs- und Softwareteams parallel arbeiten. In solchen Projekten behandeln wir Gateway als neexo-Produkt und nicht als versteckten internen Hilfscode.

Beginnen Sie mit der Maschine, nicht mit der 3D-Engine: Welche Steuerungen hat sie, welche Signale braucht das Modell, was soll simuliert werden, und was muss weiterhin auf realer Hardware nachgewiesen werden?

Auf dieser Basis lässt sich die Grenze zwischen den Steuerungen, Gateway und digitalem Zwilling festlegen, bevor die Integration später teuer nachgebaut werden muss.