Kapitel 4. Der Lebenszyklus des Geräts

Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: translation-feedback@oreilly.com

Mit bist du jetzt in die komplizierte Welt der IoT-Lösungen eingetaucht, in der Hardware, Software und die Cloud zu einer Symphonie der Technologie verschmelzen. Die Wahl der Geräte oder ihrer Kombinationen hängt von den spezifischen Bedürfnissen ab, die du erfüllen willst. Im vorigen Kapitel haben wir uns mit dem Konzept "Teste, bevor du kaufst" befasst und Möglichkeiten erkundet, wie du die beste Lösung für dein Gerät findest. Es ist jedoch wichtig zu verstehen, dass die Anschaffung eines Geräts und seine Inbetriebnahme nur die Spitze des Eisbergs ist - ich wünschte, es wäre so einfach wie das! IoT-Lösungen umfassen viel mehr, als man auf den ersten Blick sieht.

Eine Parallele zum Auto könnte helfen, den Punkt zu verdeutlichen. Der Hauptzweck eines Autos ist der Transport von A nach B. Dazu gehören ein Motor, Kraftstoff, eine Lenkung und Sitzplätze für die Passagiere. Diese Aspekte sind die grundlegenden funktionalen Anforderungen. Doch du verlangst mehr von deinem Auto als nur das Nötigste - denk an Scheinwerfer, Sicherheitsgurte, Klimatisierung und so weiter. Darüber hinaus kommt der Bereich der Wartung ins Spiel, der qualifizierte Mechaniker, Ersatzteile, Sicherheitsprüfungen und die Einhaltung gesetzlicher Vorschriften erfordert. All diese Aspekte werden sorgfältig berücksichtigt, lange bevor ein Auto in den Ausstellungsräumen steht.

Auch wenn dein IoT-Projekt vielleicht nicht so komplex ist wie der Automobilbau, musst du dir darüber im Klaren sein, dass die funktionalen und nicht-funktionalen Anforderungen an dein Gerät schon lange vor der Implementierung erfüllt werden müssen. Ein systematischer Ansatz besteht darin, diese Anforderungen in das Lebenszyklusmanagement des Geräts einzubinden. Dieser Rahmen dient nicht nur dazu, die Aktivitäten des Geräts zu steuern, sondern auch dazu, funktionale und nicht-funktionale Anforderungen zu kapseln. Die Entscheidungen, die das Gerätemanagement nach der Einführung betreffen, müssen lange im Voraus getroffen werden, noch bevor das Gerät seine Jungfernfahrt antritt.

Deshalb wirst du in diesem Kapitel jede Phase des Lebenszyklus des Geräts durchlaufen. Innerhalb dieser Phasen werde ich auf die Anforderungen hinweisen, die deine Aufmerksamkeit verdienen.

Device Lifecycle Management

Das Management des Gerätelebenszyklus umfasst alle Aufgaben im Leben eines Geräts, die mit seiner Entwicklung, Herstellung, Wartung und eventuellen Stilllegung zusammenhängen. Im breiteren Kontext der in Kapitel 1 beschriebenen IoT-Landschaft ist das Gerätelebenszyklusmanagement Teil der Cloud-Seite von Azure, wie in Abbildung 4-1 dargestellt.

Stell dir vor, dass alles, was zum Lebenszyklusmanagement gehört, auch Teil eines Kontrollplans ist. Wenn du es mit einem oder ein paar Dutzend Geräten zu tun hast, mag es übertrieben erscheinen, sie mit einem Kontrollplan zu verwalten, aber wenn du es mit Tausenden oder Millionen von Geräten zu tun hast, macht ein Kontrollplan das scheinbar Unmögliche machbar. Das Management des Gerätelebenszyklus gilt für alle Geräte, egal ob sie von einem einzelnen Nutzer oder von einer weltweiten Organisation genutzt werden sollen. Die Schritte sind die gleichen, auch wenn sie in unterschiedlichem Umfang durchgeführt werden. Die Schritte sind in Abbildung 4-2 dargestellt.

Der Lebenszyklus eines Geräts ist chronologisch in sich überschneidende Abschnitte unterteilt, die durch einige wichtige Ereignisse gekennzeichnet sind:

Die Forschungs- und Entwurfsphase beginnt mit einer Idee für ein Gerät, die dann weiterentwickelt wird, bis sie zu einem Produkt wird, das hergestellt werden kann. Du hast in den letzten beiden Kapiteln schon einiges über diesen Teil gelesen, aber dazu gehört auch die Überlegung, wie du dein Gerät warten wirst.
In der Herstellungsphase werden die Pläne aus der Forschungs- und Entwurfsphase in die Tat umgesetzt, um das Gerät tatsächlich herzustellen.
- Die Geräteanmeldung erfolgt als Teil des Herstellungsprozesses und ist ein wichtiges Ereignis innerhalb des Herstellungsprozesses, bei dem ein Gerät bei einer Geräteverwaltungslösung registriert wird. Im Fall von Azure ist diese Lösung der Device Provisioning Service.
- Das Gerät wird ausgeliefert und gilt als einsatzbereit, wenn der Herstellungsprozess abgeschlossen ist.
Die Phase der Gerätebereitstellung findet statt, sobald ein Gerät ausgeliefert wird und bereit für den Einsatz ist. Durch die Bereitstellung wird das Gerät mit einer Gerätemanagementlösung online gestellt, damit es sicher mit der Cloud kommunizieren kann.
In der Hauptsequenz führt das Gerät seine Hauptfunktion aus, während es mit der Cloud durch Nachrichtenaustausch, Twinning und den Empfang von Software-Updates kommuniziert. Software-Patches und -Updates werden regelmäßig auf das Gerät angewendet, damit es optimal und sicher läuft.
Die Deprovisionierungsphase beginnt, wenn das Gerät für den vorgesehenen Zweck nicht mehr nützlich ist. Es wird dann aus dem Verkehr gezogen und entsorgt.

Sicherheit ist ein Querschnittsthema für den gesamten Lebenszyklus eines Geräts, weshalb es in Abbildung 4-2 als Kasten um alles andere herum erscheint. In diesem Buch ist ein ganzes Kapitel(Kapitel 14) der Sicherheit gewidmet, weil sie ein so übergreifendes Thema ist.

Gehen wir die einzelnen Phasen genauer durch, beginnend mit Forschung und Design.

Forschung und Design

Forschung und Design (F&E) für Geräte konzentrieren sich in den meisten Fällen darauf, zu planen, wie dein Gerät ein Problem lösen soll, und zu entscheiden, wie es das tun soll. Es gibt eine Vielzahl scheinbar unterschiedlicher Dinge, die du bei der Entwicklung deines Geräts in dieser Phase berücksichtigen musst, wie z. B. Hardware, Betriebssysteme und zu verwendende SDKs. Dieser Abschnitt wird nicht alles abdecken, woran du in der F&E-Phase deines Geräts denken musst, aber er gibt dir einen Eindruck davon, wo du anfangen kannst.

Beginnen wir mit den drei Phasen von F&E.

Drei Phasen von F&E

In der F&E-Phase wird das Gerät so lange entwickelt, bis es einen klaren Plan für die Machbarkeit und die endgültige Herstellung gibt. Die wichtigsten Schritte sind Konzeptnachweis, Prototyping und schließlich ein minimal lebensfähiges Produkt, wie in Abbildung 4-3 dargestellt.

Proof of Concept

Wenn du einen Proof of Concept für ein Gerät erstellst, ist das wenig mehr als eine technische Demonstration der Machbarkeit einer Idee für ein Gerät. Er zeigt, dass die funktionalen Anforderungen des Geräts erfüllt werden können, auch wenn die Methoden alles andere als optimal, sicher, skalierbar oder effizient sind. Bei einem Proof of Concept geht es nicht darum, ein elegantes Produkt zu entwickeln, das man sofort herstellen kann, und es ist in der Regel ziemlich unfertig. Es kann auch nur ein Breadboard mit Drähten, Sensoren, Servos und anderer Hardware sein, das mit einem angeschlossenen PC und einer Ausgabe auf einem Monitor läuft. In jedem Fall sind diese Rohprodukte nur dazu da, dir die Gewissheit zu geben, dass etwas machbar ist.

Manchmal ist die Anbindung von Geräten an Azure Teil dieses Proof-of-Concept-Prozesses, weil du Daten an die Cloud senden musst, um zu demonstrieren, wie die Daten verwendet werden. Diese Verbindung wird wahrscheinlich die funktionalen Anforderungen deines Geräts unterstützen, ohne dass du dir Gedanken über das Lebenszyklusmanagement des Geräts machst.

Prototyp

Sobald du einen Proof of Concept hast, der die technische Machbarkeit eines Geräts zeigt, erstellst du einen Prototyp, um zu zeigen, wie das Endprodukt aussehen und funktionieren wird. Der Prototyp erhält ein produktorientiertes Finish, das nicht nur die funktionalen Anforderungen, sondern auch einige der nichtfunktionalen Anforderungen demonstriert. Wenn du eine unternehmensweite Lösung planst, ist der Prototyp in der Regel etwas, das du einem Investor oder einer externen Partei zeigen möchtest, um Interesse an dem Gerät zu wecken. Diese Prototypen sind vielleicht nicht perfekt, aber sie zeigen, dass dein Plan zu einem funktionsfähigen Gerät führen wird, das hergestellt und genutzt werden kann.

Während du den Prototyp entwickelst, kannst du auch darüber nachdenken und vielleicht sogar testen, wie dein Gerät während des restlichen Lebenszyklus verwaltet werden soll. Du möchtest vielleicht einen Azure IoT Hub erstellen, das Gerät mit dem IoT Hub verbinden und Daten senden und empfangen.

Minimum Viable Product

Nachdem du deinen Prototyp verfeinert hast, hast du ein "Minimum Viable Product", das alle funktionalen und nicht-funktionalen Merkmale aufweist, die für das Gerät erforderlich sind, um als "vollständig" zu gelten. Bis zu diesem Zeitpunkt solltest du herausgefunden haben, wie dein Gerät über die Cloud mit allen unterstützenden Cloud-Diensten verwaltet werden kann. Manchmal ist ein Minimum Viable Product die einfachste Form eines Produkts oder vielleicht sogar etwas mehr als das. Bei manchen Geräten reicht das aus, um sicherzustellen, dass das Gerät zumindest in der ersten Generation hergestellt werden kann.

Während der drei F&E-Phasen wirst du viele Entscheidungen über dein Gerät und seine zahlreichen funktionalen und nichtfunktionalen Anforderungen treffen müssen. Du kannst jede der in den folgenden Abschnitten besprochenen Kategorien durchgehen, um herauszufinden, welche Anforderungen du für dein Gerät in Betracht ziehen solltest.

Hardware

Der Großteil der Hardware, die du für ein Gerät auswählst, dient der Unterstützung der Hauptfunktion deines Geräts. Um das Beispiel des Autos von vorhin aufzugreifen: Die meisten Hardware-Komponenten - wie die Räder, das Lenkrad, der Motor und so weiter - unterstützen die funktionalen Anforderungen des Autos für den Transport. Die nicht-funktionalen Anforderungen des Autos spiegeln sich auch in der Hardware wider. Es gibt eine Möglichkeit, das Öl mit einer Schraube zu wechseln und einen herausnehmbaren Ölfilter. Es gibt einen Diagnoseanschluss, der mit einem Computer verbunden werden kann, um Codes aus dem Auto auszulesen. Diese gehören zu den nicht-funktionalen Anforderungen, die sich aus der Wartung ergeben .

Hier ein weiteres Beispiel im Kontext des IoT: Stell dir ein bildgebendes Gerät mit einer Kamera vor. Die Kamera und die benötigten Rechenressourcen für die Bildverarbeitung sind ausschlaggebend für die Wahl der Hardware. Manche Geräte, vor allem wenn sie keine Benutzeroberfläche wie einen Touchscreen haben, benötigen jedoch einen Anschluss für ein Kabel, damit sich ein Techniker in das Gerät einloggen und es reparieren kann. Manchmal sind die Geräte mit einem speziellen Diagnosemodus ausgestattet, der es einem Techniker oder Benutzer ermöglicht, Probleme am Gerät zu beheben.

