IoT Hub vs Event Hubs — Perché la maggior parte dei produttori sceglie il servizio sbagliato

1. IL SINTOMO DEL SHOP FLOOR E LA SFIDA PRINCIPALE. I team spesso inviano i dati di telemetria degli impianti ad Azure utilizzando il servizio che sembra più adatto durante i workshop iniziali, scoprendo solo mesi dopo che il percorso dei dati non è in grado di supportare le operazioni reali dello stabilimento. Ne derivano spesso più dashboard che mostrano valori contrastanti (ad esempio medie a 5 minuti confrontate con valori massimi o allarmi) derivati da copie dello stesso segnale. In definitiva, questo disallineamento tecnico crea un problema di fiducia piuttosto che un semplice bug software. L'errore di fondo sta nel trattare tutti i dati macchina in arrivo come telemetria generica, anziché separare controllo del dispositivo, stato di configurazione, comandi ed elaborazione dei flussi.

2. CLASSIFICARE IL TRAFFICO DI FABBRICA. Prima di selezionare i servizi Azure, il traffico deve essere classificato per nome, direzione e responsabilità, così da garantire una gestione appropriata.

• Gli eventi rappresentano fatti legati a un preciso momento nel tempo, descrivendo cosa è accaduto e quando, ad esempio il completamento di un ciclo di pressa o una lettura di vibrazione che supera un limite. Sono record in sola aggiunta che non dovrebbero essere modificati a valle.
• I comandi sono richieste che indicano a un dispositivo o a un gateway di eseguire un'azione con un intento specifico, ad esempio raccogliere diagnostica o testare una connessione. Comportano una responsabilità esecutiva e devono rispettare i confini locali dei controllori logici programmabili (PLC) e di sicurezza.
• Lo stato riflette la condizione corrente nota di un dispositivo, come la sua versione software o la mappatura della ricetta attiva, piuttosto che la sua cronologia completa. Lo stato è in genere gestito tramite proprietà desiderate e proprietà riportate.
• I messaggi di business riguardano il lavoro operativo che deve essere svolto e tracciato, inclusi blocchi qualità e richieste di manutenzione. Non dovrebbero mai essere mescolati direttamente nelle pipeline di eventi dei sensori grezzi.

3. MODELLO MENTALE: IL GATE DI IDENTITÀ CONTRO L'AUTOSTRADA DEI DATI. Azure IoT Hub agisce come gate controllato, concentrandosi principalmente sulle relazioni e sul ciclo di vita dei dispositivi tramite un registro delle identità, l'autenticazione e lo stato abilitato o disabilitato. Questo consente ai team di sicurezza di isolare o disabilitare un singolo gateway compromesso o sospetto, ad esempio un gateway della linea 4, durante un incidente senza fermare l'intero percorso di telemetria dello stabilimento. Al contrario, Azure Event Hubs funge da autostrada dei dati, concentrandosi interamente sull'elaborazione dei flussi e sul movimento ad alto volume per molti lettori indipendenti. Event Hubs non gestisce i cicli di vita dei dispositivi, il firmware o le configurazioni desiderate; il suo compito principale è far scorrere il traffico in modo efficiente attraverso partizioni e consumer group.

4. GESTIONE E SICUREZZA DEI DISPOSITIVI. Le opzioni di autenticazione dipendono fortemente dalle capacità dell'hardware e dall'architettura di sicurezza. Le chiavi simmetriche con token SAS sono adatte a hardware vincolato e gateway, ma richiedono un'archiviazione sicura su hardware per prevenire il furto delle chiavi. In alternativa, i certificati X.509 offrono catene più pulite tramite una Certificate Authority attendibile per flotte più grandi, anche se richiedono una gestione robusta di rotazione e ciclo di vita. Il ciclo di vita del dispositivo segue un pattern di registrazione, modifica, disabilitazione e sostituzione, garantendo che un'unità hardware sostitutiva si colleghi in modo pulito al suo ruolo operativo e alla sua identità cloud senza interrompere le pipeline a valle o creare asset fantasma. Inoltre, i device twin utilizzano stati desiderati e riportati per la gestione della configurazione e lo stato di salute, sebbene la telemetria ad alta frequenza non debba mai essere memorizzata nei device twin.

5. ELABORAZIONE DEI FLUSSI E MECCANICHE DI ROUTING. Le partizioni dividono i flussi in corsie ordinate, dove le garanzie di ordinamento si applicano rigorosamente all'interno di una singola partizione, tipicamente partizionata per ID macchina, linea o gateway secondo la logica di business. I consumer group consentono a più sistemi a valle, come i calcolatori OEE, gli strumenti di condition monitoring e i servizi di ingestion verso il data lake, di leggere lo stesso flusso in modo indipendente senza competere per le posizioni di lettura. La retention del flusso fornisce una finestra operativa per il recupero a breve termine, la tolleranza ai guasti e la correzione della logica tramite replay. Tuttavia, la retention del flusso non sostituisce uno storico durevole o un lakehouse per la conservazione dei dati a lungo termine.

6. SINTESI DELLE DECISIONI ARCHITETTURALI. Nella valutazione dei servizi, Azure IoT Hub è il più indicato per gateway edge gestiti, configurazioni remote e isolamento della sicurezza dei dispositivi tramite un registro per dispositivo e device twin nativi. Azure Event Hubs è il più indicato per telemetria continua e ad alto volume distribuita a più consumer tramite policy di accesso a livello di namespace, senza una gestione nativa del ciclo di vita dei dispositivi. Un'architettura di fabbrica robusta combina frequentemente entrambi: IoT Hub al confine di connessione per gestire fiducia, identità e configurazione, ed Event Hubs a valle per distribuire in modo sicuro il flusso di eventi ad alto volume ai consumer indipendenti.






Diventa un sostenitore di questo podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.