IoT zum Anfassen – Von der Maschine in die Cloud
Die Digitalisierung schreitet immer weiter voran, wodurch auch das Thema IoT (Internet of Things) und IIoT (Industrial Internet of Things) einen zunehmend größeren Stellenwert in Unternehmen einnimmt. Besonders im industriellen Umfeld ist zu beobachten, dass die Ausgangslage in den meisten Fällen verschiedene Maschinen darstellen, die entweder nicht oder nur teilweise z. B. durch ein MES (Manufacturing Execution System) mit anderen Systemen vernetzt sind. Die Nachrüstung von Bestandsmaschinen, das sogenannte Retrofitting, spielt dabei eine zentrale Rolle, denn für die Vernetzung wäre es unwirtschaftlich, neue Maschinen kaufen zu müssen.
Um die Vorteile der Digitalisierung auszuschöpfen und in Richtung Industrie-4.0-Szenarien denken zu können, ist die vollständige Vernetzung eine Grundvoraussetzung. Nur wenn alle entsprechenden Systeme und Dienstleister eingebunden sind, kann ein maximaler Nutzen erzielt werden. Es reicht dabei nicht aus, die eigenen Daten nur für sich selbst in der Cloud zur Verfügung zu stellen. Die Daten verlassen in Industrie-4.0-Anwendungsfällen zunehmend schneller die eigenen Unternehmensgrenzen und müssen dort in einem geeigneten Format anderen Beteiligten zur Verfügung gestellt werden.
IoT und IIoT sollte nicht nur eingeführt werden, um sagen zu können "Wir machen IoT", es ist vielmehr sehr wichtig, sich vorher Gedanken über den zukünftigen Einsatz zu machen. Dabei ist es hilfreich, sich von den bestehenden technischen Limitierungen zu lösen und nur den Gedanken des Mehrwerts zu verfolgen. Industrie-4.0-Szenarien können dazu beitragen, einen Marktvorteil gegenüber Mitbewerbern zu erlangen. In Zukunft könnte sich dies aber auch zu einem Hygienefaktor entwickeln, der zwingend erfüllt sein muss, damit das eigene Unternehmen konkurrenzfähig bleibt.
Wir möchten anhand eines konkreten Beispiels den Weg von der Maschine in die Cloud aufzeigen und veranschaulichen, wie sich dieser mithilfe von Microsofts IoT-Technologien umsetzen lässt. Darauf aufbauend wird ein Ausblick gegeben, wie dieser Weg weiter ausgebaut werden kann, um eine vollständige Vernetzung zu erreichen.
Was bietet Microsoft Azure?
Wer eine IoT-Lösung umsetzen möchte, hat die Qual der Wahl: Alles selbst zu implementieren oder eine bestehende Lösung zu verwenden. Für beide Varianten eignet sich Microsoft Azure (s. Abb. 1).
Mit IoT Central [1] bietet Azure eine fertige IoT-Plattform als Software-as-a-Service-Lösung (SaaS) an, für die keinerlei technisches Know-how erforderlich ist und die mit einem Klick ausgerollt werden kann. Die komplette Applikation wird in Azure gehostet und der Benutzer muss sich nur um die Konfiguration kümmern. Mit eigenen Device Dashboards, Visualisierung von Telemetriedaten und konfigurierbaren Regeln kann so schon vieles abgebildet werden. Der Vorteil einer SaaS-Lösung ist, dass nichts selbst programmiert werden muss, dafür muss man sich aber mit der Funktionalität begnügen, die IoT Central zur Verfügung stellt. Dabei ist IoT Central jedoch nicht nur als schneller Proof-of-Concept gedacht. Auch aufwändige Anwendungsfälle können in IoT Central abgebildet und durch verschiedene Integrationen in andere Azure-Dienste erweitert werden.
Für alle die mehr Anpassbarkeit benötigen, jedoch auch nicht auf der grünen Wiese starten wollen, bieten die Azure IoT Solution Accelerators[3] eine IoT-Plattform-Blaupause als Platform-as-a-Service (PaaS). Mit dieser Blaupause wird der Source-Code für eine IoT-Plattform sowie alle benötigten Azure-Dienste mitgeliefert. Diese IoT-Plattform kann dann ebenfalls mit einem Klick ausgerollt werden. Die IoT Solution Accelerators gibt es für verschiedene Szenarien wie die Connected Factory oder für Predictive Maintenance. Da der Source-Code vorliegt, können diese bis ins kleinste Detail angepasst und Azure-Dienste auch beliebig ausgetauscht werden.
Noch nicht anpassbar genug? Dann stellt Azure noch verschiedenste PaaS-Technologien zur Verfügung, die helfen, eine eigene IoT-Plattform zu erstellen. Diese Technologien lassen sich in vier Kategorien einteilen: Device Support, IoT, Data/Analytics und Visualization/Integration. Unterschieden wird in Abb. 1 zwischen IoT-Services in gelb und allgemeinen Azure-Services in blau.
In die Kategorie Device Support fallen Technologien wie z. B. das Azure IoT Device SDK, mit dem sich Geräte an Azure IoT in unterschiedlichen Programmiersprachen wie C, C++ oder C# anbinden lassen. Hier findet man auch Windows 10 IoT, welches ein speziell für IoT-Devices ausgelegtes Betriebssystem ist.
Die Kategorie IoT beinhaltet alle IoT-relevanten Technologien wie den Azure IoT Hub zum Provisionieren von Geräten und Senden von Nachrichten zwischen Cloud und Device in verschiedenen Protokollen wie MQTT, AMQP und HTTP. Bei Data/Analytics und Visualization/Integration findet man allgemeine Azure-Dienste, die für diese Aufgaben im IoT-Umfeld verwendet werden können, wie z. B. Azure HD Insight zum Analysieren von Daten oder Microsoft Flow für die Integration mit anderen Systemen.
Letztendlich ist die Frage, die sich jeder stellen muss, ob die Entwicklung einer eigenen IoT-Plattform notwendig ist oder ob für den Anfang nicht eine fertige Lösung mit IoT Central oder den IoT Solution Accelerators ausreicht. Der Vorteil von beiden Lösungen ist, dass die Azure-Dienste im Hintergrund die gleichen sind, wodurch eine Umstellung auf eine eigene Lösung einfacher ist.
IIoT am praktischen Beispiel
Da ein Anwendungsfall am Beispiel einer echten Maschine immer auch ein gewisses Domänenwissen erfordert, zeigen wir eine exemplarische Anbindung mithilfe unserer Taktstraße, die sehr übersichtlich gestaltet ist und kein Domänenwissen erfordert.
Die Taktstraße ist ein fischertechnik-Modell das zwei Bearbeitungsstationen besitzt und automatisiert Werkstücke bearbeitet (s. Abb. 2). Die erste Bearbeitungsstation ist ein Bohrer und die zweite ein Fräser. Das Besondere ist, dass die Taktstraße von einer Siemens SIMATIC S7 1500 gesteuert wird. Die lokale Bedienung der Maschine wird durch ein angeschlossenes HMI (Human Machine Interface) ermöglicht. Das Ziel ist, die gelieferten Daten in der Cloud auswerten und Interaktionen aus der Cloud heraus auf der Maschine auslösen zu können. Es wird keine reine Monitoring-Lösung angestrebt, sondern es soll ein wirklicher Mehrwert durch intelligente Interaktionen geliefert werden.
Weiterhin wird durch die Siemens-Steuerung ein OPC UA Server bereitgestellt. Der OPC UA Server ermöglicht eine recht einfache und standardisierte Anbindung und bildet die Basis, um die Daten letztlich an eine Cloudlösung anzubinden. Natürlich können auch Maschinen angebunden werden, die keinen OPC UA verwenden, jedoch wird die Vernetzung deutlich vereinfacht, wenn auf OPC UA aufgebaut werden kann.
Nun wird lediglich noch eine Cloudlösung benötigt, die die Daten entsprechend visualisieren kann. Wie bereits dargestellt, kommt ein IoT Solution Accelerator oder IoT Central in Frage. Da wir uns in diesem Anwendungsfall voll auf die Vernetzung konzentrieren möchten und nicht noch eine eigene Cloudlösung entwickeln wollen, haben wir uns für IoT Central entschieden.
Doch wie kommen die Daten vom OPC UA Server nach IoT Central? IoT Central stellt einen IoT Hub zur Verfügung, der für die Übertragung von Telemetriedaten verwendet werden kann. Jetzt fehlt nur noch die Funktionalität, um auf dem Device den OPC Server anzusprechen und die Daten an den IoT Hub zu schicken. Und genau hier kommt das Thema Edge Computing ins Spiel.
Was ist eigentlich Edge Computing?
Generell beschreibt Edge Computing die dezentrale Datenverarbeitung am Rande des Netzwerks (der sogenannten Edge). Dadurch ergibt sich die Möglichkeit Daten und Dienste zumindest teilweise an Ort und Stelle zu verarbeiten. Anschließend können bearbeitete oder aggregierte Daten dennoch mittels Edge Device in die Cloud geschickt werden.
In der Regel wird nicht angestrebt, dass die Maschinen direkt mit dem Internet verbunden sind (s. Abb. 2). Dies ist meist schon aus Sicherheitsgründen bedenklich. Damit weiterhin keine direkte Internetanbindung erforderlich ist, wird ein IoT Edge Device eingesetzt. Dieses besitzt zwei Netzwerkschnittstellen, über die es mit dem Maschinennetzwerk und dem Internet verbunden ist und dient so als zentrales Gateway ins Internet. In diesem Fall muss nur dieses Gerät speziell abgesichert werden und nicht jede Maschine einzeln. Auch ergibt sich daraus der Vorteil, dass nur das Edge Device up to date gehalten werden muss. Zwangsläufig ist es natürlich notwendig, auch die Maschinen aktuell zu halten, denn man weiß nie, wer im Maschinennetzwerk unterwegs ist.
Für unseren Zweck nutzen wir Azure IoT Edge [4]. Dieses bringt eine eigene Open-Source-Runtime mit, welche direkt auf dem Edge Device installiert werden kann. Durch die Edge Runtime ergeben sich viele Vorteile.
Mit der direkten Anbindung an den IoT Hub können aus Azure neue Funktionalitäten in Form von Edge-Modulen auf das Edge Device ausgeliefert werden. Diese Edge-Module sind nichts anderes als Docker-Container, die über eine Docker-Registry von der Runtime auf das Edge Device geladen und dort isoliert ausgeführt werden. Jedes Edge-Modul kann Nachrichten an den IoT Hub senden und auch wieder empfangen. So können einfach neue Funktionalitäten nachgeliefert werden, um z. B. Daten zu transformieren, bevor diese an die Cloud geschickt werden oder um Datenquellen wie z. B. OPC UA anzubinden. Dadurch muss nicht von Anfang an jedes Protokoll unterstützt werden. Die Edge Devices können so ad hoc mit weiteren Funktionen nachgerüstet werden.
Um die Daten eines OPC UA Servers anzubinden, gibt es von Microsoft bereits das OPC-Publisher-Modul [5]. Dieses ermöglicht es über Konfiguration auf dem Edge Device, den OPC UA Server anzubinden und bei Änderung von Werten, diese an den IoT Hub zu schicken. Der Vorteil ist, dass wir nur ein Edge Device brauchen, um mehrere Maschinen an die Cloud anzubinden. Wie viele Maschinen angebunden werden können, hängt dabei von der Hardware ab.
Ein weiterer Vorteil von IoT Edge ist das Routing von Nachrichten. So kann konfiguriert werden, welche Nachrichten von welchen Modulen wohin fließen. Dabei kann das Ziel entweder ein anderes Modul oder der IoT Hub sein. Dadurch kann z. B. eine Datenpipeline aufgebaut werden, bei der sich Module die Daten gegenseitig zuspielen. So muss das OPC-Modul nicht wissen, dass es noch andere Module gibt, die dafür verwendet werden, die OPC-Daten zu filtern, zu transformieren oder anzupassen. Auch können beliebige Daten an andere Ziele als den IoT Hub geschickt werden. Wer seine Daten z. B. lieber in einer anderen Cloud oder IoT-Plattform haben möchte, schreibt sich einfach selbst ein Modul, welches die Übermittlung der Daten an eine andere Zielplattform übernimmt.
Falls die ständige Verbindung ins Internet ein Problem darstellt, kann auch noch zusätzlich die Offlinefähigkeit von IoT Edge verwendet werden. Diese ist dafür ausgelegt, dass Nachrichten für einen gewissen Zeitraum zwischengespeichert werden, sollte z. B. die Internetverbindung ausfallen. Zusätzlich können IoT Devices, die an dem Edge Device hängen, auch in einem Offlineszenario noch miteinander kommunizieren. So kann auch eine Machine-to-Machine-Kommunikation ermöglicht werden, bei der keine Internetverbindung nötig ist. Die Frage die sich am Ende jedoch stellt ist: Wie sicher ist eigentlich die Übertragung der Daten in die Cloud?
Wie steht es um die Sicherheit?
Spätestens wenn es um das Senden von Daten in die Cloud geht, muss auch das Thema Security näher betrachtet werden. Wie wird sichergestellt, dass Daten sicher übertragen werden, nicht manipuliert sind und am richtigen Ziel ankommen? Hier stellt Azure mit seinen Services eine End-to-End-Security sicher.
Durch den Azure IoT Hub ist die Kommunikation zwischen Device und Cloud stets auf der Transportschicht verschlüsselt, wodurch Daten sicher übertragen werden. Durch Nachrichtensignaturen wird validiert, dass Nachrichten auf dem Weg nicht manipuliert wurden. Auch das Thema Verfügbarkeit des IoT Hub wird durch die Einschränkung von Nachrichtengröße und Anzahl der Nachrichten pro Sekunde sichergestellt. Somit kann kein einzelnes Device den IoT Hub zum Absturz bringen.
Das Azure IoT Client SDK kann für die Authentifizierung des Devices auf Keys bzw. Device Zertifikate über ein HSM (Hardware Security Module) out-of-the-box zugreifen. Mit Azure Sphere [6] bietet Microsoft einen Microchip inklusive angepasstem Linux-Betriebssystem, das speziell für IoT Devices ausgelegt ist und die zusätzliche Schicht an Sicherheit schon auf Hardwareebene mitbringt.
Die Azure IoT Edge Runtime beinhaltet einen eingebauten Security Daemon [7], welcher auf Softwareebene sicherstellt, dass Devices über Zertifikate berechtigt sind, Nachrichten an den IoT Hub zu verschicken. Des Weiteren gibt es an dieser Stelle eine direkte Integration mit dem HSM für die Verwaltung von Keys und Zertifikaten sowie direkte Verschlüsselung von Konfiguration beim Persistieren auf der Festplatte.
Wer zusätzlich noch Monitoring von Security benötigt, kann auf das Azure Security Center for IoT [8] zurückgreifen. Dieses bietet für IoT Devices und IoT Services neben Security Policies, die dafür sorgen, dass Devices nach Vorgabe konfiguriert wurden, auch proaktives Alerting, basierend auf festen Regeln oder durch intelligente Bedrohungserkennung.
Sind die Daten erstmal in der Cloud, werden diese standardmäßig nicht vom IoT Hub persistiert. Diese können jedoch an einen Azure Blob Storage weitergeleitet werden, um diese zu archivieren. Innerhalb eines Azure Blob Storage erfolgt die Ablage immer verschlüsselt [9].
Ausblick
Wie bereits eingangs erwähnt, gibt es verschiedene Wege, die übertragenen IoT-Daten geeignet zu visualisieren. Möchte man diesen Aufwand geringhalten, so liegt die Entscheidung nahe, IoT Central zu verwenden. Dafür müssen Nachteile hinsichtlich Erweiterbarkeit und Modifizierbarkeit hingenommen werden. Daher kann man sich nun die Frage stellen, ob eine spätere Migration durch geänderte oder neu hinzugekommene Anforderungen dennoch möglich ist.
Die Antwort lautet "Ja", die Daten können in andere Systeme übertragen werden. Dafür gibt es verschiedene Punkte, an denen die Daten exportiert werden können. Sollen die Daten z. B. bereits in lokale Systeme exportiert werden, bevor diese in die Cloud übertragen werden, so kann das Edge Device die Daten direkt zum Zielsystem übertragen. Auf der Cloudseite ist ebenfalls eine Datenmigration möglich, hierfür muss evtl. eine Aufbereitung und ein Mapping auf das Zieldatenformat vorgenommen werden.
Einmal in der Cloud angekommen stellt sich nur noch die Frage, ob ein Hot- oder Cold-Path-Processing benötigt wird. Worin unterscheiden sich diese Ansätze?
- Beim Cold-Path-Processing werden Daten stapelweise zu einem bestimmten Zeitpunkt abgeholt und in ein anderes System übertragen. Durch die Verzögerung eignet sich dieses Verfahren für Daten, die archiviert werden sollen oder sich nicht besonders oft ändern.
- Beim Hot-Path-Processing geht es darum, die Daten möglichst ohne Verzögerung in das neue Zielsystem zu leiten, um dort wiederum Aktionen basierend auf eintreffenden Daten auslösen zu können.
Durch die volle Vernetzung lassen sich Industrie-4.0-Szenarien ermöglichen. So wäre es durchaus praktisch, wenn die Maschine sich selbst bei dem Dienstleister meldet, der ihre Wartung übernimmt und einen Techniker bestellt. Dem Techniker sendet die Maschine die aktuelle Konfiguration und alle notwendigen Parameter zu. An diesem einfachen Beispiel ist zu sehen, wie schnell die Unternehmensgrenzen verlassen werden. Wenn die Maschine selbständig alle notwendigen Daten zum Dienstleister überträgt, so ist eine Automatisierung des Prozesses möglich. Wenn tiefergreifende Erkenntnisse aus den Daten gewonnen werden sollen, wäre das Thema Machine Learning relevant. Im Falle von Microsoft ist es möglich, Machine Learning in ein Hot-Path-Processing zu integrieren.
Ein kleines Beispiel für Machine Learning im Kontext der Taktstraße wäre z. B. das Thema Predictive Maintenance. Sofern genügend Sensorwerte und Parameter der Machine gespeichert werden, können diese verwendet werden, um ein Machine-Learning-Modell zu trainieren. Dieses könnte dann in der Zukunft dem Wartungsdienstleister einen Auftrag zum Wechsel von Sensoren geben, noch bevor diese defekt sind. Die Auswertung kann dabei entweder in der Cloud erfolgen oder dank eigenem Machine-Learning-Edge-Modul direkt auf dem Edge Device.
All dies sind lediglich erste Eindrücke von Einsatzmöglichkeiten, die jederzeit nach Bedarf ausgebaut werden können, da die komplette Infrastruktur bereits vorhanden ist. Die Frage ist nur noch, welche Daten in welchem System benötigt werden.
Fazit
Es wurde aufgezeigt, wie der Weg in Richtung Digitalisierung und Industrie 4.0 bestritten werden kann. Daraus ist auch erkenntlich, dass die Technologien bereits verfügbar sind und ein sinnvoller Aufbau relativ leicht geschaffen werden kann. Dies ebnet nicht nur den Weg für aktuelle Anforderungen, sondern auch für zukünftige Anforderungen im Industrie-4.0-Zeitalter. Je früher mit der Anbindung begonnen wird, desto weniger Gedanken muss man sich machen, wenn Industrie 4.0 zum Hygienefaktor wird.
Ein wesentlicher Aspekt ist, dass der Anwendungsfall im Mittelpunkt steht und man sich dahingehend ausreichend Gedanken machen sollte, bevor eine solche Lösung angestrebt wird. Weiterhin ist es empfehlenswert, sich von den aktuellen Beschränkungen der Systeme zu lösen und sich rein darauf zu konzentrieren, welches Szenario einen Mehrwert für das Unternehmen selbst und auch dessen Kunden liefern kann.
Am Ende gilt: Lieber anfangen, als sich zu lange mit der Theorie zu beschäftigen. Das Übertragen der Daten funktioniert heute schon relativ einfach, die weiteren Anwendungsfälle ergeben sich danach.