OPC UA (Open Platform Communications Unified Architecture) ist ein etablierter Standard für die industrielle Kommunikation. Besonders in der Maschinenvernetzung und der Automatisierung hat sich OPC UA fest etabliert. Doch wie passt dieser Standard in moderne Architekturen wie den Unified Namespace (UNS)? In diesem Artikel werfen wir einen praxisnahen Blick auf OPC UA im Unified Namespace, klären Stärken und Schwächen und zeigen, wo der Einsatz sinnvoll ist – und wo nicht.
Was ist OPC UA?
Open Platform Communications Unified Architecture (OPC UA) ist ein standardisiertes Kommunikationsprotokoll, das von der OPC Foundation entwickelt wurde. Seit seiner Einführung 2006 wurde es kontinuierlich erweitert und deckt heute eine Vielzahl industrieller Anforderungen ab. Die Kommunikation ist robust, herstellerunabhängig und flexibel. Deshalb wird OPC UA häufig zur Integration verschiedener Automatisierungskomponenten im ISA-95-Modell genutzt.
Aufbau der OPC UA Spezifikation
OPC UA weist mit über 1200 Seiten eine sehr umfangreiche Spezifikationen auf. Sie besteht aus einer Vielzahl an Teilstandards, die jeweils unterschiedliche Aspekte der industriellen Kommunikation abdecken (z.B. für den Datenzugriff). Diese Struktur zeigt, dass OPC UA weit mehr ist als nur ein Protokoll zur Datenübertragung: Es ist ein umfassendes Framework für industrielle Kommunikation.
Ein Großteil der Spezifikation ist optional, sodass je nach Anwendungsfall nur bestimmte Funktionen implementiert werden müssen. Die vollständige Umsetzung aller Spezifikationsteile wäre äußerst aufwendig und ist daher in der Praxis unüblich. Umso wichtiger ist es, bei der Anbindung von OPC-Servern und -Clients genau zu prüfen, welche Teile der Spezifikation tatsächlich unterstützt werden.
Client/Server Architektur
Im Kern basiert OPC UA auf einer Client/Server-Architektur. Ein Client fordert Daten vom Server an, der daraufhin antwortet. Diese direkte Kommunikation eignet sich besonders für Szenarien, in denen es auf niedrige Latenz und hohe Synchronität ankommt – etwa bei Steuerungs- und Regelprozessen. Viele Geräte können gleichzeitig als Client und Server fungieren, was die Flexibilität erhöht.
Umsetzung von OPC UA in der Praxis
In realen Industrieanlagen werden OPC UA Server meist direkt auf der Maschinensteuerung oder innerhalb eines Edge-Gateways implementiert.
- OPC UA Server auf der Steuerung: Die Integration direkt in der Steuerung (z. B. SPS oder HMI) ermöglicht eine schnelle, echtzeitnahe Bereitstellung von Prozessdaten ohne zusätzliche Hardware. Diese Lösung ist jedoch oft herstellerspezifisch, bietet eingeschränkte Konfigurationsmöglichkeiten und limitiert die Flexibilität bei der Datenmodellierung.
- OPC UA Server auf einem Gateway: Alternativ werden OPC UA Server in dedizierten Gateways betrieben, die über industrielle Schnittstellen mit der Maschine verbunden sind. Diese Architektur bietet mehr Freiheiten bei der Konfiguration, ermöglicht zusätzliche Verarbeitung (z. B. Mapping, Filtering) und erlaubt die Kombination mit anderen Protokollen. Allerdings entstehen dadurch zusätzliche Kosten und Integrationsaufwand.
Was ist OPC UA Pub/Sub?
OPC UA Publisher/Subscriber (Pub/Sub), Teil 14 der Spezifikation, wurde erstmals im Jahr 2017 als Ergänzung zum ursprünglichen Client/Server-basierten Kommunikationsmodell veröffentlicht. Pub/Sub adressiert insbesondere die Limitierung in der Skalierbarkeit des Client/Server Modelle und wurde entwickelt, um den wachsenden Bedarf an effizienten und leichtgewichtigen Kommunikationsmechanismen für IoT und Cloud-Anwendungen zu adressieren. Im Gegensatz zur synchronen Anfrage-Antwort-Kommunikation des Client/Server-Modells ermöglicht Pub/Sub die asynchrone Verteilung von Nachrichten von einem Publisher an viele Subscriber über einen Message Broker. Dies reduziert den Kommunikationsaufwand erheblich und verbessert die Skalierbarkeit und Flexibilität in großen Netzwerken.
Datenformate und Transportprotokolle in OPC UA Pub/Sub
OPC UA Pub/Sub unterscheidet zwischen zwei Hauptvarianten der Datenübertragung: UADP (Binary) über UDP und JSON über MQTT. UADP (Universal Architecture Datagram Protocol) ist für den Einsatz in echtzeitkritischen OT-Umgebungen konzipiert und ermöglicht extrem geringe Latenzen – allerdings ohne integrierte Empfangsbestätigung oder Fehlertoleranzmechanismen. Diese Variante erfordert ein präzise abgestimmtes Multicast-fähiges Netzwerk. JSON über MQTT hingegen adressiert primär IT-nahe Anwendungen: Es bietet höhere Interoperabilität, flexible Topic-Strukturen und zuverlässige Zustellung durch MQTT Quality-of-Service (QoS). Diese Kombination ist ideal für Cloud-Integration, Analyseanwendungen oder als Teil eines Unified Namespace.
Pub/Sub vs. Monitoring: Der entscheidende Unterschied
Ein häufiges Missverständnis ist die Gleichsetzung von OPC UA Pub/Sub (beschrieben in Teil 14 der Spezifikation) mit der Subskriptionsfunktion im klassischen OPC UA Client/Server-Modell. Dabei handelt es sich nicht um echte Publish/Subscribe-Kommunikation. Vielmehr basiert sie auf Polling: Der Client fragt den Server in festgelegten Intervallen aktiv ab – eine synchrone und eng gekoppelte Kommunikation. OPC UA Pub/Sub hingegen ist ereignisgesteuert und entkoppelt. Genau diese Eigenschaften machen es zu einem entscheidenden Baustein für skalierbare Architekturen wie den Unified Namespace.
Sicherheit in OPC UA: Flexibel, aber fehleranfällig
Im Kontrast zu anderen Anwendungen ist die Implementierung von Sicherheitsmaßnahmen in OPC UA nicht zwangsläufig erforderlich. Das bedeutet, dass die Kommunikation auch ohne Sicherheitsvorkehrungen erfolgen kann. Die Gewährleistung eines sicheren Datenaustauschs mittels OPC UA hängt von der korrekten Konfiguration von Servern und Clients ab. Dabei können Sicherheitsmechanismen flexibel kombiniert werden, wodurch OPC UA in unterschiedlichen Szenarien anwendbar ist. Allerdings ergeben sich durch diese Flexibilität in der Praxis häufig enorme Sicherheitslücken.
Sicherheitslücken durch Komplexität
OPC UA bietet umfangreiche Sicherheitsfunktionen – darunter Verschlüsselung, Authentifizierung und Benutzerrechteverwaltung. In der Praxis stellt jedoch vor allem das Zertifikatsmanagement eine Herausforderung dar. Viele Systeme erfordern manuelles Einrichten von Trust Stores, was bei größeren Installationen schnell unübersichtlich und fehleranfällig wird. Zudem bestehen oft Kompatibilitätsprobleme zwischen verschiedenen OPC UA-Stacks, etwa bei der Unterstützung bestimmter Sicherheitsrichtlinien oder Token-Typen.
Drei Ebenen der OPC UA Sicherheit
OPC UA verfolgt einen ganzheitlichen Sicherheitsansatz, der auf drei Ebenen greift: Benutzersicherheit, Anwendungssicherheit und Transportsicherheit. Jede Ebene trägt dazu bei, Daten und Kommunikation zuverlässig vor unbefugtem Zugriff, Manipulation und Verlust zu schützen.
Benutzersicherheit
OPC UA ermöglicht Benutzersicherheit durch die Implementierung verschiedener Sicherheitsfunktionen:
- Benutzeridentitäts-Token: OPC UA unterstützt unterschiedliche Methoden der Benutzerauthentifizierung für Endpunkte. Dazu gehören Anonym, Benutzername & Passwort sowie Zertifikat.
- Sicherheitsmodi: Verschiedene Sicherheitsmodi wie „Keine“, „Signieren“ und „Signieren & Verschlüsseln“ stehen zur Verfügung. Diese Modi bestimmen, wie Authentifizierung, Vertraulichkeit und Integrität in den Nachrichtenaustausch integriert werden.
- Sicherheitsrichtlinien: Diese legen die kryptografischen Verfahren für jeden Sicherheitsmodus fest.
Anwendungssicherheit
OPC UA ermöglicht Anwendungssicherheit durch folgende Funktionen:
- Verschiedene Endpunkte: Im Rahmen eines sicheren Client-Server-Verbindungsaufbaus stellt der Server verschiedene Endpunkte bereit. Jeder Endpunkt ist durch Sicherheitsmodi, Sicherheitsrichtlinien und unterstützte Benutzeridentitäts-Token definiert.
- Sicherheitsmodi: Die Sicherheitsmodi bestimmen die Authentifizierung, Vertraulichkeit und Integrität im Nachrichtenaustausch zwischen Client und Server. Dazu gehören Modi wie „None“ (Keine Sicherheit), „Sign“ (Signieren) und „Sign & Encrypt“ (Signieren und Verschlüsseln).
- Richtlinien für Sicherheitsmaßnahmen: Sicherheitsrichtlinien legen die kryptografischen Verfahren für jeden Sicherheitsmodus fest. Dadurch wird die Art und Weise definiert, wie die Sicherheitsziele im spezifischen Sicherheitsmodus erreicht werden.
Transportsicherheit
OPC UA ermöglicht Transportsicherheit durch verschiedene Mechanismen:
- Kommunikationsstrategien: OPC UA bietet zwei Kommunikationsstrategien – Client/Server und Publisher/Subscriber. Beide ermöglichen es, Nachrichten zu signieren und zu verschlüsseln, um Authentizität und Vertraulichkeit zu gewährleisten.
- Sicherheitsmodi: OPC UA definiert verschiedene Sicherheitsmodi, darunter „Keine“, „Signieren“ und „Signieren & Verschlüsseln“. Diese Modi bestimmen, wie die Nachrichten ausgetauscht werden, um Authentifizierung, Vertraulichkeit und Integrität sicherzustellen.
- Sicherheitsrichtlinien: Die Sicherheitsrichtlinien legen die kryptografischen Verfahren für jeden Sicherheitsmodus fest.
Vor- und Nachteile von OPC UA
OPC UA ist ideal für Anwendungen mit komplexen Kommunikationsanforderungen in der OT geeignet. Allerdings ist die Praktikabilität des Standard aufgrund der jahrzehntelang gewachsenen Spezifikationen und der daraus gewachsenen technischen Schuld eingeschränkt. Im Folgenden sind die wichtigsten Punkte zusammengefasst.
Vorteile
- Hochkomplexe Datenstrukturen: Der Standard ermöglicht die Übertragung und Verwaltung von hochkomplexen Datenstrukturen, einschließlich hierarchischer Datenstrukturen. Dies ist besonders nützlich in industriellen Systemen, in denen die Daten oft komplex und hierarchisch organisiert sind.
- Sichere Kommunikation: OPC UA bietet eine robuste Sicherheitsschicht, die Verschlüsselung und Authentifizierung umfasst. Dies gewährleistet, dass Daten sicher übertragen werden und dass nur autorisierte Benutzer und Systeme auf die Informationen zugreifen können.
- Zuverlässige und vorhersagbare Kommunikation: Der Standard stellt sicher, dass die Kommunikation zwischen Geräten zuverlässig und vorhersagbar ist. Dies bedeutet, dass Daten in Echtzeit übertragen werden können, ohne dass es zu unerwarteten Verzögerungen oder Verlusten kommt.
- High-Level-Dienste: OPC UA bietet High-Level-Dienste, darunter Ereignisbenachrichtigungen und komplexe Methodenaufrufe. Dies ermöglicht fortgeschrittene Funktionen wie das Senden von Benachrichtigungen über Zustandsänderungen und das Auslösen von Aktionen.
Nachteile
- Interoperabilität: Obwohl die Norm auf Interoperabilität abzielt, treten in der Realität Probleme auf. Denn aufgrund der hohen Anzahl an alternativen Spezifikationen und Implementierungen, werden typischerweise verschiedene Teile, und Versionen des Standards in Systemen verwendet. Zwei Systeme sind daher nur mit sehr viel Glück wirklich interoperabel.
- Komplexität: OPC UA ist ein umfassendes und komplexes Kommunikationsprotokoll. Die Implementierung und Konfiguration können zeitaufwändig sein, auch wenn die allermeisten Systeme lediglich einen kleinen Teil des Standards nutzen. Aufgrund dieser Komplexität beschränkt sich der Einsatz von OPC UA oft auf Level 0-2 (siehe RAMI 4.0 oben), da Protokolle wie MQTT die Kommunikationsanforderungen der höheren Ebenen (z.B. leichtgewichtig) deutlich besser erfüllen.
- Overhead: Aufgrund der umfassenden Funktionalität und Sicherheitsmerkmale kann der Standard einen Overhead bei der Kommunikation erzeugen (teilw. über 95%). Dies wird insbesondere im Vergleich zu leichtgewichtigeren Protokollen deutlich und wirkt sich auf die Skalierbarkeit aus. Der Standard hat bereits mit der Ergänzung von OPC UA Pub/Sub auf dieses Problem reagiert.
OPC UA im Unified Namespace (UNS): Rolle und Einordnung
OPC UA ist ein bewährter Standard für die Kommunikation auf der Fertigungs- und Steuerungsebene. Als Schnittstelle zwischen Maschinen, SPSen und lokalen Systemen ermöglicht OPC UA eine strukturierte, sichere und herstellerunabhängige Datenübertragung. Für die Anbindung an übergeordnete IT-Systeme oder Cloud-Plattformen stößt der Standard jedoch an Grenzen – insbesondere bei Skalierbarkeit, Flexibilität und Kommunikationsparadigma. Moderne Industriearchitekturen setzen daher zunehmend auf leichte, pub/sub-basierte Protokolle wie MQTT. Diese eignen sich deutlich besser für große, heterogene Netzwerke. Besonders in Kombination mit dem Unified Namespace (UNS) hat sich MQTT als skalierbarer, entkoppelter Kommunikationslayer etabliert.
In dieser Architektur übernimmt OPC UA im Unified Namespace nicht die Rolle des zentralen Kommunikationsbackbones, sondern fungiert als zuverlässige Datenquelle. Es liefert strukturierte und kontextualisierte Informationen aus der OT-Ebene, die über MQTT in Echtzeit weiterverarbeitet werden können. Mehr zu den Unterschieden OPC UA vs. MQTT finden Sie hier.
Was ist der Unified Namespace (UNS)
Der Unified Namespace (UNS) ist ein zentrales Architekturprinzip für moderne industrielle Dateninfrastrukturen. Dabei handelt es sich um einen zeitnahen, kontextualisierten Informationsraum, der typischerweise auf einem MQTT Broker basiert. Im UNS werden alle relevanten Daten – von Maschinenwerten bis zu Geschäftsprozessen – in einem gemeinsam zugänglichen Topic-Tree organisiert. So entsteht ein digitaler Zwilling der gesamten Produktionsumgebung, der von allen Systemen gelesen und beschrieben werden kann.
Einsatzbereiche von OPC UA vs. MQTT
Mit seinen Eigenschaften zielt OPC UA hauptsächlich darauf ab, die nahtlose Steuerung von Prozessen in einem lokalen Netzwerk zu ermöglichen. Im Kontext des RAMI 4.0-Modells wird OPC UA typischerweise auf den Ebenen „Feldgerät“ (Level 0), „Steuerung“ (Level 1) und „Station“ bzw. „Überwachung“ (Level 2) eingesetzt.
In diesen Ebenen übernimmt OPC UA eine zentrale Rolle für die standardisierte, herstellerunabhängige Kommunikation zwischen Sensoren, Aktoren, SPSen und übergeordneten Steuerungseinheiten. Die Kommunikation erfolgt in der Regel über eine Client/Server-Architektur mit direktem synchronem Datenabruf. Ein Beispiel hierfür ist die Anforderung von Daten durch eine SPS (Client) von einer zentralen SPS oder Liniensteuerung (Server), die anschließend die verarbeiteten Daten, wie Befehle (Server), an einen Roboter (Client) sendet. Im Kontext des Unified Namespace dient OPC UA in dieser Systemarchitektur als zuverlässige Datenquelle. Dabei stellt OPC UA strukturierte, semantisch angereicherte Informationen im UNS bereit – etwa Messwerte, Maschinenstatus oder Alarme. Diese werden über MQTT an weiterführende Anwendungen auf höheren Ebenen (z. B. MES, ERP oder Analytics) weitergeleitet.
Integration von OPC UA im Unified Namespace (UNS)
Die Integration von OPC UA im Unified Namespace kann auf zwei Wegen erfolgen. Eine detailliertere Schritt-für-Schritt Anleitung finden Sie hier.
Option 1: Direkte Integration über OPC UA Pub/Sub
In dieser Variante senden OPC UA Server ihre Daten direkt im Publisher/Subscriber-Modell – typischerweise über MQTT oder UDP – an einen Broker. Damit entfällt die klassische Client/Server-Kommunikation, und die Daten werden asynchron im Netzwerk verteilt.
Vorteile:
- Keine zusätzliche Middleware erforderlich
- Asynchrone Kommunikation direkt aus dem OPC UA Stack
- Weniger Latenz bei nativer Unterstützung
Nachteile:
- Geringe Verbreitung und Unterstützung durch Hersteller
- Unterschiedliche Implementierungen führen zu Interoperabilitätsproblemen
- Keine zentrale Datenanreicherung und Mapping-Funktionalitäten
Option 2: Integration über Gateways wie i-flow Edge
In dieser Variante fungieren Gateways wie i-flow Edge als Konnektor zwischen OPC UA Servern und dem MQTT-basierten Unified Namespace. Dabei übernimmt i-flow die Datenabfrage, Transformation, Kontextanreicherung und Veröffentlichung der Nachricht in MQTT Topics.
Vorteile:
- Einheitliches MQTT-Publishing unabhängig von OPC UA-Implementierung
- Zentrale Verwaltung von Topic-Struktur, QoS und Payload-Formaten
- Kontextualisierung und Anreicherung von OPC UA-Daten möglich
Nachteile:
- Erfordert zusätzlichen Infrastrukturaufwand
- Latenz leicht höher durch Polling Mechanismus sowie zusätzlicher Middleware
Beide Ansätze ermöglichen es, OPC UA Daten in den Unified Namespace (UNS) zu integrieren. Dabei bietet der Einsatz von i-flow zusätzlich den Vorteil zentraler unternehmensweiter Datenstandardisierung. Dies ist besonders in heterogenen Umgebungen mit vielen OPC UA Quellen sinnvoll.
Fazit: OPC UA im Unified Namespace gezielt einsetzen
OPC UA im Unified Namespace bietet ein starkes Fundament für die strukturierte und sichere Datenbereitstellung aus der OT-Welt. Der Standard überzeugt durch seine Robustheit, Flexibilität und breite Unterstützung auf Maschinen- und Steuerungsebene. Gleichzeitig stößt OPC UA bei Skalierung, Interoperabilität und Cloud-Anbindung an Grenzen. Genau hier bietet der Unified Namespace, basierend auf MQTT, einen modernen, entkoppelten Lösungsansatz. Die Kombination beider Technologien spielt ihre Stärken besonders im Zusammenspiel aus: OPC UA als zuverlässige, kontextualisierte Datenquelle – MQTT als skalierbares Kommunikations-Backbone zwischen IT und OT. Ob direkt per Pub/Sub oder über Gateways wie i-flow Edge – die Integration von OPC UA in den Unified Namespace schafft einen durchgängigen, herstellerneutralen Datenfluss über alle Ebenen der Industriearchitektur hinweg.
Wer eine zukunftssichere OT/IT-Integration anstrebt, sollte OPC UA im Unified Namespace nicht nur als Option sehen – sondern als essenziellen Baustein moderner industrieller Dateninfrastrukturen.
