IoT-Architekturdiagramm: Geräte, MQTT, Stream Processing und Speicher

Die meisten IoT-Diagramme haben drei Boxen: Geräte, ein Cloud-Symbol und ein Dashboard. Die wichtigen Fragen liegen dazwischen. Woher weiß der Broker, welches Gerät spricht? Was passiert, wenn ein Standort eine Stunde lang keine Verbindung hat? Welche Nachrichten können verloren gehen oder doppelt ankommen? Wie erreicht ein Befehl einen Sensor unter Tausenden?

Ein IoT-Architekturdiagramm sollte diese Fragen auf der Seite beantworten. Dieser Beitrag baut eines für einen konkreten Fall, die Temperaturüberwachung in Kühlhäusern, und geht die Entscheidungen hinter jedem Hop durch: MQTT und seine Quality-of-Service-Stufen, Topic-Design, Geräteidentität, Standorte ohne Verbindung und Event Time und wo die Daten landen.

Die Schichten eines IoT-Systems

Nicht jedes System braucht jede Schicht. Geräte mit Mobilfunk- oder WLAN-Modul veröffentlichen oft ohne Gateway direkt an den Broker. Zeichne die Schichten, die du tatsächlich betreibst.

Warum MQTT

MQTT ist ein Publish/Subscribe-Protokoll, bei dem sich Clients mit einem Broker verbinden und Nachrichten über Topics austauschen. Die MQTT-5.0-Spezifikation, seit März 2019 ein OASIS-Standard, beschreibt es als leichtgewichtig, offen und einfach zu implementieren. Port 1883 ist bei der IANA für MQTT ohne TLS registriert, Port 8883 für MQTT über TLS. Alles, was den Standort verlässt, sollte 8883 nutzen.

Jede Nachricht wird mit einer Quality-of-Service-Stufe (QoS) veröffentlicht:

QoS gilt pro Hop, nicht Ende zu Ende: Ein Subscriber erhält eine Nachricht mit dem niedrigeren Wert aus der QoS, mit der sie veröffentlicht wurde, und der QoS, die seinem Abonnement gewährt wurde. Bei QoS 1 kann der Broker Duplikate zustellen, also muss jeder Konsument denselben Messwert zweimal verkraften. Eine vom Gerät erzeugte Nachrichten-ID oder ein Zeitstempel pro Sensor macht das einfach.

MQTT 5 bringt einige Funktionen mit, die ins Diagramm gehören:

• Retained Messages. Der Broker behält die letzte Nachricht auf einem Topic und schickt sie an neue Subscriber, was zum aktuellen Status eines Geräts passt.
• Will Messages. Der Broker veröffentlicht die Will Message eines Clients, wenn dessen Verbindung ohne sauberes Trennen abbricht, sodass ein Gateway melden kann, dass es offline gegangen ist.
• Message Expiry. Läuft eine Nachricht ab, bevor die Zustellung beginnt, löscht der Broker sie. Nutze das für Befehle, die nur eine Zeit lang gültig sind.
• Shared Subscriptions. Mehrere Konsumenten teilen sich ein Abonnement, und jede Nachricht geht nur an einen von ihnen, sodass die Bridge zur Streaming-Plattform horizontal skalieren kann.

Topic-Design

Topics sind hierarchisch, und Subscriber nutzen + für eine Ebene und # für den Rest. Ein Aufbau wie site/{site}/device/{id}/telemetry erlaubt es, einen Standort, ein Gerät oder alles zu abonnieren, und lässt den Broker jedes Gerät auf seine eigenen Topics beschränken. Topics, die mit $ beginnen, sind für den Broker reserviert, und Filter, die mit einem Wildcard beginnen, treffen sie nicht.

Nutze Topics für Routing und Berechtigungen. Schema-Version und Messzeitpunkt gehören in den Payload, wo sie sich ändern können, ohne jedes Abonnement zu brechen.

Geräteidentität

