IoT Hub Message Routing vs. Event Grid — Warum Telemetrie und Ereignisse nicht dasselbe Problem sind

Ein Gerät sendet alle paar Sekunden Temperaturwerte, Vibrationsdaten, Zykluszähler, Stromverbrauch und Betriebszustände. Dann bricht das Gateway plötzlich die Verbindung ab. Sind all diese Nachrichten einfach „Ereignisse“? Technisch könnte man sie so bezeichnen. Architektonisch kann das jedoch ernsthafte Probleme verursachen. Azure IoT Hub Message Routing und Azure Event Grid lösen unterschiedliche Probleme. Der eine Pfad ist auf das Erhalten und Verteilen von Betriebsdaten ausgelegt. Der andere ist darauf ausgelegt, Systeme darüber zu informieren, dass sich etwas geändert hat und möglicherweise eine Reaktion erforderlich ist. Sie als austauschbar zu behandeln, kann dazu führen, dass teure Workflows routinemäßige Sensordaten verarbeiten – oder dass wichtige Signale in einer Telemetrie-Pipeline untergehen, die niemand aktiv überwacht. In ddieser Episode von M365 FM begleiten wir eine Fertigungsmaschine durch eine reale Azure-IoT-Architektur und erklären, wo IoT Hub, Event Grid, Event Hubs, Microsoft Fabric, Power BI, MES, ERP, Functions und Logic Apps tatsächlich hingehören.

WAS SIE LERNEN WERDEN
In dieser Episode untersuchen wir:

• Warum Maschinentelemetrie und diskrete Geschäfts- oder Lebenszyklusereignisse unterschiedliche Architekturmuster erfordern
• Wie Azure IoT Hub Message Routing als Teil einer Telemetrie-Datenebene funktioniert
• Wo Azure Event Grid in ereignisgesteuerten und reaktiven Architekturen eingeordnet wird
• Warum die Reihenfolge von Nachrichten bei Fertigungstelemetrie wichtig ist
• Warum Event Grid nicht zu Ihrem primären hochvolumigen Telemetrie-Bus werden sollte
• Warum IoT-Hub-Routing nicht in jeden Benachrichtigungsworkflow gezwungen werden sollte
• Wie IoT Hub und Event Grid in derselben Architektur zusammenarbeiten können
• Wie Event Hubs unabhängige Stream-Processing-Consumer unterstützen kann
• Warum Rohtelemetrie oft für Nachvollziehbarkeit und spätere Untersuchungen aufbewahrt werden sollte
• Wie Microsoft Fabric und Power BI aufbereitete Betriebsdaten nutzen können
• Warum MES, ERP und Asset-Modelle einen Kontext liefern, den Gerätedaten allein nicht bieten können
• Wie Verbindungsabbruch-Ereignisse von Geräten interpretiert werden sollten, ohne automatisch anzunehmen, dass die Produktion stillsteht
• Wie doppelte Zustellung, Wiederholungsversuche, Zeitstempel und Idempotenz zuverlässige industrielle Architekturen beeinflussen
• Wie Workflows für Zustandsüberwachung, vorausschauende Wartung, Qualitätsrückverfolgbarkeit und Produktionsstörungen gestaltet werden
• Wie Sie entscheiden, ob eine Nachricht zur Datenebene, zum Reaktionspfad oder zu beiden gehört

TELEMETRIE IST EINE ZEITLICHE AUFZEICHNUNG
Telemetrie ist nicht deshalb wertvoll, weil ein einzelner Temperaturwert eingetroffen ist. Sie wird wertvoll, weil Tausende von Messwerten zusammen beschreiben, was passiert ist. Eine Produktionsmaschine kann kontinuierlich melden:

• Temperatur- und Vibrationsmessungen
• Motorstrom und Energieverbrauch
• Zykluszähler und Produktionszähler
• Zustände wie laufend, Leerlauf, gestoppt oder fehlerhaft
• Quell-Zeitstempel und Sequenzinformationen
• Diagnose- und Anlagengesundheitsinformationen

