Come funziona una pipeline di dati IoT?

I dispositivi producono un flusso di piccoli record con marca temporale. Da solo, quel flusso non vale quasi nulla. Il valore nasce da ciò che succede dopo: validare i record, archiviarli dove possono essere interrogati, calcolare qualcosa a partire da essi e attivare un’azione quando il calcolo lo richiede. La catena di componenti che fa tutto questo è la pipeline di dati, ed è lì che finisce la maggior parte del lavoro di ingegneria in un sistema IoT maturo.

Le pipeline IoT si distinguono dal data engineering generico per alcuni aspetti. I dati arrivano in modo continuo e fuori sequenza, da dispositivi con orologi inaffidabili e connettività intermittente. Il volume è il numero di dispositivi moltiplicato per la frequenza di campionamento. E molte decisioni vanno prese entro pochi secondi dall’arrivo dei dati, non in un batch notturno.

Questa guida percorre le fasi in ordine e mette in evidenza le scelte che determinano se una pipeline regge quando cresce di scala.

Cosa succede all’acquisizione?

L’acquisizione (ingestion) dei dati è il confine attraverso cui i messaggi dei dispositivi entrano nel back end. Di norma un broker o un servizio gateway riceve i messaggi via MQTT, CoAP o HTTP e li passa alla pipeline.

Alcune operazioni devono avvenire a questo confine e in nessun altro punto. Il mittente viene autenticato e il messaggio viene etichettato con l’identità del dispositivo verificata, non con quella dichiarata nel payload. Il payload viene decodificato, che sia JSON, CBOR o Protocol Buffers, e validato rispetto a uno schema. Si aggiungono i metadati: tipo di dispositivo, versione del firmware, cliente, sito. E accanto alla marca temporale del dispositivo si registra una marca temporale di ricezione lato server, perché gli orologi dei dispositivi vanno alla deriva e le batterie si scaricano.

Uno schema ricorrente consiste nel pubblicare ogni messaggio validato su una coda di messaggi o su un log, così che i consumatori a valle possano elaborarlo in modo indipendente. In questo modo l’acquisizione è disaccoppiata dall’elaborazione: se il servizio di analisi è lento, i messaggi si accodano invece di essere scartati dal broker.

Cosa sono l’hot path e il cold path?

Dopo l’acquisizione, la maggior parte delle pipeline si divide in due. L’hot path, il percorso caldo, gestisce i dati che richiedono una risposta in pochi secondi: soglie di allarme, dashboard in tempo reale, comandi agli attuatori. Il cold path, il percorso freddo, gestisce tutto ciò che può aspettare: archiviazione a lungo termine, reportistica, addestramento dei modelli.

L’hot path usa l’elaborazione in streaming, che valuta ogni record, o una piccola finestra di record, nel momento in cui arriva. Le operazioni tipiche sono il filtraggio (scartare le letture fuori da un intervallo plausibile), l’arricchimento (associare l’ID del dispositivo a una posizione), l’aggregazione su finestra (la media degli ultimi cinque minuti) e il rilevamento di pattern (tre letture consecutive sopra un limite). Il motore di regole di una piattaforma IoT è un elaboratore di stream semplificato.

Il cold path usa l’elaborazione batch: job periodici che leggono un giorno o un mese di dati archiviati, calcolano aggregati e report e alimentano l’ETL verso un data warehouse. I job batch costano meno per record, quindi tutto ciò che non richiede bassa latenza dovrebbe passare di lì.

L’architettura basata su eventi lega i due percorsi: l’hot path emette eventi come “soglia superata” o “dispositivo silenzioso”, e gli altri servizi sottoscrivono quegli eventi invece della telemetria grezza.

Come vengono archiviati i dati?

I dati IoT sono serie temporali: un valore, una marca temporale e un insieme di tag che identificano la sorgente. Un database relazionale può archiviarli, ma fatica con la frequenza di scrittura e con lo schema di interrogazione, che è quasi sempre “questa metrica, questi dispositivi, questo intervallo di tempo, aggregati per intervallo”. Un database di serie temporali è costruito esattamente per questo, con una compressione ottimizzata per numeri che cambiano lentamente e funzioni di interrogazione per gli aggregati su finestra.

Tre decisioni dominano la progettazione dell’archiviazione.

Conservazione. I dati grezzi ad alta frequenza occupano molto spazio e raramente servono dopo qualche settimana. Una politica di conservazione dei dati mantiene i dati grezzi per una finestra breve, gli aggregati sottocampionati più a lungo e le statistiche di sintesi a tempo indefinito. Le normative possono imporre durate minime o massime.

