Edge, cloud o fog: dove dovrebbe avvenire l'elaborazione nell'IoT?

Ogni architettura IoT risponde molte volte alla stessa domanda: per questo pezzo di lavoro, dove gira il codice? Il sensore, il gateway nell’armadio, un server nell’edificio, un nodo all’edge dell’operatore telefonico o una regione cloud in un altro continente sono tutti candidati, e ciascuno è la risposta giusta per alcuni carichi di lavoro e quella sbagliata per altri.

Il vocabolario attorno a questo tema è più confuso del necessario. Il cloud computing è abbastanza chiaro: centralizzato, elastico, remoto. L’edge computing significa elaborare vicino alla sorgente dei dati, ma “vicino” si estende da un microcontrollore a un data center metropolitano. Il fog computing, termine promosso da Cisco e dall’OpenFog Consortium a metà degli anni 2010, descrive i livelli intermedi tra dispositivi e cloud, con calcolo, archiviazione e rete distribuiti lungo il percorso. Nella pratica, oggi quasi tutti fanno rientrare il fog nell‘“edge” e parlano di livelli.

Questa guida presenta i livelli, i fattori che decidono la collocazione e un metodo ripetibile per assegnare i carichi di lavoro.

Quali sono i livelli, dal più sottile al più spesso?

Livello dispositivo. Il sensore o l’attuatore stesso, di solito un microcontrollore con una memoria che va da qualche kilobyte a pochi megabyte. Può filtrare, applicare soglie, comprimere ed eseguire piccoli modelli, ed è l’unico livello in grado di agire con tempi dell’ordine dei microsecondi. Non può conservare uno storico né coordinarsi con i vicini oltre un salto radio.

Livello gateway. Un gateway edge con un sistema operativo completo, che aggrega i dispositivi di un sito. Può tradurre protocolli, fare da buffer durante le interruzioni, eseguire regole e modelli di dimensioni medie e ospitare un’interfaccia utente locale. Conosce i dispositivi del suo sito e nulla oltre.

Livello sito o fog. Server on premise o un piccolo cluster, oppure capacità di calcolo ospitata dall’operatore all’edge della rete. Può eseguire un historian locale, inferenza più pesante, un gemello digitale (digital twin) a livello di sito e il coordinamento tra molti gateway. Ha archiviazione e calcolo veri, ma resta una risorsa fissa e finita che qualcuno deve mantenere in loco.

Livello cloud. Calcolo e archiviazione elastici con portata globale. È l’unico livello che può vedere l’intera flotta, conservare anni di storico, addestrare modelli su dati provenienti da più siti e servire persone che non si trovano sul posto. È anche il più lontano, e quello che sparisce quando sparisce il collegamento.

Quali fattori decidono la collocazione?

Tempo di risposta

Misura la scadenza, non la preferenza. Un ciclo di controllo che deve chiudersi in meno di dieci millisecondi vive sul dispositivo o su un controller cablato a esso. Una decisione necessaria entro un secondo può vivere su un gateway. Tutto ciò che tollera secondi o minuti può vivere ovunque, cloud compreso. Sii onesto nel decidere in quale categoria ricade davvero un carico di lavoro: molte dashboard “in tempo reale” vanno benissimo con due secondi di ritardo.

Volume di dati e capacità del collegamento

Confronta ciò che il carico di lavoro produce con ciò che l’uplink può trasportare a un costo accettabile. Video, vibrazioni ad alta frequenza e audio hanno quasi sempre bisogno di essere ridotti prima di lasciare il sito. La telemetria a bassa frequenza su Ethernet o Wi-Fi può salire direttamente. Su LPWAN o su rete cellulare a consumo, anche gli stream piccoli si sommano, e il sottocampionamento all’edge si ripaga da solo.

Comportamento in assenza di connessione

Decidi cosa deve continuare a funzionare durante un’interruzione. Sicurezza locale, controllo locale, allarmi locali e buffering locale vanno collocati al di sotto del collegamento. La reportistica di flotta e l’analisi storica possono aspettare. La pipeline di dati va progettata in modo che un’interruzione produca un arretrato, non una perdita di dati.

Privacy, normativa e sovranità

Individua i dati che non possono lasciare il sito, il Paese o il controllo del cliente. Elaborali al di sotto di quel confine e trasmetti solo ciò che è consentito. Gli obblighi di sovranità dei dati spesso decidono da soli l’esistenza del livello fog.

