Azure IoT – News (Build 2018)

Hallo zusammen,

eine weitere Runde Updates vom Azure IoT Team habe ich noch. Diesmal von der Microsoft Build Conference 2018, die Anfang Mai in Seattle stattfand.

Was ist neu?

Kurze Antwort: Vieles und deshalb der Reihe nach.

Fangen wir erstmal, mit etwas einfachen an und zwar ein paar Namensänderungen:

Aus dem Azure Location Service (ein Dienst der es euch ermöglicht, in einem Dashboard die Daten von IoT Devices mit geographischen Bezug darzustellen) wird Azure Maps. Auch wenn der neue Name stark an Bing Maps erinnert. hat dieser Dienst doch einiges mehr zu bieten (z.B. in Form diverser APIs). Alles vorzustellen würde aber den Umfang des Artikels sprengen. Eine ausführliche Einführung folgt deshalb bald.

Zeitgleich mit der Namensänderung erhielt der Dienst übrigens auch den GA Status.

Die nächste Namensänderung betrifft die Azure IoT Suite. Wie ihr ja bestimmt schon wisst, ist die Azure IoT Suite eine Sammlung von sogenannten Pre Configurated Solutions, die ihr als Basis für eure IoT Solutions nutzen könnt. Ok, der Name Azure IoT Suite, ist nicht unbedingt aussagekräftigt und deshalb hört das Ganze jetzt auf den Namen Azure IoT Solution Accelerators. Passt irgendwie – oder?

Neben der Namensänderung bei der Azure IoT Suite, gabt es auch einige Verbesserungen unter der Haube (z.B. wurde Bing Maps durch Azure Maps ersetzt und die Integration von Cloud Services, wie beispielsweise Power BI, verbessert)

Jetzt aber genug mit den Formsachen. Kommen wir nun zu den zahlreichen weiteren Produktupdates und Erweiterungen.:

• Azure IoT Hub

Hier gab es Erweiterungen im Bereich des Device Management und beim Management von Modulen. Mit dem Automatic Device Management  könnt ihr Konfigurationen oder Bereitstellungen einmal festlegen und dann alle IoT Devices automatisch verwalten, sobald sie dem IoT Hub hinzugefügt werden. Dies ist perfekt in Szenarien, wo die Komplexität der Bereitstellung und Überwachung von Aktualisierungen in großem Umfang auftreten. Das Modul Twins Konzept ermöglicht euch eine fein abgestufte Verwaltung von Anwendungen auf IoT Devices und von Modulen innerhalb dieser Anwendung, z. B. bei einer IoT Edge-Bereitstellung.

• Azure IoT Edge

Der Bereich Azure IoT Edge ist der heimliche Gewinner der Build 2018. Hier gab es die meisten Updates und Erweiterungen. Was genau könnt ihr der folgenden Liste entnehmen:

• Support für Microsoft Cognitive Services: Nachdem ihr bereits Azure Functions, Azure Machine Learning, Azure Stream Analytics (ASA) und SQL Server Database auf einem IoT Edge Device zum Einsatz bringen konntet, ist dies ab sofort auch mit den Microsoft Cognitive Services (zurzeit nur Custom Vision) möglich. Eine ausführliche Einführung folgt in den nächsten Tagen.
• Support für C# Custom Code in ASA Jobs auf Azure IoT Edge
• Support für Kubernetes: Die Funktionalität des Azure IoT Edge wird durch (auf Docker basierende) Container bereitgestellt. Mit dem neuen Support für Kubernetes habt ihr nun die Möglichkeit, diese in einem Kubernetes Environment zu erstellen. Eine ausführliche Einführung folgt in den nächsten Tagen.
• Support für Azure Event Grid: Mit dem Support für Azure Event Grid sind jetzt auch Szenarien denkbar, die eine Routing Funktionalität benötigen.
• Azure IoT Edge Runtime wird Open Source: Azure IoT Edge und Open Source ist eigentlich nichts Neues, denn zu mindestens im Modulbereich ist es bereits gängige Praxis.  Durch den erweiterten Zugriff, nun auch auf den Quellcode der Runtime, erhalten Entwickler eine noch größere Flexibilität und Kontrolle über ihre Edge-Lösungen und die Möglichkeit die Runtime anzupassen oder Debug-Probleme zu lösen.