Wenn du die Hardware für dein Gerät auswählst, musst du an Dinge wie die benötigte Rechenleistung für die gewünschten Funktionen, die erforderlichen Sicherheitsvorkehrungen und die Konnektivitätsfunktionen für den Zugriff auf die Cloud denken, was bei einem IoT-Gerät fast vorausgesetzt wird. Außerdem solltest du überlegen, welche Hardwarefunktionen für das Lebenszyklusmanagement des Geräts am besten geeignet sind.

Berechne

In der F&E-Phase musst du die Rechenressourcen von auswählen, die sowohl die Verwaltung des Geräts als auch die Hauptfunktion deines Geräts unterstützen. Am unteren Ende des Spektrums stehen die einfachsten Geräte, bei denen die RAM Speicherung in Megabyte und die Geschwindigkeit in Megahertz gemessen wird. Am anderen Ende des Spektrums gibt es Hardware-Appliances mit Hunderten von Gigabyte Arbeitsspeicher, Terabyte an Speicherung und Multicore-Prozessoren, die oft über spezielle Rechenressourcen wie GPUs für spezielle Verarbeitungsfälle verfügen.

Der Kompromiss für mehr Rechenleistung ist der Stromverbrauch. Auch wenn die Geräte nur über minimale Rechenkapazitäten verfügen, verbrauchen sie in der Regel nur einstellige Milliwatt- oder sogar Mikrowatt-Leistungen. Einige Anwendungen erfordern einen minimalen Stromverbrauch über einen längeren Zeitraum, weil die Geräte in einer Umgebung installiert werden und lange Zeit - vielleicht sogar jahrelang - laufen müssen, ohne dass das Gerät aufgeladen wird.

Für ein Gerät solltest du gerade so viel Hardware auswählen, dass deine Anwendung ausgeführt werden kann, und zusätzlich einen gewissen Overhead an Rechenleistung, RAM und Speicherung für nicht funktionale Anforderungen oder für den Fall, dass ein zukünftiges Update mehr Rechenleistung benötigt. Dein Gerät braucht genügend Speicherung, um ein Update herunterzuladen und die Änderungen auf den bestehenden Code anzuwenden.

Sicherheitsmerkmale

Wenn du über die Hardware deines Geräts nachdenkst, solltest du auch über die Sicherheit nachdenken. Sicherheit ist ein wichtiger Bestandteil des Gerätelebenszyklusmanagements, insbesondere wenn es um die Ausführung von Code, die Beanspruchung von Geräten, die Bereitstellung von Geräten und die Sicherheit im Allgemeinen geht. Die Auswahl der richtigen hardwarebasierten Sicherheit ist daher eine der besten Verteidigungsmaßnahmen gegen eine Reihe von Sicherheitsherausforderungen und die Bereitstellung, die später in diesem Kapitel besprochen werden.

Ein solches Sicherheitsmerkmal ist ein Trusted Platform Module (TPM). TPMs gibt es seit den frühen 2010er Jahren in Computern. Diese kryptografischen Mikrocontroller bieten eine Reihe von Funktionen für die Kryptografie und Sicherheit von Geräten. Eine der Hauptfunktionen eines TPMs ist das Speichern von Schlüsseln . Die Geräte verwenden diese Schlüssel und speichern sie im TPM und nicht im Speicher. Einmal geschrieben, können die Schlüssel nicht mehr entfernt werden, ohne das TPM zu löschen. Wenn die Schlüssel verloren gehen, funktionieren viele andere Dinge, die auf den Schlüsseln basieren, nicht mehr, z. B. die verschlüsselte Speicherung. Eine weitere Hauptfunktion von TPMs ist die hardwarebasierte Zertifizierung. Sie bestätigt, dass es sich bei dem Gerät tatsächlich um ein Gerät handelt, das von einem Hersteller hergestellt und ausgeliefert wurde. Dies ist besonders bei IoT-Geräten nützlich. Das TPM sorgt für die Einzigartigkeit des Geräts und authentifiziert das Gerät gegenüber einem Bereitstellungsdienst.

TPMs verwenden eine von der Industrie veröffentlichte Spezifikation, die derzeit in der Version 2.0 vorliegt (Stand: Ende 2023). TPMs werden je nach Gerät auf viele verschiedene Arten implementiert, aber die meisten verwenden einen diskreten Mikrocontroller für diesen Zweck. Hypervisoren integrieren ein virtuelles TPM oder nutzen das TPM eines Host-Geräts für virtuelle Maschinen. Maschinen ohne physisches TPM können softwarebasierte TPMs verwenden, die von der Firmware des Geräts (BIOS, UEFI usw.) oder dem Betriebssystem bereitgestellt werden. Software-TPMs können für Entwicklungszwecke verwendet werden, sind aber für Produktionsanwendungen nicht zu empfehlen. Verwende stattdessen ein Hardware-TPM.

Viele sicherheitsgehärtete, eingeschränkte Geräte wie Azure Sphere verfügen über eingebaute Sicherheitsfunktionen, sodass ein TPM auf diesen Geräten nicht notwendig ist. Allerdings ist es ratsam, ein TPM für die Bescheinigung zu verwenden, wenn es sich um ein Gerät handelt, das mehr Commodity-Computing verwendet, wie z. B. x86- oder ARM-basierte Boards für ein Gerät, insbesondere bei Geräten mit erheblichen Sicherheitsbedenken.

Ein TPM kann als Lösung für viele gängige Sicherheitsbedrohungen verwendet werden, aber es wird auch bei der Gerätebereitstellung eingesetzt. Darauf wird später in diesem Kapitel eingegangen.

KI und ML

Künstliche Intelligenz (KI) und maschinelles Lernen (ML) werden nicht immer in IoT-Lösungen verwendet, aber sie werden immer häufiger eingesetzt, weil sie viele relevante Anwendungen in IoT-Workloads haben. Manchmal ist es schwer zu wissen, ob deine IoT-Lösung ML auf dem Gerät braucht, während du sie entwickelst. KI ist ein weit gefasster Begriff, der verschiedene Computersysteme umfasst, die versuchen, Aufgaben zu erledigen, für die normalerweise menschliche Intelligenz erforderlich ist. ML ist ein Teilbereich der KI, der sich auf die Erstellung und Anwendung von Modellen konzentriert, die aus der Analyse großer Datensätze entwickelt wurden, um die richtigen Modelle zu finden, und diese Modelle dann auf neue Eingaben anwendet. Mein Kollege Jeff Prosise hat ein ganzes Buch über dieses Thema geschrieben.¹

Zu den klassischen Anwendungsfällen für AL und ML gehören die Signalverarbeitung von Bildern, Videos und Audiodaten sowie die Erkennung von Mustern in großen Datensätzen. In der Vergangenheit waren IoT-Geräte in der Regel nicht in der Lage, diese Art von Workloads auf einem Gerät auszuführen. Die Daten mussten zur Verarbeitung in die Cloud oder an ein Kantengerät weitergeleitet werden. Die jüngsten Fortschritte im Chipdesign ermöglichen es jedoch, diese Aufgaben auf IoT-Geräten auszuführen. Bild- und Audioverarbeitung finden in vielen verschiedenen Bereichen Anwendung, z. B. in der Bestandsverwaltung, bei selbstfahrenden Autos, in der Videoüberwachung, in der Fertigung und in intelligenten Häusern. Einer der beliebtesten Anwendungsfälle ist die Benachrichtigung, wenn eine Person (im Gegensatz zu einem Tier oder einem zufälligen Objekt) an der Haustür ankommt. Das liegt daran, dass ein Modell trainiert wurde, um Menschen mithilfe von Computer Vision zu erkennen. Das Modell ist auf dem Gerät implementiert, so dass es die Benachrichtigung senden kann, ohne dass ein Videostream zur Analyse ins Internet gesendet werden muss.

Um diese Art von Arbeitslasten zu unterstützen, werden bei KI-basierten Arbeitslasten hauptsächlich zwei Arten von Hardware eingesetzt: Grafikprozessoren (GPUs) und KI-Beschleuniger. Grafikprozessoren (GPUs) waren die erste weit verbreitete Computerhardware für die KI-Verarbeitung, da viele PCs, z. B. Workstations und Spielecomputer, über GPUs verfügten. Im Jahr 2007 begann NVIDIA mit der Bereitstellung von SDKs, die für KI-basierte Arbeitslasten mit CUDA nützlich sind. GPUs eignen sich in der Regel gut für KI-Arbeitslasten auf PC-Hardware, aber aufgrund ihres Kühlungsbedarfs, ihres Stromverbrauchs und ihrer Größe sind sie für die meisten IoT-Anwendungen nicht geeignet; in einigen Umgebungen mit Kanten-Anwendungen können GPUs jedoch trotzdem funktionieren.

Eines der populärsten Beispiele ist die Tensor Processing Unit (TPU) von Google, die jetzt auch in Geräten wie Handys zum Einsatz kommt. Eine TPU arbeitet mit Googles TensorFlow-Bibliothek zusammen, sodass Modelle, die für TensorFlow entwickelt wurden, auf einer TPU laufen können. Google hat verschiedene Arten von TPUs gebaut, darunter Einplatinencomputer, USB-basierte Geräte und PCIe-basierte Geräte.

KI-Workloads auf IoT- oder Kanten-Geräten waren ursprünglich nur auf leistungsstarken, zentralisierten Computern wie Servern oder cloudbasierten Computern möglich. Diese Methode ist für das IoT immer noch relevant, aber KI-fähige IoT-Geräte haben zwei Hauptvorteile. Erstens verarbeiten KI-fähige IoT-Geräte Daten in Echtzeit mit geringen Latenzzeiten und ohne das Risiko von Netzwerkausfällen. Dadurch können IoT-Geräte schneller und zuverlässiger Entscheidungen treffen. Zweitens reduziert KI auf IoT-Geräten die Netzwerkbelastung. Die Daten werden lokal verarbeitet und müssen daher nicht über ein Netzwerk an ein Kantengerät oder die Cloud zur Verarbeitung übertragen werden.

Die flächendeckende Einführung von KI-fähigen Geräten für das IoT steht noch aus. Der Durchsickereffekt der Technologie, die ihren Weg in mobile Geräte, Einplatinencomputer und Module mit geringer Leistung findet, deutet jedoch darauf hin, dass KI auf IoT-Geräten die Anwendungsarchitektur für das IoT und das Hardwaredesign verändern wird .

Konnektivität

Gerät Konnektivitätshardware spielt eine Rolle dabei, wie ein Gerät mit der Cloud kommuniziert, um Daten in der Cloud zu senden und zu empfangen. Jede Form hat unterschiedliche Vor- und Nachteile und Sicherheitsbedenken.

Ethernet

Ethernet ist eine altbewährte Methode, um Geräte mit einem Netzwerk zu verbinden. Ethernet ist immer noch eine weit verbreitete Methode, um IoT-Geräte zu verbinden. Der Hauptvorteil von Ethernet ist, dass es aufgrund seiner Einfachheit und Allgegenwärtigkeit in Netzwerken einen großen Komfort für die Verbindungsanforderungen eines Geräts bietet. Alles, was man braucht, ist ein Ethernet-Kabel, und das Netzwerk kümmert sich um den Rest. Ethernet hat den Vorteil, dass es Power over Ethernet (POE) zur Verfügung stellt, das auch Geräte mit geringerer Leistung mit Strom versorgen kann. Obwohl es einfach ist, kann Ethernet Sicherheitsprobleme verursachen, da es keine Verschlüsselung auf Hardware-Ebene bietet, wie es bei anderen Medien der Fall ist. Netzwerksicherheit ist daher ein absolutes Muss. Du solltest einen Netzwerkanschluss an einem Switch sichern, IoT-Geräte durch Segmentierung isolieren und den physischen Zugang zu einem Gerät beschränken.

