IoT-Geräteentwicklung

Das folgende Diagramm zeigt eine allgemeine Ansicht der Komponenten in einer typischen edgegebundenen IoT-Lösung. Dieser Artikel konzentriert sich auf die Geräte, Objekte und Connectors, die im Diagramm gezeigt werden:

Ressourcen verfügen in der Regel über integrierte Firmware, die Standardprotokolle implementiert. So kann z. B. ein Roboterarm ein OPC UA-Client sein, und eine Sicherheitsvideokamera ONVIF implementieren. Azure IoT Einsatz umfasst verschiedene Connectors, die diese Protokolle verwenden können, um mit Ressourcen zu kommunizieren und Nachrichten aus den Objekten in MQTT-Nachrichten zu übersetzen. Einige Ressourcen können Nachrichten empfangen, mit denen Sie Vorgänge auf diesen Ressourcen ausführen können, z. B.:

• Schwenken oder Kippen einer Sicherheitskamera
• Ändern des Protokolliergrads für einen Roboterarm
• Initiieren eines Firmwareupdates

Sie können eigene, benutzerdefinierte Connectors erstellen, um eine Verbindung mit Objekten herzustellen, die Protokolle verwenden, die von Azure IoT Einsatz nicht nativ unterstützt werden.

Das folgende Diagramm zeigt eine allgemeine Ansicht der Komponenten in einer typischen cloudgebundenen IoT-Lösung. In diesem Artikel geht es hauptsächlich um die im Diagramm gezeigten Geräte und das Gateway:

In Azure IoT schreibt ein Geräteentwickler den Code, der auf den Geräten in der Lösung ausgeführt werden soll. Dieser Code macht typischerweise Folgendes:

• Stellt eine sichere Verbindung mit einem Cloud-Endpunkt her.
• Sendet Telemetriedaten, die von angefügten Sensoren gesammelt wurden, an die Cloud.
• Verwaltet den Gerätestatus und synchronisiert diesen Status mit der Cloud.
• Antwortet auf Befehle, die aus der Cloud gesendet werden.
• Ermöglicht die Installation von Software-Updates aus der Cloud.
• Ermöglicht es dem Gerät, weiterhin zu funktionieren, während es von der Cloud getrennt ist.

Zu den Beispielressourcen in einer edgegebundenen Lösung gehören:

• Roboterarme, Förderbänder und Aufzüge
• Industrielle CNC-Maschinen, Drehmaschinen, Sägen und Bohrer
• Medizinische Geräte für bildgebende Diagnoseverfahren
• Sicherheitsvideokameras
• Programmierbare Logikcontroller

Diese Ressourcen verfügen in der Regel über integrierte Firmware, die Standardprotokolle implementiert. So kann z. B. ein Roboterarm ein OPC UA-Client sein, und eine Sicherheitsvideokamera das ONVIF-Protokoll implementieren. In einer edgegebundenen Lösung verwenden Sie spezielle Connectors, um eine Verbindung mit diesen Ressourcen herzustellen und Nachrichten daraus in ein gängiges Format zu übersetzen.

Für Ressourcen gibt es keine direkte Entsprechung für die Geräteentwicklerrolle. Stattdessen kann ein Bediener die Connectoren so konfigurieren, dass eine Verbindung mit den Anlagen hergestellt wird. Möglicherweise müssen Sie jedoch benutzerdefinierte Connectors entwickeln, um eine Verbindung mit Objekten herzustellen, die Protokolle verwenden, die von Ihrer edgegebindeten Lösung nicht nativ unterstützt werden.

Beispiele für Geräte in einer mit der Cloud verbundenen Lösung sind:

• Ein Drucksensor einer Ölpumpe an einem entfernten Ort
• Temperatur- und Luftfeuchtigkeitssensoren in einer Klimaanlage
• Ein Beschleunigungsmesser in einem Fahrstuhl
• Präsenzmelder in einem Raum

Diese Geräte werden in der Regel mit Mikrocontrollern (MCUs) oder Mikroprozessoren (MPUs) erstellt:

• Mikrocontroller sind kostengünstiger und einfacher zu verwenden als Mikroprozessoren.
• Ein Mikrocontroller enthält viele Funktionen, z. B. Arbeitsspeicher, Schnittstellen und E/A, direkt auf dem Chip. Ein Mikroprozessor greift auf diese Funktionalität von Komponenten in unterstützenden Chips zu.
• Ein Mikrocontroller verwendet häufig ein Echtzeitbetriebssystem (Real-Time OS, RTOS) oder kein Betriebssystem (Bare Metal) und stellt Echtzeitantworten und hochgradig deterministische Reaktionen auf externe Ereignisse bereit. MPUs führen in der Regel ein allgemeines Betriebssystem aus, z. B. Windows, Linux oder macOS, das eine nicht unbestimmte Echtzeitantwort bereitstellt. Es gibt in der Regel keine Garantie dafür, wann eine Aufgabe abgeschlossen wird.