Gib jedem Gerät oder Gateway ein eigenes X.509-Zertifikat, signiert von deiner Geräte-CA, und lass den Broker Client-Zertifikate verlangen. Der Subject-Eintrag des Zertifikats wird zur Client-ID, und der Broker vergibt Topics auf dieser Basis. Ein gestohlenes Gerät lässt sich dann einzeln sperren, und in der Firmware von Tausenden Geräten steckt kein gemeinsames Passwort. Lege fest, wie Zertifikate ausgestellt werden, bei der Herstellung oder beim ersten Start, und wie sie vor dem Ablauf rotiert werden, und zeichne die CA ins Diagramm.

Standorte ohne Verbindung und Event Time

Standorte verlieren ihre Verbindung. Ein Gateway, das Messwerte lokal puffert, schickt eine Stunde Daten auf einmal, sobald die Leitung zurück ist, sodass Daten spät und in falscher Reihenfolge ankommen. Versieh jeden Messwert mit dem Zeitpunkt der Messung, halte die Uhren der Gateways synchron und verarbeite in Event Time mit einer Toleranz für Verspätung. Ein Alarm wie „Gefrierschrank seit zehn Minuten über -18 °C“ muss danach berechnet werden, wann die Messwerte genommen wurden, nicht wann sie ankamen. Dasselbe Denken gilt für jede Event-driven Architecture.

Das Beispiel: Kühlhausüberwachung

Jedes Lager hat etwa vierzig Gefriersensoren, die alle 30 Sekunden melden, und ein Dutzend Türsensoren, die bei Änderungen melden. Ein Standort-Gateway sammelt ihre Messwerte über Funk vor Ort, puffert sie offline und veröffentlicht sie mit QoS 1 über gegenseitiges TLS an den MQTT-Broker. Der Broker prüft jedes Client-Zertifikat gegen die Geräte-CA. Eine Bridge mit einer Shared Subscription kopiert die Telemetrie nach Kafka. Ein Konsument archiviert die Rohnachrichten im Object Storage; ein Stream Processor berechnet Ein-Minuten-Aggregate in Event Time, schreibt sie für Dashboards in einen Zeitreihenspeicher und löst Temperaturalarme aus. Die Geräteverwaltung schickt Befehle und Konfiguration über den Broker zurück.

So liest du es:

• Links, der Standort. Sensoren sprechen nur mit dem Standort-Gateway; das Gateway ist der einzige Client, den der Broker von diesem Standort sieht.
• In der Mitte, der Broker. Telemetrie geht mit QoS 1 nach oben. Die gestrichelten Kanten sind Befehle zum Standort hinunter und die Zertifikatsprüfung gegen die Geräte-CA.
• Rechts, der Datenpfad. Kafka speist das Rohdatenarchiv und den Stream Processor, der Aggregate in den Zeitreihenspeicher schreibt und Alarme auslöst.
• Der Markdown-Block enthält den Topic-Aufbau, die QoS pro Topic und die Identitätsregel.

Was du beschriften solltest

• Protokoll, Port und QoS auf der Verbindung vom Standort zum Broker.
• Nachrichtenraten pro Geräteklasse. Vierzig Sensoren alle 30 Sekunden sind 80 Nachrichten pro Minute und Standort; multipliziere mit der Zahl der Standorte, bevor du den Broker dimensionierst.
• Identität: welches Zertifikat, welche CA und wie Zertifikate rotiert und gesperrt werden.
• Pufferung: wie lange das Gateway Daten offline halten kann.
• Aufbewahrung für jeden Speicher, von Stunden im Stream bis zu Jahren im Archiv.
• Den Befehlspfad, einschließlich Message Expiry und dessen, was ein Gerät mit einem unbekannten Befehl tut.

Häufige Fehler

