IoT Hub Message Routing vs Event Grid — Perché Telemetria ed Eventi Non Sono lo Stesso Problema

Una macchina invia letture di temperatura, dati di vibrazione, conteggi dei cicli, consumo energetico e stati operativi ogni pochi secondi. Poi il gateway si disconnette improvvisamente. Tutti quei messaggi sono semplicemente “eventi”? Tecnicamente, si potrebbero descrivere così. Dal punto di vista architetturale, però, questo può creare problemi seri. Azure IoT Hub Message Routing e Azure Event Grid risolvono problemi diversi. Un percorso è progettato per preservare e distribuire i dati operativi. L'altro è progettato per notificare ai sistemi che qualcosa è cambiato e potrebbe richiedere una risposta. Trattarli come intercambiabili può portare a flussi di lavoro costosi che elaborano dati di sensori di routine, oppure a segnali importanti sepolti in una pipeline di telemetria che nessuno sta monitorando attivamente. In questo episodio di M365 FM seguiamo una macchina di produzione attraverso un'architettura IoT reale di Azure e spieghiamo dove effettivamente collocare IoT Hub, Event Grid, Event Hubs, Microsoft Fabric, Power BI, MES, ERP, Functions e Logic Apps.

COSA IMPARERAI
In questo episodio esploriamo:

• Perché la telemetria delle macchine e gli eventi aziendali o di ciclo di vita discreti richiedono pattern architetturali diversi
• Come funziona Azure IoT Hub Message Routing come parte di un data plane della telemetria
• Dove si colloca Azure Event Grid nelle architetture event-driven e reattive
• Perché l'ordine dei messaggi è importante per la telemetria manifatturiera
• Perché Event Grid non dovrebbe diventare il tuo principale bus di telemetria ad alto volume
• Perché il routing di IoT Hub non dovrebbe essere forzato in ogni flusso di notifica
• Come IoT Hub ed Event Grid possono lavorare insieme nella stessa architettura
• Come Event Hubs può supportare consumer indipendenti di elaborazione di stream
• Perché i dati grezzi di telemetria dovrebbero spesso essere conservati per tracciabilità e indagini successive
• Come Microsoft Fabric e Power BI possono consumare dati operativi preparati
• Perché MES, ERP e modelli di asset forniscono un contesto che i soli dati del dispositivo non possono fornire
• Come interpretare gli eventi di disconnessione dei dispositivi senza presumere automaticamente che la produzione si sia fermata
• Come la consegna duplicata, i tentativi di ripetizione, i timestamp e l'idempotenza influiscono sulle architetture industriali affidabili
• Come progettare flussi di lavoro per monitoraggio delle condizioni, manutenzione predittiva, tracciabilità della qualità e interruzioni della produzione
• Come decidere se un messaggio appartiene al data plane, al percorso di risposta o a entrambi

LA TELEMETRIA È UNA REGISTRAZIONE NEL TEMPO
La telemetria non è preziosa perché è arrivata una singola lettura di temperatura. Diventa preziosa perché migliaia di letture insieme descrivono cosa è successo. Una macchina di produzione può riportare in modo continuo:

• Misure di temperatura e vibrazione
• Corrente del motore e consumo energetico
• Conteggi dei cicli e contatori di produzione
• Stati di esecuzione, inattività, arresto o guasto
• Timestamp di origine e informazioni di sequenza
• Informazioni diagnostiche e sullo stato dell'attrezzatura

Un singolo valore di temperatura può significare molto poco. È la sequenza intorno a quella lettura a raccontare la storia. La macchina si stava riscaldando? Stava già producendo? La vibrazione stava aumentando contemporaneamente? Il tempo ciclo ha iniziato ad aumentare? La macchina si è fermata poco dopo? La telemetria richiede quindi un percorso progettato attorno a sequenza, conservazione, riproduzione, consumer indipendenti e tracciabilità.

GLI EVENTI ESISTONO PER AVVIARE UNA RISPOSTA
Un evento serve a uno scopo diverso. Un evento dice: qualcosa è cambiato. Un sistema o una persona potrebbe dover reagire. Esempi includono:

• È stato registrato un nuovo dispositivo
• Un gateway si è disconnesso da IoT Hub
• Un dispositivo si è riconnesso
• Un dispositivo è stato eliminato
• Un processo di monitoraggio ha rilevato una condizione che richiede un'indagine
• Un'ispezione è stata completata e un altro flusso di lavoro può iniziare

Il destinatario di solito non ha bisogno di ore di telemetria prima di avviare il primo passo. Ha bisogno di informazioni sufficienti per identificare cosa è successo e determinare la risposta appropriata. Tale risposta potrebbe includere:

• Avviare una Azure Function
• Attivare una Logic App
• Aprire un'indagine di supporto
• Aggiornare un record dell'asset
• Verificare lo stato attuale del dispositivo
• Chiamare un'applicazione esterna tramite webhook
• Notificare il team responsabile del sistema interessato

L'evento avvia l'indagine. Non contiene necessariamente tutti i fatti necessari per prendere la decisione operativa finale.

PERCHÉ “TUTTO È UN EVENTO” NON FUNZIONA
Inviare ogni misura del sensore a flussi di lavoro attivati da eventi può sembrare attraente durante una proof of concept. Poi arriva la scala di produzione. Ogni lettura attiva un'altra Function. Un'altra Logic App valuta qualcosa. Un'altra integrazione riceve un altro messaggio. La manutenzione crea la sua sottoscrizione. Anche la qualità ne crea un'altra. Così come la gestione energetica. Presto ogni team ha filtri, gestione dello stato, gestione dei tentativi e logica di archiviazione leggermente diversi. Una misura di temperatura non è automaticamente un incidente. Può contribuire a un incidente in seguito, ma le misure continue dovrebbero restare disponibili come prova. Quando la telemetria di routine inizia a generare notifiche costanti, gli utenti possono anche iniziare a ignorare gli avvisi, perché il sistema li ha abituati a aspettarsi rumore anziché informazioni utili.

COSA FA DAVVERO AZURE IOT HUB
Azure IoT Hub fornisce il confine cloud rivolto ai dispositivi. Supporta aree come:

• Identità sicure dei dispositivi
• Messaggistica da dispositivo a cloud
• Comunicazione da cloud a dispositivo
• Gestione dei dispositivi
• Device twin
• Accesso controllato tra attrezzature connesse e servizi Azure

IoT Hub sa che un dispositivo autenticato ha inviato un messaggio. Non comprende automaticamente cosa significhi quel messaggio per la produzione. Un gateway potrebbe riportare: state = running Ma “running” potrebbe significare:

• Produzione di pezzi approvati
• Ciclo a vuoto
• Esecuzione del setup
• Esecuzione di rilavorazioni
• Movimento senza materiale

Quel contesto di solito proviene da altri sistemi come il MES, l'ERP, il modello degli asset o l'applicazione di produzione.

Diventa un sostenitore di questo podcast: https://www.spreaker.com/podcast/m365-fm-a-microsoft-mvp-podcast-by-mirko-peters--6704921/support.