Wie koppeln Sie Ihre SPS-Plattform an die virtuelle Inbetriebnahme?

Virtuelle Inbetriebnahme ist kein Produkt eines einzelnen Herstellers, sondern eine Arbeitsweise: Echte Steuerungslogik läuft gegen ein repräsentatives Maschinenmodell, bevor die Anlage vollständig verdrahtet ist. Welche Kopplungswege dabei praktikabel sind, bestimmt die vorhandene Steuerungsplattform: eine Soft-SPS auf dem Engineering-Arbeitsplatz, gespiegelte Ein- und Ausgänge in eine Simulationsschicht oder standardisierter Datenaustausch über OPC UA.

Kaum ein Maschinenbauer wechselt mitten im Projekt die SPS-Familie, nur um eine Simulationsfunktion zu bekommen. Die bessere Frage lautet: Wie koppeln Sie die vorhandene Steuerung an den geplanten Zwilling, ohne zwei parallele Variablenlisten zu pflegen, die nach der ersten Änderung an der Automatisierung auseinanderlaufen?

B&R, Beckhoff und Siemens sind im europäischen Sondermaschinenbau weit verbreitet. Alle drei Ökosysteme bieten ausgereifte Werkzeuge für die Logikentwicklung, die Tiefe der Kopplung an einen 3D-Zwilling unterscheidet sich jedoch. Manche Abläufe funktionieren reibungslos innerhalb der Werkzeugkette des Herstellers; andere brauchen eine explizite Brücke, sobald der visuelle Zwilling in Unity oder einer anderen Umgebung läuft.

Eine ehrliche Abgrenzung verringert späte Integrationsnacharbeit. Ein Projekt, das von Anfang an voll abgebildete Achsbewegungen voraussetzt, gerät ins Stocken, wenn die gewählte Kopplung zunächst nur digitale Ein- und Ausgänge unterstützt. Beginnen Sie bei dem, was Sie bei der Fabrikabnahme nachweisen müssen: Verriegelungen, Betriebsartenwechsel, Rezepturwechsel und Bewegungsabläufe, wo räumliches Verhalten zählt. Wählen Sie dann das Kopplungsmuster, das genau diese Risiken abdeckt, nicht das schönste Schaubild aus der Herstellerpräsentation.

B&R ist ein guter Ausgangspunkt für Teams, die Steuerungssoftware und ein testbares Maschinenmodell zusammenführen wollen. Automation Studio bündelt Logik, Visualisierung und Antriebstechnik in einer Werkzeugkette. Die Kopplung an einen externen Zwilling erfordert dennoch eine definierte Schnittstelle und eine geführte Signalzuordnung; Variablen lassen sich exportieren oder spiegeln, aber die Zuordnungsarbeit entfällt nicht.

Als Soft-SPS steht ARsim bereit: Das SPS-Programm läuft damit auf dem Engineering-Arbeitsplatz, sodass Sequenzen getestet werden können, bevor Schaltschränke gebaut sind. Kommt eine 3D-Ebene hinzu, arbeitet der digitale Zwilling mit denselben digitalen und analogen Signalen, die das SPS-Programm erwartet: Endlagen, Quittierungen, Betriebsarten-Bits und antriebsbezogene Statusworte. Die SPS-Anwendung kann in der Regel produktionsnah bleiben, die Integration braucht aber weiterhin Schnittstellenzuordnung und repräsentatives Maschinenverhalten.

Bewegungsintensive B&R-Anlagen profitieren, wenn der Zwilling die Achsstatussignale abbildet, die das Projekt tatsächlich nutzt: in Position, Fehler, referenziert und weitere Antriebs- oder Steuerungsbits, auf die die Sequenz wartet. Fotorealistische Grafik ist dafür nicht nötig. Um zu prüfen, ob eine Sequenz auf das richtige Statuswort wartet, braucht es dieselben Namen und Skalierungen wie im SPS-Projekt. Simulierte Safety-Statussignale können Sequenztests unterstützen; sie validieren nicht die Sicherheitsfunktion selbst.

