Die Industrie-4.0-fähige Sensorlösung Messen alleine reicht nicht mehr

Bei Industrie 4.0 oder IIoT geht es in erster Linie um Daten und den Austausch von Daten über alle Systemgrenzen hinweg. Ein Großteil dieser Daten wird mit Hilfe von Sensoren generiert. Grundsätzlich besteht die Aufgabe eines Sensors darin, Messdaten aufzunehmen und über die Schnittstelle nach außen zu übermitteln.

Bei einfachen binär schaltenden Sensoren ist das meist nur ein Schaltbit, bei distanzmessenden Sensoren wird als Schnittstelle oft ein Analogausgang verwendet. Bei Absolutwertgebern werden die Positionsinformationen in der Regel über serielle Schnittstellen, wie beispielsweise SSI übertragen. Alle diese Schnittstellen sind jedoch ausschließlich dafür geeignet, Prozessdaten zu übermitteln.

Ein wichtiger Gesichtspunkt für einen Weg in Richtung Industrie 4.0 sind die Themen Diagnose, Predictive Maintainance, Rezepturwechsel sowie Formatumstellung bei der Parametrierung von Maschinen und Anlagen im Produktionsbetrieb. Dafür ist es nötig, Diagnose- und Parametrierdaten mit dem Sensor auszutauschen. Hierzu muss der Sensor mit Kommunikationsschnittstellen ausgestattetet werden, über die komplexere Daten übermittelt werden können.

Je nach Leistungsbedarf und Kostenpunkt kann dies eine Feldbusschnittstelle, wie zum Beispiel Profinet, oder eine standardisierte serielle Kommunikationsschnittstelle wie IO-Link sein. Über diese Schnittstellen können sowohl die Prozess- aber eben auch Diagnose- und Parametrierdaten mit der Steuerung ausgetauscht werden. Die Implementierung einer solchen Schnittstelle ist ein erster Schritt in Richtung größerer Datentransparenz und damit auch ein Schritt in Richtung Industrie 4.0.

Reicht IO-Link schon aus?

Eine intelligente und standardisierte Datenschnittstelle ist die Voraussetzung für einen hohe Datentransparenz und damit eine Basis für Industrie 4.0. Die Schnittstelle alleine reicht aber noch nicht, um Industrie 4.0 Systeme realisieren zu können. Industrie 4.0 Komponenten müssen sich durch das RAMI-Modell der Plattform Industrie 4.0 beschreiben lassen.

Das bedeutet, dass ein Sensor (Field Device) über alle Ebenen des RAMI-Modells Daten austauschen können muss, wenn er als echte Industrie 4.0-Komponente funktionieren können soll. Das kann ein Sensor, der nur über eine IO-Link-Schnittstelle oder einen integrierten Feldbus verfügt, nicht leisten, da diese Schnittstellen ausschließlich mit der Steuerung kommunizieren, aber keine Daten in die oberen Ebenen der Automatisierungspyramide transportieren können. Ein Weg, um von außerhalb der Steuerungsebene auf ein Asset auf der Komponentenebene der Automatisierungspyramide zuzugreifen, ist die Implementierung eines Webservers.

Der Webserver erlaubt eine einfache Diagnose, ohne auf die Steuerung zugreifen zu müssen. Ebenso ermöglicht er einen globalen Zugriff auf den Sensor. Ein solcher lässt sich heute noch nicht in einfache Sensoren, wie zum Beispiel einen Kontrasttaster integrieren. Verfügt jedoch ein Edge-Device über eine IO-Link-Schnittstelle, ist es möglich, diese Funktionalität über einen IO-Link Feldmaster zu realisieren. Der Webserver ist in den Master integriert und verbindet bis zu vier IO-Link-Sensoren über einen Feldbus wie zum Beispiel Profinet mit der Steuerung. Parallel dazu erlaubt der Webserver die Kommunikation über alle IT-Ebenen und damit eine einfache globale Diagose. Auf diese Weise kann die Insel aus mehreren einfachen Sensoren am IO-Link-Master wieder als Realisierung eines Industrie 4.0-Systems bezeichnet werden.

OPC UA als künftiger Kommunikationsstandard

Eine der vielversprechendsten Realisierungen von Industrie 4.0-Systemen erfolgt derzeit sicherlich über die Nutzung des OPC UA-Protokolls. Der große Fortschritt im Sinne von Industrie 4.0 besteht darin, dass OPC UA als Plattform-übergreifende Implementierung realisiert wurde. Hinzu kommt, dass Daten, die auf dem OPC UA-Informationsmodell basieren, sich mit den OPC UA-Protokollen über alle Ethernet basierenden Busschnittstellen wie zum Beispiel Profinet oder Ethernet/IP übertragen lassen.

