Instradamento dei messaggi di IoT Hub vs Event Grid — Perché telemetria ed eventi non sono lo stesso problema

Una temperatura, un campione di vibrazione, un ciclo macchina e una disconnessione di un dispositivo possono essere tutti descritti come eventi, ma non rappresentano lo stesso problema architetturale. Negli ambienti IoT industriali e manifatturieri, confondere la telemetria continua con gli eventi discreti può creare flussi di lavoro rumorosi, storie di produzione incomplete, elaborazioni non necessarie e sistemi che reagiscono senza un contesto sufficiente.

In questo episodio analizziamo la differenza architetturale tra Azure IoT Hub Message Routing e Azure Event Grid seguendo uno scenario manifatturiero realistico. Una linea di presse invia continuamente, tramite un gateway industriale, informazioni su temperatura, vibrazioni, conteggio dei cicli, consumo energetico e stato della macchina. Queste misurazioni creano uno storico operativo che ingegneri, team dei dati, team di manutenzione e sistemi di produzione potrebbero dover analizzare in seguito. La disconnessione di un dispositivo è diversa, perché rappresenta un cambiamento che potrebbe richiedere a un altro sistema o a una persona di reagire.

LA TELEMETRIA È UN REGISTRO, NON UN ALLARME
La telemetria rappresenta misurazioni ripetute nel tempo. Un singolo valore di temperatura o una singola misurazione di vibrazione di solito dice ben poco da solo. L'informazione reale esiste nella sequenza: quanto rapidamente i valori sono cambiati, cosa stava facendo la macchina in quel momento, cosa è accaduto prima di un arresto, se le misurazioni sono scomparse durante un'interruzione di rete e se lo stesso comportamento era presente in precedenti cicli di produzione.


La telemetria industriale tipica include:
• Temperatura, vibrazione, pressione, consumo energetico e assorbimento di corrente
• Stati della macchina come in funzione, inattiva, ferma o in guasto
• Conteggi dei cicli, contatori di produzione e misurazioni di processo
• Timestamp di origine, identificativi dei dispositivi, numeri di sequenza e informazioni di correlazione

Questi record possono successivamente supportare il monitoraggio delle condizioni, le indagini sulla qualità, l'analisi dell'energia, i calcoli OEE, le analisi di Microsoft Fabric, i report di Power BI e l'ottimizzazione della produzione. Per questo la telemetria richiede conservazione, replay, gestione dei duplicati, consumer indipendenti e un modo affidabile per ricostruire la cronologia della produzione.

IOT HUB MESSAGE ROUTING COME PIANO DATI DELLA TELEMETRIA
Azure IoT Hub fornisce il confine controllato tra dispositivo e cloud. Dispositivi e gateway si autenticano con le proprie identità, inviano messaggi da dispositivo a cloud, mantengono lo stato di gestione dei dispositivi e possono partecipare a comunicazioni controllate da cloud a dispositivo.

Una volta che un messaggio di telemetria raggiunge IoT Hub, Message Routing determina dove devono andare quei dati. Il routing può ispezionare proprietà del messaggio, proprietà di sistema, parti del corpo del messaggio e informazioni del device twin. Ciò consente di separare classi di messaggi come telemetria di produzione, misurazioni energetiche o diagnostica prima che raggiungano i consumer a valle.
Un'architettura comune potrebbe essere la seguente: gateway industriale → Azure IoT Hub → Message Routing → Event Hubs o Storage → Elaborazione → Microsoft Fabric.

Un consumer può eseguire analisi quasi in tempo reale, mentre un altro conserva un archivio grezzo. Un terzo consumer può preparare dati operativi curati per Microsoft Fabric. Ogni consumer può lavorare in modo indipendente senza trasformare ogni singola lettura di telemetria in un'invocazione di flusso di lavoro.

PERCHÉ L'ORDINE CONTA
La telemetria industriale è particolarmente sensibile alla sequenza. Immaginate una macchina che segnala di essere entrata in stato di funzionamento, poi trasmette diversi conteggi di cicli, seguiti da una deviazione di processo e infine da uno stato di arresto. Se questi record vengono ricostruiti in modo errato, un sistema a valle potrebbe concludere che la macchina ha prodotto pezzi mentre era ferma oppure che una deviazione di processo è avvenuta dopo la fine della produzione.

Lo stesso problema interessa i calcoli dei tempi di fermo, l'OEE, i conteggi di produzione e il monitoraggio delle condizioni. È quindi necessario distinguere tra quando la fonte ha osservato un evento, quando IoT Hub ha ricevuto il messaggio e quando un sistema a valle lo ha elaborato.

