MENÜ
Hintergrundbild
IoT Azure

IoT Lösungen auf Basis von Microsoft Azure

Inklusive Details zur typischen Architektur von IoT Lösungen

Grundlegend kann eine IoT Lösung so beschrieben werden, dass Devices Daten generieren (generate data), aus diesen Daten Erkenntnisse gewonnen werden (insights) und aus diesen dann Aktionen abgeleitet werden (actions).

Architektur von IoT Lösungen

IoT Lösungen 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 geändert 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.

Microsoft schlägt für IoT eine Architektur auf Basis der folgenden Grundannahmen vor:

Die IoT Lösung sollte aus unabhängigen Services zusammengesetzt werden, 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 (https://azure.microsoft.com/de-de/services/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, also welche Eigenschaften es anbietet und welche Daten verarbeitet werden sollen 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.

Microsoft_Azure_IoT_Reference_Architecture.pdf (https://azure.microsoft.com/en-us/blog/azure-iot-reference-architecture-update/ )

Kernkomponenten von IoT Lösungen

IoT Lösungen bestehen zumindest aus den folgenden Komponenten:

  • Devices bzw. auch in Verbindung mit Edge-Devices (https://en.wikipedia.org/wiki/Edge_device), 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 werden nach Art der Daten verschiedene Datenspeicher benötigt. 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, 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

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 Geräte, die Daten sammeln beziehungsweise von der IoT-Lösung überwacht und auch gesteuert werden sollen.

IoT Hub

Im einfachen Fall ist das ein direkt 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.

Für die Anbindung des Gerätes selbst an den IoT Hub oder die Integration des IoT Hubs in eigene Lösungen bietet Microsoft mit den Azure IoT Device SDKs (https://docs.microsoft.com/en-us/azure/iot-hub/iot-hub-devguide-sdks) Bibliotheken für verschiedenste Umgebungen (.net, Java, C etc) an.

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 bzw. jedes Gerät kann 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. Natürlich wird diese Funktionalität auch über APIs angeboten um Entwickler die Möglichkeit zu geben, 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 (siehe …) automatisch mit dem gewünschten IoT Hub, z.B. auch nach Regionen aufgeteilt, 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, sowie Datenanalyse und daraus resultierende Entscheidungen rasch treffen zu können, ohne Umwege über die Cloud gehen zu müssen.

Zur Kommunikation zwischen Maschine und Edge Device bietet sich OPC UA (https://de.wikipedia.org/wiki/OPC_Unified_Architecture) 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 (https://www.docker.com/resources/what-container), 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 auch 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 (https://github.com/Azure/iot-edge-opc-publisher) 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 könnte jede Applikation, Service, Datenbank etc., das sich in einem Container betreiben lässt, eingesetzt werden.

Besonders hervorheben sollte man aber Module wie:

  • Azure Stream Analytics (https://github.com/MicrosoftDocs/azure-docs/blob/master/articles/stream-analytics/stream-analytics-edge.md) : 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 und gezielt weiterleiten oder um einzelne Messwerte in gewissen Zeitfenstern aggregieren, so wie aus 60 Einzelwerten pro Minute einen Durchschnittswert pro Minutenintervall zu errechnen, der dann als Basis für eine weitere Verarbeitung dient.
  • Machine Learning Modelle (https://docs.microsoft.com/en-us/azure/iot-edge/tutorial-deploy-machine-learning): 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 (https://docs.microsoft.com/en-us/azure/iot-edge/tutorial-deploy-function): 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. Der Entwickler 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 Daten werden von den Geräten an den IoT Hub gesendet 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 (https://azure.microsoft.com/de-de/services/storage/) als Dienst an. Der Preis von Storage richtet sich nach dem benötigten Speicherplatz und ist 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 wie Apache Spark oder Hadoop 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, z.B. mit Hilfe von Stream Analytics nach wichtigen Ereignissen, wie Grenzwertüberschreitungen oder Fehlermeldungen und leitet diese an andere Dienste weiter, die dann selbst Aktionen auslösen oder entsprechende Daten an eine andere Applikation wie ein ERP-System weiterleiten.

In der gezeigten Grafik würde Stream Analytics (7) Ereignisse erkennen und dann an entsprechende Queues in Azure Service Bus (https://azure.microsoft.com/de-de/services/service-bus/) (8) weiterleiten.

Hinter diesen Queues würden dann entweder Azure Functions Code (9) ausführen, 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 (https://azure.microsoft.com/en-us/services/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

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) (https://azure.microsoft.com/de-de/services/time-series-insights/) 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 kann direkt mit dem IoT Hub (2) gekoppelt werden und automatisch von dort Daten abholen.

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 (https://azure.microsoft.com/de-de/services/app-service/web/) (13) oder PowerBI (https://powerbi.microsoft.com/de-de/) (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 jedoch in Hinblick auf die Betriebskosten der Lösung den Preis der fertigen Zeitseriendatenbank beim jeweiligen Mengenmodell den unten angeführten Möglichkeiten gegenüberzustellen.

Für die darüber hinausgehenden 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 würden z.B. durch das Eintreffen von IoT Daten am IoT Hub Azure Functions (15) aktiviert werden, die dann die Daten aufbereiten – aggregieren, vorberechnen, bereinigen etc. – und im einfachsten Fall in eine SQL Datenbank (17), oder im üblicheren Fall, sollte Skalierung der Lösung ein Thema sein, in eine CosmosDB (16) schreiben.

Die Kunst bezüglich Speicherung der Daten liegt hier im Finden der richtigen Balance zwischen Performance beim Datenzugriff und Preis der Cloud-Dienste, der richtigen Aufteilung der Daten auf das jeweils optimal passende System, sowie die Partitionierung der Daten um auch bei hohen Datenmengen skalierbar zu bleiben.

Übergreifende Anforderungen einer (IoT)-Lösung

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 (https://azure.microsoft.com/de-de/services/active-directory/)und Azure Active Directory B2C (https://azure.microsoft.com/de-de/services/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 angeboten wird.

Zum Thema Betrieb und Monitoring der Lösung beantwortet Application Insights (https://docs.microsoft.com/en-us/azure/azure-monitor/app/app-insights-overview) alle Fragen rund um die Verfügbarkeit, die Performance und Fehlersituationen von Webservices und Webanwendungen, wie in oben angegebener Architektur das Webportal.

Fazit

Mit den Diensten von Microsoft Azure erhält man einen mächtigen Werkzeugkasten um individuell entwickelte, skalierbare und hochverfügbare IoT – Lösungen zu erstellen. Diese Services bieten fertige Bausteine, die jeder für sich technische Hausausforderungen 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.

Interesse? Wir unterhalten uns gerne mit Ihnen!
Neueste Beiträge
IoT Lösungen auf Basis von Microsoft Azure
Inklusive Details zur typischen Architektur von IoT Lösungen
Grundlegend kann eine IoT Lösung so beschrieben werden, dass Devices Daten generieren (generate data), aus diesen Daten Erkenntnisse gewonnen werden (insights) und aus diesen dann Aktionen abgeleitet... mehr dazu
KEBA TrendTreff bei dataformers
Workshop mit 25 innovativen KEBAnern und aktuellen Microsoft-Technologien
Gemeinsam mit dem langjährigen Technologiepartner Microsoft initiierte dataformers einen Technologieworkshop für interessierte Teilnehmer der KEBA AG – dem unmittelbaren Büronachbarn am Standort Linz.... mehr dazu
Turbinenüberwachung und Kraftwerks-management mit IoT SCADA
Eine dataformers Success Story zum Thema „Industrial IoT“
HEROS Connect – gemeinsam entwickelt von GLOBAL Hydro und dataformers – bietet Betreibern und Investoren von Wasserkraftwerken eine Möglichkeit, alle Kraftwerke auf einer zentralen Plattform zu steuern,... mehr dazu