Beispiele für spezialisierte Hardware und Betriebssysteme sind:

Windows für IoT ist eine eingebettete Version von Windows für MPUs mit Cloudkonnektivität, mit der Sie sichere Geräte mit einfacher Bereitstellung und Verwaltung erstellen können.

Eclipse ThreadX ist ein Echtzeitbetriebssystem für IoT- und Edge-Geräte, die von Mikrocontrollern unterstützt werden. Eclipse ThreadX ist für die Unterstützung von stark eingeschränkten Geräten vorgesehen, die mit einem Akku betrieben werden und über weniger als 64 KB Flashspeicher verfügen.

FreeRTOS ist ein Echtzeitbetriebssystem (Real-Time Operating System, RTOS) für eingebettete Geräte. Sie können FreeRTOS mit der Azure IoT Middleware für FreeRTOS verwenden, um Geräte mit Azure IoT zu verbinden. Eine Übersicht über RTOS-Optionen für die Geräteentwicklung finden Sie unter Anwendungsszenarien für C SDK und Embedded C SDK.

Azure Sphere (Integrated) ist eine sichere, allgemeine Anwendungsplattform mit integrierten Kommunikations- und Sicherheitsfeatures für internetbasierte Geräte. Es umfasst einen geschützten, verbundenen Crossover-Mikrocontroller, ein benutzerdefiniertes, allgemeines Linux-basiertes Betriebssystem sowie einen cloudbasierten Sicherheitsdienst, der für kontinuierliche und erneuerbare Sicherheit sorgt.

Grundelemente für Geräte

Bei der Geräteentwicklung werden in der Regel die folgenden primitiven Typen für die Interaktion mit der Cloud im Gerätecode implementiert:

• Gerät-zu-Cloud-Nachrichten zum Senden von Zeitreihen-Telemetriedaten an die Cloud. Beispielsweise Temperaturdaten, die von einem Sensor erfasst werden, der an das Gerät angeschlossen ist.
• Datei-Uploads für Mediendateien, z. B. erfasste Bilder und Videos. Zeitweilig verbundene Geräte können Telemetrie-Batches senden. Geräte können Uploads komprimieren, um Bandbreite zu sparen.
• Gerätezwillinge zum Freigeben und Synchronisieren von Statusdaten mit der Cloud. Beispielsweise kann ein Gerät den Gerätezwilling verwenden, um den aktuellen Status eines von ihm gesteuerten Ventils an die Cloud zu melden und eine gewünschte Zieltemperatur von der Cloud zu empfangen.
• Digitale Zwillinge zum Darstellen eines Geräts in der digitalen Welt. Beispielsweise kann ein digitaler Zwilling den physischen Standort eines Geräts, seine Funktionen und seine Beziehungen zu anderen Geräten darstellen.
• Direkte Methoden zum Empfangen von Befehlen aus der Cloud. Eine direkte Methode kann Parameter enthalten und eine Antwort zurückgeben. Beispielsweise kann die Cloud eine direkte Methode aufrufen, um den Neustart des Geräts in 30 Sekunden anzufordern.
• Cloud-zu-Gerät-Nachrichten zum Empfangen von unidirektionalen Benachrichtigungen aus der Cloud. Beispielsweise eine Benachrichtigung, dass ein Update zum Herunterladen bereit ist.

Weitere Informationen finden Sie unter Leitfaden zur Gerät-zu-Cloud-Kommunikation und Leitfaden zur Cloud-zu-Gerät-Kommunikation.

SDKs und Bibliotheken

Die Geräte-SDKs bieten allgemeine Abstraktionen, mit denen Sie die Primitiven ohne Kenntnisse der zugrunde liegenden Kommunikationsprotokolle verwenden können. Die Geräte-SDKs handhaben auch die Details zum Herstellen einer sicheren Verbindung mit der Cloud und zur Authentifizierung des Geräts.

Für Mikroprozessorgeräte sind Geräte-SDKs für die folgenden Sprachen verfügbar:

• C
• Python
• C# (.NET)
• Node.js
• Java

Informationen zu Mikrocontrollergeräten finden Sie unter:

• Eclipse ThreadX
• FreeRTOS Middleware
• Azure SDK für Embedded C

Beispiele und Anleitungen

Alle Geräte-SDKs enthalten Beispiele, die veranschaulichen, wie Sie das SDK verwenden, um eine Verbindung mit der Cloud herzustellen, Telemetriedaten zu senden und die anderen Primitiven zu nutzen.

Weitere Beispiele finden Sie im Code-Beispiel-Browser.

Geräteentwicklung ohne ein Geräte-SDK

Es wird zwar empfohlen, eines der Geräte-SDKs zu verwenden, es kann jedoch auch Szenarien geben, in denen Sie dies besser nicht tun sollten. In diesen Szenarien muss Ihr Gerätecode direkt eines der Kommunikationsprotokolle verwenden, die IoT Hub und der Device Provisioning Service (DPS) unterstützen.