Un'architettura di telemetria robusta dovrebbe quindi considerare:
• Timestamp di origine e timestamp di ricezione nel cloud
• Partizionamento stabile appropriato per l'asset o per il carico di lavoro
• ID dei messaggi o numeri di sequenza per il rilevamento dei duplicati
• Consumer idempotenti in grado di gestire una consegna almeno una volta

Le interruzioni di rete rendono tutto questo particolarmente importante. Un gateway potrebbe bufferizzare la telemetria e inviarla quando la connettività ritorna, il che significa che l'ora di arrivo su Azure può essere molto successiva al timestamp reale della macchina.

EVENT GRID RISOLVE UN PROBLEMA DIVERSO
Azure Event Grid è progettato attorno alle notifiche publish-and-subscribe. Invece di ricostruire continuamente lo stato di una macchina a partire da migliaia di letture, Event Grid comunica ai sistemi interessati che qualcosa è cambiato e offre ai subscriber la possibilità di reagire.
Esempi in un ambiente IoT includono la creazione o l'eliminazione di un dispositivo, la connessione o la disconnessione, oppure condizioni accuratamente selezionate derivate dalla telemetria. Un evento di creazione del dispositivo potrebbe avviare un processo di onboarding dell'asset. Un evento di disconnessione potrebbe avviare un'indagine tecnica. Una condizione ingegneristica rilevata potrebbe avviare un flusso di lavoro di manutenzione.

I subscriber tipici includono:
• Azure Functions
• Logic Apps
• Webhook
• Flussi di lavoro di sicurezza
• Sistemi di gestione degli asset
• Applicazioni operative

La differenza architetturale fondamentale è semplice: la telemetria chiede cosa ha fatto un asset, mentre un evento chiede cosa è cambiato e se qualcosa dovrebbe reagire.

GLI EVENTI DOVREBBERO AVVIARE INDAGINI, NON DEFINIRE LA REALTÀ
Event Grid dovrebbe generalmente essere considerato un meccanismo di notifica, non lo stato finale e autorevole del mondo fisico. La consegna di un evento può essere ripetuta, e un subscriber non dovrebbe interpretare ciecamente un evento come stato corrente definitivo senza verificarlo.
Un evento di dispositivo disconnesso dovrebbe quindi di solito avviare un controllo dello stato. Una Azure Function potrebbe verificare lo stato corrente del dispositivo, ispezionare la telemetria recente, controllare le informazioni rilevanti del registro e poi decidere se l'indagine deve restare aperta.

I gestori dovrebbero essere progettati attorno a:
• Elaborazione idempotente
• Verifica dello stato corrente
• Identità e timestamp dell'evento
• Proprietà chiaramente definita dell'azione risultante

Questo è importante perché gli eventi duplicati non dovrebbero creare ticket duplicati, allarmi duplicati o record operativi in conflitto.

UNA DISCONNESSIONE DEL DISPOSITIVO NON SIGNIFICA CHE LA MACCHINA SI SIA FERMATA
Una delle distinzioni più importanti nell'IoT industriale è la differenza tra connettività cloud, stato della raccolta dati e stato di produzione. Se un gateway industriale si disconnette da IoT Hub, il cloud ha perso la visibilità su quel gateway. Questo non significa automaticamente che la macchina fisica si sia fermata.

Il PLC può continuare a controllare localmente l'apparecchiatura mentre il gateway perde temporaneamente la connettività. La produzione può proseguire normalmente, e il gateway può persino bufferizzare la telemetria e caricarla in seguito. Può accadere anche il contrario: un gateway può restare connesso ad Azure mentre la sua connessione al PLC o all'apparecchiatura locale è guasta.

Un'architettura utile separa quindi lo stato di connessione cloud, la salute del gateway, lo stato di produzione della macchina e lo stato dell'ordine di lavoro MES. Solo combinando queste fonti l'azienda può determinare se un problema tecnico di connettività abbia effettivamente influito sulla produzione.

FILTRAGGIO IN IOT HUB VS FILTRAGGIO IN EVENT GRID
Entrambe le tecnologie supportano il filtraggio, ma lo scopo è diverso. Il filtraggio di IoT Hub Message Routing risponde a quali messaggi operativi devono entrare in uno specifico percorso di dati. Il filtraggio delle sottoscrizioni di Event Grid risponde a quali notifiche un determinato subscriber deve ricevere.

Ad esempio, la telemetria di produzione può andare a un flusso Event Hubs, mentre i dati energetici vanno a un'altra destinazione. Allo stesso tempo, un flusso di supporto potrebbe sottoscrivere solo gli eventi di disconnessione di un particolare