Das reicht euch noch nicht?

Ok, zwei Punkte habe ich noch:

• Microsoft hat die Gründung eines IoT Edge Marketplace innerhalb des Azure Marketplace angekündigt. Dort habt ihr dann die Möglichkeit eure Modulentwicklungen zu vermarkten
• Microsoft hat eine Azure IoT Edge Hardware Certification Category, innerhalb des Azure Certified for IoT Devices Program angekündigt

Jetzt aber genug für heute. Ein zweiter Teil des Artikels folgt 🙂

Liebe Grüße

Oliver

 

[Lesetipp] Azure IoT Reference Architecture

Hallo zusammen,

es ist nun schon über zwei Jahre her, da habe ich euch hier die Azure IoT Reference Architecture als Lesetipp vorgestellt. Inzwischen sind viele Produkte (Technologien) dazugekommen und der Ansatz für die Architektur wurde umfassend geändert.

Deswegen wird es jetzt auch endlich Zeit für:

Azure IoT Reference Architecture Version 2.0

Das Whitepaper ist nun 61 Seiten stark und deckt in kompakter Form alle relevanten Bereiche (z.B. Security, Device Connectivity etc.) ab.

Den Download des Whitepapers gibt es hier:

• https://aka.ms/iotrefarchitecture

Resümee: Sehr Lesenswert     

Achtung: Die Azure IoT Reference Architecture Version 2.0 ist Teil eines größeren Guidance Projekts  des Azure CAT Teams. Ihr könnt bald weitere Ergebnisse erwarten.

Schöne Grüße

Oliver

IoT School

Hallo zusammen,

vielleicht kennt der ein oder andere von euch schon die AI School von Microsoft. Die AI School ist das zurzeit umfassendste Trainingsangebot für den Bereich Künstliche Intelligenz und wird von vielen Usern für die Weiterbildung genutzt.

Da das Konzept sehr erfolgreich ist, hat sich Microsoft entschlossen das Angebot zu erweitern und deshalb gibt es ab sofort:

die IoT School

Zur Startseite der IoT School geht es hier:

• https://iotschool.microsoft.com/learning-paths

Mein Tipp: Back to School und das möglichst sofort 😉

Schöne Grüße

Oliver

Azure IoT – News (HM 2018)

Hallo zusammen,

mein Lieblingsupdate vom Azure IoT Team (Azure Sphere) hatte ich euch bereits in der letzten Folge vorgestellt (hier). Das war allerdings nicht alles was das Azure IoT Team zu bieten hat, denn auch auf der Hannover Industrie Messe 2018 wurde einiges geboten:

Meldung 1

Microsoft hat angekündigt, dass der Azure IoT Hub und der Azure IoT Hub Device Provisioning Service künftig auch auf Azure Stack verfügbar sein wird. So könnt ihr also künftig im Vorfeld entscheiden, ob ihr eure IoT Szenarios auf der Basis der Public Cloud oder als Teil einer Hybrid Cloud Lösung realisiert.

Meldung 2

Die nächste Meldung betrifft die Connected Factory PCS, der Azure IoT Suite. Hier wurde die Solution um einige Funktionen ergänzt (z.B. in Form von Azure IoT Edge Modulen). Highlight ist aber der neue Automatic Discovery Service. Dieser Service dient unteranderem der automatische Erkennung, Registrierung und Durchführung einer Sicherheitsüberprüfung von Industrieanlagen und gibt euch die Möglichkeit, die Sicherheit dieser Anlagen automatisch zu konfigurieren,

Ok, in dieser Meldung steckt noch viel mehr und deshalb folgt ein Deep Dive Artikel zur Connected Factory PCS schon bald.

Meldung 3

Siemens und Microsoft haben die Verfügbarkeit (allerdings momentan in einer limitierten Preview) von Siemens MindSphere auf der Azure IoT Plattform bekanntgegeben.

