Bei I4.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 mithilfe von Sensoren generiert. Grundsätzlich besteht die Aufgabe eines Sensors darin, Sensordaten aufzunehmen und über die Schnittstelle nach außen zu übermitteln. Bei einfachen binär schaltenden Sensoren ist das meist nur ein Schaltbit, bei Distanzsensoren wird oft ein Analogausgang verwendet. Bei Absolutwertgebern werden die Positionsinformationen in der Regel über serielle Schnittstellen, wie SSI übertragen. Alle diese Schnittstellen sind jedoch ausschließlich dafür geeignet, Prozessdaten zu übermitteln. Sie werden vermutlich auch längerfristig ihre Berechtigung für die Übermittlung von Prozessdaten behalten. Allerdings werden neue Protokolle und Schnittstellen hinzukommen, über die Daten übertragen werden, die keine Prozessdaten sind. Ein wichtiger Gesichtspunkt für einen Weg in Richtung I4.0 sind die Themen Diagnose, Predictive Maintenance, 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 ausgestattet sein, über die komplexere Daten übermittelt werden können. Je nach Leistungsbedarf und Kostenpunkt kann dies eine Feldbusschnittstelle, wie Profinet, oder eine standardisierte serielle Kommunikationsschnittstelle wie IO-Link sein. Über diese Schnittstellen können sowohl die Prozess- als auch Diagnose- und Parametrierdaten mit der Steuerung ausgetauscht werden. Die Implementierung einer solchen Schnittstelle ist ein erster Schritt in Richtung größerer Datentransparenz.
Ist eine Kommunikationsschnittstelle schon I4.0
Eine intelligente und standardisierte Datenschnittstelle ist die Voraussetzung für einen hohe Datentransparenz und damit Basis für I4.0. Die Schnittstelle alleine reicht aber noch nicht, um I4.0-Systeme realisieren zu können. I4.0-Komponenten müssen sich durch das RAMI-Modell beschreiben lassen, d.h. dass ein Sensor (Field Device) über alle Ebenen des RAMI-Modells Daten austauschen können muss, wenn er als echte I4.0-Komponente funktionieren 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. Dieser 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 z.B. 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 mit der Steuerung. Parallel dazu erlaubt der Webserver die Kommunikation über alle IT-Ebenen und damit eine globale Diagose. Auf diese Weise gibt die Insel aus mehreren einfachen Sensoren am IO-Link-Master ein I4.0-System.
OPC UA als künftiger Kommunikationsstandard
Eine der vielversprechendsten Realisierungen von I4.0 erfolgt derzeit über das OPC-UA-Protokoll. Der Fortschritt besteht darin, dass OPC UA als plattformübergreifende Implementierung realisiert wurde und damit nicht mehr an Windows-Plattformen gebunden ist, sondern sogar auf Embedded-Systemen wie sie in Edge Devices üblich sind, implementiert werden kann. Hinzu kommt, dass Daten, die auf dem OPC-UA-Informationsmodell basieren, sich mit den OPC-UA-Protokollen über alle Ethernet-basierenden Busschnittstellen (Profinet, Ethercat…) übertragen lassen. Des Weiteren beinhaltet OPC UA eine Security-Implementierung, die zur Authentifizierung, Autorisierung, Verschlüsselung und Datenintegrität mit Signaturen besteht. Damit erlaubt es eine sichere Kommunikation, was bei den Kommunikationsmethoden, wie sie bisher 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 (z.B. ERP-Schicht) kommunizieren. Entweder über eine Client/Server-Kommunikation oder über ein Publisher-Verfahren. Bei der Client/Server-Kommunikation wird in der Datenquelle (z.B. Sensor) ein OPC-UA-Server integriert, der Daten an einen Datenabnehmer liefert. Beim Publisher-Verfahren wird ein OPC UA Publisher in der Datenquelle integriert. Dieser kann seine Daten dann verschiedenen Datenabnehmern zur Verfügung stellen. Gibt es mehr als eine Datenquelle 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 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. Da I4.0 und IIoT für den Austausch von Daten zwischen erfassenden und agierenden Einheiten (Sensoren und Aktoren) über alle Systemgrenzen hinweg steht, ist OPC UA ein wichtiger Bestandteil von I4.0. Leuze Electronic hat in Zusammenarbeit mit Microsoft gezeigt, dass die vollständige technische Umsetzung der Möglichkeiten, die OPC UA eröffnet, bereits jetzt möglich sind. So transportiert der Barcodeleser BCL348i seine Daten parallel zu einer Feldbusschnittstelle für Prozessdaten und einem Webserver für Diagnosedaten direkt in die Microsoft Azure Cloud. In dieser können die Daten analysiert und weiterverteilt werden, um sie z.B. auf einem mobilen Device zu visualisieren. Ebenso ist der umgekehrte Weg möglich, einen Barcodescanner von einem beliebigen Ort auf der Welt, beispielsweise von einem mobilen Device, über die Azure-Cloud anzusprechen.
Welche Daten eignen sich für OPC UA Übertragungen?
Daten von Sensoren lassen sich im industriellen Umfeld im Sinne von I4.0 in unterschiedliche Kategorie einordnen. Hier sind insbesondere die schon erwähnten Kategorien Prozess-, Diagnose-, Konfigurations- und statistische Daten zu nennen. Diese variieren allerdings stark in ihren Echtzeitanforderungen: Prozessdaten in hochautomatisierten Prozessen, in denen z.B. Kontrasttaster eingesetzt werden, haben Echtzeitanforderungen im Sub-ms-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 z.B. bei der Erfassung von driftenden Mittelwerten. Um Letzteres geht es bei den gängigen Ansätzen von Predictive Maintenance. 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 Nachlaufes 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 Diagnosefunktionalitäten von Maschinenkomponenten angesprochen wie z.B. 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 (z.B. Sensor) bzw. einem Maschineneinrichter oder Servicepersonal und 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 z.B. die Erfassung eines sich langsam ändernden Füllstandes, bietet sich hingegen die direkte Erfassung in einem ERP-System an. Aus diesem können dann unmittelbar weitere Aktionen, wie eine Nachbestellung oder Erteilung eines Serviceauftrages ausgelöst werden. Da OPC UA direkt Sensor- und Aktor-Daten in die ERP-Cloud übertragen kann, ist es prädestiniert für die Übertragung solcher statistischen Daten.
