IoT Hub-Nachrichtenweiterleitung vs. Event Grid — Warum Telemetrie und Ereignisse nicht dasselbe Problem sind

Eine Temperaturmessung, eine Schwingungsprobe, ein Maschinenzyklus und eine Geräte-Trennung können alle als Ereignisse beschrieben werden, stellen aber nicht dasselbe architektonische Problem dar. In industriellen IoT- und Fertigungsumgebungen kann die Verwechslung von kontinuierlicher Telemetrie mit diskreten Ereignissen zu verrauschten Workflows, unvollständigen Produktionshistorien, unnötiger Verarbeitung und Systemen führen, die ohne ausreichenden Kontext reagieren.

In dieser Episode zerlegen wir den architektonischen Unterschied zwischen Azure IoT Hub Message Routing und Azure Event Grid anhand eines realistischen Fertigungsszenarios. Eine Pressenlinie sendet über ein industrielles Gateway kontinuierlich Temperatur-, Schwingungs-, Zyklenzähler-, Energieverbrauchs- und Maschinenzustandsinformationen. Diese Messwerte bilden eine betriebliche Historie, die Ingenieure, Datenteams, Wartungsteams und Produktionssysteme später analysieren können. Eine Geräte-Trennung ist dagegen anders, weil sie eine Änderung darstellt, auf die ein anderes System oder eine Person reagieren muss.

TELEMETRIE IST EIN PROTOKOLL, KEIN ALARM
Telemetrie stellt wiederholte Messungen über die Zeit dar. Ein einzelner Temperatur- oder Schwingungswert sagt meist für sich genommen sehr wenig aus. Die eigentliche Information liegt in der Abfolge: wie schnell sich Werte veränderten, was die Maschine zu diesem Zeitpunkt tat, was vor einem Stillstand geschah, ob Messwerte während einer Netzwerkunterbrechung fehlten und ob dasselbe Verhalten bereits in früheren Produktionsläufen auftrat.


Typische industrielle Telemetrie umfasst:
• Temperatur, Schwingung, Druck, Energieverbrauch und Stromaufnahme
• Maschinenzustände wie laufend, leerlaufend, gestoppt oder gestört
• Zyklenzähler, Produktionszähler und Prozessmessungen
• Quellzeitstempel, Geräte-IDs, Sequenznummern und Korrelationsinformationen

Diese Datensätze können später Zustandsüberwachung, Qualitätsuntersuchungen, Energieanalysen, OEE-Berechnungen, Microsoft-Fabric-Analysen, Power-BI-Berichte und die Optimierung der Produktion unterstützen. Deshalb benötigt Telemetrie Aufbewahrung, Wiedergabe, Duplikatbehandlung, unabhängige Konsumenten und eine verlässliche Möglichkeit, die Produktionszeitleiste zu rekonstruieren.

IOT HUB MESSAGE ROUTING ALS TELEMETRIE-DATENEBENE
Azure IoT Hub stellt die kontrollierte Grenze zwischen Gerät und Cloud dar. Geräte und Gateways authentifizieren sich mit ihren eigenen Identitäten, senden Nachrichten von Gerät zu Cloud, verwalten den Gerätezustand und können an kontrollierter Kommunikation von Cloud zu Gerät teilnehmen.

Sobald eine Telemetrienachricht IoT Hub erreicht, bestimmt Message Routing, wohin diese Daten weitergeleitet werden sollen. Routing kann Nachrichteneigenschaften, Systemeigenschaften, Teile des Nachrichtenkörpers und Informationen aus dem Device Twin auswerten. So lassen sich Produktionstelemetrie, Energiemessungen, Diagnosedaten oder andere Nachrichtenklassen trennen, bevor sie nachgelagerte Konsumenten erreichen.
Eine übliche Architektur könnte so aussehen: Industrielles Gateway → Azure IoT Hub → Message Routing → Event Hubs oder Storage → Verarbeitung → Microsoft Fabric.

Ein Konsument kann nahezu in Echtzeit analysieren, während ein anderer ein Rohdatenarchiv führt. Ein dritter Konsument kann kuratierte Betriebsdaten für Microsoft Fabric aufbereiten. Jeder Konsument kann unabhängig arbeiten, ohne dass jede Telemetrieablesung einen Workflow auslöst.

WARUM DIE REIHENFOLGE ENTSCHEIDEND IST
Industrielle Telemetrie reagiert besonders empfindlich auf die Reihenfolge. Stellen Sie sich vor, eine Maschine meldet, dass sie in den Laufzustand gewechselt hat, überträgt danach mehrere Zyklenzähler, anschließend eine Prozessabweichung und schließlich den Stillstand. Werden diese Datensätze falsch rekonstruiert, könnte ein nachgelagertes System schließen, dass die Maschine im Stillstand Teile produziert hat oder dass eine Prozessabweichung erst nach Produktionsende auftrat.

Dasselbe Problem betrifft Stillstandsberechnungen, OEE, Produktionszählungen und Zustandsüberwachung. Sie müssen daher unterscheiden, wann die Quelle etwas beobachtet hat, wann IoT Hub die Nachricht empfangen hat und wann ein nachgelagertes System sie verarbeitet hat.