Partizionamento. I dati vengono partizionati per tempo, e spesso per tenant, così che le partizioni vecchie possano essere eliminate a basso costo e le interrogazioni tocchino solo gli intervalli necessari.

Archiviazione fredda. Lo storico completo finisce in un data lake su object storage, in un formato colonnare aperto, dove costa poco conservarlo e resta disponibile per l’addestramento dei modelli e le analisi ad hoc.

Accanto alle serie temporali, la pipeline mantiene lo stato corrente di ogni dispositivo, di solito in un documento device shadow, così che le applicazioni possano rispondere a “qual è lo stato adesso” senza scorrere lo storico.

Cosa calcolano elaborazione e analisi?

Con i dati in flusso e archiviati, la pipeline calcola qualcosa. I casi semplici sono le soglie e i KPI: energia al giorno, uptime per macchina, OEE per linea. Sono in genere aggregazioni in streaming scritte nel database di serie temporali e mostrate su una dashboard.

I casi più difficili coinvolgono il machine learning. Il rilevamento delle anomalie apprende il comportamento normale e segnala le deviazioni, utile quando nessuno è in grado di scrivere la soglia in anticipo. I modelli di manutenzione predittiva stimano il tempo al guasto a partire dallo storico di vibrazioni, temperatura e carico. Questi modelli vengono addestrati in batch sul data lake e poi distribuiti nell’elaboratore di stream oppure, sempre più spesso, all’edge, dove possono agire senza un’andata e ritorno verso il cloud. La guida sulla manutenzione predittiva con IoT e AI descrive questo flusso di lavoro, e le pratiche MLOps gestiscono il riaddestramento quando subentra il drift del modello.

Come agisce la pipeline sui dati?

L’ultima fase chiude il ciclo. Le azioni prendono tre forme. Le notifiche raggiungono le persone tramite avvisi, ticket o messaggi, e il principale problema di progettazione è evitare l’affaticamento da avvisi (alert fatigue): si deduplica, si raggruppa e si applica un’isteresi, così che un valore che oscilla intorno a una soglia non generi cento allarmi. Le integrazioni spingono gli eventi verso altri sistemi tramite webhook e API: un ordine di lavoro di manutenzione, una registrazione di fatturazione, un aggiornamento di inventario. I comandi tornano ai dispositivi, pubblicati su un topic di comando su cui agisce il firmware del dispositivo, con il risultato riportato indietro perché lo shadow rifletta la realtà.

Una regola automatica in grado di accendere o spegnere apparecchiature fisiche dovrebbe avere limiti di frequenza e di ambito, una traccia di audit e la possibilità di essere scavalcata manualmente da una persona. Un bug che accende e spegne un riscaldatore ogni secondo è un problema di sicurezza, non solo un problema di dati.

Dove si colloca l’edge?

Non tutto questo deve avvenire nel cloud. L’analisi all’edge sposta l’hot path, o una sua parte, su un gateway o sul dispositivo. Filtrare e sottocampionare all’edge riduce la banda; le regole locali continuano a funzionare durante le interruzioni; eseguire l’inferenza in locale evita di inviare altrove video o audio grezzi. Il cold path finisce comunque in un punto centrale, perché l’addestramento e il confronto tra siti hanno bisogno di tutti i dati in un unico posto. Decidere dove passa il confine è l’argomento di edge, cloud o fog.

Come si gestisce la pipeline in esercizio?

Una pipeline è un sistema in produzione e si guasta nei modi tipici dei sistemi in produzione. I segnali da monitorare sono il tasso di acquisizione rispetto a quello atteso (un calo improvviso significa che i dispositivi o la rete hanno un problema), la latenza end-to-end dalla marca temporale del dispositivo all’azione, la profondità delle code (una coda che cresce significa che un consumatore resta indietro) e il numero di dispositivi che non hanno inviato dati entro il loro intervallo atteso. Le questioni di governance dei dati, chi può accedere a cosa e come si trattano i dati personali, vanno risolte prima che venga archiviato il primo record.

Per continuare

• Le piattaforme IoT spiegate descrive i servizi gestiti che implementano le fasi di acquisizione e regole.
• Edge, cloud o fog aiuta a decidere quali fasi avvicinare ai dispositivi.
• Gemelli digitali spiegati copre il modello che si appoggia su una pipeline matura.
• Manutenzione predittiva con IoT e AI mostra la pipeline applicata a un problema specifico.

Argomenti: dati, pipeline, serie temporali, elaborazione in streaming, architettura