Neue Datenaustauschformate

Die IO-Link-Master ICE2 (Ethernet/IP) und ICE3 (Profinet)

Die IO-Link-Master ICE2 (Ethernet/IP) und ICE3 (Profinet) von Pepperl+Fuchs sind zur webbasierten Konfiguration geeignet, sodass zusätzliche Software oder eine übergeordnete SPS nicht benötigt werden. Eine integrierte OPC-UA-Schnittstelle macht die IO-Link-Master zur idealen Lösung für cloudbasierte, aber auch hybride Systeme (Quelle: Pepperl)

In der Prozessebene haben sich im Lauf der Jahre verschiedene Industrial-Ethernet-Protokolle, wie Profinet, Ethernet/IP oder Ethercat, etabliert. Auf der IIoT-Ebene kommen neuere Datenaustauschformate, wie MQTT, OPC UA oder Rest API, zum Einsatz. Sie dienen dazu, umfangreiche Zustandsdaten nicht echtzeitkritisch in eine Cloud zu übertragen. „Die Datenmenge kann in einer einzigen Werkshalle pro Tag einige Gigabyte betragen“, nennt L. Pogoda einen Daumenwert. „Teilweise werden hier auch die Daten von mehreren Produktionswerken weltweit zusammengeführt. Deshalb dürfen die Netzwerkgrenzen nicht zu stark ausgeprägt sein.“ Da hier die Daten verschiedener Herstellersysteme übergreifend zusammengefasst werden, ist die Standardisierung der Protokolle von großer Bedeutung.

Doch wie unterscheiden sich eigentlich MQTT, OPC UA und Rest API voneinander? L. Pogoda: „Bei MQTT handelt es sich lediglich um einen Übertragungsmechanismus, hinter dem keine Standardisierungsorganisation steht. Im Gegensatz dazu handelt es sich bei Rest API um eine Programmierschnittstelle. Bei dieser gibt es durch die sogenannte Restful API bereits Implementierungsempfehlungen. Allerdings überwacht auch hier keine Organisation, ob diese eingehalten werden. Bei OPC UA handelt es sich um ein komplettes Framework, das von der OPC Foundation überwacht und zertifiziert wird.“

Betrachtet man den Footprint, also die bei der Übertragung anfallende Datenmenge, ist MQTT eher „leichtgewichtig“. Hier kommt ein Publish/Subscribe-Mechanismus zum Einsatz: Ein Publisher stellt Daten im Netzwerk bereit, Teilnehmer können sich darauf subscriben und erhalten dann die entsprechenden Daten. Die Rest API basiert auf http bzw. https und bietet eine Client-Server-Architektur. „Hier gibt es eine stehende Verbindung zwischen einem Client, der Daten abgreifen möchte, und einem Server, der diese bereitstellt. Diese Verbindung erfordert einen gewissen Daten-Overhead, wodurch der Footprint dieses Protokolls steigt“, erklärt der Kommunikationsexperte. Bei OPC UA werden zusätzlich zu den Prozessdaten Metadaten übertragen, sodass der Footprint hier am größten ist.

Was das Thema Security anbelangt, wird dieses bei MQTT auf einer höheren Ebene realisiert. „Da alle Subscriber auf die Daten in einem Netzwerk zugreifen können, muss der Nutzer in einer höheren Ebene sicherstellen, dass sich nur gewünschte Teilnehmer in einem Netz anmelden können“, sagt L. Pogoda. Bei der Client-Server-Architektur, welcher der Rest-API zugrunde liegt, können bereits erste Authentifizierungsmechanismen implementiert werden: „Vor dem Datenaustausch werden vom Nutzer Benutzername und Passwort abgefragt“, erklärt er dazu. OPC UA gehe an dieser Stelle noch einen Schritt weiter: Neben Authentifizierungsmechanismen gibt es hier auch ein Zertifikatemanagement. „Dadurch lässt sich Security direkt in OPC UA realisieren“, gibt er an.

Betrachtet man die unterschiedlichen Datenaustauschformate in der Anwendung, gilt für MQTT: Einzelne Sensoren lassen sich recht einfach ins Netzwerk einbinden; der manuelle Aufwand steigt jedoch pro Sensor, der integriert wird. Bei Rest API ist der Aufwand zur Implementierung von Sensoren identisch zu MQTT. Vorteile ergeben sich dann, wenn Sensoren gleicher Hersteller eingebunden werden sollen und der Hersteller dieser Sensoren die Schnittstelle für sich standardisiert hat. Grenzen zeigen sich auf, wenn Sensoren unterschiedlicher Hersteller eingebunden werden. „Bei OPC UA ist der Initialaufwand für die Integration eines Sensors zwar etwas höher als bei den beiden anderen Kommunikationslösungen. Der Vorteil liegt allerdings darin, dass keine separaten Dateien oder Handbücher erforderlich sind, sondern eine direkte Kommunikation mit dem Server erfolgt. Die Metadaten sind direkt mit verfügbar“, erläutert L. Pogoda. Als weiteren Nutzen für den Anwender nennt er Companion Specifications. „Sie beschreiben für einen spezifischen Gerätetyp, wie das Informationsmodell aussehen soll. Wird nun ein Sensor mit einem solchen Informationsmodell integriert, ist gewährleitet, dass die entsprechenden Daten an der gewünschten Stelle ankommen.“ Das ist hilfreich, wenn ein zweiter Sensor von einem anderen Hersteller eingebunden wird. Folgt dieser der gleichen Companion Spec, kann sich der Anwender darauf verlassen, dass die Daten automatisch eingelesen und das Dashboard aufgebaut wird. „Demnach spielt OPC UA dann seine Vorteile aus, wenn es um Standardisierung über Herstellergrenzen hinweggeht – wenn also viele Sensoren verschiedener Hersteller eingebunden werden sollen“, fasst L. Pogoda die Theorie zusammen.

Anforderungen in der Feldebene

Prinzipiell sind die Experten von Pepperl+Fuchs davon überzeugt, dass die Sensorik die Basis des IIoT bildet. Vor diesem Hintergrund ist die geschützte Marke Sensorik 4.0 entstanden. Mit dieser werden Produkte gekennzeichnet, die die Anforderungen von Industrie 4.0 erfüllen. Diese Anforderungen werden von der Plattform Industrie 4.0 gestellt und jährlich aktualisiert. „I4.0-ready-Produkte bzw. Sensorik 4.0 bedeutet für uns: eindeutige Identifikation der Produkte und bidirektionale Kommunikation auf Basis von festgelegten Standards“, sagt Benedikt Rauscher, Leiter globale IoT-/Industrie-4.0-Projekte bei Pepperl+Fuchs. Neben den zuvor genannten Kommunikationslösungen auf Prozess- und IIoTEbene nennt Sonja Armbruster, Produktmanagerin industrielle Kommunikation bei Pepperl+Fuchs, für die Feldebene IO-Link zur Verdrahtung der Sensorik und Aktorik. „In der Vergangenheit wurden vorwiegend Standardmesssignale oder Schaltsignale übermittelt. Dank der bidirektionalen Kommunikation von IO-Link lassen sich Sensoren auch parametrieren oder konfigurieren sowie Diagosedaten abrufen. Das stellt den Baustein einer jeden IoT-Applikation dar“, erklärt sie weiter. Sie weist ferner darauf hin, dass durch den Industrie-4.0-Gedanken die Kommunikation in die Cloud in den letzten Jahren an Bedeutung gewonnen habe. „Daraus ergeben sich neue Strukturen – an der klassischen Automatisierungspyramide vorbei“, so S. Armbruster.

2 / 4

Ähnliche Beiträge