OPC UA – Anwendungsgebiet und Grenzen des Standards

Die Open Platform Communications Unified Architecture (OPC UA) hat sich als ein zentraler Kommunikationsstandard in der Industrie etabliert. Insbesondere in der Maschinenvernetzung und -anbindung ist der Standard nicht mehr wegzudenken. Dieser Artikel bietet einen Einblick in die Stärken und Schwächen von OPC UA und zeigt das Anwendungsgebiet und die Grenzen des Standards auf.

Was ist OPC UA?

Open Platform Communications Unified Architecture (OPC UA) ist eine Sammlung vielfältiger Spezifikationen zur Standardisierung der industriellen Kommunikation. OPC UA wurde im Herbst 2006 als neueste Generation der Spezifikationen der OPC Foundation veröffentlicht und seitdem stetig erweitert. Der einheitliche Kommunikationsstandard findet dank seiner Vorteile wie Robustheit und Herstellerunabhängigkeit Einsatz zwischen mehreren Ebenen des ISA95-Modells.

Eine Vielfalt an Spezifikationen

Die OPC UA Standard besteht aus einer Vielfalt an Spezifikationen, von denen jede eine spezifische Teilfunktion (z.B. für den Datenzugriff) beschreibt. Nicht alle Spezifikationen müssen von OPC-Servern und -Clients unterstützt werden. Die umfassende Implementierung sämtlicher Spezifikationen wäre tatsächlich äußerst zeit- und ressourcenintensiv, was daher auch nicht der gängigen Praxis entspricht. Vielmehr ist es entscheidend, je nach Anwendungsfall nur die relevanten Spezifikationen zu programmieren. Für die Anbindung von OPC-Servern und -Clients ist es wiederum wichtig zu wissen, welche Spezifikationen in den Servern und Clients tatsächlich umgesetzt sind.

OPC UA – Anwendungsgebiet in der OT/IT Integration

OPC UA ermöglicht eine nahtlose Kommunikation zwischen der Fertigungs- (Level 0), Steuerungs- (Level 1) und Überwachungsebene (Level 2) während der Betriebs- und Wartungsphase eines Assets. Folgende Abbildung illustriert das typische Anwendungsgebiet des Standards in der Produktion auf Basis des RAMI 4.0 Modells. Mit seinen Eigenschaften zielt OPC UA hauptsächlich darauf ab, die nahtlose Steuerung von Prozessen in einem lokalen Netzwerk zu ermöglichen. 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.

Was ist OPC UA Client/Server?

Im Kern basiert der Standard auf einer Client/Server-Architektur. In dieser „Eins-zu-Eins“ Topologie fordert ein Client Daten vom einem Server an und der Server antwortet mit den geforderten Daten. Während Clients mit vielen Servern gleichzeitig interagieren können, können Server viele Clients bedienen. Es ist auch üblich, dass ein Gerät gleichzeitig als Client und als Server fungiert. Die Client/Server Architektur ist insbesondere in Automatisierungsszenarien geeignet, in denen eine direkte synchrone Kommunikation (z.b. für closed-loop, command & control) zwischen wenigen Systemen erforderlich ist.

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. Dies reduziert den Kommunikationsaufwand und verbessert die Skalierbarkeit und Flexibilität in großen Netzwerken.

OPC UA Pub/Sub vs. OPC UA Monitor

OPC UA und Sicherheit

Im Kontrast zu anderen Protokollen 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 und sicherheitskritischen Umgebungen effektiv anwendbar ist.

Benutzersicherheit

OPC UA ermöglicht Benutzersicherheit durch die Implementierung verschiedener Sicherheitsfunktionen:

1. Benutzeridentitäts-Token: OPC UA unterstützt unterschiedliche Methoden der Benutzerauthentifizierung für Endpunkte. Dazu gehören Anonym, Benutzername & Passwort sowie Zertifikat.
2. 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.
3. Sicherheitsrichtlinien: Diese legen die kryptografischen Verfahren für jeden Sicherheitsmodus fest.

Anwendungssicherheit

OPC UA ermöglicht Anwendungssicherheit durch folgende Funktionen:

1. 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.
2. 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).
3. 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:

1. 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.
2. 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.
3. Sicherheitsrichtlinien: Die Sicherheitsrichtlinien legen die kryptografischen Verfahren für jeden Sicherheitsmodus fest.

Die Vorteile von OPC UA

OPC UA ist ideal für Anwendungen mit den folgenden Kommunikationsanforderungen geeignet:

1. 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.
2. 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.
3. 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.
4. 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, das Auslösen von Aktionen in entfernten Geräten und die Fernwartung von Systemen.

OPC UA – die Grenzen des Standards

Insbesondere aufgrund der jahrzehntelang gewachsenen Spezifikationen innerhalb des Standards sowie der gewachsenen technischen Schuld („technical dept“) gibt es einige Nachteile:

1. 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.
2. 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.
3. 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.

i-flow und OPC UA

Die i-flow Software bietet in Verbindung mit OPC UA erhebliche Vorteile in der Fabrik, dazu gehören:

1. Interoperabilität: In der Praxis entstehen häufig Kompatibilitätsprobleme, da Hersteller aus verschiedenen Bereichen und Branchen unterschiedliche Teile des OPC UA Standards implementieren. Mittels i-flow können Sie Kompatibilität innerhalb des Standards und mit anderen Technologien (z.B. MQTT) herstellen.
2. Datenkonvertierung: Nicht alle Systeme in einer Fabrik nutzen den Standard. i-flow kann Daten aus nicht OPC-UA-Quellen in das OPC UA Protokoll konvertieren und umgekehrt. Damit kann eine nahtlose Integration verschiedener Systeme gewährleistet werden.
3. Edge-Analytics: In Fabriken entstehen große Datenvolumen aus zahlreichen Quellen. Dabei ermöglicht i-flow die Orchestrierung der Datenflüsse und Automatisierungsfunktionen, um die Datenverarbeitung und -analyse in Edge- und Cloud-Umgebungen zu optimieren.
4. Datenintegration:  Die formatierten Daten können dann in konsistentem Format an nachgelagerte Geschäftssysteme (z.B. ERP, MES) oder Datenbanken weitergeleitet werden.