WiFi

WiFi ist die am weitesten verbreitete Art der Netzwerkverbindung für Geräte, da sie kostengünstig, schnell, sicher und weithin unterstützt ist. Die WiFi-Installation ist unterschiedlich und WiFi ist abwärtskompatibel mit Geräten, die bis zur ersten WiFi-Generation aus den 1990er Jahren zurückreichen.

WiFi hat ein paar Nachteile. Erstens können WiFi-Verbindungen für eingeschränkte Geräte eine Belastung für die Leistung eines Geräts sein. Zweitens können WiFi-Netzwerke eine Angriffsfläche bieten, weil sie über die Luft zugänglich sind (man muss nicht in ein Gebäude einbrechen, um auf das Netzwerk zuzugreifen). Geräte in WiFi-Netzwerken sollten eine starke Verschlüsselung und sicher gespeicherte WiFi-Schlüssel verwenden.

Cellular

Mobilfunk Verbindungen zu Mobilfunknetzen sind für Geräte sinnvoll, die sich nicht in der Nähe einer Netzwerkinstallation befinden. WiFi und Ethernet sind in der Regel auf Gebäude beschränkt, aber Mobilfunknetze sind in den meisten besiedelten Gebieten der Welt verfügbar. Wenn es nicht die Hauptverbindung für ein Gerät ist, kann es auch als Backup für ein Gerät dienen.

Mobilfunkmodems können ebenso wie WiFi bei eingeschränkten Geräten eine Menge Strom verbrauchen. Auch wenn Mobilfunknetze in der Regel von den Mobilfunkanbietern streng kontrolliert werden, sollte man nie davon ausgehen, dass ein Mobilfunknetz an sich sicher ist. Geräte in einem Mobilfunknetz befinden sich in einem öffentlichen Netz und sollten daher so sicher wie möglich gemacht werden.

Bluetooth

Bluetooth stellt normalerweise keine Verbindung zum Internet her, aber kann Informationen von einem Gerät an ein anderes Gerät mit Internetverbindung weiterleiten. In vielen Fällen fungiert das mit dem Internet verbundene Gerät als Proxy, Hub und Kante für mehrere andere Bluetooth-fähige Geräte. Bei dem Bluetooth-Gerät selbst kann es sich um ein IoT-Gerät oder in einigen Fällen um ein Telefon oder einen Laptop handeln. Normalerweise verwenden diese Lösungen eine App, wenn es sich um ein Verbrauchergerät handelt, oder eine Sicherheitsverbindung mit Bluetooth zwischen dem Gerät und seinem Internet-Proxy.

Bluetooth ist ein relativ einfach zu implementierendes Protokoll für Entwickler, aber das bedeutet, dass ein Gerät ein anderes Gerät wie ein Telefon oder einen Laptop haben muss, um seine Verbindung zum Internet zu vertreten. Außerdem hat Bluetooth eine relativ begrenzte Reichweite.

Andere

Ethernet, WiFi, Mobilfunk und Bluetooth sind gängige Verbindungsarten, aber das IoT ist keineswegs auf diese beschränkt. Einige Gerätehersteller stellen spezielle Verbindungen über Medien her, um Konnektivität zu gewährleisten, z. B. über Koaxialkabel, elektrische Infrastruktur oder ein eigenes drahtloses Protokoll.

Unabhängig davon, wie sich das Gerät verbindet, muss es die Sicherheit und andere nichtfunktionale Anforderungen wie Beantragung, Bereitstellung, Aktualisierung und Deprovisionierung berücksichtigen, um mit Azure zu arbeiten, und diese erfordern alle eine Netzwerkverbindung, um zu funktionieren .

Software

Die Software als Teil des IoT-Nexus liefert alle Anweisungen, die die Hardware deines Geräts ausführt, um Daten zu sammeln und zu verarbeiten, bevor sie sie schließlich an die Cloud sendet. Die Software, die dafür benötigt wird, besteht aus mehreren Schichten: Betriebssysteme, SDKs und schließlich dein Anwendungscode. Jede Ebene hat unterschiedliche Aspekte, die du bei der Auswahl der Software für dein Gerät berücksichtigen solltest.

Betriebssysteme

Das Betriebssystem bildet die Grundlage für alle anderen Programme, die du einsetzen möchtest. Sie sind alle unterschiedlich, also musst du dir überlegen, welches Betriebssystem zu deinen Entwicklungszielen und Hardwareanforderungen passt. Ein schwerfälliges Betriebssystem wie Ubuntu IoT Core, das du in Kapitel 3 kennengelernt hast, kannst du nicht auf einem Arduino-Gerät einsetzen, und von FreeRTOS kannst du nicht erwarten, dass es auf PC-Hardware gut funktioniert. Die Quintessenz ist, dass ein Betriebssystem für die Bedürfnisse deines Geräts geeignet sein und zum gesamten Lebenszyklus deines Geräts passen muss.

In Kapitel 2 wurden mit Azure Sphere, Azure RTOS und Windows IoT einige Betriebssysteme mit Bezug zu Azure besprochen. Über den Rahmen eines Azure-zentrierten Betriebssystems hinaus solltest du jedoch noch etwas anderes in Betracht ziehen:

Sicherheitsmerkmale

Unabhängig von der Anwendung, sei sie einfach oder komplex, sollte das Betriebssystem, das du für ein Gerät auswählst, sicher sein. Die meisten Betriebssysteme, die explizit für den Einsatz im Internet der Dinge gedacht sind, wurden von Grund auf mit Blick auf die Sicherheit entwickelt. Linux-basierte Betriebssysteme sind für ihre strengen Sicherheitskontrollen bekannt und können für eine optimale Gerätesicherheit gehärtet werden. Außerdem unterstützen sie Sicherheits-Hardwarefunktionen wie TPMs. Kapitel 14 befasst sich mit verschiedenen Arten von Sicherheitsüberlegungen bei der Entwicklung von Geräten.

Kompatibilität

Ein wichtiges Kriterium bei der Auswahl eines Betriebssystems für ein Gerät ist die Kompatibilität mit deiner geplanten Software und Hardware. Was die Software angeht, so unterstützen die meisten uneingeschränkten Betriebssysteme, z. B. die auf Linux oder Windows basierenden, eine breite Palette von Softwareplattformen wie .NET, Python oder JavaScript. Bei eingeschränkten Geräten ist die Auswahl wesentlich größer, da einige Plattformen speziell für bestimmte Sprachen entwickelt wurden. In den meisten Fällen können IoT-Geräte jedoch C- und C++-Anwendungen ausführen.

Die Hardwarekompatibilität eines Betriebssystems beinhaltet, welche CPUs von einem Gerät unterstützt werden und welche andere Hardware, wie z. B. Netzwerkverbindungen, Geräteintegration durch Treiber und Hardwareschnittstellen wie GPIO, seriell und USB, von einem Betriebssystem unterstützt werden. Linux-basierte Betriebssysteme bieten eine breite Unterstützung für eine große Bandbreite an Hardware. Eher eingeschränkte Betriebssysteme wie FreeRTOS haben weniger Optionen, stellen aber in der Regel auch keine hohen Anforderungen an die Hardware.

Einfachheit

Einfachheit ist bei Betriebssystemen das Kriterium, das wahrscheinlich den größten Einfluss hat, denn "Einfachheit" kann viele Bedeutungen haben. Ein Betriebssystem sollte:

Einfach zu nutzen, zu bauen und sicher zu sein
Einen kleinen Fußabdruck haben
Benötigen weniger Rechenressourcen wie RAM und CPU
Einfach zu aktualisieren und zu pflegen sein
Mehr Sicherheit mit einer kleinen Angriffsfläche

Einfachheit bedeutet jedoch nicht, dass man bei den Funktionen Kompromisse eingeht. Ein einfaches Betriebssystem beginnt mit Minimalismus als Designziel und ermöglicht es den Nutzern, mit Tools wie Paketmanagern und Konfigurationsskripten darauf aufzubauen.

Konsistenz

Wenn du ein Betriebssystem für ein Gerät auswählst, solltest du Konsistenz anstreben, was bedeutet, dass das Betriebssystem ein regelmäßiges, vorhersehbares Lebenszyklusmanagement haben sollte. Viele moderne Betriebssysteme verwenden ein Long-Term-Support (LTS)-Modell für die Verwaltung von Updates. Eine LTS-Version eines Betriebssystems ist ein bestimmtes Build, das bis zu einem bestimmten Datum Systemaktualisierungen, in der Regel Sicherheitspatches, enthält. Die Version erhält jedoch möglicherweise keine neuen Funktionen. Für Betriebssysteme auf Geräten, die keine Hardware-Upgrades erhalten, sind LTS-Versionen ein Segen: Ein Gerätehersteller kann ein Betriebssystem bereitstellen und vorhersehbare Patches für die Zukunft bereitstellen, ohne das Betriebssystem neu zu importieren oder zu aktualisieren. Außerdem brauchen die Geräte nicht immer die neuesten Betriebssystemfunktionen, um den Zweck zu erfüllen, für den sie entwickelt wurden. Windows IoT und die meisten Linux-Builds wie Ubuntu Core und Yocto Linux bieten LTS-Versionen.

Betriebssysteme bilden die Grundlage für den Betrieb eines Geräts. Die Wahl des richtigen Systems ist nicht einfach.

SDKs

In Kapitel 2 wurden die Azure SDKs für eingeschränkte und nicht eingeschränkte Geräte für Azure-Konnektivität behandelt. Diese SDKs sind jedoch nur ein Teil der SDKs, die du für dein Gerät verwenden wirst. Wenn du mit Hardware von einem Hardwarehersteller arbeitest, werden dir wahrscheinlich SDKs für diese Hardware zur Verfügung gestellt. Außerdem kannst du ein SDK für dein Gerät erstellen, wenn du es erweitern willst.

SDKs sind eine Abhängigkeit für deine Anwendung, aber viele SDKs haben auch ihre eigenen Abhängigkeiten. Sie basieren auf dem Anwendungsframework, wie z. B. Node.js, Python oder .NET, und enthalten wahrscheinlich Pakete und Code, den das SDK benötigt, um zusätzlich zu dem, was sie bereitstellen, zu funktionieren. Software wird ständig weiterentwickelt, so dass es von Zeit zu Zeit notwendig wird, Software und Abhängigkeiten zu aktualisieren. Hier sind ein paar Dinge, auf die du achten solltest:

Überprüfe SDKs und ihre Abhängigkeiten auf Updates, insbesondere Sicherheitsupdates.
Entwickle automatisierte Regressionstests und scanne den neuesten Code auf Sicherheitsschwachstellen mit Tools wie SonarQube.
Beziehe Updates als Teil eines vorhersehbaren Update-Lebenszyklus des Geräts ein.

App-Isolierung

In Kapitel 14 wird die Sicherheit ausführlich behandelt, aber eine Möglichkeit, die Anwendungssicherheit deutlich zu verbessern, ist die App-Isolierung. App-Isolation bedeutet, dass dein Anwendungscode und normalerweise auch die zugehörigen Laufzeiten in einer isolierten Umgebung laufen, die vom primären Betriebssystem getrennt ist. Das Betriebssystem gibt nur das preis, was für die Ausführung einer Anwendung notwendig ist.

Eine einfache Möglichkeit, dies auf Linux-basierten Systemen zu tun, ist die Verwendung von chroot. Der Befehl chroot ist die Abkürzung für "change" und "root". Er richtet ein isoliertes Dateisystem für einen Prozess ein. Der Prozess kann keine Dateien im Dateisystem des Hosts durchsuchen, sondern nur die innerhalb des chroot-Kontexts. Dieses Dienstprogramm bietet auch eine gewisse Ausführungsisolierung und Sicherheit für einen Prozess, um ihn vom Rest des Betriebssystems zu isolieren.