Läuft der visuelle Zwilling außerhalb von Automation Studio, ist OPC UA die übliche Brücke: Die SPS-Seite stellt Knoten bereit, der Zwilling liest, schreibt oder abonniert sie mit vereinbarten Abtast- und Publish-Intervallen. Behandeln Sie OPC UA nicht als deterministischen Motion-Bus. B&R bringt mit dem Scene Viewer zwar ein eigenes 3D-Werkzeug mit, für die Kopplung an einen Unity-Zwilling ist er aber keine Voraussetzung. Dokumentieren Sie, welche Variablen verbindlich sind und welche im Zwilling nur Platzhalter für noch nicht modellierte Anlagenteile darstellen.

Eine praxisnahe Architektur koppelt eine B&R-Laufzeitumgebung über OPC UA an einen Unity-basierten Zwilling, damit Bediener den räumlichen Kontext sehen, während dieselben Verriegelungen in Software laufen. Das Muster funktioniert, solange jemand die Signalzuordnung als gepflegtes Arbeitsdokument verantwortet und bei jeder Änderung an I/O oder HMI aktualisiert.

Beckhoff TwinCAT ist im Sondermaschinenbau weit verbreitet, wo PC-basierte Steuerung und deterministische Ein- und Ausgänge zählen. Für die virtuelle Inbetriebnahme lässt sich der Steuerungscode in einer Software-Laufzeitumgebung auf dem Engineering-Arbeitsplatz ausführen, sodass Teams die Logik durchspielen können, bevor Hardware eintrifft. Das ist wertvoll für frühe Verriegelungstests und HMI-Betriebsarten.

Die Stärke von TwinCAT liegt in der engen Verzahnung von SPS, Antriebstechnik und I/O-Konfiguration in einem Projekt. Bei der Anbindung an einen externen 3D-Zwilling laufen die Prozessdaten typischerweise über ADS oder OPC UA, je nachdem, was die Simulationsschicht unterstützt. ADS ist schnell und in Beckhoff-geprägten Teams etabliert; OPC UA hilft, wenn mehrere Clients, darunter eine Unity-Laufzeitumgebung, dieselben Variablen benötigen.

Die Motion-Integration verdient eine klare Abgrenzung. TwinCAT-NC/PTP-Simulationsachsen unterstützen Achsbefehle und Sequenztests. Mechanische Kinematik, Kollisionen, Kabelführungen und reale Lose brauchen ein separates Modell. Halten Sie das im Testplan fest, damit FAT-Teilnehmer wissen, welche Verhaltensweisen virtuell nachgewiesen wurden.

Externe Projektbeteiligte können TwinCAT-Sitzungen mitverfolgen, wenn Laufzeitumgebung und Zwilling über einen stabilen Netzwerkpfad verbunden sind. Behandeln Sie solche Termine als Generalprobe für die Fabrikabnahme, nicht als Abnahme selbst. Protokollieren Sie Softwareversionen, den Typ der Laufzeitumgebung und welche Ein- und Ausgänge real oder simuliert waren.

Teams, die bereits auf Beckhoff standardisiert haben, sollten ihre bestehende Variablenbenennung früh in den Zwilling übernehmen. Umbenennungen an bereits gereifter Logik erzeugen stille Abweichungen, die in virtuellen Testläufen als falsche Freigaben auftauchen.

Siemens bietet ein breites Portfolio: TIA Portal, S7-PLCSIM und S7-PLCSIM Advanced für virtuelle Steuerungsinstanzen sowie Anbindungen an Simulationspartner. Für viele Maschinenbauer reicht SPS- und HMI-Simulation aus, um Logik, Alarme und Bedienbilder ohne 3D-Modell zu prüfen. Das ist wertvolle Vorarbeit vor der Inbetriebnahme. Zur virtuellen Inbetriebnahme wird es, wenn die Steuerung an ein repräsentatives Verhaltens- oder räumliches Maschinenmodell gekoppelt ist.

Die ehrliche Grenze liegt in der Kopplung an einen räumlichen Zwilling. Die Siemens-eigene Simulation ist stark bei SPS-zentrierten Tests. Wer Bediener-Sichtlinien, Freigangsprüfungen oder Roboterreichweite in derselben Sitzung wie S7-Logik braucht, ergänzt typischerweise eine Brücke: OPC UA, die S7-PLCSIM-Advanced-API oder Partnerwerkzeuge. Siemens-eigene mechanische Abläufe können NX Mechatronics Concept Designer nutzen. Planen Sie Integrationszeit ein; selten ist es ein einzelner Exportschritt.

