In modernen Produktionsanlagen müssen Steuerungen unterschiedlichster Hersteller, SCADA-Systeme, MES-Ebenen und Cloud-Backends miteinander kommunizieren — und das zuverlässig, sicher und ohne proprietäre Zwischenschichten. Genau hier setzt OPC Unified Architecture, kurz OPC UA, an. Der von der OPC Foundation entwickelte und in der Normenreihe IEC 62541 standardisierte Rahmen gilt heute als das de-facto-Rückgrat der vertikalen und horizontalen Datenkommunikation in der Industrie 4.0. Anders als ältere Feldbussysteme transportiert OPC UA nicht nur Rohwerte, sondern beschreibt Daten mit Kontext, Semantik und Metainformationen — ein entscheidender Unterschied für durchgängige Automatisierungslösungen.
Für SPS-Entwickler und Steuerungsingenieure stellt sich die Frage, wie OPC UA konkret in Steuerungsprojekte integriert wird, welche Architekturvarianten existieren und worauf bei Auswahl und Implementierung zu achten ist. Die folgenden Abschnitte geben einen kompakten, praxisorientierten Überblick.
Was OPC UA von klassischen Feldbussen unterscheidet
Klassische Feldbussysteme wie PROFIBUS, CANopen oder ältere Ethernet-basierte Protokolle wurden primär für den zyklischen Echtzeitaustausch von Prozessdaten zwischen Feldgeräten und einer übergeordneten SPS konzipiert. Sie sind auf deterministische Übertragungszeiten optimiert, transportieren aber in der Regel nur Rohwerte ohne eingebettete Bedeutungsbeschreibung. Wer aus einem EtherCAT-Frame einen Temperaturwert liest, erfährt aus dem Protokoll allein weder die physikalische Einheit noch den Messpunkt noch den zulässigen Wertebereich.
OPC UA hingegen trennt bewusst zwischen dem Transportmechanismus und dem Informationsmodell. Das Protokoll kann über TCP/IP, HTTPS oder — mit OPC UA PubSub — über MQTT und AMQP betrieben werden. Das eigentliche Unterscheidungsmerkmal ist der Adressraum: Jeder OPC-UA-Server stellt einen strukturierten Baum aus Knoten bereit, in dem Variablen, Methoden, Ereignisse und Objekte mit Typinformationen, Einheiten, Timestamps und Zustandsinformationen versehen sind. Ein lesender Client empfängt damit nicht nur einen Zahlenwert, sondern ein vollständiges, selbstbeschreibendes Datenelement.
Das Informationsmodell: Adressraum, Knoten und Companion Specifications
Der OPC-UA-Adressraum ist objektorientiert aufgebaut. Grundlegende Einheiten sind Knoten (Nodes), die über typisierte Referenzen miteinander verbunden werden. Node-Klassen umfassen unter anderem Variablen (Variable), Objekte (Object), Methoden (Method) und Datentypen (DataType). Jeder Knoten besitzt Attribute wie NodeId, BrowseName, DisplayName und Description. Über den Mechanismus der Typdefinition lassen sich domänenspezifische Strukturen modellieren, die weit über einfache Tagpoint-Listen hinausgehen.
Für spezifische Branchen und Geräteklassen existieren sogenannte Companion Specifications — standardisierte Erweiterungen des Basisinformationsmodells. Die OPC UA for Machinery (Part 1–n), OPC UA for Robotics oder OPC UA for PackML definieren, wie Maschinenzustände, Achsdaten oder Produktionsaufträge einheitlich abzubilden sind. Steuert eine SPS eine Verpackungsmaschine, kann der OPC-UA-Server dieser Steuerung das PackML-Zustandsmodell direkt im Adressraum abbilden — MES-Systeme anderer Hersteller können diese Information dann ohne kundenspezifische Mapping-Tabellen konsumieren.
Client-Server- und PubSub-Architektur im Steuerungskontext
OPC UA unterstützt zwei grundlegende Kommunikationsparadigmen. Im klassischen Client-Server-Modell baut ein Client eine gesicherte Session zum Server auf, abonniert Datenpunkte über sogenannte Subscriptions mit konfigurierbaren Publish-Intervallen und empfängt bei Wertänderungen Notifications. Dieses Modell eignet sich besonders für SCADA- und MES-Anbindungen, bei denen eine SPS als Server fungiert und übergeordnete Systeme als Clients die Prozessdaten abfragen.
Mit OPC UA PubSub, das in IEC 62541 Part 14 spezifiziert ist, kam ein zweites Paradigma hinzu, das ohne direkte Verbindung zwischen Produzent und Konsument auskommt. Eine SPS veröffentlicht Datenpakete (DataSetMessages) über einen Message-Broker wie MQTT oder über UDP-Multicast, beliebig viele Empfänger können diese Nachrichten konsumieren. Dieses Modell reduziert den Verbindungsaufwand in größeren Anlagen erheblich und passt gut zu Cloud- und IIoT-Architekturen, in denen viele Datenproduzenten auf asynchronen Kanälen publizieren.
Für die SPS-Integration bedeutet dies: Bei der Auswahl einer Steuerungsplattform sollte geprüft werden, ob der Hersteller sowohl einen nativen OPC-UA-Server (für SCADA-Anbindung) als auch OPC-UA-PubSub-Publisher (für Cloud- und Edge-Szenarien) direkt in der Runtime oder als zertifizierte Zusatzkomponente bereitstellt. Die Implementierung über externe Gateway-Hardware ist zwar möglich, erhöht jedoch Latenz, Komplexität und Wartungsaufwand.
Sicherheitsmechanismen: Zertifikate, Signaturen und Verschlüsselung
OPC UA integriert Sicherheitsmechanismen auf Protokollebene, was es von vielen älteren industriellen Protokollen grundlegend unterscheidet. Jede Client-Server-Verbindung wird über einen Security Channel abgesichert, der auf dem Austausch von X.509-Zertifikaten basiert. Drei Security Modes stehen zur Verfügung: None (kein Schutz, nur für Testumgebungen geeignet), Sign (Nachrichtensignierung zur Integritätsprüfung) und SignAndEncrypt (Signierung plus AES-Verschlüsselung der Nutzdaten). Ergänzend regeln User-Authentifizierungsmechanismen — Anonymous, Username/Password oder Zertifikat — welche Clients auf welche Datenpunkte zugreifen dürfen.
In der Praxis bedeutet der Zertifikatsbasierte Ansatz, dass jede SPS ein eigenes Zertifikat benötigt, das von einer internen oder externen Certificate Authority signiert ist. Der Verwaltungsaufwand steigt mit der Anlagenanzahl, weshalb für größere Installationen ein dediziertes Certificate Management System empfohlen wird. Die OPC Foundation hat hierfür das Global Discovery Server-Konzept (GDS) spezifiziert, das automatisiertes Zertifikats-Enrollment und -Renewal ermöglicht.
Integration in SPS-Projekte: Vorgehensweise und typische Fallstricke
Beim Einsatz von OPC UA in SPS-Projekten bewährt sich ein strukturierter Ansatz. Zunächst wird das Informationsmodell spezifiziert: Welche Variablen, Objekte und Methoden soll der Server bereitstellen? Welche Companion Specification ist relevant? Erst dann folgt die Konfiguration oder Implementierung in der SPS-Umgebung. Viele moderne SPS-Plattformen generieren den OPC-UA-Adressraum automatisch aus dem vorhandenen Variablen-Deklarationsbereich, bieten aber auch manuelle Kontrolle über Node-Klassen und Zugriffsrechte.
Ein häufiger Fallstrick ist die unreflektierte Exposition des gesamten SPS-Adressraums als OPC-UA-Adressraum. Das führt einerseits zu unübersichtlichen Strukturen für Client-Entwickler, andererseits zu unnötigen Sicherheitsrisiken. Besser ist ein selektives Mapping: Nur die für den jeweiligen Anwendungsfall relevanten Datenpunkte werden im OPC-UA-Server exponiert, versehen mit sprechenden Namen und Typbeschreibungen gemäß der jeweiligen Companion Specification.
Performanceaspekte sind ebenfalls zu beachten. OPC-UA-Stack und SPS-Laufzeitsystem teilen sich Rechenressourcen. Bei leistungsschwachen Steuerungen kann ein schlecht dimensionierter OPC-UA-Server die Zykluszeit der eigentlichen Automatisierungsapplikation beeinflussen. Hersteller empfehlen in der Regel, OPC-UA-Publish-Intervalle deutlich größer zu wählen als den SPS-Zyklus — typischerweise 100 ms bis 1 s für Monitoring-Zwecke — und echtzeitkritische Steuerungsfunktionen vollständig davon zu entkoppeln.
Ausblick: OPC UA TSN und die Konvergenz von Echtzeit und IT-Kommunikation
Mit der Kombination aus OPC UA und Time-Sensitive Networking (TSN) nach IEEE 802.1 zeichnet sich eine Entwicklung ab, die die bisherige strikte Trennung zwischen deterministischer Feldkommunikation und IT-orientierter Datenkommunikation aufhebt. OPC UA over TSN verspricht, sowohl harte Echtzeitanforderungen als auch semantisch reichhaltige Kommunikation auf demselben Ethernet-Netz zu ermöglichen — ohne parallele Netzwerkinfrastruktur für Feldbus und Office-IT.
Für die Steuerungstechnik bedeutet das mittelfristig, dass SPS-Plattformen zunehmend mit TSN-fähigen Ethernet-Schnittstellen ausgestattet werden und OPC UA als einheitliches Kommunikationsprotokoll von der Feldebene bis in die Cloud durchgängig genutzt werden kann. Bis zur breiten Marktdurchdringung sind jedoch noch Interoperabilitätsfragen zwischen verschiedenen TSN-Profilen zu lösen. Steuerungsingenieure, die heute OPC UA in ihren Projekten verankern, legen damit eine Kommunikationsbasis, die für diese nächste Evolutionsstufe industrieller Vernetzung offen ist.
