Edge computing · base

Che cos'è l'edge computing?

Cosa significa edge computing nell'IoT, perché latenza, banda, privacy e resilienza spingono l'elaborazione verso i dispositivi, e come decidere cosa gira dove.

Fibre-optic cables plugged into a network switch in a rack

Foto: Kirill Sh / Unsplash

Dopo aver letto questo articolo saprai:

  • Spiegare le quattro forze, latenza, banda, resilienza e privacy, che spingono l'elaborazione verso l'edge
  • Descrivere il continuum dell'edge, dal microcontrollore di un sensore al gateway, al cluster di sito e all'edge dell'operatore
  • Decidere quali carichi di lavoro stanno bene all'edge e quali devono restare nel cloud
In questa pagina
  1. Quali sono le quattro ragioni per elaborare all’edge?
  2. Come si presenta l’edge in pratica?
  3. Qual è il modello software all’edge?
  4. Quali sono i compromessi?
  5. Come si decide cosa gira dove?
  6. Per continuare

La prima ondata dell’IoT era costruita su uno schema semplice: i sensori mandano tutto al cloud, e il cloud decide cosa fare. Funzionava per installazioni piccole e segnali lenti. Ha smesso di funzionare quando una linea di fabbrica ha voluto una decisione in pochi millisecondi, quando una telecamera ha iniziato a produrre più video di quanto il collegamento in uplink potesse trasportare, e quando a un ospedale è stato detto che i dati dei pazienti non potevano uscire dall’edificio.

L’edge computing è la risposta a questi limiti: eseguire l’elaborazione vicino alla sorgente dei dati invece che in un data center lontano. “Vicino” può voler dire sul microcontrollore del sensore stesso, su un gateway nello stesso edificio, oppure in un rack di server in un sito dell’operatore telefonico a pochi chilometri di distanza. Il filo conduttore è che il lavoro avviene prima che i dati attraversino la rete geografica, e spesso al posto di quell’attraversamento.

Questa guida spiega le forze che spingono l’elaborazione verso l’edge, come si presenta davvero un’installazione edge, i compromessi che introduce e come decidere quali carichi di lavoro vanno collocati lì.

Quali sono le quattro ragioni per elaborare all’edge?

Latenza

Un’andata e ritorno verso una regione cloud richiede decine di millisecondi nel migliore dei casi, e molto di più su collegamenti cellulari o satellitari. Un braccio robotico che deve fermarsi quando una persona entra nella sua cella, o un controller di rete elettrica che reagisce a una deviazione di frequenza, non possono aspettare. La latenza è la ragione più citata per l’edge computing, e l’unica che non si può risolvere pagando più cloud.

Banda

Una singola telecamera a risoluzione modesta produce in un giorno più dati di quanti ne produca in un anno una flotta di sensori di temperatura. Mandare tutto a monte è costoso su rete cellulare, impossibile su LPWAN e uno spreco ovunque, dato che la maggior parte dei fotogrammi non contiene nulla di interessante. Elaborare in loco e inviare solo eventi, sintesi o spezzoni riduce la banda di ordini di grandezza.

Resilienza

Un edificio in cui luci, serrature e climatizzazione smettono di funzionare quando cade il collegamento a internet è progettato male. I cicli di controllo locali continuano a girare durante le interruzioni; il cloud riceve l’arretrato quando il collegamento torna. Questo conta soprattutto negli ambienti industriali, dove il fermo ha un costo diretto, e nei siti remoti con connettività inaffidabile.

Privacy e sovranità

Alcuni dati non dovrebbero mai lasciare un sito: il video grezzo di un reparto ospedaliero, l’audio di una casa, le ricette di produzione di una fabbrica. Elaborarli in loco e trasmettere solo risultati derivati e anonimizzati soddisfa sia la normativa sia la fiducia del cliente. Le regole sulla sovranità dei dati in diverse giurisdizioni ne fanno un requisito vincolante, non una preferenza.

Come si presenta l’edge in pratica?

L’edge è uno spettro, non un luogo unico.

Il continuum edge dal dispositivo al cloud Tre stadi da sinistra a destra, dispositivo, edge e cloud, ciascuno con l'elenco dei carichi di lavoro che vi girano; sotto, la latenza cresce dai microsecondi ai secondi e i dati si riducono da flussi grezzi a eventi e riepiloghi. Dispositivo o sensore MCU, TinyML Campionamento, filtri Anelli di controllo Interblocchi di sicurezza Edge gateway o server on premise Aggregazione, buffer Traduzione protocolli Regole locali, inferenza Cloud regione centrale Addestramento modelli Analisi della flotta Archiviazione storica MQTT LATENZA da microsecondi a ms millisecondi decine di ms a secondi DATI INOLTRATI flussi grezzi filtrati, aggregati eventi e riepiloghi
Il continuum dell’edge dal dispositivo al cloud e cosa gira in ogni fase. Spostandosi da sinistra a destra, la latenza accettabile cresce dai microsecondi ai secondi e i dati inoltrati si riducono da stream grezzi a eventi e sintesi.

