Unter der geschützten Marke Sensorik 4.0 fasst Pepperl+Fuchs Sensorlösungen für Industrie-4.0-Anwendungen zusammen

Unter der geschützten Marke Sensorik 4.0 fasst Pepperl+Fuchs Sensorlösungen für Industrie-4.0-Anwendungen zusammen (Quelle: Pepperl+Fuchs)

Nahezu täglich werden wir mit Begriffen, wie IIoT, Industrie 4.0 oder Digital Factory, konfrontiert. Doch was bedeuten sie eigentlich konkret? Eine Einordnung liefert Lukas Pogoda, Produktmanager für industrielle Kommunikation bei Pepperl+Fuchs. Dazu verweist er zunächst auf die bisherige Situation in der Produk­tion, wo Automatisierungsgeräte ihre Daten mit einer zentralen Steuerung austauschen. Diese steuert den Prozess in Echtzeit. Als Herausforderung führt er an, dass die ­Automatisierungsgeräte immer mehr zusätzliche Daten zur Verfügung stellen, zum Beispiel Diagnose- und Identifikationsdaten. ­Diese sind für die Prozesskontrolle zunächst irrelevant, bringen allerdings auf einer höheren Ebene Mehrwert. „Das IIoT beschäftige sich nun damit, die Daten von Automatisierungsgeräten in der Cloud verfügbar zu machen, sodass sie einen Mehrwert schaffen können“, erklärt er und fügt an: „IIoT ist aber nicht nur eine Laune der Automatisierungshersteller, um den Kunden neue Produkte anbieten zu können, sondern bringt auch entscheidende Vorteile.“ Als Beispiel aus der Feldebene führt er optische Sensoren von Pepperl+Fuchs an, die Verschmutzungen auf der Linse erkennen und ein entsprechendes Warnsignal senden können. „Wartungseinsätze lassen sich dadurch optimal planen und  Ausfälle vermeiden“, nennt er als Vorteil und verdeutlicht: „In der Feldebene geht es darum, mit möglichst geringem Ressourceneinsatz einen möglichst großen Output zu generieren.“

Weitere Vorteile ergeben sich seinen Angaben zufolge auf der IIoT-Ebene. Dort lassen sich durch datengestützte Analysen beispielsweise Korrelationen in Datenmustern erkennen, die zu Fehlproduktionen führen können. „Werden diese rechtzeitig festgestellt, lässt sich die Qualität der Produktion erhöhen. 

Remote-Zugriffe ermöglichen es ferner, Fehler schnell durch den Mitarbeiter von Zuhause aus zu beheben. Letztlich ergeben sich zudem neue Business-Modelle, wie Wartungsverträge oder Pay-per-Use-Modelle“, informiert er weiter.

Neue Datenaustauschformate

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 Founda­tion ü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 Sen­soren 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 Integra­tion 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.    
 

1 / 4

Ähnliche Beiträge