Ein einzelner Temperaturwert sagt vielleicht wenig aus. Die Abfolge rund um diesen Messwert erzählt die Geschichte. Hat sich die Maschine aufgewärmt? Produzierte sie bereits? Ist die Vibration gleichzeitig gestiegen? Hat sich die Zykluszeit erhöht? Ist die Maschine kurz darauf stehen geblieben? Telemetrie benötigt daher einen Pfad, der auf Reihenfolge, Aufbewahrung, Wiedergabe, unabhängige Konsumenten und Nachvollziehbarkeit ausgelegt ist.

EREIGNISSE DIENEN DAZU, EINE REAKTION AUSZULÖSEN
Ein Ereignis erfüllt einen anderen Zweck. Ein Ereignis sagt: Etwas hat sich geändert. Ein System oder eine Person muss unter Umständen reagieren. Beispiele sind:

• Ein neues Gerät wurde registriert
• Ein Gateway hat sich von IoT Hub getrennt
• Ein Gerät hat sich wieder verbunden
• Ein Gerät wurde gelöscht
• Ein Überwachungsprozess hat einen Zustand erkannt, der eine Untersuchung erfordert
• Eine Prüfung ist abgeschlossen und ein weiterer Workflow kann beginnen

Der Empfänger benötigt meist nicht stundenlange Telemetrie, bevor er den ersten Schritt beginnt. Er braucht genügend Informationen, um zu erkennen, was passiert ist, und die passende Reaktion festzulegen. Diese Reaktion könnte umfassen:

• Das Starten einer Azure Function
• Das Auslösen einer Logic App
• Das Eröffnen einer Support-Untersuchung
• Das Aktualisieren eines Anlagendatensatzes
• Die Prüfung des aktuellen Gerätezustands
• Den Aufruf einer externen Anwendung über einen Webhook
• Die Benachrichtigung des für das betroffene System zuständigen Teams

Das Ereignis startet die Untersuchung. Es enthält nicht zwangsläufig alle Fakten, die für die endgültige operative Entscheidung benötigt werden.

WARUM „ALLES IST EIN EREIGNIS“ SCHEITERT
Das Senden jeder Sensormessung in ereignisgesteuerte Workflows kann in einem Proof of Concept attraktiv wirken. Dann kommt der Produktivbetrieb im großen Maßstab. Jeder Messwert löst eine weitere Function aus, eine weitere Logic App wertet etwas aus, eine weitere Integration empfängt eine weitere Nachricht. Die Instandhaltung richtet ihre eigene Subskription ein, die Qualitätssicherung eine weitere, ebenso das Energiemanagement. Bald hat jedes Team eine leicht abweichende Filterung, Zustandsverwaltung, Wiederholungslogik und Speicherlogik. Eine Temperaturmessung ist nicht automatisch ein Vorfall. Sie kann später zu einem Vorfall beitragen, aber die kontinuierlichen Messwerte sollten als Nachweis verfügbar bleiben. Wenn routinemäßige Telemetrie ständig Benachrichtigungen erzeugt, beginnen Anwender außerdem häufig, Alarme zu ignorieren, weil das System sie daran gewöhnt hat, Rauschen statt verwertbarer Informationen zu erwarten.

WAS AZURE IOT HUB TATSÄCHLICH LEISTET
Azure IoT Hub bildet die gerätenahe Cloud-Grenze. Er unterstützt Bereiche wie:

• Sichere Geräteidentitäten
• Nachrichtenübertragung vom Gerät zur Cloud
• Kommunikation von der Cloud zum Gerät
• Gerätemanagement
• Device Twins
• Kontrollierten Zugriff zwischen vernetzter Anlage und Azure-Diensten

IoT Hub weiß, dass ein authentifiziertes Gerät eine Nachricht gesendet hat. Er versteht jedoch nicht automatisch, was diese Nachricht für die Produktion bedeutet. Ein Gateway könnte melden: state = running Doch „running“ könnte bedeuten:

• Es werden zugelassene Teile produziert
• Es läuft ein Trockenzyklus
• Es läuft ein Rüstvorgang
• Nacharbeit wird durchgeführt
• Die Maschine bewegt sich ohne Material

Dieser Kontext stammt in der Regel aus weiteren Systemen wie dem MES, dem ERP, dem Anlagenmodell oder einer Produktionsanwendung.

Unterstützen Sie diesen Podcast: https://www.spreaker.com/podcast/m365-fm-a-microsoft-mvp-podcast-by-mirko-peters--6704921/support.