La discussione sull’[edge computing” negli ambienti aziendali tende a ruotare attorno ai costi: elaborazione locale per ridurre i costi del cloud, filtraggio dei dati all’edge in modo da non trasmettere ciò che non ha bisogno di essere trasmesso. Nel contesto industriale, questa inquadratura è sbagliata. L’edge computing in una fabbrica non è una decisione ottimizzata in termini di costi con una valida alternativa nel cloud. Per un insieme significativo di applicazioni industriali, l’architettura cloud centralizzata semplicemente non soddisfa i requisiti operativi: troppa latenza per il controllo dei processi, volume di dati troppo elevato per la trasmissione continua, dipendenza dalla rete inaccettabile per le operazioni critiche. La domanda non è se sia più economico l’edge o il cloud. La domanda è quali applicazioni richiedono l’elaborazione locale come requisito funzionale non negoziabile e come scalare l’infrastruttura edge per supportarle.
Cosa significa latenza millisecondo sulla linea di produzione
I sistemi di controllo dei processi industriali (PLC, DCS, sistemi di visione) operano su cicli temporali che vanno dai microsecondi per il controllo del movimento alle decine di millisecondi per il controllo dei processi chimici. La latenza di andata e ritorno verso un data center nella stessa città, in condizioni di rete favorevoli, è generalmente compresa tra 5 e 20 millisecondi. In condizioni di rete con jitter, o con data center geograficamente distanti, può facilmente superare i 50 millisecondi.
Per un sistema di visione artificiale su una linea di ispezione che deve scartare le parti difettose prima che queste passino alla stazione successiva, la latenza decisionale deve essere compatibile con la velocità della linea. Un ciclo di linea di 200 millisecondi per parte fornisce una finestra di tempo per l'acquisizione della fotocamera, l'elaborazione del modello e l'invio del segnale di rifiuto all'attuatore. Sottraendo il tempo di acquisizione dell'immagine, il tempo di attivazione dell'attuatore e il margine di sicurezza, la finestra di elaborazione può essere inferiore a 50 millisecondi. Nessuna architettura di cloud pubblico offre questa latenza in modo affidabile e coerente.
Lo stesso ragionamento si applica ai sistemi di controllo robot collaborativi, ai sistemi di arresto di emergenza basati sull’analisi dei sensori e a qualsiasi applicazione in cui l’azione fisica dipende dalla decisione dell’algoritmo in tempo reale. In questi casi, l’edge computing non è preferibile: è obbligatorio. Il costo di una decisione con latenza eccessiva non è una dashboard obsoleta. Si tratta di una parte difettosa che ha superato l'ispezione, di un'apparecchiatura che non si è fermata al momento giusto o di un'operazione interrotta dalla rete.
Il problema del volume dei dati risolto dalla matematica
Una telecamera per ispezione industriale ad alta risoluzione a 30 fotogrammi al secondo genera circa da 1 a 3 gigabyte di dati all'ora per telecamera, a seconda della compressione e della risoluzione. Un impianto con cinquanta telecamere di ispezione genera tra 50 e 150 gigabyte all'ora. In un mese di attività su due turni, si tratta di una quantità di video compresa tra 24 e 72 terabyte. La trasmissione continua di questo volume al cloud non è una questione di larghezza di banda: ci sono operazioni che hanno la larghezza di banda disponibile per questo. È una questione di costi di archiviazione ed elaborazione nel cloud che diventano rapidamente ingiustificabili quando la stragrande maggioranza delle immagini catturate sono costituite da parti impeccabili e non necessitano di analisi.
Il modello che funziona è l’inferenza al limite: il modello di visione artificiale funziona su hardware locale, elabora ogni fotogramma e produce solo il risultato – approvato o rifiutato, con un certo grado di sicurezza – invece di trasmettere l’immagine completa. Le immagini delle parti rifiutate o con scarsa affidabilità possono essere inviate al cloud per la revisione e la riqualificazione da parte di personale. Il risultato è che la trasmissione al cloud passa da gigabyte all’ora a megabyte all’ora, e i dati che raggiungono il cloud sono quelli che hanno valore per l’analisi e il miglioramento del modello.
I sensori di vibrazioni ad alta frequenza per l'analisi delle condizioni delle apparecchiature hanno un profilo simile. Il campionamento a 10kHz – necessario per rilevare alcune categorie di difetti meccanici – genera volumi di dati che non giustificano la trasmissione continua. Ciò che ha senso è calcolare i parametri rilevanti – spettro di frequenza, ampiezza in bande specifiche, indici di condizione – localmente e trasmettere solo questi indicatori calcolati, con le serie temporali complete disponibili sull’archiviazione locale per un’analisi più approfondita quando necessario.
Architettura edge industriale: cosa costituisce lo stack
L'ambiente edge industriale non è un server rack Linux. Si tratta di una gerarchia di capacità di elaborazione distribuita tra l'apparecchiatura e il cloud, con diversi livelli di elaborazione che si verificano a ogni livello.
Al livello più vicino delle apparecchiature ci sono i gateway di protocollo, ovvero dispositivi che traducono protocolli industriali come Modbus, Profibus, EtherNet/IP e OPC-UA in formati utilizzabili dal resto dello stack. Questi gateway sono spesso hardware specializzato - Moxa, Advantech, Siemens SIMATIC - con firmware progettato per l'ambiente industriale: temperatura operativa estesa, assenza di ventole, ciclo di vita dei componenti di dieci anni. Il costo per unità è superiore a quello dell'hardware IT equivalente nelle specifiche di elaborazione, ma il requisito di affidabilità in un ambiente industriale giustifica la differenza.
Uno strato sopra ci sono i server edge: hardware in grado di eseguire qualsiasi cosa, dai PC industriali rinforzati ai rack GPU compatti per dedurre modelli di visione artificiale. Qui la scelta dell'hardware dipende dal carico computazionale. Per l'elaborazione delle serie temporali e il calcolo degli indicatori di manutenzione è sufficiente un processore a basso consumo. Per l'inferenza del modello di visione artificiale ad alta frequenza, le GPU industriali come Nvidia Jetson AGX o la linea A2000 di Nvidia compaiono nelle specifiche di progettazione.
A livello di software, la questione dell’orchestrazione (come distribuire, aggiornare e monitorare le applicazioni in esecuzione su dozzine o centinaia di nodi edge) è dove la maggior parte delle architetture edge industriali presenta il divario maggiore. Kubernetes funziona, ma la sua complessità operativa negli ambienti OT può essere eccessiva per i team senza una profonda esperienza nell'orchestrazione dei container. Piattaforme come Azure IoT Edge, AWS Greengrass e Balena offrono astrazioni più semplici e integrazione nativa con i servizi cloud corrispondenti, ma creano vincoli al fornitore che devono essere valutati nel contesto del progetto.
Sicurezza fisica e logica in un ambiente di fabbrica
L’edge computing industriale aggiunge una superficie di attacco agli ambienti progettati per funzionare in isolamento. Un edge server in fabbrica è un hardware fisico accessibile, connesso alla rete OT e spesso gestito da personale IT che non ha accesso fisico di routine allo spazio. Ciò crea rischi che il modello di sicurezza del data center centralizzato non affronta.
La sicurezza fisica inizia con la recinzione: gli scaffali industriali con serrature e monitoraggio dell’apertura non sono una paranoia, sono una pratica standard per qualsiasi attrezzatura informatica in un’area ad accesso non controllato di uno stabilimento. La gestione dell'accesso fisico all'hardware include il controllo di chi può connettere l'USB, rimuovere il disco o ripristinare l'hardware.
La sicurezza logica in un ambiente edge richiede che ogni nodo edge sia autenticato per la comunicazione con il cloud: autenticazione basata su certificati, non credenziali statiche condivise. Gli aggiornamenti firmware e software devono essere firmati digitalmente per impedire l'installazione di software dannoso. Il modello di segmentazione della rete dovrebbe limitare ciò a cui il server periferico può accedere oltre ai sistemi di cui ha bisogno per funzionare: non c'è motivo per cui un server di inferenza di visione artificiale abbia accesso al sistema HR dell'azienda.
Come dimensionare e budgetare l'infrastruttura edge
L’errore più comune nel budget dell’edge industriale è quello di calcolare solo il costo dell’hardware del server e ignorare tutto ciò che lo circonda: l’infrastruttura di rete OT che deve essere adattata per supportare il nuovo traffico, il cablaggio strutturato che deve essere installato in ambienti che non sono stati progettati per questo, il sistema di alimentazione ininterrotto per garantire che il nodo periferico non perda dati in caso di interruzione di corrente e il costo di ingegneria per la messa in servizio e l’integrazione con i sistemi esistenti.
Una regola pratica utilizzata nei progetti edge industriali è quella di preventivare il costo totale di proprietà dell'hardware edge pari a due o tre volte il costo dell'hardware stesso nei primi due anni. La differenza riguarda l'installazione, l'integrazione, la formazione del team operativo e il ciclo di adattamento iniziale richiesto da qualsiasi nuova implementazione. Dal terzo anno in poi i costi operativi si stabilizzano intorno al 15-25% del costo annuo dell'hardware, principalmente nella manutenzione del software e nella sostituzione preventiva di componenti con un ciclo di vita limitato come batterie e dischi UPS.
Leggi anche
- Edge computing: perché l'informatica lascia il cloud e si avvicina ai dati
- Edge computing: perché l'elaborazione distribuita ridefinirà la tua architettura
- Architettura dell'Edge Computing: strategie per l'elaborazione distribuita
- Deduzione al limite: quando eseguire l'intelligenza artificiale sul dispositivo ha più senso che nel cloud
- Città come laboratorio: quando lo spazio urbano diventa piattaforma di sperimentazione
- Calcolo autonomo: quando il sistema si corregge prima che si noti l'errore