IoT Hub Message Routing vs Event Grid — Waarom telemetrie en gebeurtenissen niet hetzelfde probleem zijn

Een temperatuurmeting, een trillingsmonster, een machinecyclus en een apparaatverbreking kunnen allemaal als gebeurtenissen worden omschreven, maar ze vormen niet hetzelfde architecturale probleem. In industriële IoT- en productieomgevingen kan het verwarren van continue telemetrie met discrete gebeurtenissen leiden tot ruisige workflows, onvolledige productiegeschiedenissen, onnodige verwerking en systemen die reageren zonder voldoende context.

In deze aflevering ontleden we het architecturale verschil tussen Azure IoT Hub Message Routing en Azure Event Grid aan de hand van een realistisch productiescenario. Een persstraat stuurt continu temperatuur-, trillings-, cyclusteller-, energieverbruik- en machinestatusinformatie via een industriële gateway. Die metingen vormen een operationele geschiedenis die ingenieurs, datateams, onderhoudsteams en productiesystemen later mogelijk moeten analyseren. Een apparaatverbreking is anders, omdat ze een wijziging vertegenwoordigt waarop een ander systeem of persoon mogelijk moet reageren.

TELEMETRIE IS EEN REGISTRATIE, GEEN ALERT
Telemetrie vertegenwoordigt herhaalde metingen in de tijd. Een enkele temperatuurwaarde of trillingsmeting zegt meestal weinig op zichzelf. De echte informatie zit in de reeks: hoe snel waarden veranderden, wat de machine op dat moment deed, wat er gebeurde vóór een stilstand, of metingen verdwenen tijdens een netwerkonderbreking, en of hetzelfde gedrag in eerdere productieruns voorkwam.


Typische industriële telemetrie omvat:
• Temperatuur, trilling, druk, energieverbruik en stroomopname
• Machinestatussen zoals draaiend, stationair, gestopt of in storing
• Cyclustellingen, productietellers en procesmetingen
• Brontijdstempels, apparaatidentificaties, volgnummers en correlatie-informatie

Die registraties kunnen later ondersteuning bieden bij conditiebewaking, kwaliteitsonderzoeken, energieanalyse, OEE-berekeningen, Microsoft Fabric-analyses, Power BI-rapportage en productieoptimalisatie. Daarom heeft telemetrie retentie, replay, duplicaatafhandeling, onafhankelijke consumenten en een betrouwbare manier nodig om de productietijdlijn te reconstrueren.

IOT HUB MESSAGE ROUTING ALS TELEMETRIE-DATAVLAK
Azure IoT Hub biedt de gecontroleerde grens van apparaat naar cloud. Apparaten en gateways authenticeren met hun eigen identiteiten, versturen berichten van apparaat naar cloud, onderhouden de apparaatbeheerstatus en kunnen deelnemen aan gecontroleerde communicatie van cloud naar apparaat.

Zodra een telemetriebericht IoT Hub bereikt, bepaalt Message Routing waar die gegevens naartoe moeten. Routing kan berichteigenschappen, systeemeigenschappen, delen van de berichtinhoud en apparaattwin-informatie inspecteren. Hierdoor is het mogelijk productietelemetrie, energiemetingen, diagnostiek of andere berichtklassen te scheiden voordat ze downstream consumenten bereiken.
Een gangbare architectuur kan er zo uitzien: Industriële gateway → Azure IoT Hub → Message Routing → Event Hubs of Storage → Verwerking → Microsoft Fabric.

Eén consument kan bijna-realtime analyse uitvoeren, terwijl een andere een ruw archief bewaart. Een derde consument kan gecureerde operationele gegevens voor Microsoft Fabric voorbereiden. Elke consument kan onafhankelijk werken zonder elke telemetrie-meting om te zetten in een workflow-aanroep.

WAAROM VOLGORDE BELANGRIJK IS
Industriële telemetrie is bijzonder gevoelig voor volgorde. Stel je voor dat een machine meldt dat ze in een draaiende toestand is gekomen, vervolgens verschillende cyclustellingen verstuurt, daarna een procesafwijking en tot slot een gestopte toestand. Als die registraties verkeerd worden gereconstrueerd, zou een downstream systeem kunnen concluderen dat de machine onderdelen produceerde terwijl ze stilstond, of dat een procesafwijking plaatsvond nadat de productie al was beëindigd.

Hetzelfde probleem geldt voor stilstandberekeningen, OEE, productietellingen en conditiebewaking. Je moet daarom onderscheid maken tussen wanneer de bron iets waarnam, wanneer IoT Hub het bericht ontving en wanneer een downstream systeem het verwerkte.

