Wie verbindet man eine SPS mit einem digitalen Zwilling?

Für eine Demo ist die Sache einfach. Eine SPS-Variable bewegt einen Zylinder in Unity, einige Signale wechseln ihren Zustand, und die Verbindung scheint gelöst. Schwieriger wird es, sobald die Lösung an einer realen Maschine eingesetzt und über SPS-Änderungen, mechanische Anpassungen und Varianten hinweg gepflegt werden muss.

Wenn das Unity-Modell konkrete OPC-UA-NodeIds, Verbindungsparameter und plattformspezifische Adressen kennt, ist die 3D-Anwendung eng an genau diese Steuerung gekoppelt. Eine Änderung im SPS-Projekt kann dann eine Änderung in Unity nach sich ziehen. Das ist keine saubere Trennung zwischen Automatisierung und Software.

Hinzu kommt die Fehlersuche. Reagiert ein Ventil in der virtuellen Maschine nicht, muss das Team schnell erkennen können, ob die Ursache in der SPS-Logik, der Verbindung, der Signalzuordnung oder im Modell liegt. Steckt die gesamte Integration im Unity-Code, bleibt dieses Wissen leicht bei der Person hängen, die die erste Version gebaut hat.

Bei Maschinenbauern mit mehreren Steuerungsplattformen oder Maschinenvarianten wird das noch deutlicher. Siemens, B&R, Beckhoff, Rockwell und Robotersteuerungen bieten nicht dieselben Laufzeit- und Integrationsmöglichkeiten. Diese Unterschiede gehören in eine Integrationsschicht und nicht in den digitalen Zwilling selbst.

Wir haben Gateway entwickelt, weil uns dieselbe Integrationsaufgabe in Projekten mit digitalen Zwillingen und virtueller Inbetriebnahme immer wieder begegnet ist. Ein projektspezifischer Connector kann für die erste Maschine funktionieren. Bei der nächsten wird er schnell zur Altlast.

neexo Gateway ist unser Produkt für genau diesen Teil der Lösung. 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 dadurch nicht alle Details der zugrunde liegenden SPS-Verbindung kennen. So entsteht eine klarere Grenze zwischen Maschinensteuerung und 3D-Anwendung.

Für den Kunden liegt der Nutzen nicht in einem weiteren Softwaremodul. Entscheidend ist, dass die Integration sichtbar, wartbar und besser wiederverwendbar wird, statt als projektspezifischer Code versteckt zu sein, den nur der ursprüngliche Entwickler versteht.

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

Eine Maschinenkonfiguration kann mehrere Steuerungsquellen unter derselben aktiven Maschine gruppieren. Gateway kann diese Quellen gemeinsam verbinden, während Unity weiterhin mit derselben Realtime-Schicht arbeitet. Das ist besonders wichtig bei Maschinen und Linien, deren Steuerungstechnik nicht von einem einzigen Hersteller stammt.

Gateway bietet heute Verbindungswege 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.

Ein einfaches Beispiel ist eine Maschinenstation mit Sensoren, zwei Servoachsen und einer Ablaufsteuerung in der SPS. Unity muss nicht wissen, wie jedes Signal in der konkreten Steuerung adressiert wird. Gateway hält Verbindung und Zuordnung zusammen, während Unity nur mit den Signalen arbeitet, die das Modell tatsächlich benötigt.

Für die Fehlersuche bietet Gateway eigene Diagnosefunktionen, Runtime-Status, lokale Logs und Werkzeuge zum Sammeln relevanter Supportdaten. Die zentrale SPS-zu-Unity-Runtime läuft lokal. Das 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.

Der erste Vorteil ist eine klare Zuständigkeit. Das SPS-Programm enthält die Maschinenlogik. Der digitale Zwilling bildet virtuelles Verhalten und Visualisierung ab. Gateway verbindet beide Seiten miteinander.

Dadurch lassen sich Teile der Lösung bei der nächsten Maschine leichter wiederverwenden. Eine neue Variante kann weiterhin neue Signale und neues Modellverhalten brauchen, aber die gesamte Verbindung muss nicht jedes Mal neu erfunden werden. Dasselbe gilt, wenn ein Kunde die Steuerungsplattform wechselt oder innerhalb einer Produktfamilie verschiedene Systeme einsetzt.

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

Es gibt außerdem einen kommerziellen Vorteil. Ein digitaler Zwilling lässt sich leichter als belastbare 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. Gateway macht diesen Teil der Lieferung einheitlicher und weniger abhängig von einmaligem Integrationscode.

Das ist für uns wichtig, weil neexo nicht nur ein ansprechendes 3D-Modell liefern will. Der eigentliche Nutzen entsteht, wenn Automatisierung, HMI, Simulation und digitales Maschinenmodell in einem Aufbau zusammenarbeiten, den auch das Team des Maschinenbauers nachvollziehen kann.

Ja. Das ist ein zentraler Teil der Architektur. Eine Maschinenkonfiguration in Gateway kann mehrere Steuerungsverbindungen enthalten, und Gateway kann diese Quellen für die aktive Maschine gemeinsam verbinden. Unity arbeitet weiterhin mit derselben Realtime-Schicht und benötigt keine eigene Integrationsarchitektur für jede SPS.

Das entspricht realen Maschinen und Produktionslinien besser. 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, solange die jeweilige Verbindung über einen unterstützten Connector oder ein unterstütztes Protokoll hergestellt werden kann.

So ist Herstellerunabhängigkeit hier gemeint: Die Unity-Seite ist unabhängig von konkreten Steuerungsadressen und Protokollen. Die Steuerungsseite bleibt spezifisch. Siemens S7, TwinCAT ADS, OPC UA, Logix Echo, Universal Robots und MQTT werden nicht identisch eingerichtet, und wir behaupten nicht, dass jede SPS Plug-and-play ist.

Für den Maschinenbauer bedeutet das, dass dieselbe Unity-Simulation und Modellstruktur über gemischte Steuerungen und Maschinenvarianten hinweg genutzt werden kann, ohne herstellerspezifische Details in den 3D-Code zu verschieben. Die Signalzuordnung muss weiterhin stimmen, aber die Integrationsarchitektur muss nicht jedes Mal neu erfunden werden.

Bei der virtuellen Inbetriebnahme ist die Verbindung kein Selbstzweck. Sie soll ermöglichen, die reale Maschinenlogik gegen ein Modell zu testen, 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 schafft dafür 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 ist besonders hilfreich, wenn ein Projekt von einer frühen Simulation zu realitätsnäheren Testaufbauten übergeht.

Gateway ergänzt deshalb unsere Arbeit mit SPS-Integration, Motion Control, HMI und Unity-basierten digitalen Zwillingen. Es ersetzt diese Disziplinen nicht. Es schafft einen kontrollierten 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. Sie ist nicht dieselbe Aufgabe, die Gateway heute löst.

Diese Abgrenzung ist bewusst gewählt. Wir sagen lieber genau, was ein digitaler Test belegen kann, als virtuelle Inbetriebnahme so darzustellen, als würde die physische Inbetriebnahme dadurch verschwinden.

Gateway ist dann interessant, wenn ein digitaler Zwilling über reine Visualisierung hinausgehen und mit der tatsächlichen Maschinensteuerung arbeiten soll. 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.

Eine gute erste Frage lautet deshalb nicht, welche 3D-Engine verwendet werden soll. Sinnvoller ist: Welche Steuerungen hat die Maschine, 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.