In heterogenen Produktionsumgebungen kommunizieren Steuerungen, Antriebe, Sensoren und übergeordnete IT-Systeme häufig über unterschiedliche, proprietäre Protokolle miteinander. Die daraus resultierenden Medienbrüche und Integrationshürden sind ein zentrales Hemmnis auf dem Weg zur vernetzten Fabrik. OPC UA — ausgeschrieben OPC Unified Architecture — adressiert genau dieses Problem: Der von der OPC Foundation definierte Standard beschreibt sowohl ein Transportprotokoll als auch ein semantisches Informationsmodell und ermöglicht damit eine einheitliche, sichere und plattformunabhängige Datenkommunikation über alle Automatisierungsebenen hinweg.
OPC UA ist nicht die Weiterentwicklung eines einzelnen klassischen OPC-Standards, sondern die Konsolidierung mehrerer früherer Spezifikationen — OPC DA, OPC HDA und OPC A&E — in einer einzigen, konsistenten Architektur. Seit der ersten Veröffentlichung im Jahr 2008 (IEC 62541) hat der Standard erheblich an Reife gewonnen und ist heute in nahezu allen Bereichen der Automatisierungstechnik präsent.
Schichtenmodell: Transport, Session und Informationsmodell
OPC UA basiert auf einem mehrschichtigen Architekturmodell. Auf der untersten Ebene stehen die Transportmechanismen: Das klassische Binary TCP-Protokoll (opc.tcp) bietet geringe Latenz und hohen Durchsatz für lokale Netzwerke. Als Alternative ist HTTPS als Transport definiert, was den Einsatz hinter Firewalls erleichtert. Ergänzend dazu existiert seit der Erweiterung durch OPC UA Part 14 (Publish/Subscribe) ein nachrichtenorientierter Ansatz auf Basis von MQTT oder AMQP, der für Cloud-Anbindungen und breitere IIoT-Szenarien geeignet ist.
Oberhalb des Transports definiert OPC UA eine Session-Schicht, die Verbindungsmanagement, Authentifizierung und Verschlüsselung regelt. Die eigentliche Stärke des Standards liegt jedoch im objektorientierten Informationsmodell: Jeder Datenpunkt, jede Methode und jede Ereignisquelle wird als typisierter Knoten (Node) in einem gerichteten Graphen — dem sogenannten Adressraum — abgebildet. Clients können diesen Adressraum zur Laufzeit durchsuchen (Browsing), ohne vorab über die Struktur informiert zu sein. Dieses Prinzip wird als Self-Description bezeichnet und ist ein wesentlicher Vorteil gegenüber einfacheren Protokollen wie Modbus oder klassischem PROFIBUS.
Client-Server und Publish/Subscribe: zwei Kommunikationsparadigmen
Das klassische OPC-UA-Kommunikationsmuster ist Client-Server: Ein Client baut eine Session zum Server auf, liest oder schreibt Datenpunkte oder abonniert sie über sogenannte Subscriptions mit konfigurierbaren Publishing-Intervallen. Dieses Modell eignet sich für Szenarien, in denen ein übergeordnetes System — etwa ein SCADA oder ein MES — gezielt Daten von einer Steuerung abruft oder Sollwerte schreibt.
Für viele IIoT- und Industrie-4.0-Architekturen ist das Client-Server-Modell jedoch zu starr. Hier kommt OPC UA Publish/Subscribe (PubSub) ins Spiel. Bei PubSub sendet ein Publisher Datennachrichten an einen Broker oder direkt per UDP-Multicast, ohne dass eine dedizierte Session zu jedem Empfänger aufgebaut werden muss. Subscriber empfangen nur die Nachrichten, für die sie sich registriert haben. Dieses Modell skaliert deutlich besser in großen, verteilten Umgebungen und ist die Grundlage für den Einsatz von OPC UA in Verbindung mit Cloud-Plattformen und Edge-Systemen.
Companion Specifications: semantische Interoperabilität auf Domänenebene
Ein generisches Informationsmodell allein reicht für domänenspezifische Interoperabilität nicht aus. Deshalb entwickelt die OPC Foundation gemeinsam mit Branchenverbänden und Konsortien sogenannte Companion Specifications — standardisierte Erweiterungen des Basismodells für spezifische Geräteklassen oder Branchen. Bekannte Beispiele sind OPC UA for Machinery (umati), OPC UA for Robotics (OPC UA Companion Specification for Robotics, basierend auf dem VDMA-Einheitsblatt), OPC UA for PackML oder OPC UA for PLC Open.
Diese Companion Specifications definieren einheitliche Datentypen, Objektstrukturen und Methodenaufrufe für Werkzeugmaschinen, Roboter, Verpackungsmaschinen oder Antriebe. Ein MES kann damit ohne gerätespezifische Anpassung auf normierte Zustandsdaten einer Vielzahl von Maschinen unterschiedlicher Hersteller zugreifen — vorausgesetzt, beide Seiten implementieren dieselbe Companion Specification korrekt. Die praktische Interoperabilität hängt dabei stark von der Konformität der jeweiligen Implementierung ab, was Zertifizierungsprogramme der OPC Foundation adressieren.
Sicherheitsmechanismen: Authentifizierung, Verschlüsselung und Zertifikate
OPC UA integriert Sicherheit als festen Bestandteil der Spezifikation, nicht als nachträgliche Ergänzung. Drei Security Modes stehen zur Verfügung: None (ungesichert, nur für isolierte Testumgebungen), Sign (signierte Nachrichten zur Integritätsprüfung) sowie Sign & Encrypt (Signatur und Verschlüsselung). Die Authentifizierung erfolgt über X.509-Zertifikate, Benutzername/Passwort oder Tokens. Jede OPC-UA-Verbindung wird durch ein Sicherheitsprofil — den sogenannten Security Policy — parametriert, der Algorithmen für Signatur und Verschlüsselung festlegt.
In der Praxis stellt das Zertifikatsmanagement eine der größten Hürden dar. In großen Anlagen mit vielen OPC-UA-fähigen Geräten müssen Zertifikate ausgerollt, verwaltet und bei Ablauf erneuert werden. Hierfür existieren Lösungsansätze wie das Global Discovery Server (GDS)-Konzept, das eine zentrale Zertifikatsverwaltung ermöglicht. Dennoch sollte das Thema PKI-Infrastruktur bei der Projektplanung frühzeitig berücksichtigt werden.
OPC UA in der Praxis: von der SPS bis zur Edge
Die Implementierungsszenarien von OPC UA sind vielfältig. Auf SPS-Ebene stellen viele Steuerungshersteller heute OPC-UA-Server als integrierten Bestandteil der Firmware bereit. Damit entfällt ein separater Gateway-Rechner für die Datenanbindung an SCADA- oder MES-Systeme. Für ältere Steuerungen ohne native OPC-UA-Unterstützung kommen Software-Gateways oder dedizierte Hardware-Gateways zum Einsatz, die bestehende Protokolle — etwa PROFIBUS DP, Modbus RTU oder proprietäre Herstellerprotokolle — in OPC-UA-Strukturen übersetzen.
Edge-Computing-Plattformen spielen eine zunehmend wichtige Rolle: Sie aggregieren OPC-UA-Daten aus mehreren Quellen, führen lokale Vorverarbeitung durch und leiten relevante Informationen weiter — entweder an ein übergeordnetes MES oder über OPC UA PubSub per MQTT an eine Cloud-Plattform. Die Trennung zwischen Echtzeit-Kommunikation auf Feldebene (klassisches Client-Server-OPC UA) und asynchroner Cloud-Kommunikation (PubSub/MQTT) hat sich dabei als praxistaugliches Architekturmuster bewährt.
Bei der Auswahl und Implementierung von OPC UA sollten Anwender auf Konformitätstests achten, die OPC Foundation bietet entsprechende Zertifizierungsprogramme an. Leistungsparameter wie maximale Session-Anzahl, Subscription-Kapazität und Publish-Intervalle variieren je nach Implementierung erheblich und sollten im Lastenheft spezifiziert werden. Langfristig zeichnet sich ab, dass OPC UA — insbesondere in Verbindung mit TSN (Time-Sensitive Networking) auf Ethernet-Ebene — auch für zeitkritische Steuerungsaufgaben relevant wird, was die Konvergenz von IT- und OT-Netzwerken weiter vorantreiben dürfte.