Ambito della conoscenza

Alcune elaborazioni hanno bisogno di informazioni che esistono in un solo livello. Confrontare questa macchina con lo stesso modello in altri quaranta impianti richiede il cloud. Rilevare che il cuscinetto di questa macchina si sta usurando richiede soltanto il suo storico, che un gateway può conservare. Abbina il carico di lavoro al livello più stretto che contiene i dati di cui ha bisogno.

Costo e gestione operativa

Il calcolo nel cloud si paga a consumo ed è mantenuto dal provider; l’hardware edge si compra in anticipo ed è mantenuto da te o dal tuo cliente. Mille gateway che eseguono un modello sono mille unità di hardware, alimentazione e patch. A volte il cloud è più economico perché esiste già; a volte l’edge è più economico perché il trasferimento dei dati domina la bolletta. Fai i conti sul costo totale di possesso invece di dare le cose per scontate.

Come si traduce tutto questo su una linea di produzione?

Prendi una linea di confezionamento con ispezione visiva, sensori di vibrazione sui motori, un PLC per stazione e un direttore di stabilimento che vuole una dashboard OEE.

• Arresti di emergenza e interblocchi: livello dispositivo, sul PLC. Deterministici, nessuna dipendenza dalla rete.
• Rilevamento dei difetti dalle telecamere: livello gateway o sito. I fotogrammi sono troppo pesanti da caricare, la decisione serve entro il tempo ciclo e le immagini possono contenere dettagli riservati del prodotto. A monte vanno solo le immagini dei difetti e i conteggi.
• Rilevamento dell’usura dei cuscinetti dalle vibrazioni: livello dispositivo per l’estrazione delle feature (il sensore calcola le bande spettrali), livello gateway per il modello di rilevamento delle anomalie, livello cloud per addestrare il modello sui dati di tutti gli impianti e rimandare indietro le versioni aggiornate.
• Dashboard OEE: livello cloud, perché il direttore di stabilimento, il direttore regionale e il fornitore devono vederla tutti, e qualche secondo di ritardo va bene. Una copia a livello di sito tiene vivi gli schermi locali quando cade il collegamento.
• Addestramento dei modelli e confronto tra flotte: livello cloud, dove stanno lo storico e la capacità di calcolo.

Lo stesso carico di lavoro spesso attraversa più livelli, con l’estrazione delle feature in basso e l’apprendimento in alto. È normale, ed è così che di solito si assesta lo schema AIoT.

Quali sono gli errori più comuni?

Il primo è scegliere un livello per l’intero sistema invece che per ogni carico di lavoro. “Siamo un’azienda edge” o “siamo cloud-first” producono entrambe collocazioni sbagliate. Il secondo è progettare solo il percorso ideale, così la prima interruzione rivela che il gateway locale non può agire senza un token del cloud. Il terzo è sottovalutare la gestione operativa dell’edge: il prototipo gira su una scatola in laboratorio, e nessuno ha pianificato come aggiornarne cinquecento negli armadi sparsi in una regione. Il quarto è trattare il fog come un prodotto da comprare invece che come una decisione di collocazione da prendere; il livello intermedio ha valore esattamente quando un carico di lavoro specifico ne ha bisogno, e altrimenti è zavorra.

Come si decide, passo dopo passo?

Per ogni carico di lavoro, annota la scadenza, il volume di dati, il comportamento in assenza di connessione, i vincoli sui dati, l’ambito dei dati di cui ha bisogno e le persone che ne consumano l’output. Collocalo nel livello più stretto che soddisfa la scadenza e i vincoli sui dati e che contiene i dati necessari. Poi verifica le conseguenze in termini di costo e gestione operativa, e spostalo di un livello verso l’alto se quello inferiore non vale la pena di essere mantenuto. Rivedi la scelta quando cambiano il collegamento, i volumi o le normative.

Per continuare

• Edge computing spiegato approfondisce le forze che spingono verso la collocazione all’edge.
• Architettura IoT: i livelli presenta il modello a livelli su cui questi livelli si mappano.
• La pipeline di dati IoT segue i dati attraverso acquisizione, archiviazione, elaborazione e azione lungo i vari livelli.
• Le piattaforme IoT spiegate esamina i runtime cloud ed edge che mettono in pratica questa collocazione.

Argomenti: edge computing, cloud computing, fog computing, architettura, latenza