Schwerpunkte

MQTT mit Sparkplug versus OPC UA

Intelligente Kommunikation für das IIoT

13. April 2021, 07:30 Uhr   |  Von Anja Helmbrecht-Schaar

Intelligente Kommunikation für das IIoT
© Shutterstock

OPC UA gilt als Standardprotokoll in der Automation. Jedoch wird MQTT zunehmend eine Alternative. Wer die Unterschiede der Architekturmodelle versteht, der kann beurteilen, in welchen Bereichen MQTT mit Sparkplug gegenüber OPC UA die Nase vorne hat.

OPC UA – Open Platforms Communication Unified Architecture – ist ein Standard zum Vernetzen von Infrastruktur wie Sensoren und Geräten im Produktionsumfeld. Er wurde 2008 als Nachfolger von OPC oder OLE – Object Linking and Embedding for Process Control – veröffentlicht [1]. Ziel von OPC UA war es, eine »Unified Architecture« – also eine plattformunabhängige Architektur zu erschaffen und einzuführen. Ebenso wollten die beteiligten Unternehmen eine Geräteinteroperabilität ohne Nutzung von proprietären Programmierschnittstellen (APIs) der Gerätehersteller erreichen.

Mittlerweile gehört das Protokoll zu den wichtigsten Kommunikationsprotokollen für das Industrial Internet of Things (IIoT). Einsatzbereiche sind Anwendungen für industrielle Prozesse und die Automatisierung sowie gene­rische Client-Server-Interaktionen zwischen Komponenten.

So funktioniert OPC UA

Innerhalb der Infrastruktur sind alle Adressen von Servern und Geräten sichtbar, um Anfragen an alle Objekte zu ermöglichen und so die Konfiguration, das Durchsuchen, das Monitoring und den Datenzugriff zu erleichtern. OPC UA unterstützt das semantische Beschreiben von Daten und basiert auf einer Client-Server-Architektur. Der OPC-Client sendet die Anfragen an die OPC-Server. Ein OPC-Server verarbeitet die Anfrage und sendet eine Antwort an den jeweiligen Client zurück. Hierbei verwendet er strukturierte Daten für Request und Response.

OPC UA basiert auf dem TCP/IP-Protokoll sowie dem Verwenden von HTTP beziehungsweise dem Simple Object Access Protocol (SOAP). Der OPC-Server konvertiert das Kommunikationsprotokoll. So ist es möglich, über ein standardisiertes »Device-Modell« auf die Daten des Gerätes zuzugreifen. Entsprechende Sicherheitsmaßnahmen können Nutzer über verschiedene Verfahren wie PKI-Zertifikate, Websocket-Token oder Transport Layer Security (TLS) umsetzen. Möglich ist ebenfalls das Verwenden von Benutzername und Passwort für Geräteknoten. Teilweise ist in die Dienste von OPC UA außerdem eine Quality of Service (QoS)-Funktion integriert. Als zugrunde liegendes Konzept ist es jedoch nicht vorhanden. Über spezifische Events und Alarme unterstützt die Architektur das Fehlermanagement und Behandeln von Ausnahmen.

OPC UA definiert ein vollständiges Datentypsystem. Als »Knoten« werden beispielsweise OPC UA Ressourcen bezeichnet, die einzeln adressierbar sind. Verschiedene Knoten eines Gesamtsystems können als Datenobjekte aus einfachen oder komplexen, strukturierten Datentypen aufgebaut sein. Des Weiteren sind sogenannte Discovery Services verfügbar, um dynamisch neue Komponenten im In­­frastruktur-Set-up erkennen zu können.

Das OPC-UA-Schichtenmodell
© HiveMQ

Bild 1. Das OPC-UA-Schichtenmodell

Generische Gerätemodelle spielen in der OPC-UA-Architektur eine zentrale Rolle. Verantwortlich für das Bereitstellen des Servers, der ein generisches Gerätemodell dem konkreten Gerät zuordnet, sind die Gerätehersteller.

Der OPC-UA-Standard setzt sich aus einzelnen Spezifikationen zusammen. Jede Spezifikation beschreibt hierbei eine Teilfunktion. Sie gibt vor, welche Schnittstellen von Server und Client für die Funktion zu implementieren sind, um sie zu unterstützen. Da ein Nutzer nicht alle Spezifikationen implementieren muss, ist es für Clients und Services nötig zu wissen, welche Spezifikationen man benötigt und ob diese implementiert sind. Hilfreich sind hierbei sogenannte Companion Specifications, soweit sie für die beteiligten Geräte und Systeme nutzbar sind. Sie existieren für verschiedene Branchen. In den Companion Specifications sind vordefinierte Strukturen für die jeweiligen branchenspezifischen Anwendungen und beteiligten Objekte festgelegt. Man unterscheidet sie nach Industry und Producer specific models (Bild 1).

Client und Server sprechen miteinander

