Nel mondo dell’automazione industriale la vera domanda non è “quale tecnologia è migliore tra Edge, Fog e Cloud?”, ma “dove è sensato eseguire quale parte dell’elaborazione?”. È qui che spesso si perde il focus: si confonde il luogo del calcolo con il valore del calcolo. In fabbrica, il valore nasce quando una misura diventa azione nel tempo utile e nella posizione giusta della catena OT–IT. Questo articolo chiarisce ruoli, limiti e complementarità di Edge, Fog e Cloud senza sconfinare in una guida alla progettazione.
Tre modelli, un’unica catena: ruoli senza ambiguità
Quali sono le differenze tra Edge, Fog e Cloud?
Edge: l’intelligenza sul bordo della macchina
Per Edge intendiamo l’elaborazione eseguita vicino alla sorgente del dato, su dispositivi di campo o su gateway locali robusti (IPC industriali, controller, smart camera). Qui contano latenza, jitter e determinismo: cicli di controllo, safety, sincronismi stretti, visione in linea. L’Edge decide “qui e ora” e, per definizione, non dipende dalla WAN per svolgere le funzioni critiche. È il regno dell’inferenza leggera, del filtraggio, dell’estrazione di feature e della logica di interblocco.
Non è il posto ideale per l’addestramento di modelli pesanti né per l’archiviazione storica di lungo periodo.
Fog: l’intermedio che coordina e normalizza
Il Fog è un livello intermedio on-premise che aggrega i flussi di più celle o linee, normalizza i dati, mantiene storici di breve-medio periodo, espone servizi condivisi (broker, storicizzatori, HMI/SCADA moderni, KPI di stabilimento). È “di stabilimento”, non “remoto”: vicino abbastanza da offrire risposte pronte per operatori e MES, potente abbastanza da eseguire analisi più complesse del singolo Edge, ma senza pretendere l’elasticità del Cloud.
Il Fog non sostituisce l’Edge, lo orchestra e lo contestualizza.
Cloud: l’ampiezza elastica e il lungo periodo
Il Cloud risiede in data center remoti e offre scalabilità, ampiezza di storage e servizi avanzati. Qui vivono data lake, modelli globali, correlazioni inter-stabilimento, digital twin estesi, BI e integrazioni enterprise. Il Cloud non chiude loop di controllo: fornisce visione e potenza quando il tempo di risposta non è critico al millisecondo.
È il livello giusto per consolidare, addestrare, pianificare, con regole di governance e sicurezza adeguate.
Il nodo cruciale: latenza, jitter e determinismo
Nell’automazione “real-time” non significa necessariamente “veloce”: significa prevedibile. Un ciclo di motion a 1 ms tollera pochissimo jitter; una rete geografica non garantisce né latenza massima né stabilità dell’andata-ritorno.
Da qui una regola netta: il controllo resta locale. Anche quando la connettività migliora (5G, WAN ottimizzate), la variabilità intrinseca di tratte e router rende il Cloud inadatto a funzioni che richiedono determinismo.
L’Edge vince per i loop stretti; il Fog supporta consolidamento e calcoli “near real-time” a livello di reparto; il Cloud assume il ruolo di analista e storico.
Ridurre il tema a una media di latenza è fuorviante: in fabbrica gli incidenti si annidano nelle code di distribuzione dei tempi di risposta, non nella media. Per questo gli ingegneri separano nettamente il dominio hard/soft real-time dal resto: non è dogma, è “fisica” dei sistemi.
“Gravità dei dati” e ciclo di vita dell’informazione
I dati “pesano” dove vengono usati più spesso. Le vibrazioni di un mandrino servono all’Edge per riconoscere un’anomalia prima che nascano problemi; servono al Fog per correlare asset uguali in linee diverse; servono al Cloud per cercare pattern su mesi e su più stabilimenti. Spostare tutto sempre in alto è inefficiente e costoso, oltre che inutile. La pipeline sana funziona così:
- Vicino alla sorgente si fa pulizia e arricchimento minimo: de-rumore, estrazione di feature, soglie locali, allarmi.
- A livello di stabilimento si normalizza e storicizza ciò che scorre veloce, producendo viste e KPI coerenti per operatori e responsabili.
- Nel Cloud si conserva, correla e addestra: qui ha senso l’ampiezza temporale e geografica.
Questo non è un “metodo” da seguire ciecamente: è la descrizione del perché le architetture funzionanti convergono spontaneamente verso questa distribuzione del calcolo.
Sicurezza: separare i domini senza creare muri inutili
Un errore diffuso è opporre IT e OT come mondi inconciliabili. In realtà, la sicurezza efficace si fonda su tre idee semplici:
- Zone e condotti: ciò che controlla macchine e persone resta in reti segmentate e pubblica informazioni verso l’alto, non espone servizi in ascolto al mondo.
- Identità forti e cifratura end-to-end: dispositivi e applicazioni sono autenticati e autorizzati. I dati viaggiano cifrati tanto tra Edge e Fog quanto tra Fog e Cloud.
- Minimo privilegio e tracciabilità: si accede a ciò che serve, per il tempo necessario, lasciando tracce chiare.
Edge, Fog e Cloud si distribuiscono anche le responsabilità: l’Edge applica safety e privacy by design (non manda immagini quando basta un esito), il Fog funge da cuscinetto tra OT e IT (filtra, anonimizza, controlla), il Cloud mantiene posture di protezione adeguate al perimetro più esposto (gestione identità, chiavi, segregazione tenant, posture management). Non servono muri ideologici, serve coerenza operativa.
Costi: dove si spende davvero (e dove si risparmia)
Dire “il Cloud costa meno” o “l’on-premise costa meno” ha poco senso fuori contesto. Il TCO dipende da:
- CapEx distribuito per l’Edge (gateway, IPC, smart device) e OpEx per tenerli aggiornati e monitorati.
- CapEx medio-alto del Fog (server, storage, ridondanze, condizionamento) e OpEx di gestione locale.
- OpEx variabile del Cloud (compute, storage, rete, egress), con rischio di sorprese se si carica tutto indiscriminatamente.
Il risparmio vero nasce quando si evitano i costi inutili: banda saturata da dati grezzi, fermi linea per dipendenza dalla WAN, duplicazioni di funzioni in dieci gateway diversi, data lake trasformati in data swamp.
La scelta del “punto giusto” di elaborazione è la leva che più incide sul TCO senza sacrificare performance e sicurezza.
Interoperabilità: perché “parlare la stessa lingua” fa la differenza
Se i livelli non condividono modelli e semantica, ogni integrazione diventa un progetto a sé. Nelle fabbriche che funzionano, la coerenza si ottiene con tre ingredienti:
- Modello informativo condiviso: nomi, gerarchie e metadati coerenti per asset, variabili e allarmi.
- Protocolli standard tra OT e IT: accesso strutturato alle variabili dai PLC e messaggistica leggera per diffondere eventi e misure.
- Time stamping affidabile: senza, le correlazioni perdono di significato.
Non è un vezzo architetturale: è ciò che evita la proliferazione di conversioni ad-hoc e incoerenze che, nel tempo, mangiano ogni beneficio promesso dall’IIoT.
Come lavorano insieme: il flusso senza forzature
L’immagine corretta non è “scegliere uno dei tre”, ma definire cosa ciascun livello deve fare per bene.
All’Edge si chiudono i loop e si produce informazione pronta all’uso operativo: decisioni sul singolo pezzo, sul singolo ciclo, sulla singola macchina. Il dato resta vicino perché lì genera valore immediato.
Al Fog si raccordano linee e reparti, trasformando flussi eterogenei in viste consistenti di stabilimento con storici di breve periodo, correlazioni, KPI, allarmi aggregati.
Al Cloud si scala in profondità e ampiezza: correlazioni multi-sito, analitiche su mesi, addestramento e distribuzione di versioni di modelli, integrazioni con ERP e sistemi aziendali.
Questa ripartizione non è un compromesso: è ciò che permette alla fabbrica di essere realmente reattiva sul campo e intelligente nel lungo periodo.
Malintesi frequenti (e perché non reggono alla prova dei fatti)
“Con il 5G faccio controllo in Cloud”
La riduzione della latenza media non risolve il jitter e la variabilità dell’intera catena di rete. Il controllo deterministico resta locale: il 5G è eccellente per mobilità, backup e telemetria ricca, non per spostare in Cloud il motion control.
“Edge significa spostare tutto sui gateway”
L’Edge sensato sposta solo ciò che serve per prendere decisioni tempestive. Inondare il bordo di funzioni non critiche crea complessità e costi senza ritorno. Il restante calcolo troverà posto meglio al Fog o al Cloud.
“Il Fog è un mini-Cloud”
Il Fog non replica il Cloud. Invece, accorcia il percorso tra dati di linea e decisioni di stabilimento. Se non aggrega, normalizza o fornisce servizi condivisi, probabilmente non serve. Se lo si usa per far “girare di tutto”, diventa soltanto un carico amministrativo.
“Metto tutto in Cloud, poi vedo”
È la strada più rapida verso costi di banda imprevisti, data swamp ingestibili e dipendenze pericolose. Il Cloud rende al massimo quando riceve dati già utili, non quando diventa un deposito di grezzi senza semantica.
Cosa cambia quando si passa dalla singola linea al multi-stabilimento
Su una cella si può “tamponare” con integrazioni ad-hoc; su dieci stabilimenti no. Crescendo, emergono tre esigenze:
- Coerenza semantica: un namespace unificato evita che ogni sito parli un dialetto diverso.
- Governance del ciclo applicativo: versioni dei modelli, roll-out, rollback, telemetria sulle prestazioni devono essere tracciabili.
- Separazione delle responsabilità: i team di stabilimento gestiscono ciò che è locale; un team centrale governa modelli, sicurezza, integrazioni enterprise.
In questa transizione, Fog e Cloud smettono di essere “tecnologie” e diventano sedi organizzative della conoscenza e delle decisioni.
Uno scenario realistico che tiene il focus
Immaginiamo uno stabilimento con tre linee di assemblaggio e controlli dimensionali in linea. Le smart camera all’Edge eseguono inferenza su profili e difetti superficiali; non inviano fotogrammi, ma esiti e feature numeriche. Il gateway di bordo estrae tempi ciclo e classifica gli scarti, propagando allarmi in meno di un ciclo macchina.
Un cluster Fog di reparto riceve i flussi dalle tre linee, li allinea temporalmente con lotti e ordini, produce KPI coerenti (OEE, first-pass yield) e tiene uno storico di settimana. L’operatore visualizza tendenze e heatmap per turno; il responsabile riceve avvisi quando una linea devia rispetto alle altre due con la stessa ricetta.
Nel Cloud si mantengono mesi di dati, si addestrano modelli globali di previsione degli scarti, si verificano correlazioni con fornitori e lotti materia prima, si distribuiscono versioni di modello firmate verso il Fog. Quando un modello migliorato è pronto, il Fog lo propaga agli Edge delle tre linee e misura l’impatto su scarti e tempo ciclo. La scelta “dove elaborare cosa” non è stata ideologica: è stata guidata da dove ciascun pezzo di informazione produce valore.
Conclusioni: “dove elaborare i dati?”
La risposta corretta non è un nome, ma una mappa:
- Vicino alla macchina (Edge) vanno le decisioni che devono accadere nel tempo del processo e non tollerano incertezze: controllo, safety, visione in ciclo, allarmi che devono fermare o deviare il flusso. Qui la priorità è determinismo e continuità locale.
- Nel perimetro dello stabilimento (Fog) vanno le informazioni che devono diventare conoscenza operativa per linee e reparti: aggregazioni, normalizzazioni, storici brevi, KPI, correlazioni intra-plant. Qui la priorità è coerenza e prontezza per chi gestisce la produzione.
- Nel dominio aziendale (Cloud) vanno le elaborazioni che beneficiano di ampiezza e scalabilità: storici lunghi, correlazioni multi-sito, addestramento e orchestrazione di modelli, BI e integrazioni enterprise. Qui la priorità è elasticità e visione.
Se il focus resta su chi decide cosa, quando e dove, l’architettura si assesta da sola: l’Edge non viene sovraccaricato, il Fog non diventa un data center in miniatura, il Cloud non è un pozzo senza fondo. Il risultato per il lettore, che lavora in automazione o la governa, è la capacità di riconoscere dove l’elaborazione produce valore e dove, invece, è solo una trasferta inutile del dato.
In definitiva, Edge, Fog e Cloud non sono tre “scelte” in competizione, ma tre posizioni della stessa catena di senso che va dalla misura all’azione: il calcolo si mette dove la decisione deve nascere. Tutto il resto, compresi gli slogan tecnologici, è rumore.