• Gemeinsame Zugangsdaten für alle Geräte. Dann öffnet ein einziges geleaktes Passwort jedes Gerät. Nutze ein Zertifikat pro Gerät.
• Port 1883 im Internet. Ohne TLS laufen Messwerte und Zugangsdaten im Klartext.
• Genau-einmal voraussetzen. QoS 1 kann Duplikate zustellen; mach Konsumenten idempotent, statt überall zu QoS 2 zu greifen.
• Verarbeitung nach Ankunftszeit. Gepufferte Daten lösen dann falsche Alarme aus oder verdecken echte.
• Geräte, die direkt in die Datenbank schreiben. Du verlierst die Authentifizierung, Pufferung und Verteilung des Brokers.
• Kein Update-Pfad. Firmware-Updates und Konfigurationsänderungen sind Teil der Architektur; zeichne sie ein.
• Wildcard-Berechtigungen für Geräte. Ein Gerät, das # abonnieren darf, kann die Daten aller anderen Geräte lesen.

Das Netzwerktopologie-Diagramm behandelt das eigene Netz des Standorts, das ein IoT-Diagramm meist weglässt.

In Archboard nachbauen

1. Melde dich mit Google oder GitHub an und leg ein Diagramm an.
2. Füge aus dem Basis-Pack einen Rahmen für den Standort hinzu. Füge darin aus dem Netzwerk-Pack für jede Sensorgruppe ein Gerät mit der Art IoT / Smart Home hinzu und ein weiteres Gerät mit der Art Modem / Gateway für das Standort-Gateway.
3. Füge aus dem C4-Modell-Pack Container-Nodes für den MQTT-Broker, die Geräteverwaltung und den Stream Processor hinzu und eine Datenbank für den Zeitreihenspeicher.
4. Füge aus dem Sicherheits-Pack ein Zertifikat für die Geräte-CA hinzu.
5. Füge aus dem Daten-Pack Kafka und eine Objektablage für das Rohdatenarchiv hinzu. Füge aus dem DevOps-Pack Metriken für die Dashboards und einen Alarm-Node hinzu.
6. Verbinde sie von links nach rechts, beschrifte den Uplink mit seiner QoS, zeichne Befehle und Zertifikatsprüfung gestrichelt und füge einen Markdown-Block aus dem Basis-Pack mit dem Topic-Design hinzu.

Das Beispiel nutzt 14 Diagramm-Nodes und bleibt damit im Free-Plan. Die Seite zum Netzwerkdiagramm zeigt den Rest des Netzwerk-Packs.

FAQ

Sollten IoT-Geräte MQTT oder HTTP nutzen? MQTT hält eine Verbindung offen, sodass die Cloud Befehle pushen kann, und der Overhead pro Nachricht ist gering. HTTP ist einfacher für Geräte, die selten melden und nie Befehle empfangen.

Welche QoS-Stufe sollte ich nutzen? QoS 1 für den Großteil von Telemetrie und Befehlen, mit Konsumenten, die Duplikate vertragen. QoS 0 für hochfrequente Messwerte, deren Verlust du verschmerzen kannst. QoS 2 nur dort, wo Duplikate nachgelagert nicht behandelt werden können.

Brauche ich Kafka, wenn ich schon einen MQTT-Broker habe? Nicht immer. Der Broker routet Nachrichten an verbundene Subscriber; er ist kein langfristiges Log, das du wiederabspielen kannst. Nimm eine Streaming-Plattform dazu, wenn mehrere Konsumenten dieselben Daten brauchen oder du Historie neu verarbeiten musst.

Wie bekommen Geräte ihre Zertifikate? Bei der Herstellung oder beim ersten Start über einen Provisioning-Dienst, jedes mit eigenem Schlüsselpaar. Bewahre den privaten Schlüssel in sicherer Hardware auf, wenn das Gerät welche hat.

Sollten Regeln am Edge oder in der Cloud laufen? Regeln, die auch während eines Ausfalls funktionieren müssen, etwa ein lokaler Alarm für eine offen gelassene Tür, laufen auf dem Gateway. Regeln, die Daten vieler Standorte brauchen, laufen in der Cloud.

Kostenlos starten — ein Seat, keine Kreditkarte.