Een robuuste telemetriearchitectuur moet daarom rekening houden met:
• Brontijdstempels en ontvangsttijdstempels in de cloud
• Stabiele partitionering passend bij het asset of de workload
• Bericht-ID's of volgnummers voor duplicaatdetectie
• Idempotente consumenten die at-least-once-levering aankunnen

Netwerkonderbrekingen maken dit bijzonder belangrijk. Een gateway kan telemetrie bufferen en verzenden wanneer de connectiviteit terugkeert, wat betekent dat de aankomsttijd in Azure veel later kan liggen dan het werkelijke machinetijdstempel.

EVENT GRID LOST EEN ANDER PROBLEEM OP
Azure Event Grid is ontworpen rond publish-and-subscribe-notificaties. In plaats van de status van een machine continu te reconstrueren uit duizenden metingen, vertelt Event Grid geïnteresseerde systemen dat er iets is veranderd en geeft abonnees de gelegenheid te reageren.
Voorbeelden in een IoT-omgeving zijn het aanmaken, verwijderen, verbinden of verbreken van een apparaat, of zorgvuldig geselecteerde door telemetrie afgeleide condities. Een gebeurtenis "apparaat aangemaakt" kan een onboardingproces voor assets starten. Een gebeurtenis "apparaat losgekoppeld" kan een technisch onderzoek starten. Een gedetecteerde technische conditie kan een onderhoudsworkflow activeren.

Typische abonnees zijn:
• Azure Functions
• Logic Apps
• Webhooks
• Beveiligingsworkflows
• Asset-beheersystemen
• Operationele applicaties

Het fundamentele architecturale verschil is eenvoudig: telemetrie vraagt wat een asset heeft gedaan, terwijl een gebeurtenis vraagt wat er is veranderd en of iets moet reageren.

GEBEURTENISSEN MOETEN ONDERZOEKEN STARTEN, NIET DE REALITEIT DEFINIËREN
Event Grid moet over het algemeen worden beschouwd als een notificatiemechanisme, niet als de definitieve, gezaghebbende toestand van de fysieke wereld. Gebeurtenislevering kan herhaald worden, en een abonnee mag een gebeurtenis niet blindelings als de definitieve huidige toestand interpreteren zonder dit te controleren.
Een gebeurtenis "apparaat losgekoppeld" moet daarom meestal een statuscontrole activeren. Een Azure Function kan de actuele apparaatstatus verifiëren, recente telemetrie inspecteren, relevante registergegevens controleren en vervolgens beslissen of het onderzoek open moet blijven.

Handlers moeten worden ontworpen rond:
• Idempotente verwerking
• Verificatie van de huidige status
• Gebeurtenisidentiteit en tijdstempels
• Duidelijk gedefinieerd eigenaarschap van de resulterende actie

Dit is belangrijk omdat dubbele gebeurtenissen geen dubbele tickets, dubbele alerts of conflicterende operationele registraties mogen veroorzaken.

EEN APPARAATVERBREKING BETEKENT NIET DAT DE MACHINE GESTOPT IS
Een van de belangrijkste onderscheidingen in industrieel IoT is het verschil tussen cloudconnectiviteit, gezondheid van de gegevensverzameling en productiestatus. Als een industriële gateway de verbinding met IoT Hub verliest, heeft de cloud het zicht op die gateway verloren. Dat betekent niet automatisch dat de fysieke machine is gestopt.

De PLC kan de apparatuur lokaal blijven aansturen terwijl de gateway tijdelijk de connectiviteit verliest. De productie kan normaal doorgaan, en de gateway kan zelfs telemetrie bufferen en later uploaden. Het omgekeerde kan ook gebeuren: een gateway kan verbonden blijven met Azure terwijl de verbinding met de PLC of lokale apparatuur is uitgevallen.

Een bruikbare architectuur scheidt daarom de cloudverbindingstoestand, de gezondheid van de gateway, de productiestatus van de machine en de MES-werkorderstatus. Alleen door die bronnen te combineren kan het bedrijf bepalen of een technisch connectiviteitsprobleem daadwerkelijk de productie heeft beïnvloed.

FILTEREN IN IOT HUB VS FILTEREN IN EVENT GRID
Beide technologieën ondersteunen filteren, maar het doel verschilt. Filteren in IoT Hub Message Routing beantwoordt welke operationele berichten een specifiek datapad mogen binnengaan. Filteren in Event Grid-abonnementen beantwoordt welke notificaties een bepaalde abonnee moet ontvangen.

Productietelemetrie kan bijvoorbeeld naar de ene Event Hubs-stroom gaan, terwijl energiedata naar een andere bestemming gaat. Tegelijkertijd kan een supportworkflow zich alleen abonneren op gebeurtenissen van losgekoppelde apparaten van een bepaald