All’estremo più sottile c’è il dispositivo stesso. Un sensore di vibrazione che calcola uno spettro di frequenza sul proprio MCU e segnala qualcosa solo quando un picco si sposta sta facendo edge computing. Lo stesso vale per un modello TinyML che riconosce una parola chiave o classifica un gesto con poche centinaia di kilobyte di RAM. È l’edge AI nella sua forma più vincolata.

Un gradino più su c’è il gateway edge: un PC industriale, una scheda della classe del Raspberry Pi o un’appliance dedicata che aggrega decine o centinaia di dispositivi via Modbus, OPC UA, BLE o Zigbee, esegue la traduzione dei protocolli, regole locali, buffering e analisi, e parla con il cloud via MQTT. Gran parte di ciò che nell’IoT commerciale viene chiamato “l’edge” è questa scatola.

Più in alto ci sono i server e i cluster edge on premise: un rack in fabbrica che esegue container e macchine virtuali e ospita un historian locale, un servizio di inferenza per la visione artificiale o un gemello digitale (digital twin) della linea. All’estremo opposto c’è l’edge dell’operatore telefonico o regionale, dove operatori e provider cloud collocano capacità di calcolo nelle stazioni base e nei siti metropolitani, così che un dispositivo connesso in 5G ottenga una risposta abbastanza rapida per i casi d’uso interattivi e di controllo senza che i dati raggiungano una regione centrale. Il fog computing è un termine più datato per questa zona intermedia a più livelli.

Qual è il modello software all’edge?

Ciò che distingue l’edge computing moderno dai sistemi embedded del passato è che prende in prestito gli strumenti del cloud. I carichi di lavoro sono confezionati come container, distribuiti e aggiornati da remoto attraverso un piano di gestione dei dispositivi, configurati in modo dichiarativo e monitorati centralmente. Ogni piattaforma cloud offre un runtime edge che estende i propri servizi all’hardware locale: lo stesso instradamento dei messaggi, gli stessi motori di regole, lo stesso deployment dei modelli, ora in esecuzione su una scatola dentro l’edificio che si sincronizza con il cloud quando è connessa.

Il flusso di dati tipico è: acquisire in locale, filtrare e aggregare all’edge, agire in locale dove una regola o un modello lo consente, inoltrare a monte il risultato compresso per l’archiviazione a lungo termine, l’analisi sull’intera flotta e l’addestramento dei modelli. Il cloud conserva i ruoli in cui eccelle: scala, storico, addestramento, confronto tra siti e un unico posto in cui le persone possono guardare. L’analisi all’edge si occupa delle decisioni istante per istante.

Quali sono i compromessi?

L’edge non è gratis. L’hardware sul campo va comprato, alimentato, raffreddato, protetto fisicamente e sostituito quando si guasta, e quando succede nessuno gli sta accanto. Il software va costruito per connettività intermittente, risorse limitate e un insieme eterogeneo di schede e sistemi operativi. Una flotta di mille gateway edge è un migliaio di piccoli data center a cui applicare le patch.

Anche la sicurezza cambia forma. Una regione cloud sta dietro un perimetro ben difeso; una scatola edge può trovarsi in un armadio non chiuso a chiave. Secure boot, cifratura del disco, identità per dispositivo e rilevamento delle manomissioni passano da optional a necessari, e la superficie di attacco cresce con ogni servizio locale esposto sulla rete del sito.

La coerenza è il costo più sottile. Quando la logica gira in molti posti, le versioni divergono, le decisioni locali si disallineano, e fare debug di un problema significa ricostruire ciò che ogni nodo credeva in quel momento. Le buone piattaforme edge trattano configurazione e codice come artefatti versionati centralmente e fanno in modo che ogni nodo riporti cosa sta eseguendo.

Come si decide cosa gira dove?

Una regola pratica: colloca un carico di lavoro all’edge quando almeno una delle quattro forze si applica con decisione, e tienilo nel cloud altrimenti. Un rapporto mensile sull’energia non ha esigenze di latenza, usa poca banda, non ha requisiti di resilienza né problemi di privacy, quindi resta nel cloud. Un interblocco di sicurezza ha un vincolo di latenza rigido, quindi resta sul controller. Un controllo qualità basato su telecamera ha un problema di banda e probabilmente uno di privacy, quindi l’inferenza gira su un gateway e a monte vanno solo le immagini dei difetti.

Poi chiediti chi gestisce l’hardware. Se la scatola edge sarà in carico al team IT del cliente, tienila semplice, standard e gestibile da remoto. Se se ne occuperà il tuo team sul campo, puoi permetterti qualcosa di più capace, ma devi pianificare ricambi e visite in sito. E prototipa per prima cosa, non per ultima, la modalità di guasto della connettività, perché è lì che i sistemi edge si guadagnano o perdono la loro ragione d’essere.

Per continuare

Correzioni e aggiornamenti
  • 17 ottobre 2026: resa qualitativa la cifra non documentata della latenza di pochi millisecondi; fonti collegate

Come gestiamo le correzioni: politica editoriale (in inglese).

Argomenti: edge computing, gateway edge, latenza, architettura, edge AI

Diagramma