Barcodeleser überträgt Daten direkt in die Azure Cloud
Weltweiter Datentunnel
Leuze Electronic und Microsoft entwickeln auf Basis des Barcodelesers BCL 348i eine Industrie-4.0-fähige Sensorlösung, die Daten direkt an die Azure Cloud und wieder zurück in den Sensor überträgt.
Eine intelligente und standardisierte Datenschnittstelle ist Voraussetzung für einen hohe Datentransparenz und damit Basis für Industrie 4.0 (I4.0). Die Schnittstelle alleine reicht aber nicht aus, um I4.0-Systeme realisieren zu können. Entsprechende Komponenten müssen sich durch das RAMI-Modell 4.0 beschreiben lassen, d.h. ein Sensor (Field Device) muss über alle IT-Ebenen kommunizieren können, wenn er als I4.0-Komponente eingesetzt werden soll. Dies kann ein Sensor mit einer klassischen Feldbus-Schnittstelle nicht leisten, da diese Schnittstellen ausschließlich mit der Steuerung kommunizieren, aber keine Daten in die oberen IT-Ebenen abgeben.
OPC UA als M2M-Standard
Im Gegensatz zu den klassischen Feldbus-Schnittstellen, kann eine Schnittstelle, die um das OPC UA-Kommunikationsmodell erweitert ist, Daten in höhere IT-Ebenen des RAMI-Modells transportieren. OPC wurde entwickelt, mit dem Ziel, Prozessdaten von Aktoren und Sensoren unterschiedlicher Hersteller mit SCADA- und HMI-Systemen auszutauschen. OPC basiert dabei auf den Microsoft-Technologien OLE, COM und DCOM. Das UA in OPC UA steht für Unified Architecture und stellt eine Weiterentwicklung von OPC dar. Im Gegensatz zu der ursprünglichen OPC-Technologie handelt es sich bei OPC UA um eine Plattform-übergreifende Implementierung, die damit nicht mehr an Windows-Plattformen gebunden ist. Sie kann u.a. auch auf Embedded Systemen und damit in Sensoren implementiert werden. Darüber hinaus lässt sich das OPC UA-Kommunikationsmodell neben den klassischen Protokollen wie Profinet oder Ethercat über alle Ethernet basierenden Feldbus-Schnittstellen betreiben. OPC UA beinhaltet eine Security-Implementierung, die aus Authentifizierung, Autorisierung, Verschlüsselung und Datenintegrität mit Signaturen besteht. Damit erlaubt es im Gegensatz zu den üblicherweise im industriellen Umfeld eingesetzten Kommunikationsmethoden eine sichere Kommunikation. Von der Feldebene der Automatisierungspyramide kann OPC UA über zwei unterschiedliche Mechanismen kommunizieren: Entweder über eine Client/Server-Kommunikation oder über ein Publisher-Verfahren. Bei der Client/Server-Kommunikation wird in der Datenquelle, z.B. ein Sensor, ein OPC UA-Server integriert, der Daten an einen Datenabnehmer liefert. Beim Publisher-Verfahren wird ein OPC UA Publisher in der Daten-Quelle integriert, der dann verschiedenen Datenabnehmern seine Daten zur Verfügung stellt. Gibt es im System mehr als eine Datenquelle (Sensor), kann der Datenabnehmer entscheiden, welche Daten er von welchem Publisher beziehen möchte. Somit muss der Abnehmer nicht immer die Daten aller Publisher empfangen. Über dieses Verfahren ist somit eine Kommunikation von m-Datenquellen zu n-Daten-Abnehmern möglich. Zum Anderen kann sich eine Cloud interessante Daten direkt von der Datenquelle holen. Auch in der entgegengesetzten Richtung – von der Cloud in den Sensor – wird in der Zukunft eine Kommunikation möglich sein. OPC UA kann somit die Schichten der Automatisierungspyramide quasi durchtunneln und Daten in höhere Schichten des RAMI-Modells transportieren. Somit wird eine standardisierte Kommunikation von Sensoren und Aktoren unterschiedlicher Hersteller, direkt mit einem Cloud-basierten ERP-System möglich. 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 über alle Systemgrenzen hinweg steht, ist OPC UA ein wichtiger Bestandteil von I4.0 und mit den oben genannten Eigenschaften einer der wichtigsten Kandidaten für einen zukünftigen Standard in der Maschine-to-Maschine-Kommunikation (M2M).
Microsoft Azure Clould
Die Datenbereitstellung von Komponenten über die OPC UA-Kommunikation alleine ist aber nicht ausreichend für eine I4.0-Anwendung. Es werden zusätzliche Mechanismen zur Datenabnahme von der Cloud benötigt. Der Datentransfer vom Sensor in die Cloud wird als Telemetrie bezeichnet. Um die Telemetriedaten ohne zusätzliche Komponenten wie beispielsweise ein I4.0-Gateway zu realisieren, starteten Leuze Electronic und Microsoft eine Zusammenarbeit, deren erste Ergebnisse auf der SPS IPC Drives gezeigt werden. Sensordaten des Barcodelesers BCL 348i werden über das OPC UA-Publish/Subscriber Communication Modell (PSCM) in den Azure IoT Hub von Microsoft übertragen. Vom Barcodeleser werden sowohl Prozess- als auch Metadaten wie Codeart oder die Anzahl von Lesungen über das Advanced Message Queuing Protokoll (AMQP) der OPC UA-Schnittstelle an die Microsoft Azure Cloud übertragen. Die Daten werden dort vom IOT-Hub erfasst, und den Azure Cloud Services zur Analyse und Visualisierung bereit gestellt. Microsoft ist mit der Azure Cloud einer der führenden Cloud-Anbieter. Die Cloud stellt dem Nutzer eine Vielzahl von Anwendungen zur Verfügung. Diese Dienste sind Hyperscaling-fähig und können vom Anwender global abgerufen werden. Aktuell bietet Microsoft für Embedded Geräte erstmals die Möglichkeit einer Relay/Broker-Kommunikation an, die jetzt in dem Barcodeleser integriert wurde. Mit dieser Kommunikation kann ein Embedded Device aus der Azure Cloud gesteuert werden und wird als Command/Controll-Funktion bezeichnet. Am Beispiel des Barcodelesers BCL 348i wird gezeigt, wie ein Device von der Cloud, ohne dass ein weiteres Gateway benötigt wird, auf der untersten RAMI-Ebene angesprochen werden kann. Somit ist es überall auf der Welt von einem beliebigen Mobil-Device aus möglich, über die Azure Cloud, das Lesetor eines Barcodelesers zu steuern. Im Sinne von Big Data ist jedoch ein weiterer Anwendungsfall von weitaus größerer Bedeutung. Die vom IoT-Hub erfassten Sensordaten können von den Analysewerkzeugen der Cloud nach vorbestimmten Kriterien analysiert werden und anschließend Ereignisse im I4.0-Gesamtsystem auslösen.