Docker ist eine weitere Möglichkeit, Prozesse zu isolieren. Docker ist jedoch mehr als nur eine Isolierung. Es ist ein ganzes Ökosystem für die Verpackung und Bereitstellung von Software in Containern. Docker-Images werden auf einem Host-Betriebssystem in einer vollständig isolierten Umgebung ausgeführt. Sie bieten eine bequeme Möglichkeit, Anwendungen zu verteilen, da sie verpackt und in einer Container-Registry veröffentlicht werden. Die Images werden aus der Registry gezogen und als neue Instanzen des Images als Container gestartet. Du kannst eine neue Version deines Container-Images veröffentlichen, wenn du deine Anwendung aktualisieren musst. Docker kann dieses Image installieren, ohne dass das zugrunde liegende Betriebssystem aktualisiert werden muss. Kapitel 6 enthält eine vollständige Erklärung von Docker-Containern und dem Docker-Container-Workflow.

Eine dritte Möglichkeit, die mit vielen Linux-Distributionen funktioniert, nutzt ein Projekt namens Snapcraft. Snapcraft erstellt Pakete, sogenannte "Snaps", die über einen Paketmanager auf einem Linux-Gerät bereitgestellt werden. Es verwendet ein App-Isolationsmodell, das dem von Docker mit Containern ähnelt, bietet aber einen deklarativen Ansatz, der sowohl Build- als auch Run-Anweisungen für die App enthält und verschiedene Dinge eher implizit als explizit offenlegt, wie z. B. Netzwerkverbindungen oder den Zugriff auf bestimmte Hardware. Snapcraft lässt den Snapd-Daemon herausfinden, was diese Deklarationen im Einzelnen bedeuten. Snaps werden von IoT-fokussierten Linux-Distributionen wie Yocto und Ubuntu Core weitgehend unterstützt.

Azure Sphere ist zwar ein eingeschränktes Gerät, bietet aber eine App-Isolierung, um die Sicherheit auf dem Gerät zu verbessern. Die Apps laufen hier in einem Container, der die Hardware über eine API offenlegt.

Bauen, testen und freigeben

Der Prozess der Erstellung, des Testens und der Freigabe von Software für ein Gerät ist vielschichtig, da er Betriebssysteme, Frameworks, SDKs, Abhängigkeiten und deine Software einbezieht.

Die einfachste Form dieses Prozesses besteht darin, etwas manuell zu erstellen und es auf ein Gerät zu übertragen. Dies eignet sich jedoch nicht für qualitativ hochwertigen und sicheren Code. Um die Qualität und Sicherheit des Codes zu verbessern, muss der Code eine Reihe von Scans und Tests durchlaufen, bevor er auf das Gerät übertragen wird. Um diesen Prozess zu beschleunigen, nutzen Entwicklerinnen und Entwickler kontinuierliche Integration und kontinuierliche Bereitstellung (CI/CD) durch Automatisierung, üblicherweise Pipelines genannt.

Der CI/CD-Prozess umfasst die Erstellung von Software aus dem Quellcode, das Testen dieser Software mithilfe von automatisierten Tests, z. B. mit Unit-Tests und Gerätesimulatoren für Integrationstests, die Paketierung deiner Software und schließlich die Bereitstellung dieser Software auf den Geräten.

CI/CD durch Automatisierung hat den zusätzlichen Vorteil zusätzlicher Sicherheitsebenen, die zur Verbesserung der Codequalität und Sicherheit beitragen. Die Nutzung dieser Sicherheitsfunktionen durch Automatisierung bedeutet in der Regel keinen zusätzlichen Zeitaufwand für einen Build-Prozess:

Stelle sicher, dass die Nutzer, die zum Code beitragen, vertrauenswürdige Akteure sind, die über die entsprechenden Berechtigungen verfügen, um den Code einzusehen und beizutragen.
Stelle sicher, dass die Entwickler/innen ihren Code im Rahmen eines Prüfverfahrens einbringen. Dies verbietet in der Regel das Übertragen von Code in den Hauptzweig eines Projekts. Beiträge sollten als Pull-Request eingereicht werden, und nur autorisierte Beauftragte können den Code nach Prüfung in den Hauptzweig übertragen.
Stellen Sie sicher, dass Code, der einen Build-Prozess durchläuft, mit einem vertrauenswürdigen Principal erstellt wird, der in der Regel kein User Principal ist.
Verwende die Code-Signierung, um sicherzustellen, dass das Gerät den auf einem Gerät installierten Code vor der Installation mithilfe vertrauenswürdiger Zertifizierungsstellen validieren kann.
Erlaube es den Mitwirkenden nicht, Releases direkt in ein Build-Repository, wie z.B. eine Container-Registry, zu übertragen.

Der Einsatz von Tests, Sicherheitsscans und Sicherheitskontrollen im Rahmen eines Build- und Testprozesses kann dazu beitragen, die Gesamtqualität eines Produkts von den ersten Entwicklungsphasen über die Prototyping-Phase und den Herstellungsprozess bis hin zum Update-Prozess zu verbessern.

Soweit es möglich ist, solltest du den Code ohne Geräte erstellen und testen, denn so kann der Code schnell fehlschlagen, d.h. Probleme können im Code gefunden werden, bevor er auf ein Gerät übertragen wird. Wenn ein Gerät benötigt wird, versuche, emulierte Hardware zu verwenden, wenn sie mit einem Projekt wie Qemu verfügbar ist, das Prozessoremulationen für die Erstellung virtueller Maschinen aller Art bietet. Qemu kann auf einem Linux-Host als Teil einer CI/CD-Pipeline laufen.

In Kapitel 3 wurde die Verwendung von Gerätesimulatoren für Integrationstests, Regressionstests, Lasttests und Leistungstests als Teil der Automatisierung von Cloud-seitigem Code besprochen. Code, der auf einem Gerät läuft, sollte einen ähnlichen Prozess mit seinen Integrationstests, Regressionstests, Lasttests und Leistungstests durchlaufen. Wie jeder Code sollte auch dieser mit Unit-Tests validiert werden (in der Regel bis hinunter zur Methodenebene) und mit Tools wie SonarQube auf Sicherheitslücken und Muster untersucht werden.

Letztendlich muss der Code auf einem physischen Gerät getestet werden. Soweit es möglich ist, solltest du auch diesen Prozess automatisieren, aber in der Regel ist es besser, die Tests auf einem Gerät durchzuführen, da dies weniger Zeit und weniger manuelle Eingriffe zwischen den Builds erfordert.

Nachdem der Code eine Build- und Testphase durchlaufen hat, wird er erstellt und für eine Veröffentlichung verpackt. Eine Freigabe ist einfach eine Version des Codes, die möglicherweise als endgültige Version ausgeführt werden kann. Dieser Code kann noch einige weitere Prüfungen durchlaufen, wie z. B. Akzeptanztests oder ähnliche Tests, bevor er in eine Umgebung zur Veröffentlichung freigegeben wird.

In den letzten Abschnitten haben wir uns mit den verschiedenen nicht-funktionalen Anforderungen beschäftigt, die du bei der Entwicklung eines IoT-Geräts in Bezug auf Hardware und Software berücksichtigen musst. Wenn du mit der Entwicklung eines Prototyps beginnst, wirst du wahrscheinlich genauso viel Zeit damit verbringen, dich mit den nicht-funktionalen Anforderungen des Geräts zu befassen wie mit der Hauptfunktion des Geräts. Das ist ganz normal. Bei Geräten, insbesondere bei IoT-Geräten, müssen diese als Teil des Funktions- und Aufgabenbestands des Geräts berücksichtigt werden. Einiges davon kann "ausgelagert" werden, indem du auf Plattformen mit umfangreicheren Funktionen wie Azure Sphere zurückgreifst, aber letztendlich ist ein Gerät deine Kreation - es ist dein Design, um einen bestimmten Bedarf zu erfüllen, den du dir vorstellst. Selbst wenn du Dienste für ein gewisses Maß an Automatisierung nutzt, müssen diese in das Gerät integriert werden, auch wenn du sie nicht selbst entwickelst .

Herstellung

Der Herstellungsprozess besteht darin, aus einem verfeinerten Prototyp das tatsächliche Produkt herzustellen, das verwendet werden soll. Die Komplexität des Prozesses hängt vom Umfang und der Größe des Geräts ab und davon, wer es benutzen wird. Der Herstellungsprozess für Geräte sieht für solche Anwendungen ganz anders aus. Die handelsüblichen Tags werden zu Tausenden in einer Fabrik nach einem wiederholbaren Verfahren hergestellt. Im Gegensatz dazu werden bei kundenspezifischen Lösungen vielleicht nur Dutzende von Geräten hergestellt, wobei jedes einzelne auf die Bedürfnisse des Nutzers zugeschnitten ist.

Bei der Herstellung von IoT-Geräten werden in der Regel keine Rohstoffe genommen und zu etwas Brauchbarem zusammengesetzt. Vielmehr erfordert die Herstellung die Beschaffung von Hardwarekomponenten und den Zusammenbau dieser Komponenten, die Installation von Software und die Vorbereitung des Geräts für die Bereitstellung. Der Herstellungsprozess beginnt parallel zu Forschung und Design.

Wenn sich ein Gerät von der Machbarkeitsstudie zu einem Prototyp oder sogar zu einem minimal brauchbaren Produkt entwickelt, untersuchen die Gerätehersteller mögliche Lösungen und beginnen mit der Beschaffung der Hardware und Anlagen für die Herstellung von IoT-Geräten. Je näher ein Gerät an die Produktionsreife heranrückt, desto detailliertere Pläne werden für die Herstellung des Geräts erstellt. Ein Hersteller wird eine kleine Charge von Vorproduktionsgeräten herstellen, um sicherzustellen, dass die Geräte die erforderlichen Spezifikationen erfüllen. Danach wird das Gerät in Serie produziert. Schließlich wird das Produkt verpackt und an den Nutzer verschickt, der das Gerät aufstellt oder von einem Vertreter aufstellen lässt.

Unabhängig vom Verfahren ist der Beginn der ersten Produktionsläufe der Punkt im Produktlebenszyklus, der das Ende der bedeutenden Forschungs- und Entwurfsphase markiert, da das Gerät mit der Bereitstellung seinen Hauptablauf beginnt.

Versand

Nachdem ein Gerät hergestellt wurde, wird es vom Hersteller zu seinem Einsatzort gebracht. Je nach Art des Geräts kann das so einfach sein wie der Transport von der Fabrik zum Aufstellungsort oder etwas viel Aufwändigeres, wie der Vertrieb im Einzelhandel. Alle diese Vorgänge beinhalten eine Art von Transportprozess.

Ich erwähne den Versand hier nicht, weil er besonders technisch ist, sondern weil er ein wichtiger Meilenstein im Leben eines Geräts ist. Es ist wahrscheinlich das letzte Mal, dass ein Gerätehersteller das Gerät physisch zu Gesicht bekommt. Zu diesem Zeitpunkt hat das Gerät alles, was es braucht, um zu funktionieren, und es ist bereit, seine Hauptfunktion zu erfüllen.

Beantragung und Bereitstellung

Die Beantragung eines Geräts ist zwar technisch gesehen ein Schritt im Herstellungsprozess, aber er ist ein wichtiger Schritt im Lebenszyklusmanagement eines Geräts, denn in diesem Schritt erhält das Gerät seinen ersten Satz von Anmeldeinformationen, die für die Bereitstellung verwendet werden.

Die beiden wichtigsten Azure-Dienste, die bei der Gerätebereitstellung verwendet werden, sind der Device Provisioning Service (DPS) und der mit dem Gerät verbundene IoT Hub. Der DPS von Azure ist ein Verbindungsbroker zwischen einem Gerät und einem Azure IoT Hub. Ein DPS ist für Geräte nicht notwendig, wenn die Anmeldedaten für den IoT Hub bereits auf dem Gerät vorhanden sind. Aber eine DPS ist eine gute Möglichkeit, die Gerätebereitstellung zu verwalten, weil sie die Erstellung und Verwaltung von Geräten in einem IoT Hub automatisiert. Außerdem kann ein einziger DPS mehr als einen IoT Hub verwalten, was ihn für große IoT-Geräteeinsätze besser geeignet macht.

