Im vorhergehenden Beitrag “IoT zum Anfassen – Azure IoT Edge” wurden die Grundlagen von Azure IoT Edge dargestellt. In diesem Zusammenhang wurden auch Edge Module, als Möglichkeit eigene Geschäftslogik sowie unterstützende Azure Services auf Edge Devices zu deployen und auszuführen, angesprochen. Doch wie sehen Module nun konkret aus?
Das kleine Einmaleins für IoT Edge Module
Das Gesamtbild von Modulen ergibt sich aus dem Zusammenspiel vier konzeptioneller Puzzleteile:
Ein Module Image ist ein Softwarepaket, welches das Modul in seiner Gesamtheit definiert und wird über eine Container Registry in der Cloud verwaltet. Jedes Mal wenn ein solches Module Image auf ein Edge Device deployed und von der IoT Edge Runtime gestartet wird, wird dabei eine neue Module Instance erzeugt. Die Module Instance ist die konkrete Recheneinheit, welche als Container auf einem Device läuft und dort das Module Image ausführt. Damit kann auf verschiedenen Devices dasselbe Image ein oder mehrmals ausgeführt werden, wobei für jede Ausführung eine eigene Module Instance erzeugt wird (vgl. Abbildung 1).
Jede Module Instance besitzt wiederum eine eigene Module Identity. Diese wird im IoT Hub gespeichert und enthält benötigte Informationen zur Kommunikation mit der Module Instance. Der Name der Module Identity setzt sich aus den folgenden Teilen zusammen: devices/<deviceName>/modules/<moduleName> (vgl. Abbildung 2).
Nicht zuletzt besteht zu jeder Module Instance ein separater Module Twin. Dies ist ein JSON-Dokument, welches ebenso wie die Module Identity im IoT Hub gespeichert und über die Module Identity einer Module Instance zugeordnet wird.
Der Module Twin beschreibt Informationen sowie Konfigurationseigenschaften einer Module Instance. Ein wesentlicher Teil dabei sind sogenannte Properties, welche für die Synchronisierung der Modulkonfiguration oder -zuständen zwischen Backend und Modul verwendet werden (vgl. Abbildung 3). Während Reported Properties Eigenschaften bezeichnen, welche vom Modul geschrieben werden und vom Backend gelesen werden können, bezeichnen Desired Properties Eigenschaften, welche vom Backend gesetzt und vom Modul gelesen und verarbeitet werden können. Kurz gesagt bilden Reported Properties also den aktuellen Ist-Zustand und Desired Properties den Soll-Zustand ab.
Damit ist das Bild komplett: Module Image, Module Instance, Module Identity und Module Twin stellen das konzeptionelle Grundgerüst, um mit Modulen zu arbeiten. Freuen Sie sich nun darauf, im nächsten Blogbeitrag mehr darüber zu erfahren, wie eigene Module entwickelt werden können und welche Stolpersteine es zu beachten gibt.
Sprechen Sie uns an, wenn auch Sie Hilfe bei der Planung, Einführung oder Umsetzung von IoT und Industrie 4.0 in Ihrem Unternehmen benötigen. Wir führen Sie gerne ans Ziel.
Sie möchten mehr zum Thema IoT erfahren? Besuchen Sie doch unseren kostenlosen Workshop „IoT in a day – Von Null auf Cloud in einem Tag“ oder buchen Sie unseren zweitägigen IoT Proof of Concept-Workshop.