S7-PLCSIM Advanced ergänzt unter anderem mehrere virtuelle Steuerungsinstanzen, TCP/IP-Kommunikation, eine offene Co-Simulations-API sowie breitere Unterstützung für S7-1500 und ET 200SP gegenüber dem Basis-S7-PLCSIM. OPC UA auf der Instanz braucht eine TCP/IP-Adapterkonfiguration, nicht Softbus allein. Mechanische Verifikation ersetzt es dennoch nicht. Nutzen Sie es für Sequenzlogik und Kommunikation zwischen Steuerungen auf einer Linie, und erweitern Sie die Abdeckung danach im 3D-Zwilling, wo räumliche Fehler entstehen.

Prüfen Sie unterstützte Betriebsumgebungen, Lizenzierung, virtuelle Netzadapter und lokale IT-Richtlinien vor der Integration. Dedizierte virtuelle Maschinen oder zentrale Lizenzierung sind standortspezifische Entscheidungen. Klären Sie Netz und Zugriffsregeln in Woche eins, nicht in der Woche vor der Kunden-Fabrikabnahme.

Hat Ihr Kunde auf Siemens standardisiert, stimmen Sie die Erwartungen ab: Virtuelle Inbetriebnahme mit Siemens-Werkzeugen plus einem Unity-Zwilling ist eine kombinierte Architektur, keine Funktion, die sich im Siemens-Katalog einfach ankreuzen lässt. Dokumentieren Sie, wer den Zwilling aktualisiert, wenn sich der Stand des TIA-Projekts ändert.

OPC UA ist die neutrale Schicht, wenn SPS-Werkzeugkette und 3D-Umgebung von unterschiedlichen Herstellern stammen. Statt projektspezifischer Schnittstellen veröffentlichen Sie einen strukturierten Adressraum: digitale Eingänge simulierter Sensoren, Ausgänge für Animationen, Analogwerte mit technischen Einheiten und Methodenaufrufe für seltene Aktionen wie Rücksetzen oder das Laden einer Rezeptur.

Gestalten Sie den Adressraum für die Inbetriebnahme, nicht für jedes interne Hilfsbit. Aufgeblähte Adressräume machen Clients träge und begünstigen Kopierfehler. Gruppieren Sie Signale nach Maschinenmodul: Zuführung, Prozessstation, Entnahme, Sicherheit und Versorgung. Spiegeln Sie diese Modulstruktur im SPS-Projekt, damit ein Zwillingsentwickler Modul für Modul zuordnen kann.

Sicherheit und Performance brauchen eine frühzeitige Vereinbarung. Verbindet sich der Zwilling nur lokal im Engineering-VLAN während der Entwicklung, oder abonnieren Remote-Teilnehmer während Kundenreviews? Nutzen Sie Zertifikate und Rollen, wo die IT-Richtlinien es verlangen. Vereinbaren Sie Abtast- und Publish-Intervalle: eine 3D-Szene braucht nicht für jeden Türsensor Millisekunden-Updates. Achsbefehle und -status können höhere Raten brauchen als diskrete Signale, harte Echtzeit-Servo-Kopplung gehört aber auf eine geeignete deterministische Schnittstelle, nicht allein auf OPC UA.

Versionieren Sie das OPC-UA-Informationsmodell zusammen mit den SPS-Ständen. Wird eine Variable in der SPS umbenannt, muss der Zwilling sichtbar fehlschlagen und darf nicht still veraltete Knoten lesen. Automatisierte Prüfungen, die exportierte Variablenlisten mit dem UA-Modell abgleichen, fangen solche Abweichungen früh ab.

OPC UA ersetzt keinen Testplan; es reduziert die Reibung zwischen Logik und Modell. Die Kriterien für bestanden und nicht bestanden stehen weiterhin in den Inbetriebnahmedokumenten und sind an dieselben Signale gebunden, die der UA-Server bereitstellt.