Der IoT-Hub auf Azure erleichtert viele Vorgänge für die Gerätekommunikation, Twinning, Updates und Messaging. Deshalb ist er die wichtigste cloudbasierte Komponente für Geräte. Auf Twinning und Updates gehe ich später in diesem Kapitel ein. Kapitel 6 befasst sich mit dem Einsatz von IoT Edge und Kapitel 5 mit den verschiedenen Arten von Messaging, die von IoT Hub unterstützt werden. Betrachte das Messaging vorerst als eine der beiden Seiten dessen, was der DPS vermittelt.

Die Beantragung und Bereitstellung umfasst Folgendes:

Das Claiming beginnt mit der Erstellung eines ersten Satzes von Anmeldedaten, die auf ein Gerät geladen werden. Dieser Vorgang wird cloud-seitig auf dem DPS durchgeführt. Diese Berechtigungsnachweise können sein:

Shared Access Signature (SAS) Token

Ein SAS-Token verwendet einen Schlüssel, der auf dem Gerät und in der Cloud gespeichert ist. Das Gerät verwendet den Schlüssel, um ein Token zu signieren, und der DPS verwendet denselben Schlüssel, um das Token zu validieren.

X.509-Zertifikate

Ein X.509-Zertifikat verwendet Private Key Infrastructure (PKI), um ein Zertifikat zu erstellen, das eine vertrauenswürdige Zertifizierungsstelle zwischen dem Gerät und der Cloud nutzt.
Beide können verwendet werden, aber Zertifikate sind wahrscheinlich sicherer und werden auch benötigt, wenn du eine TPM-basierte Geräte-Attestierung verwenden willst. Die Berechtigungsnachweise können für ein einzelnes Gerät oder für eine Gruppe von Geräten gemeinsam verwendet werden, je nach Bedarf. Ein einzelnes Gerät muss eine Geräte-ID angeben, um das Gerät richtig zu identifizieren.
Die Beantragung wird fortgesetzt, nachdem die Anmeldedaten auf dem DPS erstellt wurden. Diese Anmeldeinformationen werden auf dem Gerät gespeichert, bevor es ausgeliefert wird. Die Berechtigungsnachweise können Teil eines Build-Prozesses sein und in die Firmware oder das Betriebssystem des Geräts integriert werden. Die Zugangsdaten können auch separat installiert werden, nachdem die Firmware oder das Betriebssystem des Geräts installiert wurde. Sobald die ersten Zugangsdaten geladen sind, ist die Beantragung abgeschlossen.
Das Gerät wird nach dem Herstellungsprozess und nach der Reklamation versandt. Der Versand bedeutet, dass das Gerät von der Herstellung bis zum Einbau fertig ist.
Sobald sich ein Gerät an dem für die Installation vorgesehenen Ort befindet, ist es bereit für die Bereitstellung. Die Bereitstellung beginnt, sobald das Gerät eingeschaltet und mit einem Netzwerk verbunden ist. Das Gerät verwendet die vorinstallierten Anmeldedaten, um den DPS über eines von drei verschiedenen Verfahren zu kontaktieren:

Shared Access Signature (SAS) Token

SAS Token werden mit dem auf dem Gerät mitgelieferten gemeinsamen Zugangsschlüssel erstellt. Die ID des Geräts und andere Metadaten bilden das SAS-Token, das dann mit dem Schlüssel signiert wird. Die Signatur und die Metadaten werden zur Authentifizierung an den DPS zurückgeschickt.

X.509-Zertifikate

Zertifikate bieten einen robusten Sicherheitsmechanismus, da sie eine dritte Zertifizierungsstelle verwenden, um die Zertifikate vor ihrer Verwendung zu validieren. Das Zertifikat wird vom DPS ausgestellt. Nach der Validierung wird das Zertifikat dem DPS vorgelegt, um das Gerät anhand eines Stammzertifikats zu authentifizieren.

TPM-basierte Beglaubigung mit Zertifikaten

Die TPM-basierte Authentifizierung ist eine Authentifizierungsmethode auf Hardware-Ebene, die auf einem TPM gespeicherte Zertifikate verwendet. Das TPM verwendet seine Hardware-IDs und das Zertifikat, um das Gerät zu authentifizieren. Diese Methode ist am sichersten, weil sie Spoofing und andere Angriffe auf eine IoT-Cloud verhindert.

Sobald die Anmeldedaten akzeptiert wurden, weist der DPS ein Gerät einem IoT Hub zu. Der IoT-Hub kann einer von vielen verschiedenen Hubs sein, die im Rahmen eines Round-Robin-Auswahlverfahrens zugewiesen werden, oder ein spezieller Hub für die angegebenen Anmeldedaten.
Sobald sich das Gerät mit den Geräteanmeldeinformationen authentifiziert hat, erstellt der DPS einen gerätespezifischen Satz von Anmeldeinformationen für den IoT Hub. Die Geräteanmeldedaten auf dem IoT Hub können entweder ein Verbindungsstring mit einem SAS-Token oder ein X.509-Zertifikat sein, das von einem anderen Zertifikat abgeleitet wurde. An diesem Punkt ist der IoT Hub bereit für die Verbindung des Geräts. Das Provisioning gilt an diesem Punkt als abgeschlossen.
Nachdem die Anmeldedaten im IoT Hub erstellt wurden, werden sie vom DPS an das Gerät gesendet. Diese Anmeldedaten werden auf dem Gerät gespeichert und sollten wie alle anderen Anmeldedaten gesichert werden. Die Zugangsdaten enthalten auch Informationen darüber, wo der IoT Hub zu finden ist. Außerdem sendet der DPS eine Anfangskonfiguration für das Gerät. Das sind die gleichen Daten, die im Gerätezwilling auf Azure gespeichert sind.
Der letzte Schritt besteht darin, die vom IoT Hub bereitgestellten Anmeldedaten zu verwenden.

Sobald das Gerät über die erforderlichen Zugangsdaten für den IoT Hub verfügt, kann der DPS aus dem Weg gehen und das Gerät und den IoT Hub direkt miteinander kommunizieren lassen. Sollte ein Gerät jemals neu provisioniert werden müssen, durchläuft es einfach den gleichen Prozess wie die Provisionierung. Es erhält neue Anmeldedaten, die mit demselben Azure IoT Hub kommunizieren können oder auch nicht. In jedem Fall legt die Gerätebereitstellung den Grundstein für den Hauptablauf des Geräts im Rahmen seines Lebenszyklus .

Geräte mit einem IoT Hub über den Device Provisioning Service bereitstellen

Das Einrichten eines Device Provisioning Services und eines IoT Hubs auf Azure ist ziemlich einfach. Die Vorlage befindet sich auch im Ordner Kapitel 4 des Code-Repositorys des Buches, falls du sie auf andere Weise einsetzen möchtest. In jedem Fall benötigt die Vorlage zwei Parameter: den Namen des Provisioning Service und den Namen des IoT Hubs. Diese sind Teil des Hostnamens, also müssen sie eindeutig sein. Sobald du einen Namen hast, kannst du die Felder im Azure-Portal ausfüllen. Außerdem musst du ein Abonnement und eine Ressourcengruppe auswählen oder du kannst eine neue Ressourcengruppe erstellen. Wähle eine Region für die Ressourcengruppe.

Sobald du bereit bist, klicke auf die Schaltfläche "Überprüfen + Erstellen". Die ARM-Vorlage wird den IoT Hub mit dem Device Provisioning Service als Teil der Bereitstellung verbinden. Warte ein paar Augenblicke, bis der Vorgang abgeschlossen ist. Du kannst dies unter "Die Bereitstellung läuft" überwachen . Sobald der Vorgang abgeschlossen ist, klickst du auf "Zur Ressourcengruppe gehen", um die hier beschriebene Einrichtung abzuschließen:

In der Ressourcengruppe wählst du den Device Provisioning Service.
Wähle "Anmeldungen verwalten" und dann "Anmeldergruppe hinzufügen". Mit einer Anmeldegruppe können sich mehrere Geräte bei einem oder mehreren IoT Hubs anmelden. Eine Einzelanmeldung ist für ein bestimmtes Gerät.
Das Blatt "Anmeldergruppe hinzufügen" enthält mehrere Felder, die du ausfüllen musst. Zum Zeitpunkt der Erstellung dieses Buches gibt es noch keine Möglichkeit, die Einrichtung einer Anmeldegruppe mithilfe einer ARM-Vorlage zu automatisieren.
1. Gib für "Gruppenname" einen beschreibenden Namen für die Gruppe ein.
2. Wähle für "Bescheinigungstyp" die Option "Symmetrischer Schlüssel". Der symmetrische Schlüssel ist für die Zwecke dieser Anleitung geeignet, aber für einen sicheren Einsatz ist ein Zertifikat vorzuziehen.
3. Lass "Schlüssel automatisch generieren" aktiviert.
4. Setze "IoT Edge Device" auf false. In Kapitel 5 wirst du mit diesem DPS ein IoT Edge-Gerät einrichten.
5. Nimm die Standardeinstellung bei "Wähle aus, wie du Geräte den Hubs zuweisen willst". Da es nur einen einzigen IoT Hub gibt, ist diese Einstellung in Ordnung. Für größere Geräteeinsätze kannst du eine andere Methode verwenden oder sie sogar mit einer Azure-Funktion anpassen.
6. Das Blade wird standardmäßig auf den IoT Hub gesetzt, den du beim Erstellen des DPS erstellt hast.
7. Übernimm die Standardeinstellungen bei "Wähle aus, wie die Gerätedaten bei der Wiederbereitstellung behandelt werden sollen ".
8. Lösche den Text im Feld "Initial Device Twin State" und ersetze ihn durch einen leeren Satz geschweifter Klammern {}.
9. Lass "Eintrag aktivieren" auf "Aktivieren" stehen.
10. Zum Schluss klickst du auf "Speichern".
Wähle nun die soeben erstellte Einschreibungsgruppe aus.
Klicke auf die Schaltfläche "In die Zwischenablage kopieren" neben dem Wert für den Primärschlüssel.
Öffne in Visual Studio Code den Ordner für das Gerät, mit dem du in Kapitel 2 gearbeitet hast. Wenn du das noch nicht getan hast, kannst du ein Beispielgerät oder ein simuliertes Gerät mit dem Code im Repository erstellen. Befolge die Anweisungen in Kapitel 2, um zu erfahren, wie du das machst.
Öffne settings.json.
Füge den Schlüssel, den du kopiert hast, in den Wert für symmetricKey ein.
Jetzt navigierst du zur Registerkarte "Übersicht" im Azure-Portal. Auf dieser Registerkarte musst du einige Werte abrufen:
- Hol dir den Wert für "ID Scope" von der Klinge und füge ihn in den Wert für idScope in der settings.json ein.
- Hol dir den Wert für den "Service-Endpunkt" aus dem Blade und füge ihn in den Wert für provisioningHost in der settings.json ein.
  
  Wenn du fertig bist, solltest du eine settings.json haben, die ungefähr so aussieht:
```
{   
    "start":"dps",
    "telemetry":"simulator",
    "camera":"simulator",
    "pollFreq": 5000,
    "connString": "",
    "provisioningHost":"blaizedps1.azure-devices-provisioning.net",
    "idScope":"0ne007C4D38",
    "symmetricKey":"rREfrgOcrb7Bm4da…6WvRs2HzwLPcg==",
    "registrationId":"device1"
}
```
Speichere settings.json. Dies ist im Wesentlichen der Claiming-Teil des Lebenszyklus eines Geräts.
Starten Sie nun das Gerät. Das Gerät verwendet den Schlüssel gegenüber dem Provisioning Service zur Bescheinigung und schließt den Provisioning-Prozess ab. Das Gerät, egal ob du ein Beispielgerät oder einen Simulator verwendest, erstellt eine Datei namens conn.json im Stammordner des Repositorys. Diese Datei enthält die Verbindungszeichenfolge für das Gerät. Jedes Mal, wenn du das Gerät startest, verwendet es diese Datei, um zu wissen, nach welchem IoT Hub es suchen und wie es sich verbinden soll.
Durchsuche im Azure-Portal den IoT Hub, den du erstellt hast. Dort solltest du unter Geräte ein Gerät mit der Registrierungs-ID "device1" sehen, oder was immer du in der Datei settings.json geändert hast.

