Architektur von IoT Lösungen mit Microsoft Azure
Auch IoT Lösungen mit Microsoft Azure zeichnen sich durch ein paar Besonderheiten in Bezug auf Komplexität, Skalierung, Stabilität und Nachhaltigkeit einer möglichen Architektur aus. Mit jedem neuen Gerät wächst die Zahl an gesammelten und zu verarbeitenden Daten. Sind Geräte erstmal „in der Wildnis“, sprich ausgeliefert, so können Änderungen, wie z.B. ein anderes Kommunikationssystem oder -protokoll entweder gar nicht oder nur mit größerem Aufwand umgesetzt werden.
Ebenso sollte man das Thema Sicherheit im Auge behalten. Mit der Microsoft Azure IoT Reference Architecture beschreibt Microsoft, wie eine empfohlene Architektur und Implementierung für eine Azure IoT Lösung aussieht. Diese Architektur beschreibt die Terminologie, technologische Grundlagen, die Zusammenstellung der Azure IoT Services sowie Devices beziehungsweise Edge-Devices.
Für IoT Lösungen mit Microsoft Azure schlägt Microsoft eine Architektur auf Basis der folgenden Grundannahmen vor:
- Cloud-native (https://www.cloudcomputing-insider.de/was-ist-cloud-native-a-669681/)
- Microservices (https://de.wikipedia.org/wiki/Microservices)
- Serverless (https://en.wikipedia.org/wiki/Serverless_computing, https://www.heise.de/ratgeber/Mit-Java-serverless-in-die-Cloud-3756877.html)
Die IoT Lösung setzt sich aus unabhängigen Services zusammen, die sich getrennt voneinander deployen, skalieren, updaten etc. lassen.
IoT Central
Bevor man sich jedoch an die Umsetzung einer neuen IoT Lösung machen sollte, wird darauf hingewiesen, auch das SaaS (Software-as-a-Service) Angebot von Microsoft mit IoT Central zu evaluieren, mit dem man sich möglicherweise, sofern es die Anforderungen zulassen, viel Aufwand bezüglich Entwicklung und Betrieb der IoT Lösung ersparen könnte.
IoT Central ist eine fertige IoT-Lösung, um Geräte zu verwalten, Daten von Geräten zu empfangen und zu visualisieren, Alarme auf Basis der empfangenen Daten auszulösen und Geräte aus der Cloud steuern zu können. Wie ein Gerät für die Lösung aussieht, ist konfigurierbar, ebenso wie Regeln für Alarme oder Dashboards, die Werte visualisieren.
Bei zusätzlichen Anforderungen an die Lösung wie z.B. Anpassung des Designs des Portals, Änderung der Benutzeranmeldung, Bereiche für Kunden oder Standort-Informationen, sowie über den Standard hinausgehender Anforderungen an die Visualisierung der Daten, wird dann an der individual entwickelten Lösung kein Weg vorbei führen.
Kernkomponenten von IoT Lösungen
IoT Lösungen bestehen zumindest aus den folgenden Komponenten:
- Devices bzw. auch in Verbindung mit Edge-Devices, die sich mit der Cloud verbinden und Daten senden und bzw. oder empfangen können.
- Ein Cloud Gateway Service oder Hub für Devicemanagement und zum Senden und Empfangen von IoT Daten.
- Stream Processors: Services oder Applikationen zum Analysieren, Aggregieren, Transformieren und Weiterleiten des Datenstroms vom IoT Hub. Diese schreiben die Daten in einen Speicher für z.B. ein Datenarchiv oder erstellen Ereignisse aus dem Datenstrom, die dann an einen Business-Prozess weitergeleitet werden um gewisse Aktionen ausführen lassen zu können.
- Datenspeicher: üblicherweise benötigen unterschiedliche Arten der Daten verschiedene Datenspeicher. Das kann zum Beispiel Storage für ein Archiv der Rohdaten sein, ebenso wie eine Zeitseriendatenbank für rasche Auswertungen und Visualisierung von Sensorwerten, sowie vorberechnete Ereignisse oder Aggregate von Daten für die Visualisierung.
- UI & Reporting Tools: Möglichkeit für Benutzer:innen, gesammelte Informationen in aufbereiteter Form betrachten zu können. Üblicherweise Webportal oder mobile Apps, die einen Überblick über den Status der Geräte und Darstellung der gesammelten Daten bieten.
- Integration mit Geschäftsprozessen: Beim Auftreten gewisser Ereignisse wie Alarmen oder gewissen Grenzwerten in den Telemetriedaten müssen Daten an Services oder Applikationen weitergeleitet werden, die dann entsprechende Aktionen auslösen.
Zusätzlich zu diesen Systemen können noch weitere erforderlich sein:
- Datenverarbeitung am Edge-Device, um Daten schon on-premise analysieren, aggregieren oder transformieren zu können
- Machine Learning, um aus historischen Daten Vorhersagen treffen zu können
- Benutzerverwaltung, um verschiedenen Benutzerrollen verschiedene Funktionen bzw. Ansichten auf die Daten bieten zu können.
Für alle diese Systeme kommen dann noch Anforderungen in Bezug auf Sicherheit, Monitoring des Systems, Logging, hohe Verfügbarkeit, Wiederherstellung im Katastrophenfall, automatisiertem Deployment etc. dazu.
Typische Architektur einer IoT Lösung mit Microsoft Azure
Die oben angeführten Überlegungen umgesetzt mit Services von Microsoft Azure ergeben folgende typische IoT-Architektur, wenn auch nicht immer alles in diesem Umfang notwendig sein wird:
Auf der linken Seite findet man die Daten sammelnden Geräte, die von der IoT-Lösung überwacht und gesteuert werden sollen.
IoT Hub von Microsoft Azure
Im einfachen Fall ist das ein mit dem Internet verbundenes Device (1) das Daten an den Azure IoT Hub überträgt.
Der IoT Hub (2) stellt sichere und skalierbare Kommunikation der Geräte mit der Cloud zur Verfügung. Einerseits von Gerät zur Cloud und andererseits auch von der Cloud zurück ans Gerät.
Microsoft bietet mit den Azure IoT Device SDKs Bibliotheken für verschiedenste Umgebungen (.net, Java, C etc) an. Diese beinhalten die Anbindung des Gerätes selbst an den IoT Hub oder die Integration des IoT Hubs in eigene Lösungen.
Ebenso bietet der IoT Hub Funktionen zum Managen der angeschlossenen Geräte an. Dabei hat jedes Gerät seine eigene Identität mit Zugangsdaten oder Zertifikaten. Jedes Gerät kann außerdem unabhängig von anderen Geräten aktiviert oder deaktiviert werden.
In simplen Fällen können Geräte selbst im IoT Hub angelegt, geändert oder deaktiviert werden. Diese Funktionalität wird auch über APIs angeboten. Dadurch haben Entwickler:innen die Möglichkeit, diese Funktionen in eigenen Applikationen zu integrieren.
Device Provisioning Service
Sollte die einfache Geräteverwaltung über den IoT Hub nicht ausreichen, so bietet das Device Provisioning Service (3) die Möglichkeit Geräte z.B. über Informationen am TPM Chip automatisch mit dem gewünschten IoT Hub zu verbinden. In diesem Fall würde ein Gerät zuerst nur seine Instanz des Device Provisioning Service kennen und beim Starten dort um seine IoT Hub Konfiguration anfragen.
Damit wird ein geschlossener und sicherer Prozess von der Produktion eines Gerätes bis zur Inbetriebnahme ohne manuellen Eingriff gewährleistet.
Edge Device
Eine andere Möglichkeit, die vor allem im industriellen Umfeld oft anzutreffen ist, sind Geräte oder Maschinen (4), die über ein Gateway beziehungsweise Edge Device (5) mit dem Internet verbunden sind. Dies ist notwendig, falls die Maschinen nicht direkt mit dem Internet verbunden werden können, sollen, oder falls Daten vorab aufbereitet, aggregiert oder lokal verarbeitet werden müssen. Damit hat man die Möglichkeit die zu übertragende Datenmenge noch im Netzwerk der Maschine zu bestimmen. Ebenfalls kann eine Datenanalyse durchgeführt werden und daraus resultierende Entscheidungen rasch getroffen werden, ohne Umwege über die Cloud gehen zu müssen.
Zur Kommunikation zwischen Maschine und Edge Device bietet sich OPC UA an, da es sich immer mehr zur „lingua franka“ im Bereich Maschinen-zu-Maschinen-Kommunikation entwickelt, UPC UA wäre auch in der oben gezeigten Grafik enthalten, es wären aber auch andere Protokolle grundsätzlich möglich.
Das Edge Device bietet eine Container-Laufzeitumgebung, die über den IoT Hub und dessen Edge Device Verwaltung in der Cloud konfiguriert werden kann. So kann man aus der Ferne steuern, welches Edge Device welche Softwarepaketes in welcher Version ausführen sollen. Damit wird erreicht, dass die Software aus der Ferne überwacht, aktualisiert oder angepasst werden kann, ohne direkten Zugriff auf das System zu haben.
Auf dem Edge Device können üblicherweise mehrere Module (oder Container) eingesetzt werden. Das erste Modul sammelt z.B. über OPC UA Daten von Maschinen und gibt diese Daten an das interne „Bussystem“ des Edge Devices weiter.
Ein ebenfalls aus der Ferne konfigurierbares Datenrouting bestimmt dann wohin, also in welche anderen Module bzw. Container und zusätzlich an einen Datenendpunkt in der Cloud (2), welche Daten gesendet werden sollen. Sollten Verbindungen zu Modulen oder in die Cloud nicht verfügbar sein, so kümmert sich die Runtime-Umgebung um die temporäre Zwischenspeicherung der Daten.
Module
Bezüglich Möglichkeiten an Modulen, die am Edge Device eingesetzt werden könnten, sind kaum Grenzen gesetzt. Grob gesagt kann jede Applikation, Service, Datenbank etc., die sich in einem Container betreiben lässt, eingesetzt werden.
Besonders hervorheben sollte man aber Module wie:
- Azure Stream Analytics: Dieses Service dient zur Echtzeit-Analyse von Datenströmen. Damit kann man z.B. Über- oder Unterschreitungen von Messwerten oder deren Abweichungen zu einem längerfristigen Trend erkennen. Diese kann man gezielt weiterleiten oder um einzelne Messwerte in gewissen Zeitfenstern aggregieren. Außerdem kann man aus 60 Einzelwerten pro Minute einen Durchschnittswert pro Minutenintervall errechnen, der für eine weitere Verarbeitung wichtig ist.
- Machine Learning Modelle: Machine Learning Modelle können ebenfalls als Container ausgeliefert werden und sind damit auf Edge Devices lauffähig. Damit könnte man lokal Szenarien wie frühzeitige Erkennung von Fehlern oder optimierte Wartungsintervalle umsetzen.
- Azure Functions: Mit Azure Functions am Edge Device hat man die Möglichkeit Business-Logik mit dem selben einfachen Programmiermodell zu erstellen wie es in der Cloud mit Azure Functions schon lange angeboten wird. Die Entwickler:innen schreibt nur den Code für die jeweilige Funktionalität, also die Funktion selbst. Die Runtime kümmert sich selbst um die Aktivierung und Ausführung des Codes.
Damit kann man rasch z.B. Ereignisse im Datenstrom analysieren oder Integrationen zu anderen Systemen wie Datenbanken, ERP-Systemen, externen Bussystemen usw. implementieren.
Cloud Lösung
Die Geräte senden Daten an den IoT Hub und stehen dort für eine weitere Verarbeitung zur Verfügung.
Cold Path
Beim „Cold Path“ (5) geht es darum die Daten zu archivieren. Dazu bietet sich Azure Storage als Dienst an. Der Preis von Storage richtet sich nach dem benötigten Speicherplatz. Somit ist er im Vergleich zu Diensten, die auch mit Rechenleistung verbunden sind, wie z.B. Datenbanken, extrem günstig. Dafür kann man jedoch nicht mehr so schnell nach gewissen Daten suchen, wie es Datenbanken anbieten würden. Das ist aber für ein Archiv üblicherweise auch nicht notwendig.
In der einfachsten Variante legt man die Nachrichten in einen Blob-Speicher als simple Datei oder in Tabellen ab. Ebenso denkbar wäre auch die Verwendung von Data Lake Storage um dann mit Bigdata-Analysetools die Daten auszuwerten.
Das Datenarchiv dient später für Analyse der Daten und vor allem als Basis für Machine Learning.
Hot Path
Der „Hot Path“ (6) analysiert den eingehenden Datenstrom. Beispielweise mit Hilfe von Stream Analytics nach wichtigen Ereignissen, wie Grenzwertüberschreitungen oder Fehlermeldungen. Diese leitet er an andere Dienste weiter, die dann selbst Aktionen auslösen oder entsprechende Daten an eine andere Applikation weiterleiten.
In der gezeigten Grafik würde Stream Analytics (7) Ereignisse erkennen und dann an entsprechende Queues in Azure Service Bus (8) weiterleiten.
Hinter diesen Queues führen dann Azure Functions Code (9) aus, sobald eine Message an das Bussystem gesendet wird. Damit könnte man z.B. Steuernachrichten zurück an ein Gerät senden (10) oder eine Integration zu einem anderen System selbst implementieren. Oder man nimmt dafür Logic Apps (11) um grafisch Workflows zu designen, fertige Integrationsadapter für SaaS-Lösungen oder Enterprise Applications zu verwenden und EAI, B2B und EDI – Geschäftsprozesse zu automatisieren.
Visualisierung bei IoT Lösungen
Zur Visualisierung der Daten gibt es aus dem Angebot von Azure verschiedenste Möglichkeiten, das Thema zu adressieren. In der Grafik wird das durch den gelben Bereich (12,13,14) dargestellt.
Mit Time Series Insights (12) erhält man End-to-End Lösung zur Speicherung von Sensor- und Maschinendaten sowie zur Visualisierung und Ad-Hoc Analyse dieser Daten. Time Series Insights koppelt sich direkt mit dem IoT Hub (2) und holt automatisch von dort Daten ab.
Sollten die vorgefertigten Möglichkeiten von Time Series Insights bezüglich Visualisierung nicht ausreichen, so könnte man die IoT Lösung um eine eigene individuell entwickelte Weblösungen oder Berichte in Azure WebApps (13) oder PowerBI (14) ergänzen.
Datenverarbeitung und -speicherung
Time Series Insights (12) kümmert sich selbst um die optimale Datenhaltung von Maschinendaten bzw. Zeitseriendaten. Dieses Service kann auch nur als Datenbank, ohne die Verwendung der Analyse- und Visualisierungsmöglichkeiten, eingesetzt werden. Es lohnt sich dennoch den Preis der fertigen Zeitseriendatenbank beim jeweiligen Mengenmodell den unten angeführten Möglichkeiten gegenüberzustellen.
Für die darüber hinaus gehenden selbst entwickelten Lösungen zur Visualisierung in einem Webportal oder mit PowerBI Berichten, wird noch üblicherweise eine Datenbank oder zumindest irgendeine Form von Datenspeicher für die anzuzeigenden Werte benötigt.
In der oben dargestellten Grafik aktiviert das Eintreffen von IoT Daten am IoT Hub Azure Functions (15). Dann bereitet es die Daten auf (aggregieren, vorberechnen, bereinigen etc.). Im einfachsten Fall in eine SQL-Datenbank (17). Im üblicheren Fall sollte Skalierung der Lösung ein Thema sein, in eine CosmosDB (16) schreiben.
Die Kunst bezüglich Speicherung der Daten liegt im Finden der richtigen Balance zwischen Performance beim Datenzugriff und Preis der Cloud-Dienste. Die richtige Balance ist ebenfalls wichtig bei der Aufteilung der Daten auf das jeweils optimal passende System. Gleichermaßen ist die Partitionierung der Daten relevant, um auch bei hohen Datenmengen skalierbar zu bleiben.
Übergreifende Anforderungen einer IoT Lösung mit Microsoft Azure
Zusätzlich zu den oben beschriebenen Services kommen ergänzend noch Komponenten für die angesprochenen Themen wie Sicherheit, Monitoring, Logging etc. dazu.
Hier seien vor allen die Dienste Azure Active Directory und Azure Active Directory B2C erwähnt, über die einerseits die Berechtigungen der Azure Dienste gemanagt werden und mit Active Directory B2C ein Identity Provider für externe Benutzer:innen angeboten wird.
Zum Thema Betrieb und Monitoring der Lösung beantwortet Application Insights alle Fragen rund um die Verfügbarkeit, die Performance und Fehlersituationen von Webservices und Webanwendungen, wie in oben angegebener Architektur das Webportal.
Fazit zu IoT Lösungen mit Microsoft Azure
Mit diesen Diensten erhält man einen mächtigen Werkzeugkasten. Damit kann man individuell entwickelte, skalierbare und hochverfügbare IoT Lösungen mit Microsoft Azure zu erstellen. Diese Services bieten fertige Bausteine, die jeder für sich technische Herausforderungen an eine moderne Softwarelösung abdecken.
Richtig kombiniert und eingesetzt kommt man damit rasch und sicher zu einer individuell entwickelten, hochverfügbaren und -skalierbaren Lösung.