Ein ausführlicher Artikel folgt und bis dahin findet ihr weitere Informationen hier:

• https://www.siemens.com/global/de/home/produkte/software/mindsphere.html

Schöne Grüße

Oliver

Azure IoT – News (Azure Sphere)

Hallo zusammen,

wie einige von euch bestimmt wissen, ist IoT auf der Azure Plattform mein Lieblingsthema (oder zu mindestens das Gebiet, womit ich meine Brötchen verdiene).  Deshalb solltet es euch nicht wundern, dass die letzten Updates vom Azure IoT Team, bei mir große Begeisterung hervorgerufen haben 🙂

Um was geht es?

Microsoft hat  auf der RSA Conference 2018, mit Azure Sphere, eine neue Solution (ein neues Produkt, einen neuen Service) angekündigt.

Neue Solution, neues Produkt und neuer Service? Was denn nun?

Diese Frage ist eigentlich nicht ganz so einfach zu beantworten.

Eine Solution ist Azure Sphere insofern, dass es in seiner Gesamtheit sowohl aus einem Hardware Produkt als auch mehreren korrespondierenden Services besteht.

Mit dem Hardware Produkt sind die sogenannten Secured Certified MCUs gemeint. Secured Certified MCUs sind aber nicht der neueste Output des Marvel Cinematic Universe (Schade), sondern eine besondere Klasse von Microcontroller (und somit auch ein IoT Device).

Besondere Klasse von  Microcontrollern?

Grundsätzlich ist nicht jeder Microcontroller für Azure Sphere geeignet, sondern alle Microcontroller die als Secured Certified MCU durchgehen sollen, müssen dem von Microsoft Research unter dem Namen Project Sopris entwickelten Prototypen entsprechen, der als Grundlage für die künftigen Zertifizierungen dient,

Ok, etwas genauer sollten wir uns das noch anschauen:

Microcontroller die als Secured Certified MCU durchgehen sollen, sind ein sogenanntes Cross-Over aus zwei Chip Architekturen und zwar einmal Cortex A (ein Standard ARM Chip – Infos) und zum zweiten Cortex M  (ein ARM Chip optimiert für Real Time Embedded Processing- und Microcontroller Applications – Infos).

Alle Secured Certified MCUs enthalten außerdem ein Security Subsystem (Microsoft Pluton). Hiermit könnt ihr direkt im Hardware Bereich eure Private Keys speichern oder bei Bedarf komplexe Cryptographic Operations ausführen.

Einen letzten Punkt habe ich noch  in der Liste mit Vorgaben: Alle Secured Certified MCUs enthalten eine Built In Network Connectivity (dazu in einen anderen Artikel mehr),

So, jetzt habe ich genug über Hardware geschrieben. Kommen wir zum nächsten Teil, den Azure Sphere Services. Azure Sphere Services teilt sich in zwei Bereiche;

• Azure Sphere OS : Damit ist das Betriebssystem für den Microcontroller gemeint. Alles was ihr zurzeit wissen müsst ist, dass das OS auf einem Custom Linux Kernel basiert und Anwendungen in  Secured Application Container ausgeführt werden
• Azure Sphere Services (Cloud Security Services): Damit sind alle Azure Services gemeint, die für den einwandfreien Betrieb in Azure Sphere Szenarios sinnvoll oder notwendig sind (z.B. Authentifizierung auf Basis von Azure AD)

Wie ich schon geschrieben hatte, Azure Sphere wurde bisher nur angekündigt. Sobald eine Preview verfügbar ist, können wir uns auch über die VS Tools für Azure Sphere (zur MCU Entwicklung), einem Azure Sphere SDK und einem speziellen VS Connected Service freuen.

Es kommt also noch viel mehr. Ihr könnt euch jetzt schon freuen.

Schöne Grüße

Oliver

Azure IoT – News

Hallo zusammen,

was im Leben macht an meisten Spaß? Richtig: Über Preissenkungen zu berichten 🙂 Ist dann, wie im folgenden Fall, auch noch die Lieblingsspielwiese (Azure IoT) betroffen, ist der Tag  nicht mehr zu übertreffen.