Diese Demonstration zeigt den Beantragungsprozess und den Bereitstellungsprozess durch den IoT Hub und den Device Provisioning Service. Von hier aus geht das Gerät in die Hauptsequenz über, in der es Updates, Twinning-Daten und andere Nachrichten empfängt. Behalte das Gerät und die Ressource für weitere Demonstrationen für Twinning und Updates .

Hauptreihenfolge

Die Hauptsequenz des Geräts beginnt nach der Bereitstellung des Geräts und das Gerät beginnt, seine Hauptfunktion zu erfüllen. Die Hauptsequenz des Lebenszyklus eines Geräts hat drei Hauptfunktionen im Umgang mit der Cloud. Zunächst muss ein Gerät mit der Cloud kommunizieren. Dazu gehören alle Telemetriedaten, Befehle und Ereignisse, die von einem Gerät zur Cloud und von der Cloud zum Gerät fließen. Zweitens: Ein Gerät sendet und empfängt Twinning-Updates. Und drittens umfasst der primäre Ablauf eines Geräts Software-Patches und Updates.

Kommunikation

Die Kommunikation zwischen einem Gerät und der Cloud ist entscheidend für die Funktion eines Geräts. Unabhängig davon, welche Daten das Gerät sammelt oder welche Funktion es erfüllt, muss es mit der Cloud kommunizieren, um dies zu tun. Selbst die Aktualisierung der Gerätebereitstellung ist eine Kommunikation zwischen dem Gerät und der Cloud. Für unsere Zwecke hier ist Kommunikation die Hauptkommunikationssequenz, bei der Ereignisse und Telemetriedaten vom Gerät an die Cloud übertragen werden und die Cloud Befehle und andere Daten an das Gerät senden kann. Kapitel 5 befasst sich eingehend mit der Kommunikation.

Twinning

Im IoT bedeutet Twinning, dass die Cloud eine Kopie der Konfiguration oder des Zustands eines Geräts oder beides in der Cloud speichert. Dieser "Zwilling" ermöglicht es Anwendungen, Informationen über alle Geräte in einem IoT-Workload abzufragen, ohne jedes einzelne Gerät kontaktieren zu müssen - ein Prozess, der ewig dauern kann und selbst dann nicht zuverlässig ist. Gerätezwillinge gibt es aus mehreren Gründen, aber der Hauptgrund ist, dass Cloud-seitige Dienste und Anwendungen den Gerätestatus abfragen und melden können, ohne jedes einzelne Gerät einer IoT-Installation kontaktieren zu müssen. Diese Daten ermöglichen es dem Gerätemanagement, Entscheidungen über ein Gerät zu treffen. Die Gerätedaten können zum Beispiel Versionsinformationen über die auf dem Gerät installierte Software enthalten, wie das Betriebssystem, die App-Version, die SDK-Version oder die Hardware-Version. Wenn neue Software verfügbar ist, kann der cloud-seitige Update-Mechanismus die Twinning-Daten nutzen, um zu wissen, welche Geräte aktualisiert werden müssen, und die Updates nachverfolgen, während sie angewendet werden.

Eine weitere alltägliche Anwendung für Twinning ist die zentrale Verwaltung der Konfiguration eines Geräts für nichtfunktionale und funktionale Aspekte. Wenn ein Gerät bereitgestellt wird, kann es eine Anfangskonfiguration als Teil dieser Bereitstellung erhalten. Im Laufe der Zeit kann es jedoch sein, dass sich die Konfiguration ändern muss. Wenn ein Gerät zum Beispiel so konfiguriert ist, dass es einmal pro Stunde neue Daten in die Cloud meldet, kann eine neue Konfiguration gesendet werden, die das Gerät anweist, jede zweite Stunde zu melden, um Bandbreite zu sparen.

Azure IoT Hub bietet alle Möglichkeiten, um den Status von Geräten zu verwalten, die mit einem IoT Hub verbunden sind. Der IoT Hub speichert den Twinning-Status in einer Datenbank, die Teil des Hubs ist. Mit einer SQL-ähnlichen Abfragesprache können die Nutzer/innen Daten über Geräte auf der Grundlage ihrer Twinning-Daten abfragen. Ein digitaler Zwilling enthält zwei Sätze von Daten: gewünschte und gemeldete. Die gewünschten Daten spiegeln den Zustand der Zwillingsdaten wider, den die Cloud dem Gerät vorgibt. Sobald sich die Twinning-Daten ändern, wird ein Ereignis ausgelöst, das ein Gerät darüber informiert, dass sich die Twinning-Daten geändert haben, und die neuen Daten werden als Teil dieses Ereignisses an das Gerät weitergeleitet. Auf der anderen Seite senden die Geräte Daten über ihren Zustand aus, die dann als Teil der Twinning-Daten gemeldet werden.

Gewünschte und gemeldete Daten müssen jedoch nicht übereinstimmen. Wie die Zwillingsdaten verwendet und gemeldet werden, hängt von der jeweiligen Lösung ab. Ein Gerät kann zum Beispiel Daten über seinen Zustand melden, die als Teil des digitalen Zwillings gespeichert sind, aber dieser Zustand ist unwichtig - er ist lediglich eine Information über den Zustand des Geräts.

Unter anderen Bedingungen sollte ein Gerät einen Zustand melden, der dem gewünschten Zustand entspricht. Das gilt insbesondere für den Konfigurationsstatus. Nimm das Beispiel von vorhin, in dem es darum ging, wie oft sich ein Gerät in der Cloud melden soll. Wenn der gewünschte Status besagt, dass das Gerät alle zwei Stunden Bericht erstatten soll, der gemeldete Status aber besagt, dass das Gerät für alle eine Stunde konfiguriert ist, stimmt etwas nicht mit dem Gerät.

Als Geräteentwickler musst du Zustandsdaten und Ereignisse angemessen nutzen. Die Azure IoT Hub SDKs bieten Ereignisse, die du in deinen Code einbinden kannst, um auf Ereignisaktualisierungen aus der Cloud zu reagieren. Außerdem gibt es spezielle Aufrufe, um gemeldete Zwillingsdaten zurück in die Cloud zu senden.

Geräte-Twinning mit IoT Hub

Wenn du das noch nicht getan hast, richte den IoT Hub und den Device Provisioning Service nach den Anweisungen ein, die weiter oben in diesem Kapitel beschrieben sind, und richte dein Beispielgerät oder deinen Simulator mit dem DPS ein, damit es mit dem IoT Hub kommunizieren kann. Danach kannst du mit dem IoT Hub Twinning arbeiten:

Im IoT Hub findest du das Gerät, das du bereitgestellt hast, unter Geräte. Du kannst dies tun, indem du deinen IoT Hub ansiehst und dann links Geräte auswählst. Von hier aus solltest du das Gerät sehen, das du bereitgestellt hast.
Nachdem du dein Gerät gefunden hast, starte es in Visual Studio Code. Das Gerät fängt an, alle 5.000 Millisekunden Daten an den IoT Hub zu senden.
Wähle auf dem Gerät im Azure-Portal "Gerätezwilling".
Dort siehst du eine Reihe von JSON-Daten. Die JSON-Daten enthalten Daten über dein Gerät, z. B. seinen Namen, seinen Status und andere Informationen. Unter dem Abschnitt Eigenschaften siehst du zwei Objekte: das desired Objekt und das reported Objekt. Das Objekt desired drückt den gewünschten Zustand des Geräts aus, und reported spiegelt den tatsächlichen Zustand des Geräts wider. desired hat keine eingestellten Eigenschaften, aber pollFreq sollte mit einigen Metadaten eingestellt sein, die wie folgt aussehen:
```
"reported": {
    "pollFreq": 5000,
    "$metadata": {
          "$lastUpdated": "2022-10-08T00:43:52.339081Z",
          "pollFreq": {
               "$lastUpdated": "2022-10-08T00:43:52.339081Z"
          }
    },
    "$version": 9
}
```
Die Eigenschaft $version wird jedes Mal inkrementiert, wenn das Gerät seinen Zustand meldet. In diesem Fall ist das neun Mal der Fall.
Füge unter desired den folgenden Code ein:
```
"desired": {
    "pollFreq": 7000
}
```
Du kannst die Metadaten und Versionsinformationen entfernen.

Klicke jetzt auf die Schaltfläche "Speichern". Nach dem Speichern fügt das Portal Metadaten zu der Eigenschaft desired hinzu:

"desired": {
    "pollFreq": 7000,
    "$metadata": {
          "$lastUpdated": "2022-10-08T00:55:39.6799755Z",
          "$lastUpdatedVersion": 2,
          "pollFreq": {
               "$lastUpdated": "2022-10-08T00:55:39.6799755Z",
               "$lastUpdatedVersion": 2
          }
    },
    "$version": 2
}

Das Gerät erhält den neuen Status und beginnt mit der Meldung in dem von dir festgelegten Intervall. In diesem Beispiel beträgt das Intervall 7.000 Millisekunden, also einmal alle 7 Sekunden. Du solltest in der Konsole Daten sehen, die anzeigen, dass die Eigenschaft aktualisiert wurde :
```
new desired properties received:{"pollFreq":7000,"$version":2}
```
Zurück im Azure-Portal navigierst du zu deinem IoT Hub und wählst "Abfragen".
Gib in das Feld "Abfrage" die folgende SQL-Abfrage ein und klicke dann auf "Abfrage ausführen". Diese Abfrage wählt alle Geräte aus, bei denen die gewünschte Eigenschaft pollFreq auf 7.000 eingestellt ist, was wahrscheinlich nur bei deinem Gerät der Fall ist:
```
SELECT * FROM devices WHERE devices.properties.desired.pollFreq = 7000
```
Du kannst die Abfrage ändern, wenn du die gemeldeten Eigenschaften oder eine andere Eigenschaft in den Partnerschaftsdaten betrachten möchtest. Experimentiere mit verschiedenen Abfragen.

Die Abfrage des IoT Hubs nach den Twinning-Daten funktioniert für viele Anwendungsfälle. Wenn ein Gerät mehrere IoT Hubs nutzt, gibt es keine integrierte Möglichkeit, mehrere IoT Hubs nach den Twinning-Daten abzufragen. Du könntest jeden einzelnen Hub abfragen, aber das könnte bei vielen Geräten langsam sein. Außerdem müssen diese separaten Abfragen in der aufrufenden Anwendung gefiltert oder aggregiert werden. Und wenn die Daten auf irgendeine Weise zusammengeführt oder aggregiert werden müssen, gibt es auch dafür keine Möglichkeit. In diesen Fällen müssen die Daten in einen externen Datenspeicher exportiert werden, um die Twinning-Daten über eine zentrale Datenbank zu verwalten.

Twinning-Datenbanken können jede Art von Datenbank sein, aber eines der am weitesten verbreiteten Formate zur Erfassung von Twinning-Daten ist eine Graphdatenbank, die in Abbildung 4-4 dargestellt ist. Wenn du mit einer Graphdatenbank nicht vertraut bist, ist sie recht einfach zu verstehen, aber ihre Möglichkeiten sind tiefgreifend. Eine Graphdatenbank besteht aus einer beliebigen Anzahl von Knoten und Kanten.