Software-in-the-Loop mit Soft-SPS ist für die frühe Integration üblich. Der Steuerungscode läuft auf dem Engineering-Arbeitsplatz oder einer VM, tauscht I/O mit dem Zwilling und iteriert schnell nach jeder Logikänderung. Je nach Modelltreue und Testumfang lassen sich viele Sequenz-, Alarm- und HMI-Tests auf dieser Ebene erledigen.

Hardware-in-the-Loop (HIL) bringt echte Steuerungen mit simulierten Ein- und Ausgängen ins Netzwerk. Sinnvoll ist das, wenn reale Steuerungsausführung, repräsentatives Netzwerkverhalten oder Hardwareschnittstellen vor der Fabrikabnahme zählen. HIL kostet mehr Aufbauzeit und Laborplatz und kann Probleme aufdecken, die eine Software-Laufzeitumgebung nicht reproduziert; endgültige Timing- und Safety-Validierung bleiben Aufgaben an der Hardware.

Hybride Projekte sind der Normalfall: Soft-SPS für die täglichen Entwicklungszyklen, HIL für Regressionstests, bevor der Kunde anreist. Der Zwilling sollte beides bedienen können, ohne dass Variablen von Grund auf neu zugeordnet werden müssen. Das setzt eine verbindliche Signalliste voraus, die von beiden Laufzeitumgebungen genutzt wird.

Wählen Sie HIL nicht, um einen Kunden zu beeindrucken, wenn die Nachweise bei der Fabrikabnahme vor allem Logik und räumliches Verhalten betreffen. Wählen Sie es, wenn Sie mit dem Zeitverhalten realer Hardware bereits schlechte Erfahrungen gemacht haben: PROFINET-Gerätefehler, Quittierungsabläufe zwischen Steuerungen oder Rückführkreise von Sicherheitsrelais, die sich nur mit echter Hardware im Regelkreis sinnvoll prüfen lassen.

Eine testbare Signalzuordnung ist das Arbeitsergebnis, das die Plattformwahl mit dem Nutzen einer virtuellen Fabrikabnahme verbindet. Exportieren Sie die Ein- und Ausgänge aus dem SPS-Projekt in einem Format, das Automatisierungs- und Zwillingsteam gleichermaßen akzeptieren: CSV, Hersteller-XML oder OPC-UA-Knotenlisten aus derselben Quelle. Parallele Tabellen, die nur per E-Mail kursieren, haben darin nichts verloren.

Verknüpfen Sie jedes Signal nach Möglichkeit mit einer Testanforderung. Wenn DI_ConveyorReady wahr sein muss, bevor der Ausgang M_ConveyorRun gesetzt wird, sollte der Zwilling diese Beziehung in automatisierten Testläufen protokollieren. Bauen Sie aus der Mängelliste Ihrer letzten Fabrikabnahme eine kleine Bibliothek solcher Anforderungen auf; genau so verdient sich virtuelle Inbetriebnahme Vertrauen.

Bilden Sie vor- und nachgelagerte Anlagen bewusst vereinfacht ab und kennzeichnen Sie das. Linien stehen selten isoliert. Simuliert der Zwilling etwa eine Verpackungsmaschine, markieren Sie, welche Quittierungsbits echte Kundensysteme abbilden und welche nur Platzhalter sind. Stimmen Sie diese Vereinfachungen mit dem Integrator ab, damit freigegebene virtuelle Testläufe nicht auf frei erfundenen Verriegelungen beruhen.

Denken Sie die Verbindung zur übergeordneten Strategie für den digitalen Zwilling mit. Dasselbe Unity-Modell, das B&R- oder Beckhoff-Signale über OPC UA liest, kann später Bedienerschulung und Servicedokumentation unterstützen, wenn Geometrie und Variablen gepflegt bleiben. Unsere Leitfäden zur virtuellen Inbetriebnahme und zum Unity Digital Twin zeigen das Gesamtbild.

Bevor Sie Kunden einladen, führen Sie eine Generalprobe mit denselben Rollen durch wie bei der Fabrikabnahme: SPS-Verantwortlicher, HMI-Bediener und Protokollführer für Abweichungen. Schließen Sie Lücken in der Zuordnung danach, nicht am Tag der FAT. Diese Probe zeigt, ob Plattform, Brücke und Zwilling als ein System funktionieren.