Genug der Vorrede. Kommen wir zu den News:

Microsoft hat die Preise für den Azure IoT Hub im Standard Tier mit sofortiger Wirkung um  50 % gesenkt. Dies bedeutet. ihr bezahlt ab sofort für einen Azure IoT Hub der Stufe S1  25 $, für Stufe S2  250 $ und für Stufe S3 2500 $ (jeweils pro Monat und Unit) .

Immer noch zu teuer?

Kein Problem: Schaut euch einfach einmal die (neuen) Angebote vom Azure IoT Hub im Basic Tier an. Hier könnt ihr euch zwischen den Stufen B1 (entspricht S1) für 10 $, B2 (entspricht S2) für 50 $  und B3 (entspricht S3) für 500 $ (jeweils pro Monat und Unit) entscheiden.

Ok, ganz so einfach ist es dann auch nicht. Azure IoT Hubs im Basic Tier bieten kein Cloud-to-Device Messaging (und somit auch kein Device Management) und keinen Support für Azure IoT Edge.

Ihr könnt aber mit einem Azure IoT Hub im Basic Tier starten und jederzeit auf den Standard Tier upgraden.

Tolle News 🙂 🙂

Schöne Grüße

Oliver

Azure IoT Suite – News

Hallo zusammen,

vielleicht kennt ihr das: Ihr arbeitet an einer IoT Solution, das Environment (IoT Hub etc.) ist bereit und ihr wollt mit den Testläufen beginnen (also jede Menge IoT Devices anschließen). Was jetzt?

Ok. ihr könnt jetzt natürlich die Kiste mit den Raspberry Pi Devices rausholen und mehrere Stunden Installationsarbeiten durchführen. Ich sagt euch aber lieber gleich, das ist äußerst unbefriedigend und führt auch nicht immer zum gewünschten Ziel.

Wenn ich aber so anfange, habe ich natürlich auch eine Alternative für euch, die ich jetzt vorstellen will:

Azure IoT Suite Device Simulation Solution

Die Azure IoT Suite Device Simulation Solution ist der neueste Bestandteil der Sammlung von Pre Configured Solutions und dient als Werkzeug zur Bereitstellung diverser (simulierter) Devicetypen.

Jetzt habe ich aber genug geredet, schauen wir uns das ganze einmal an:

Als erstes müsst ihr das Portal der Azure IoT Suite (auf der Startseite) öffnen. Das Portal findet ihr hier:

• https://www.azureiotsuite.com/

Die notwendige Anmeldung im Portal erfolgt übrigens mit den selben Credentials, die ihr auch für eure Azure Subscription benutzt.

Die Startseite ist wie ihr sehen könnt sehr spartanisch. Die einzige Auswahl ist die „Create a new Solution“ – Kachel. Einfach einmal drücken. Jetzt bekommt ihr eine Seite angezeigt mit den verfügbaren Pre Configured Solutions:

 

Hier interessiert uns die Device Simulation Solution. Einfach die entsprechende Kachel drücken, dann auf der nächsten Seite die notwendigen Daten  (z.B. die Azure Subscription ID) eingeben (die Seite kann ich hier, aus Datenschutzgründen nicht zeigen) und abschließend den Create Button drücken.

Jetzt heißt es warten (Zeit genug für eine frische Tasse Kaffee), bis ihr dann folgendes Bild seht:

Jetzt sind wir am Ziel. Drückt jetzt den Start Button und das Solution Dashboard öffnet sich.  Im Solution Dashboard erstellt ihr die Konfigurationen für eure Simulationen.

Erster Arbeitsschritt dabei, ist die Verknüpfung eurer Simulation mit einem Azure IoT Hub. Hierfür gibt es zwei Möglichkeiten:

• Verknüpfung mit einem vorab bereitgestellten Azure IoT Hub, innerhalb der Solution (Achtung muss während des Setups der Solution erstellt werden) – (1)
• Verknüpfung mit einem beliebigen Azure IoT Hub – (2) Hierfür müsst ihr den primären oder den sekundären Schlüssel eures IoT Hubs abrufen und als Verbindungszeichenfolge in das Feld eintragen.

