IoT Hub Message Routing versus Event Grid — Waarom telemetrie en events niet hetzelfde probleem zijn

Een machine stuurt om de paar seconden temperatuurmetingen, trillingsgegevens, cyclustellingen, stroomverbruik en bedrijfstoestanden. Plotseling verbreekt de gateway de verbinding. Zijn al die berichten simpelweg “events”? Technisch gezien kun je ze zo omschrijven. Architectonisch kan dat echter ernstige problemen veroorzaken. Azure IoT Hub Message Routing en Azure Event Grid lossen verschillende problemen op. Het ene pad is ontworpen om operationele gegevens te bewaren en te distribueren. Het andere is ontworpen om systemen op de hoogte te stellen dat er iets is veranderd en mogelijk een reactie vereist. Ze als inwisselbaar behandelen kan leiden tot kostbare workflows die routinematige sensorgegevens verwerken, of tot belangrijke signalen die begraven liggen in een telemetriepijplijn waar niemand actief naar kijkt. In deze aflevering van M365 FM volgen we een productiemachine door een echte Azure IoT-architectuur en leggen we uit waar IoT Hub, Event Grid, Event Hubs, Microsoft Fabric, Power BI, MES, ERP, Functions en Logic Apps daadwerkelijk thuishoren.

WAT JE Zult LEREN
In deze aflevering verkennen we:

• Waarom machinetelemetrie en afzonderlijke zakelijke of levenscyclusgebeurtenissen verschillende architectuurpatronen vereisen
• Hoe Azure IoT Hub Message Routing werkt als onderdeel van een telemetrie-dataplane
• Waar Azure Event Grid past binnen event-driven en reactieve architecturen
• Waarom de volgorde van berichten belangrijk is voor productietelemetrie
• Waarom Event Grid niet je primaire telemetriebus voor hoge volumes moet worden
• Waarom IoT Hub-routering niet in elke notificatieworkflow geforceerd moet worden
• Hoe IoT Hub en Event Grid samen in dezelfde architectuur kunnen werken
• Hoe Event Hubs onafhankelijke stream-verwerkingsconsumenten kan ondersteunen
• Waarom ruwe telemetrie vaak bewaard moet blijven voor traceerbaarheid en later onderzoek
• Hoe Microsoft Fabric en Power BI voorbereide operationele gegevens kunnen gebruiken
• Waarom MES, ERP en assetmodellen context bieden die apparaatgegevens alleen niet kunnen leveren
• Hoe disconnect-events van apparaten geïnterpreteerd moeten worden zonder automatisch aan te nemen dat de productie is gestopt
• Hoe dubbele levering, herhalingspogingen, tijdstempels en idempotentie betrouwbare industriële architecturen beïnvloeden
• Hoe je workflows ontwerpt voor conditiebewaking, predictief onderhoud, kwaliteitstraceerbaarheid en productieverstoringen
• Hoe je beslist of een bericht thuishoort op het dataplane, het responspad of beide

TELEMETRIE IS EEN REGISTRATIE IN DE TIJD
Telemetrie is niet waardevol omdat één temperatuurmeting is binnengekomen. Ze wordt waardevol doordat duizenden metingen samen beschrijven wat er gebeurde. Een productiemachine kan continu rapporteren:

• Temperatuur- en trillingsmetingen
• Motorstroom en energieverbruik
• Cyclustellingen en productietellers
• Draaiende, stilstaande, gestopte of storingstoestanden
• Bronstijdstempels en volgordeinformatie
• Diagnostische informatie en informatie over de gezondheid van de apparatuur

Een enkele temperatuurwaarde zegt op zichzelf weinig. De reeks rond die meting vertelt het verhaal. Warmde de machine op? Produceerde hij al? Nam de trilling tegelijkertijd toe? Begon de cyclustijd te stijgen? Stopte de machine kort daarna? Telemetrie heeft daarom een pad nodig dat is ontworpen rond volgorde, retentie, herafspelen, onafhankelijke consumenten en traceerbaarheid.

EVENTS BESTAAN OM EEN REACTIE TE STARTEN
Een event dient een ander doel. Een event zegt: er is iets veranderd. Een systeem of persoon moet mogelijk reageren. Voorbeelden zijn:

• Een nieuw apparaat is geregistreerd
• Een gateway heeft de verbinding met IoT Hub verbroken
• Een apparaat heeft opnieuw verbinding gemaakt
• Een apparaat is verwijderd
• Een bewakingsproces heeft een conditie gedetecteerd die onderzoek vereist
• Een inspectie is afgerond en een andere workflow kan starten

De ontvanger heeft meestal niet uren aan telemetrie nodig voordat de eerste stap begint. Hij heeft genoeg informatie nodig om te bepalen wat er gebeurde en welke reactie past. Die reactie kan bestaan uit:

• Het starten van een Azure Function
• Het activeren van een Logic App
• Het openen van een supportonderzoek
• Het bijwerken van een assetrecord
• Het controleren van de huidige apparaattoestand
• Het aanroepen van een externe applicatie via een webhook
• Het informeren van het team dat verantwoordelijk is voor het getroffen systeem

Het event start het onderzoek. Het bevat niet noodzakelijk alle feiten die nodig zijn voor de uiteindelijke operationele beslissing.

WAAROM “ALLES IS EEN EVENT” NIET WERKT
Het sturen van elke sensormeting naar event-getriggerde workflows kan er aantrekkelijk uitzien tijdens een proof of concept. Dan komt schaal in productie. Elke meting activeert weer een Function. Nog een Logic App evalueert iets. Een andere integratie ontvangt weer een bericht. Onderhoud maakt een eigen abonnement aan. Kwaliteit maakt er nog een. Energiebeheer ook. Al snel heeft elk team iets andere filtering, statusbeheer, herhalingsafhandeling en opslaglogica. Een temperatuurmeting is niet automatisch een incident. Ze kan later wel bijdragen aan een incident, maar de continue metingen moeten beschikbaar blijven als bewijs. Wanneer routinetelemetrie constante notificaties genereert, kunnen gebruikers bovendien alerts gaan negeren, omdat het systeem hen heeft getraind om ruis te verwachten in plaats van bruikbare informatie.

WAT AZURE IOT HUB WERKELIJK DOET
Azure IoT Hub biedt de apparaatgerichte cloudgrens. Het ondersteunt onder meer:

• Veilige apparaatidentiteiten
• Berichtenverkeer van apparaat naar cloud
• Communicatie van cloud naar apparaat
• Apparaatbeheer
• Device twins
• Gecontroleerde toegang tussen verbonden apparatuur en Azure-diensten

IoT Hub weet dat een geauthenticeerd apparaat een bericht heeft verstuurd. Het begrijpt niet automatisch wat dat bericht voor de productie betekent. Een gateway kan rapporteren: state = running Maar “running” kan betekenen:

• Goedgekeurde onderdelen produceren
• Droog cyclen
• Opstelling uitvoeren
• Herbewerking uitvoeren
• Bewegen zonder materiaal

Die context komt meestal uit aanvullende systemen zoals het MES, ERP, het assetmodel of een productieapplicatie.

Word supporter van deze podcast: https://www.spreaker.com/podcast/m365-fm-a-microsoft-mvp-podcast-by-mirko-peters--6704921/support.