Weitere Informationen finden Sie unter

• Direktes Verwenden des Protokolls MQTT (als Gerät)
• Direktes Verwenden des AMQP-Protokolls (als Gerät)

In einer edgegebundenen Lösung konfiguriert ein Operator Connectors für die Verbindung mit Objekten. Diese Konfiguration umfasst eine Zuordnung zwischen den Daten der Ressource und einem Cloudschema. Beispielsweise ermöglicht der OPC UA-Connector dem Operator die Zuordnung von OPC UA-Knoten-IDs zu Datenpunkten und Ereignissen in einer JSON-Nachricht, die mit dem MQTT-Broker ausgetauscht wird. Der folgende Screenshot zeigt ein Beispiel für die Web-UI für digitale Vorgänge, die zwei solche Zuordnungen definiert:

An anderer Stelle in der Lösung kann ein Operator direkt auf die Tags Temperatur und Tag 10 verweisen, ohne die Details der OPC UA-Knoten-IDs kennen zu müssen.

In einer cloudgebundenen Lösung ermöglicht IoT Plug & Play Lösungs-Generatoren die Integration von IoT-Geräten mit ihren Lösungen ohne manuelle Konfiguration. Im Kern von IoT Plug & Play ist ein Gerätemodell, das ein Gerät verwendet, um seine Funktionen für eine IoT Plug & Play-fähige Anwendung wie IoT Central anzukündigen. Dieses Modell ist als ein Satz von Elementen strukturiert, die Folgendes definieren:

• Eigenschaften, die den schreibgeschützten oder schreibbaren Status eines Geräts oder einer anderen Entität darstellen. Beispielsweise kann eine Geräteseriennummer eine schreibgeschützte Eigenschaft sein und die Zieltemperatur eines Thermostats eine schreibbare Eigenschaft.
• Telemetriedaten, d. h. die von einem Gerät ausgegebenen Daten – unabhängig davon, ob es sich bei den Daten um einen regulären Datenstrom von Sensormesswerten, einen gelegentlichen Fehler oder eine Informationsmeldung handelt.
• Befehle, die eine Funktion oder einen Vorgang beschreiben, die bzw. der auf einem Gerät ausgeführt werden kann. Durch einen Befehl kann beispielsweise ein Gateway neu gestartet oder ein Foto mit einer Remotekamera aufgenommen werden.

Sie können diese Elemente in Schnittstellen zur modellübergreifenden Wiederverwendung gruppieren, um die Zusammenarbeit zu vereinfachen und die Entwicklung zu beschleunigen.

Das Modell wird mithilfe der Digital Twins Definition Language (DTDL) angegeben.

Die Verwendung von IoT Plug & Play, Modellierung und DTDL ist optional. Sie können die IoT-Gerätegrundtypen verwenden, ohne IoT Plug & Play oder Modellierung zu verwenden. Der dienst Azure Digital Twins verwendet auch DTDL-Modelle, um Zwillingsdiagramme basierend auf digitalen Modellen von Umgebungen wie Gebäuden oder Fabriken zu erstellen.

Wenn Sie ein IoT Plug & Play Gerät implementieren, müssen Sie als Geräteentwickler eine Reihe von Konventionen befolgen. Diese Konventionen bieten eine Standardmethode zum Implementieren des Gerätemodells im Code mithilfe der in den Geräte-SDKs verfügbaren Primitiven.

Azure IoT Einsatz containerisiert alle Connectors, Broker und andere Komponenten, die am Edge ausgeführt werden. Azure IoT Einsatz stellt einen Kubernetes-Cluster bereit, bei dem es sich um eine Container-Orchestrierungsplattform handelt. Stellen Sie benutzerdefinierte Connectors oder andere Komponenten bereit, die Sie im Kubernetes-Cluster erstellen.

Sie können eine Lösung betrachten, die Azure IoT Edge als an IoT Hub angebundenes Gateway verwendet. Diese Hybridlösung kombiniert Elemente sowohl von Edge-verbundenen als auch von Cloud-verbundenen Lösungen.

Durch die Ausführung von Geräte-Code mithilfe von Containern, z. B. Docker, können Sie Code auf Ihren Geräten bereitstellen, indem Sie die Funktionen der Containerinfrastruktur verwenden. Mit Containern können Sie auch eine Laufzeitumgebung für Ihren Code definieren, in der alle erforderlichen Bibliotheks- und Paketversionen installiert sind. Container erleichtern die Bereitstellung von Updates und das Verwalten des Lebenszyklus Ihrer IoT-Geräte.

Azure IoT Edge führt Gerätecode in Containern aus. Sie können Azure IoT Edge verwenden, um Codemodule auf Ihren Geräten bereitzustellen. Weitere Informationen finden Sie unter Develop your own IoT Edge modules.