Nächster Arbeitsschritt ist die Auswahl eines Device Models (Device Typ). Hier bietet euch die Solution drei vordefinierte Devices (Temperatur / Fahrstuhl / LKW) mit vordefinierten Parametern (3 – 4 Parameter) und …

… die Möglichkeit ein benutzerdefiniertes Device zu erstellen. Wenn ihr diese Möglichkeit auswählt öffnet sich ein weiterer Dialog, indem die zugehörigen Sensoren definiert werden. Ein benutzerdefiniertes Device kann bis zu 10  Sensoren enthalten (einfach entsprechend eurem Bedarfs, den Add Sensor Button drücken).

Beim nächsten Arbeitsschritt entscheidet ihr, wie viele Devices ihr benötigt. Zur Auswahl steht eine Range von 1 – 1000 Devices. Ihr könnt also gegebenenfalls einen Lasttest auf eurem Azure IoT Hub durchführen.

Es folgt ein optionaler Arbeitsschritt (optional da die Felder bereits vor belegt sind).  Hier geht es darum die Telemetrie Frequenz und die Laufzeit der Simulation festzulegen. Mit der Telemetrie Frequenz bestimmt ihr, wie häufig die simulierten Devices Daten an den IoT Hub senden. Als Frequenzen sind Zeiträume von 10 Sekunden (sehr häufig – vor eingestellt) bis 99 Stunden, 59 Minuten und 59 Sekunden (sehr selten) möglich. Bei der Laufzeit der Simulation bestimmt ihr die Lebenszeit, bis der Prozess automatisch beendet wird. Hier ist eine beliebige Zeitspanne zwischen 10 Minuten und 99 Stunden, 59 Minuten und 59 Sekunden möglich (Achtung vorgegeben ist ein Nonstop Lauf).

Zum  Schluss den Start Simulation Button drücken und nach ein paar Minuten könnt ihr mit den simulierten  Daten arbeiten.

Wichtiger Hinweis: Wenn ihr die Simulation nicht benötigt, solltet ihr sie unbedingt beenden.Wenn ihr z.B.  1.000 simulierte Geräte im Einsatz habt, die alle 10 Sekunden Daten an einen S1-Hub senden, wird das Limit für den Hub in etwas mehr als einer Stunde erreicht.

Schöne Grüße

Oliver

Azure IoT Suite – News

Hallo zusammen,

den Inhalt meines heutigen Artikels, kannte ich schon seit einigen Monaten. Einige  Teile hatte ich schon gesehen und war begeistert, allerdings durfte ich bisher nicht darüber reden.

Ok, die Betonung liegt auf dem Wort: Bisher

Gestern gingen die Änderungen live (zu mindestens als Preview) und so habe ich heute die Gelegenheit darüber berichten zu können.

Jetzt habe ich aber genug rumgeredet, kommen wir nun endlich zur Sache: Um was geht es?

Wie ihr vielleicht wisst, bietet euch die Azure IoT Suite sogenannte Pre Configured Solutions an. Pre Configured Solutions sind Beispiele für die am häufigsten verwendeten IoT -Lösungsszenarien und dienen als Ausgangspunkt für eigene IoT – Lösungen.

Ich höre jetzt bereits die Frage aufkommen:  Was bedeutet „Ausgangspunkt für eigene IoT – Lösungen“ eigentlich? 

Der Grundgedanke dabei ist eigentlich ganz einfach:  Eine Pre Configured Solution soll soweit anpassbar sein, dass ihr zum Schluss zu mindestens das Grundgerüst für eine eigene Lösung habt. Damit dies ohne Probleme durchgeführt werden kann, sind alle Pre Configured Solutions Open Source Projekte und ihr könnt eure Anpassungen direkt im Code vornehmen.

Jetzt habe ich bisher nichts neues erzählt, also kommen wir nun endlich zum Thema:

Microsoft hat lange überlegt, wie man das Angebot noch verbessern könnte und beschloss die  folgenden Pläne:

• Die existierenden  Pre Configured Solutions werden einem umfangreichen Redesign und Refactoring Prozess unterzogen
• Die zugrundeliegende Basisarchitektur wird geändert (Von Web Application zu Microservices und Container Apps)
• Das Deployment Modell wird zweigeteilt, in ein Basic Model (für Demo und Showcase Zwecke) und in ein Enterprise Model (das ist die vollständige Solution)

Ich hatte es ja bereits erwähnt: Erste Ergebnisse sind seit gestern verfügbar und die werde ich euch jetzt vorstellen. Alle Teile basieren auf der bisherigen PCS for Remote Monitoring und sind wie der Vorgänger natürlich Open Source Projekte. Alle Teile (und das ist neu), sind in zwei Geschmacksrichtungen erhältlich und zwar jeweils als NET (C#) oder Java Variante.

Also, was ist nun neu im Angebot und wo fange ich am besten an?

Ich denke wir sollten mit dem Basisangebot anfangen, der PCS selbst:

Azure IoT PCS for Remote Monitoring (Version 2.0)

NET

• https://github.com/Azure/azure-iot-pcs-remote-monitoring-dotnet

Java

• https://github.com/Azure/azure-iot-pcs-remote-monitoring-java

In diesen Repositories findet ihr eigentlich alles. Alle Sub Repositories sind in der jeweilig passenden Version mit eingebunden. Trotzdem möchte ich euch auch noch den Rest vorstellen.

Weiter geht es mit dem Web UI.  Das Web UI wurde in JavaScript (Node.JS) entwickelt und ist für beide Varianten der PCS gleich.

Azure IoT PCS Remote Monitoring Web UI

• https://github.com/Azure/pcs-remote-monitoring-webui

Was wäre aber eine auf der Microservice Architektur basierende Solution ohne Services. Natürlich nichts und deshalb gibt es auch hier schon einige Angebote:

Azure IoT PCS Microservice for IoT Hub Management

NET

• https://github.com/Azure/iothub-manager-dotnet

Java

• https://github.com/Azure/iothub-manager-java

Azure IoT PCS Microservice – Configuration

NET

• https://github.com/Azure/pcs-config-dotnet

Java

• https://github.com/Azure/pcs-config-java

Wichtiger Hinweis: Der Azure PCS Microservice – Configuration benötigt den jeweiligen Azure PCS Microservice – Storage Adapter zur Erledigung seiner Aufgaben.

Azure IoT PCS Microservice – Device Simulation

NET

• https://github.com/Azure/device-simulation-dotnet

Java (zurzeit nur partiell vorhanden)

• https://github.com/Azure/device-simulation-java

Wichtiger Hinweis: Der Azure PCS Microservice – Device Simulation benötigt den jeweiligen Azure PCS Microservice – Storage Adapter zur Erledigung seiner Aufgaben.

Azure IoT PCS Microservice – Storage Adapter

NET

• https://github.com/Azure/pcs-storage-adapter-dotnet

Java

• https://github.com/Azure/pcs-storage-adapter-java

Arbeiten wollen wir ja auch, also brauchen wir noch:

Azure IoT PCS Microservice – Device Telemetry

NET

• https://github.com/Azure/device-telemetry-dotnet

Java

• https://github.com/Azure/device-telemetry-java

und

Azure IoT PCS Microservice – Device Telemetry Agent (Azure IoT Hub Streaming, Analytics, Alerts)

NET

• https://github.com/Azure/telemetry-agent-dotnet

Java

• https://github.com/Azure/telemetry-agent-java

Ist das jetzt alles?

Nein, da wäre noch:

Azure IoT PCS CLI (eine Azure CLI Extension um die PCS in User Subscriptions zu deployen)

• https://github.com/Azure/pcs-cli

Azure IoT PCS Tools (eine Sammlung von Scripts um eigene PCS zu erstellen)

• https://github.com/Azure/azure-iot-pcs-tools

Ok, das war viel Stoff für Runde 1. Eine ausführliche Deep Dive Einführung ist bereits in Arbeit.

Schöne Grüße

Oliver

Azure IoT Solution Architecture – Deep Dive #3-3

Hallo zusammen,

heute möchte ich meine Deep Dive Artikelserie, zur Azure IoT Solution Architecture fortsetzen.

In der letzten Folge (hier) hatten wir uns mit dem Field Gateway (oder aus der Azure Sichtweise: dem Azure IoT Gateway SDK bzw. Azure IoT Edge) beschäftigt. Da das Thema aber zu umfangreich ist, um in nur einer Folge behandelt zu werden, geht es auch diesmal weiter mit dem Field Gateway.

Bevor wir aber mit unseren Ausführungen starten werden, gibt es auch diesmal, erstmal ein Bild zur Erinnerung:

In unseren heutigen Fokus stehen die Gateway Module (im Bild in grün gemalt) und zwar speziell das mittlere Modul mit der Bezeichnung Filter.

Filter ist dabei eigentlich eine irreführende Bezeichnung, denn der Name Filter ist nur eine grobe Umschreibung der Aufgabe des Moduls.  Ein Filter Modul wartet auf Messages mit speziellen Properties und führt dann eine benutzerdefinierte Transformation aus.

Ändern wir also unser Bild etwas ab:

Aus dem Filter Module ist jetzt das Custom Module geworden. Custom Module bedeutet, dass ihr eure eigene Anwendungslogik in einer Programmiersprache eurer Wahl (zurzeit NET, NET Core, Java, Node.JS) bereitstellt.

Ok, ganz so einfach ist es nicht. Bei einem Custom Module wird zunächst aus einem laufenden Gateway Process, ein sog. Module Host (ein Lademodule) gestartet. Der Module Host sorgt dann z.B. dafür, dass die passende Runtime zur Ausführung des Codes geladen wird. Erst wenn der Module Host vollständig initialisiert ist, kommt auch euer Code ins Spiel.

Der Gateway Process und die Module Host Units sind. wie alle Infrastrukturbestandteile des Field Gateways in ANSI C entwickelt worden. Damit wird sichergestellt, dass die Funktionalität des Gateways, unabhängig vom Betriebssystem (Linux oder Windows), bereitgestellt wird.

Kehren wir noch einmal zum zweiten Bild zurück. Wenn ihr genau hinschaut, sieht ihr neben dem Custom Module ein weiteres Module, mit dem Namen Functions Module (oder etwas genauer Azure Functions Module). Das Functions Module ist eine Sonderform der Custom Module und zugleich ein Out – of – the Box Modul (d.h. ein vorgefertigtes Angebot) des Gateway. Das Functions Module nimmt Messages vom Gateway entgegen und triggert anschließend über ein HTTP Post eine Azure Function in der Cloud.

Ok, genug für heute. Noch mehr zum Thema, gibt es in der nächsten Folge.

Schöne Grüße
Oliver

Azure IoT Solution Architecture – Deep Dive #3-2

Hallo zusammen,

heute möchte ich meine Deep Dive Artikelserie, zur Azure IoT Solution Architecture fortsetzen.

In der letzten Folge hatten wir unsere Sicht auf die Architektur etwas erweitert und das Segment Cloud Gateway in die Betrachtungen mit einbezogen. Hier das Gesamtbild noch einmal zur Erinnerung:

Da das Bild sehr komplex ist, hatte ich es für die späteren Betrachtungen noch mehrmals gesplittet. Während ich euch die Erläuterungen für Teilabbildung a + b bereits in der letzten Folge (hier) geliefert hatte, bin ich euch allerdings  die Erläuterungen für Teilabbildung c noch schuldig geblieben.

Das werde ich heute sofort nachholen aber vorher gibt es hier, auch Teilabbildung c noch einmal zum anschauen:

Wie ihr sehen könnt, gibt es in Teilabbildung c keine direkte Kommunikation mehr zwischen den Devices im Segment Field und dem Cloud Gateway. Alle Kommunikation erfolgt stattdessen über ein Field Gateway (gegebenenfalls auch in Kombination mit einem Protocol Gateway).

Stellt sich sofort die Frage: Warum diese Umleitung?

Dafür gibt es mehrere Gründe:

• Ein PAN Device  ist aufgrund seiner Beschaffenheit (niedriges Ressourcenangebot), in der Regel gar nicht in der Lage selbstständig mit der Cloud zu kommunizieren. Ihr müsst zuerst über Bluetooth eine Verbindung zu einem Gateway herstellen, um anschließend die Daten in die Cloud  zu übertragen.
• Legacy Devices benutzen oft komplexe Netzwerk Protokolle (z.B. Modbus). Diese sind für eine direkte Kommunikation auch nicht geeignet.

Neben den Kommunikationsproblemen (davon sind übrigens zirka 85% aller Devices betroffen), kann aber auch die Notwendigkeit oder der Bedarf, den Data Stream einer Vorverarbeitung (Transformation) zu unterziehen, ein Grund für den Einsatz eines Field Gateways sein.

Beispiele für diese Transformationen des Data Streams sind:

• Batching
• Compression
• Message Composition
• Queuing
• Throttling

Kommen wir zum letzten Grund, für den Einsatz eines Field Gateways: die sog. Implementation of Infrastructure Capabilities. Mit dem Field Gateway habt ihr z.B. die Möglichkeit eure Infrastruktur an Sicherheitsbedürfnisse anzupassen oder einen Identity Management Layer (Credential Management Layer) zu realisieren.

Kommen wir nun zur Azure IoT Plattform:

Für die Azure IoT Plattform wurde die Unterstützung für das Field Gateway, bisher als Open Source Projekt „Azure IoT –  Gateway SDK“ auf GitHub  angeboten.

Ok, ihr habt es gelesen: Bisher

Vor knapp drei Wochen fand in Seattle die Microsoft Build Conference 2017 statt (das ist Microsoft größte Entwicklerkonferenz). In der Keynote der Konferenz wurde eine neue Komponente der Azure IoT Platform vorgestellt:

Azure IoT Edge

Azure IoT Edge ist einerseits der Ersatz für das Azure IoT Gateway SDK, mit einer relativ identischen Funktionalität.  Andererseits bekommt ihr aber auch zahlreiche neue Möglichkeiten für die Transformation eures Data Streams geboten (dazu gibt es in einem späteren Artikel mehr).

Betrachten wir nun, das Azure IoT – Gateway SDK (oder auch das Azure IoT Edge) einmal näher:

Wie ihr sehen könnt, besteht der Inhalt eines Field Gateways nur aus zwei unterschiedlichen Elementen, den Modulen und einen Message Broker.

Klären wir nun erstmal die Frage: Was ist ein Gateway Modul?

Ein Gateway Modul empfängt eine Nachricht, führt dann eine Aktion damit aus, transformiert sie optional in eine neue Nachricht und gibt sie dann abschließend zur Verarbeitung an andere Module weiter.

Im Gateway treten Module immer als eine Verkettung von mehreren Modulen auf (auch Data Processing Pipeline genannt). Die Anzahl an unterschiedlichen Modulen hängt von euren individuellen Bedürfnissen ab. Zwei Module findet ihr aber in jeden Szenario:

• Protocol Ingester Modul (als Startpunkt der Pipeline)
• IoT Hub (Send to Cloud) Modul (als Endpunkt der Pipeline)

Zwischen dem Startpunkt und dem Endpunkt der Pipeline, kommen dann weitere vordefinierte Module (zusätzliche Gateway Funktionalitäten) oder benutzerdefiniert Module (eure Business Logic) zum Einsatz (dazu später mehr).

Nächste Frage: Was ist mit dem Message Broker?

Der Message Broker wird von den Modulen dazu verwendet, um miteinander zu kommunizieren. Ihr veröffentlicht eine Nachricht auf dem Broker, die dann schrittweise an alle angebundenen Module weitergegeben werden.

Ein Message Broker basiert je nach eurem Bedarf, auf einer Busarchitektur, dem Pub / Sub Pattern oder jeden anderen Messaging Pattern.

Ok, genug für heute. Sehr viel mehr zum Thema, gibt es in der nächsten Folge.

Schöne Grüße
Oliver