Über Gateway-Implementationen für DDS, oneM2M-Anwendungen oder durch ein HTTP Gateway kann die Kommunikation zu anderen Diensten etabliert werden. Hierbei stellen die OPC-Server eine objektorientierte, remote aufrufbare API bereit, die das Gerätemodell implementiert. Über das standardisierte Device-Modell können Nutzer auf das Gerät zugreifen. Es gibt Device-Modelle für Dutzende von Gerätetypen, vom Sensor bis zum Feedback-Controller.

Das Device-Modell eines bestimmten Sensors stellt über eine APIMethoden zum Setzen von Parametern, Lesen von Daten und Betreiben des Gerätes bereit. Anwendungen können den Sensor über die API direkt steuern, ohne den Ansatz des jeweiligen Herstellers kennen zu müssen. Ein oder mehrere OPC-Server im System warten darauf, dass beliebig viele Clients Anfragen senden. Sobald ein Server eine Anfrage erhält, ant­wortet er darauf und kehrt anschließend in einen Wartezustand zurück. Der Client kann den Server ebenso direkt anweisen, Updates zu senden, sobald sie auf dem Server verfügbar sind.

Sind jedoch viele Anwendungen und Geräte verschiedener Hersteller zu vernetzen, ist es herausfordernd, eine OPC-UA-Architektur zu implementieren. Schwierig ist dann die Implementation mehrerer Konsumenten, die bei einer 1-N-Konstellation oder in flexiblen N-N-Publish-Subscriber-Architekturen vorkommen. Ein wirkliches Entkoppeln von Daten ist aufgrund der Client-Server-Architektur nicht zu erreichen. Außerdem kann sich ein Anbinden an Cloud-basierte Anwendungen als schwierig erweisen oder ist mit einem hohen Aufwand verbunden.

Übliche OT/IT-Infrastruktur mit OPC UA

Die typische Betriebstechnik (OT)-Architektur in Produktionsumgebungen umfasst viele unterschiedliche Geräte, Sensoren und Gateways. Die jeweiligen Anwendungen fordern die nötigen Daten direkt von den speicherprogrammierbaren Steuerungen (SPSen), Gateways oder Servern an, die über verschiedene Protokolle kommunizieren. Hierbei kommuniziert eine beliebige Anzahl von Servern in der Produktion direkt mit anderen Teilnehmern in der Produktion. Solange das Set-up lediglich aus wenigen verschiedenen Systemen besteht, funktioniert der Ansatz recht gut. Bei einer größeren Anzahl von Komponenten entsteht jedoch eine schwer wartbare Architektur: Die Komponenten stehen in fixen bidirektionalen Direktverbindungen.

OPC-UA-Client-Server-Kommunikation in heterogenen Infrastrukturen
© HiveMQ

Bild 2. OPC-UA-Client-Server-Kommunikation in heterogenen Infrastrukturen.

Es gibt hierbei keine Komponente im Set-up, die alle Informationen zentral verwaltet, also keine Single Source of Truth. Eine beliebige Anzahl von OPC-UA-Servern aus dem Produktionsbereich kommuniziert direkt mit anderen Teilnehmern im OT, die ebenfalls als Client oder Server arbeiten oder mit einem oder sogar mehreren OPC-UA-Clients im IT-Bereich. Somit erhöht sich mit der Anzahl der Komponenten der Aufwand für Implementation, Betrieb und Wartung, was am Ende zu steigenden Kosten führt (Bild 2).

Um den Aufwand zu verringern, wurden weitere Schnittstellen wie Umati für die Werkzeugmaschinenbranche spezifiziert und entwickelt [2]. Sie dienen dazu

➔ den Austausch der Daten von Maschinen mit den jeweiligen IT-Systemen zu standardisieren,
➔ eine einheitliche Semantik für eine Branche zu definieren (Companion Specification),
➔ Sicherheitsrichtlinien und Konfigurationen für OPC-Server sowie
➔ Testspezifikationen beziehungsweise Templates bereitzustellen.

Hiermit ist sowohl das OPC-UA-Informationsmodell als auch die Art und Weise der Kommunikation vordefiniert – zumindest für eine Branche. Eine schnellere Integration von neuen Maschinen in das existierende System ist somit möglich. Jedoch wird die Architektur von der Spezifikation nicht weiter berührt. Somit bleiben die Ansprüche, die sich daraus ergeben, bestehen.

Die wichtigsten Eigenschaften einer OPC-UA-Architektur auf einen Blick
© HiveMQ

Viele Unternehmen wünschen sich eine hohe Anpassungsfähigkeit, Flexibilität und ein einfaches Implementieren – analog zu IT-Landschaften, jedoch genauso zuverlässig und sicher wie OT-Landschaften. Für den Paradigmenwechsel ist eine neue Architektur erforderlich. Unternehmen möchten weg von der komplexen Struktur, hin zu einer schlanken Struktur, mit der ein sicherer und zuverlässiger Datenaustausch in der industriellen Automatisierung denkbar ist. Möglich ist das mit dem MQTT-Protokoll.

Seite 1 von 2

1. Intelligente Kommunikation für das IIoT
2. MQTT macht es einfacher

Auf Facebook teilen Auf Twitter teilen Auf Linkedin teilen Via Mail teilen

Das könnte Sie auch interessieren

Verwandte Artikel

HiveMQ / dc-square GmbH