Knoten sind im Wesentlichen Objekte, die Eigenschaften haben, die in der Regel durch ein Schlüssel-Wert-Paar für jede Eigenschaft ausgedrückt werden. Eine Kante ist eine Verbindung zwischen zwei Knotenpunkten. Auch die Kante selbst kann Eigenschaften haben, die ebenfalls als Schlüssel-Wert-Paare ausgedrückt werden. Das Besondere an einer Graphdatenbank ist, dass jeder Knoten über eine Kante mit einem anderen Knoten verbunden werden kann. Es gibt keine Begrenzung, mit wie vielen anderen Knoten ein einzelner Knoten in Verbindung stehen kann. Bei dieser Art von Datenbank sind beliebige Beziehungen zwischen verschiedenen Knoten möglich.

Das IoT eignet sich gut für diese Datenbank, da die Partnerschaftsdaten oft als Schlüssel-Wert-Paare ausgedrückt werden. Jedes Gerät in der Datenbank fungiert als ein Knotenpunkt. IoT-Geräte können sich mit vielen anderen Dingen in der Datenbank verbinden. Dabei kann es sich um andere Knoten handeln, die z. B. Geografien, Gebäude, Netzwerke, andere Geräte (IoT oder andere) und Kantengeräte repräsentieren. Diese Verbindungen schaffen einen durchsuchbaren Graphen, so dass Datensätze zurückgegeben werden können, um Beziehungen zwischen allen Geräten aufzuzeigen und Experimente zu ermöglichen, wenn sich die Daten eines Geräts ändern. Azure Digital Twin und Azure Cosmos DB sind zwei hervorragende Tools, um genau das mit Graphdatenbanken zu tun.

Azure Digitaler Zwilling

Azure Digital Twin (ADT) ist die schlüsselfertige Software-as-a-Service (SaaS) Lösung für diesen Zweck. Sie dient als zentrale Graphdatenbank, die Twinning-Daten für eingesetzte Geräte erfasst, ermöglicht aber auch komplexe Topologien, die widerspiegeln, wie Geräte und andere Vermögenswerte wie Gebäude, Netzwerke, Städte und Kanten über bloße Twinning-Daten hinaus miteinander verbunden sind. Diese Topologien ermöglichen es den Nutzern, Simulationen mit Twinning-Daten gegen ADT laufen zu lassen, um "Was-wäre-wenn"-Szenarien über die Geräte zu beantworten.

ADT ist zwar schlüsselfertig, bietet aber zum Zeitpunkt der Erstellung dieses Buches keine nativen Integrationen mit IoT Hub, um Änderungen an den Gerätepartnerschaften in ADT zu integrieren. Dazu muss der Nutzer etwas definieren, das auf Lebenszyklusereignisse eines Geräts reagiert, die an IoT Hub weitergeleitet werden, und die Ergebnisse in der Datenbank aufzeichnen.

Azure Cosmos DB

Wenn ADT für deine Anwendung nicht geeignet erscheint, kannst du eine Graphdatenbank mit der Graph-API von Azure Cosmos DB erstellen. Die Graphen-API basiert auf Gremlin, einer Abfragesprache für Graphenüberquerungen. Die Graph-API von Cosmos DB ermöglicht es Kanten und Knoten, Schlüssel-Wert-Paardaten auf dem Knoten oder der Kante zu speichern, für die sie stehen.

Kapitel 6 befasst sich mit den Datenbankoptionen und untersucht, wie verschiedene Datenbankparadigmen und -architekturen mit IoT-Workloads funktionieren, einschließlich Cosmos DB und Azure Digital Twin .

Neben Twinning gibt es noch eine andere Art von Updates: Software-Updates. Dieses Buch hat dies bereits angedeutet, aber jetzt ist es an der Zeit, einen genaueren Blick darauf zu werfen .

Updates

Wenn du ein Smartphone oder einen Computer besitzt, kennst du die Updates für dein Gerät . Von Zeit zu Zeit erhältst du eine Benachrichtigung, dass für dein Telefon ein Update zur Verfügung steht, das heruntergeladen und auf dem Gerät installiert werden muss. Viele von uns schieben das vor sich her, weil es scheinbar zum ungünstigsten Zeitpunkt passiert. Schließlich lässt du das Gerät widerwillig die Updates herunterladen und machst dein Gerät für einige Zeit unbrauchbar, bis es fertig ist. Manchmal schlägt das Update fehl, und dein Gerät funktioniert nicht mehr. In jedem Fall ist das keine angenehme Erfahrung.

Updates werden meist für nicht-funktionale Anforderungen benötigt, z. B. zur Behebung von Softwarefehlern oder zur Verbesserung der Sicherheit. Gelegentlich können Updates einem Gerät Funktionen hinzufügen, die nicht auf dem Gerät vorhanden sind, aber das ist nur im Rahmen der Hardware möglich, die bereits auf dem Gerät vorhanden ist.

Obwohl sie keinen Spaß machen, sind Geräteupdates eine Lebensader für Geräte. Durch Updates erhalten Geräte Software-Upgrades, neue Funktionen, Sicherheits-Patches und andere dringend benötigte Software-Wartungen, die die Leistung und Sicherheit eines Geräts verbessern sollen. Bei IoT-Updates ist das nicht anders. Geräte brauchen gelegentliche Updates aus denselben Gründen wie Laptops und Telefone. Der größte Unterschied ist jedoch, dass IoT-Geräte in der Regel keine Benutzerkomponente für die Aktualisierung haben und daher fast ausschließlich über Fernverwaltungsprogramme verwaltet werden müssen.

Es gibt verschiedene Arten von Software-Updates für Geräte:

Updates für das Betriebssystem: Betriebssystem System-Updates gelten für das Betriebssystem des Geräts, sofern es eines hat. Einige eingeschränkte Geräte haben kein Betriebssystem, aber auch diese können ein Echtzeitbetriebssystem (RTOS) haben. Andere Geräte benötigen Betriebssystem-Updates, die u. a. Hardware-Treiber, Kernel-Patches und Sicherheitsfixes für das Betriebssystem aktualisieren. Oft werden diese Aktualisierungen über den Paketmanager des Geräts verwaltet, wenn es einen solchen hat, wie z. B. Aptitude für Ubuntu oder Windows Update für Windows.
Plattform Updates: Die Plattform aktualisiert Patches, Upgrades und Fixes für alles, was mit den benötigten Dateien für deine App zu tun hat, wie z.B. ein Patch für Node.js oder .NET. Manchmal werden diese Updates über den Paketmanager verwaltet, so wie Betriebssystem-Updates verwaltet werden. Wenn nicht, musst du dir überlegen, wie sich das auf die Bereitstellung deiner Anwendung auswirkt. Plattformen, die auf Containern basieren, verfügen über umfassende Werkzeuge, um Plattformen mit einer Anwendung zu verpacken und diese effizient an ein Gerät zu liefern.
Software Updates: Software Updates beziehen sich auf jeden Code, den du schreibst und pflegst. Das kann von einfachen Skripten oder Agenten, die Daten sammeln und an die Cloud weiterleiten, bis hin zu robusteren Anwendungen mit einem kompletten Benutzererlebnis und komplexer Logik reichen. In jedem Fall wird deine App im Laufe der Zeit wahrscheinlich gepatcht werden müssen.
Schlüsselrotationen: Das Rotieren von Sicherheitsschlüsseln und Zertifikaten ist eine bewährte Methode und funktioniert ähnlich wie andere Updates. Der Aktualisierungszyklus kann regelmäßig neue Schlüssel herausgeben, die die alten ersetzen, so wie neue Software die alten ersetzt. Diese neuen Schlüssel ermöglichen die Verbindung mit der Plattform, während die alten Schlüssel in der Regel widerrufen werden, sobald die neuen Schlüssel vorhanden sind.

Ab Ende 2022 hat Azure eine Funktion in der Vorschau für , die "over the air" (OTA) Updates durchführt. Diese Updates bieten drei verschiedene Arten von Aktualisierungen für Geräte: über den Geräteaktualisierungsagenten, der als Teil des Codes auf einem eingeschränkten Gerät oder als Daemon auf nicht eingeschränkten Geräten installiert wird.

Der Azure-Geräteaktualisierungsagent folgt einem Muster, das für die Aktualisierung von Geräten verwendet wird: Ein Gerät führt ein separates Programm oder einen Daemon aus, das/der nicht Teil der primären Software ist, in der Regel einen völlig anderen Prozess, der für die Durchführung von Updates verantwortlich ist. Die Verwendung eines Update-Agenten sorgt dafür, dass Updates zuverlässiger auf ein Gerät angewendet werden können. Wenn ein Update fehlschlägt, kann der Agent das Update neu starten oder wiederherstellen.

Aktualisierungen auf das Beispielgerät in einem Docker-Container anwenden

Container sind eine von vielen Möglichkeiten, Gerätecode zu verteilen und eine Möglichkeit, eine Plattform erweiterbar zu machen, ähnlich wie es bei IoT Edge funktioniert. Während IoT Edge in Kapitel 6 behandelt wird, erfährst du hier, wie du dies mit Docker auf einem unbeschränkten Gerät tun kannst. Weiter oben in diesem Kapitel hast du gesehen, wie du Container-Code mit Ubuntu Core über Snapcraft bereitstellen kannst. Hier wirst du einfach einen Docker-Build mit dem Gerät erstellen, ihn in eine Azure-Container-Registry pushen und ihn auf einem Linux-Host bereitstellen. Darüber hinaus erfährst du, wie Docker auch als Agent dienen kann, indem du das Watchtower-Projekt verwendest, einen Docker-Container, der nach Updates sucht und diese auf deine Docker-Umgebung anwendet.

Um dies zu tun, brauchst du zunächst eine virtuelle Maschine mit Ubuntu oder einen Raspberry Pi mit Ubuntu. Du kannst dafür Ubuntu Desktop verwenden, aber Ubuntu Server ist wahrscheinlich am einfachsten einzurichten und zu benutzen. Wenn du dir keine Mühe mit einer lokalen VM machen willst, funktioniert eine Azure-VM genauso gut. Setze eine Ubuntu-VM auf Azure ein, indem du das Marketplace-Image verwendest:

Bevor du loslegst, brauchst du einige Informationen aus der Azure Container Registry, die mit der ARM-Vorlage bereitgestellt wurde, die du bei der Erstellung des Device Provisioning Service und des IoT Hub ausgeführt hast. Finde deine Container Registry in der Ressourcengruppe mit deinem IoT Hub, navigiere zu Access Keys und notiere dir die Felder "Username", "Password" und "Login Server". Du kannst die Registerkarte geöffnet lassen oder die Werte in einen Texteditor kopieren.
Sobald deine virtuelle Maschine fertig ist und du mit ihr verbunden bist, erhältst du mit dem Befehl sudo Root-Zugriff: sudo -i.
Als nächstes installierst du Docker und seine Abhängigkeiten. Du kannst das Skript im Repository verwenden, um sie zu installieren. Verwende den folgenden Befehl:
```
bash <(curl -s \ 
    https://raw.githubusercontent.com/theonemule/
        azure-iot-architecture/main/Chapter%203/install-docker.sh)
```
Du kannst die Docker-Installation mit docker ps überprüfen, um sicherzustellen, dass alles richtig installiert wurde.
Jetzt bist du bereit, einen Container zu bauen. Klone das Code-Repository von GitHub mit einem git-Befehl:
```
git clone https://github.com/theonemule/azure-iot-architecture.git
```
Dadurch wird der Code in den Stammordner geklont.
Wechsle in das Verzeichnis von Kapitel 2:
```
cd azure-iot-architecture/Chapter\ 2
```
Jetzt kannst du das Image erstellen. Führe den folgenden Docker-Befehl aus, aber ersetze <loginserver> durch den Wert von "Login server" aus Schritt 1:
```
docker build -t <loginserver>/device-sample:latest
```
Bevor du das Image pushen kannst, musst du dich bei deiner Azure Container Registry mit Docker anmelden. Ersetze auch hier <loginserver> durch den Wert von "Login server" aus Schritt 1:
```
docker login <loginserver>
```
Jetzt kannst du das Bild verschieben. Ersetze auch hier <loginserver> durch den Wert von "Login server" aus Schritt 1. Es ist nicht notwendig, den Container zu pushen, um ihn lokal auszuführen, aber Watchtower prüft die Registry auf Updates, damit er diese Updates anwenden kann, sobald sie veröffentlicht werden:
```
docker push <loginserver>/device-sample:latest
```
Starte den Container:
```
docker run --name devicesample -it \
         -e POLLFREQ=7000 <loginserver>/device-sample
```
Der Container verwendet Umgebungsvariablen, um das Gerät zu konfigurieren. Du kannst mit diesen Werten spielen, indem du den Parameter -e verwendest, gefolgt von der Variable und dem Wert (z. B. -e POLLFREQ=7000):