Des Weiteren beinhaltet OPC UA eine Security-Implementierung, die zur Authentifizierung, Autorisierung, Verschlüsselung und Datenintegrität mit Signaturen besteht. Damit erlaubt OPC UA eine sichere Kommunikation, was bei den Kommunikationsmethoden, wie sie üblicherweise im industriellen Umfeld eingesetzt werden, nicht der Fall ist. Von der Feldebene der Automatisierungspyramide kann OPC UA über zwei unterschiedliche Mechanismen in höhere Schichten (zum Beispiel die ERP-Schicht) kommunizieren. Entweder über eine Client/Server-Kommunikation oder über ein Publisher Verfahren. Bei der Client/Server Kommunikation wird in der Datenquelle, wie beispielsweise einem Sensor, ein OPC UA Server integriert, der Daten an einen Datenabnehmer liefern kann. Beim Publisher Verfahren wird ein UPC UA-Publisher in der Datenquelle integriert. Dieser Publisher kann seine Daten dann verschiedenen Datenabnehmern zur Verfügung stellen.

Gibt es mehr als eine Datenquelle (Sensor) im System, kann der Datenabnehmer entscheiden, an welchen Daten von welchem Publisher er interessiert ist. Der Abnehmer muss damit nicht immer die Daten aller Publisher empfangen. Über dieses Verfahren ist zum einen eine Kommunikation von m-Datenquellen zu n-Daten-Abnehmern möglich. Zum anderen kann sich eine Daten-Cloud interessante Daten direkt von der Datenquelle holen. Auch in der entgegengesetzten Richtung (von der Cloud in das Edge-Device) ist eine Kommunikation möglich, um z.B. Software-Uploads oder Parametrierungen zu ermöglichen. OPC UA kann somit die Schichten der Automatisierungspyramide quasi „durchtunneln“ und Daten im gesamten RAMI-Model verteilen. Dank der sicheren Kommunikation ist sogar ein Austausch von Daten zwischen unterschiedlichen Systemen über öffentliche Kanäle denkbar.

Welche Daten eignen sich für OPC UA?

Daten von Sensoren lassen sich im industriellen Umfeld im Sinne von Industrie 4.0 in unterschiedliche Kategorie einordnen. Hier sind insbesondere die schon erwähnten Kategorien Prozessdaten, Diagnosedaten, Konfigurationsdaten und statistische Daten zu nennen. Diese Kategorien variieren stark in ihren Echtzeitanforderungen: Prozessdaten in hochautomatisierten Prozessen, in denen zum Beispiel Kontrasttaster eingesetzt werden, haben Echtzeitanforderungen im sub-millisekunden Bereich. Prozessdaten in einer teilautomatisierten Fertigung, Diagnosedaten und Konfigurationsdaten haben dagegen deutlich weniger restriktive zeitliche Anforderungen.

Statistische Daten wiederum können in der Regel gar nicht schnell erfasst werden, da es sich um eine Datenaggregation handelt, wie beispielsweise bei der Erfassung von driftenden Mittelwerten. Um Letzteres geht es bei den gängigen Ansätzen von „predictive maintainance“ - eines der am häufigsten genanntesten Beispiele für potentielle Business Cases im Umfeld von Industrie 4.0.

Praxisbeispiel Drehbank

Als Beispiel mag der Nachlauf einer Drehbank nach dem Abschalten dienen: Verkürzt sich der Nachlauf, mag sich ein Lagerschaden an der Drehbank andeuten. Somit kann eine statistische Auswertung des Nachlaufs bei jedem Ausschalten der Drehbank Aufschluss über deren Zustand geben. Diese Art, Daten zu sammeln, ist nicht mit Diagnosedaten in der Feldebene zu verwechseln.

Bei Diagnosedaten werden vorimplementierte Diagnose-Funktionalitäten von Maschinenkomponenten angesprochen wie beispielsweise die Selbstdiagnose eines Sensors. Schnelle Prozessdaten werden aufgrund der harten zeitlichen Anforderungen, die für logische Entscheidungen benötigt werden, bis auf weiteres in der Steuerungsumgebung gesammelt und bearbeitet. Bei der Übergabe von Parametrier- und Diagnosedaten handelt es sich in der Regel um eine Kommunikation zwischen einer spezifischen Maschinenkomponente (zum Beispiel einem Sensor) und einem Maschineneinrichter oder Servicepersonal – somit um eine sehr individuelle und direkte Kommunikation. Hier bietet sich der Zugriff über einen Webserver an.

Für statistische Daten und langsame Prozessdaten, wie beispielsweise bei der Erfassung eines sich langsam ändernden Füllstands, bietet sich hingegen die direkte Erfassung in einem ERP-System an. Aus dem ERP-System können dann unmittelbar weitere Aktionen im Sinne von Industrie 4.0, wie eine Nachbestellung oder Erteilung eines Serviceauftrags ausgelöst werden. Da OPC UA direkt Sensor und Aktor Daten in die ERP-Cloud übertragen kann, ist OPC UA prädestiniert für die Übertragung solcher statistischen Daten.