Eine robuste Telemetriearchitektur sollte daher Folgendes berücksichtigen:
• Quellzeitstempel und Zeitstempel des Cloud-Empfangs
• Stabile Partitionierung, passend zu Anlage oder Workload
• Nachrichten-IDs oder Sequenznummern zur Erkennung von Duplikaten
• Idempotente Konsumenten, die Zustellung mindestens einmal (at-least-once) verarbeiten können

Netzwerkunterbrechungen machen dies besonders wichtig. Ein Gateway kann Telemetrie zwischenspeichern und sie senden, sobald die Verbindung zurückkehrt, sodass die Ankunftszeit in Azure deutlich später liegen kann als der tatsächliche Maschinenzeitstempel.

EVENT GRID LÖST EIN ANDERES PROBLEM
Azure Event Grid ist um Publish-and-Subscribe-Benachrichtigungen herum konzipiert. Anstatt den Zustand einer Maschine aus Tausenden von Messwerten kontinuierlich zu rekonstruieren, teilt Event Grid interessierten Systemen mit, dass sich etwas geändert hat, und gibt Abonnenten die Gelegenheit zu reagieren.
Beispiele in einer IoT-Umgebung sind die Erstellung oder Löschung eines Geräts, eine Verbindung, eine Trennung oder sorgfältig ausgewählte, aus der Telemetrie abgeleitete Zustände. Ein Ereignis „Gerät erstellt“ könnte einen Prozess zur Aufnahme eines Assets auslösen. Ein Ereignis „Gerät getrennt“ könnte eine technische Untersuchung starten. Ein erkannter technischer Zustand könnte einen Wartungsworkflow auslösen.

Typische Abonnenten sind:
• Azure Functions
• Logic Apps
• Webhooks
• Sicherheits-Workflows
• Asset-Management-Systeme
• Betriebsanwendungen

Der grundlegende architektonische Unterschied ist einfach: Telemetrie fragt, was eine Anlage getan hat, während ein Ereignis fragt, was sich geändert hat und ob etwas darauf reagieren sollte.

EREIGNISSE SOLLTEN UNTERSUCHUNGEN AUSLÖSEN, NICHT DIE REALITÄT DEFINIEREN
Event Grid sollte grundsätzlich als Benachrichtigungsmechanismus betrachtet werden, nicht als endgültiger, maßgeblicher Zustand der physischen Welt. Ereignisse können mehrfach zugestellt werden, und ein Abonnent sollte Ereignisse nicht blind als endgültigen aktuellen Zustand interpretieren, ohne dies zu prüfen.
Ein Ereignis „Gerät getrennt“ sollte daher in der Regel eine Zustandsprüfung auslösen. Eine Azure Function könnte den aktuellen Gerätezustand verifizieren, aktuelle Telemetrie prüfen, relevante Registry-Informationen abrufen und dann entscheiden, ob die Untersuchung offen bleibt.

Handler sollten um Folgendes herum gestaltet sein:
• Idempotente Verarbeitung
• Verifizierung des aktuellen Zustands
• Ereignisidentität und Zeitstempel
• Klar definierte Zuständigkeit für die daraus folgende Aktion

Das ist wichtig, weil doppelte Ereignisse keine doppelten Tickets, doppelten Alarme oder widersprüchlichen Betriebsdaten erzeugen sollten.

EINE GERÄTE-TRENNUNG BEDEUTET NICHT, DASS DIE MASCHINE STEHT
Eine der wichtigsten Unterscheidungen im industriellen IoT ist der Unterschied zwischen Cloud-Konnektivität, Gesundheit der Datenerfassung und Produktionszustand. Wenn ein industrielles Gateway die Verbindung zu IoT Hub verliert, hat die Cloud die Sicht auf dieses Gateway verloren. Das bedeutet nicht automatisch, dass die physische Maschine angehalten hat.

Die SPS kann die Anlage lokal weiter steuern, während das Gateway vorübergehend die Verbindung verliert. Die Produktion kann normal weiterlaufen, und das Gateway kann Telemetrie sogar zwischenspeichern und später hochladen. Auch der umgekehrte Fall ist möglich: Ein Gateway kann mit Azure verbunden bleiben, während seine Verbindung zur SPS oder zur lokalen Anlage ausgefallen ist.

Eine sinnvolle Architektur trennt daher den Cloud-Verbindungszustand, die Gesundheit des Gateways, den Produktionszustand der Maschine und den Arbeitsauftragszustand im MES. Nur durch die Kombination dieser Quellen kann das Unternehmen feststellen, ob ein technisches Verbindungsproblem tatsächlich die Produktion beeinflusst hat.

FILTERUNG IN IOT HUB VS. FILTERUNG IN EVENT GRID
Beide Technologien unterstützen Filterung, doch der Zweck ist unterschiedlich. Die Filterung im IoT Hub Message Routing beantwortet die Frage, welche betrieblichen Nachrichten in einen bestimmten Datenpfad gelangen sollen. Die Event-Grid-Abonnementfilterung beantwortet die Frage, welche Benachrichtigungen ein bestimmter Abonnent erhalten soll.

Beispielsweise kann Produktionstelemetrie in einen Event-Hubs-Stream gehen, während Energiedaten in ein anderes Ziel fließen. Gleichzeitig könnte ein Support-Workflow nur Trennungsereignisse eines bestimmten