START

Der Verbindungstyp. Entweder "dps", "connection_string" oder "offline". Bei "dps" musst du PROVISIONINGHOST, IDSCOPE, SYMMETRICKEY und REGISTRATIONID mit den Werten aus dem Device Provisioning Service festlegen, wie du es im Abschnitt "Beantragung und Bereitstellung" getan hast. "connection_string" erfordert, dass eine Geräteverbindungszeichenfolge vom IoT Hub bereitgestellt und in CONNSTR eingetragen wird. Der Standardwert ist "offline".

TELEMETRIE

Entweder auf "Gerät" für echte Telemetriedaten oder auf "Simulator" für simulierte Daten.

KAMERA

Entweder auf "device" für die Kamera des Geräts oder auf "simulator" für eine simulierte Kamera. Das funktioniert nur, wenn die Kamera an den Host angeschlossen und zugeordnet ist und dann dem Container zugeordnet wird. Andernfalls verwende den Simulator.

POLLFREQ

Dies ist ein Wert in Millisekunden, der angibt, wie oft die Geräte nach Daten fragen sollen. Der Standardwert ist 5000.

CONNSTR

Verwende dies für den Verbindungsstring eines Geräts aus dem IoT Hub für das Gerät, wenn START auf "connection_string" gesetzt ist.

PROVISIONINGHOST

Hole den Provisioning-Hostnamen vom Device Provisioning Service, wenn START auf "dps" gesetzt ist.

IDSCOPE

Hole den ID-Bereich vom Device Provisioning Service, wenn START auf "dps" gesetzt ist.

SYMMETRICKEY

Hole den symmetrischen Schlüssel vom Device Provisioning Service, wenn START auf "dps" gesetzt ist.

REGISTRATIONID

Erstelle eine ID für dein Gerät, um es mit dem Device Provisioning Service zu identifizieren .
Sobald der Container läuft, kannst du Watchtower starten. Watchtower benötigt eine Reihe von Parametern, die in der Dokumentation erklärt werden. Es genügt zu sagen, dass der wichtigste Parameter WATCHTOWER_POLL_INTERVAL ist. Mit diesem Parameter wird festgelegt, wie oft Watchtower die Registry nach Änderungen abfragt. Im folgenden Beispiel ist er auf alle 60 Sekunden eingestellt. In einer Produktionsumgebung solltest du vielleicht weniger oft prüfen, vielleicht einmal am Tag oder alle paar Stunden:
```
docker run --detach --name watchtower \
   --volume /var/run/docker.sock:/var/run/docker.sock \
   -e WATCHTOWER_DEBUG=true \
   -e WATCHTOWER_NOTIFICATIONS_LEVEL=debug \
   -e WATCHTOWER_CLEANUP=true \
   -e WATCHTOWER_POLL_INTERVAL=60 \
   -e WATCHTOWER_NO_PULL=false \
   -e WATCHTOWER_MONITOR_ONLY=false \
   containrrr/watchtower
```
Notiere die aktuellen Laufzeiten für den Container devicesample und die Watchtower-Container mit docker ps -a. Der Befehl listet die laufenden Container auf. Der Container devicesample sollte zu diesem Zeitpunkt schon länger laufen als der Watchtower-Container.
Nimm nun eine triviale Änderung am Code des Containers vor. Du kannst settings.json bearbeiten und am Anfang der Datei eine Zeile mit nano hinzufügen:
```
nano settings.json
```
Ändere die Datei und drücke dann Strg + O, um die Datei zu speichern. Drücke Strg + X, um nano zu verlassen und zur CLI zurückzukehren.

Baue den Container wieder auf:

docker build -t <loginserver>/device-sample:latest

Schiebe den Behälter zurück:

docker push <loginserver>/device-sample:latest

Warte ein paar Minuten lang. Nach einem Moment rufst du docker ps -a erneut auf. Du solltest sehen, dass dein devicesample Container neu gestartet wurde. Das liegt daran, dass Watchtower, dein Update-Agent, eine Änderung in deiner Container-Registrierung festgestellt hat. Von dort hat er das neueste Image geholt und dein Gerät mit dem neuesten Image neu gestartet.

Docker-Updates sind ziemlich einfach . Die einzige Diskrepanz besteht darin, dass Docker nicht automatisch nach neuen Containern sucht, während sie laufen. Watchtower übernimmt diese wichtige Aufgabe und fungiert als Update-Agent für Container auf deinem Docker-Host.

Geräteaktualisierungen sind ein Teil der Hauptsequenz des Geräts, zusammen mit Twinning-Updates und Benachrichtigungen. Wenn die Hauptsequenz ausläuft, wird ein Gerät irgendwann fehlschlagen oder veraltet sein. In jedem Fall ist es gut, auch für Geräte eine Ausstiegsstrategie zu haben, mit der ein Gerät deprovisioniert werden kann .

Deprovisionierung

Kein Gerät wird ewig halten. Mit der Zeit geht ein Gerät kaputt oder die Hardware ist so veraltet, dass es nicht mehr die neueste Software ausführen kann. Es gibt keine Regel dafür, wie lange ein Gerät im Einsatz sein sollte. Manche Geräte haben eine relativ kurze Lebensdauer, die in Wochen oder sogar Tagen gemessen wird, andere können jahrelang genutzt werden. Unabhängig davon, wie lange ein Gerät in Betrieb ist, muss es ausgemustert werden, um sicherzustellen, dass das Gerät gelöscht und außer Betrieb genommen wird.

Das Deprovisionieren eines Geräts erfordert einige Schritte. Wenn auf dem Gerät Schlüssel gespeichert sind, sollten diese zunächst widerrufen werden. Durch den Entzug der Schlüssel wird sichergestellt, dass das Gerät keine Verbindung zu einer Cloud-Plattform herstellen kann, um Nachrichten zu senden und zu empfangen oder um sich als neues Gerät zu registrieren. Zweitens: Wenn das Gerät Daten speichert, sollten die Daten des Geräts gelöscht werden. Das Löschen eines Geräts stellt sicher, dass die auf dem Gerät verbliebenen Daten nicht für schändliche Zwecke extrahiert werden können oder versehentlich durchsickern.

Azure kann Schlüssel problemlos widerrufen, aber Azure bietet keine speziellen Dienste, mit denen ein Gerät aus der Ferne gelöscht werden kann. Diese Funktion sollte in das Gerät integriert sein und von der Cloud auf das Gerät übertragen werden können.

Und schließlich muss das Gerät im Rahmen der Bereitstellung ordnungsgemäß entsorgt werden . Zu einem verantwortungsvollen Herstellungsplan gehört, dass ein Gerät entweder recycelt oder sicher entsorgt wird. Viele Geräte enthalten giftige Chemikalien und Materialien, die nicht auf der Mülldeponie landen sollten. Die beste Vorgehensweise ist das Recycling, bei dem in der Regel wiederverwendbare Komponenten wie Batterien aus einem Gerät entnommen, andere Komponenten mit schädlichen Materialien entfernt und der Rest entsorgt wird.

Zusammenfassung

Das Management des Gerätelebenszyklus ist ein breites Thema, das alle möglichen Überlegungen berührt, die du bei der Herstellung eines Geräts berücksichtigen musst - so sehr, dass es vielleicht einfach erscheint, ein Gerät zu bekommen, das seine Hauptfunktion erfüllt.

Wie du gesehen hast, beginnt die Reise von der Entwicklung bis zur Deprovisionierung mit der Forschung und dem Design und geht über die Herstellung, bis schließlich ein Gerät beansprucht und ausgeliefert wird. Von dort aus wird ein Gerät bereitgestellt und tritt in seine primäre Sequenz ein, in der es mit der Cloud kommuniziert, Updates empfängt und seinen Status über Twinning sendet und empfängt. An einem bestimmten Punkt (wie in diesem Kapitel!) endet der Prozess schließlich. Hier sind ein paar Punkte aus diesem Kapitel, die du dir merken solltest:

Das Management des Gerätelebenszyklus ist ein entscheidender Teil der Entwicklung und Herstellung eines Geräts. Du fängst an, darüber nachzudenken, lange bevor du überhaupt ein Gerät baust.
Forschung und Entwicklung ist eine interaktive Phase, in der das Gerät von der Idee bis zu einem minimal brauchbaren Produkt für die Herstellung entwickelt wird.
Sobald ein Gerät ausgeliefert wird, muss es sich bei der Cloud registrieren. Dieser Prozess ist die Gerätebereitstellung. Azure bietet den Device Provisioning Service, um dein Gerät mit einem IoT Hub zu verknüpfen.
Während deine Geräte in Betrieb sind, müssen sie Software- und Konfigurationsaktualisierungen erhalten. Konfigurationsaktualisierungen werden über Twinning verwaltet, und die Softwareaktualisierungen werden über Daemons auf dem Gerät verwaltet, die Software herunterladen und installieren.

Dieses Kapitel vermittelt dir die notwendigen Kenntnisse, um wichtige Entscheidungen zu treffen und Microsofts umfassende Unterstützung bei der Geräteerstellung zu verstehen. kratzt aber nur an der Oberfläche. Mach dich darauf gefasst, dass das nächste Kapitel tiefer in die komplizierte Funktionsweise der Hauptsequenz eines Geräts eindringt und das verschlungene Netz der Nachrichtendetails entschlüsselt. Diese Diskussion ist ein Dreh- und Angelpunkt, der in die Abläufe des Geräts eingewoben ist und einen großen Einfluss darauf hat, wie die cloudbasierten Elemente die Geräteausgaben verwalten. Deine Reise in das Herz der Geräteorchestrierung geht weiter. Du befindest dich immer noch im Gerätemanagement der IoT-Landschaft, aber verpasse nicht die Chance, die entscheidenden Details zu enthüllen, die vor dir liegen.

¹ Jeff Prosise, Applied Machine Learning and AI for Engineers (O'Reilly, 2022).

Get Architektur von IoT-Lösungen auf Azure now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.

Start your free trial

Kapitel 4. Der Lebenszyklus des Geräts

Device Lifecycle Management

Abbildung 4-1. Gerätelebenszyklusmanagement in der IoT-Landschaft

Abbildung 4-2. Verwaltung des Gerätelebenszyklus

Forschung und Design

Drei Phasen von F&E

Abbildung 4-3. Vom Entwurf zur Herstellung

Proof of Concept

Prototyp

Minimum Viable Product

Hardware

Berechne

Sicherheitsmerkmale

KI und ML

Konnektivität

Ethernet

WiFi

Cellular

Bluetooth

Andere

Software

Betriebssysteme

Sicherheitsmerkmale

Kompatibilität

Einfachheit

Konsistenz

SDKs

App-Isolierung

Bauen, testen und freigeben

Herstellung

Versand

Beantragung und Bereitstellung

Geräte mit einem IoT Hub über den Device Provisioning Service bereitstellen

Hauptreihenfolge

Kommunikation

Twinning

Geräte-Twinning mit IoT Hub

Abbildung 4-4. Graphdatenbank mit Knoten und Kanten

Azure Digitaler Zwilling

Azure Cosmos DB

Updates

Aktualisierungen auf das Beispielgerät in einem Docker-Container anwenden

Deprovisionierung

Zusammenfassung

Don’t leave empty-handed

It’s yours, free.

Check it out now on O’Reilly