L'IoT industriale nella pratica: cosa distingue i progetti pilota da quelli su vasta scala

Esiste uno schema ripetuto nei progetti IoT industriali che qualsiasi ingegnere dell’automazione dopo qualche anno di carriera riconosce: il progetto pilota funziona. I dieci sensori trasmettono, il dashboard mostra i dati in tempo reale, il direttore dell'impianto si emoziona e autorizza l'ampliamento. Sei mesi dopo, con duecento sensori installati, il sistema inizia a perdere dati, la latenza aumenta, gli avvisi non arrivano più al momento giusto e il team IT litiga con quello di automazione su chi è responsabile di quale parte dell’infrastruttura. Stalli di espansione. Il progetto resta nel limbo. L’investimento non fornisce il rendimento previsto. Ciò che differenzia le aziende in grado di scalare l’IoT industriale da quelle bloccate nei progetti pilota non è la tecnologia: è una decisione architetturale presa prima di installare il primo sensore.

Il problema di rete che il pilota non rivela

Gli ambienti industriali sono stati progettati per funzionare con reti OT (Operational Technology), fisicamente e logicamente separate dalle reti IT aziendali. Questa separazione ha una giustificazione storica: i sistemi SCADA, i PLC e le reti di campo come Profibus e Modbus sono stati progettati per l'affidabilità deterministica in ambienti con interferenze elettromagnetiche, non per la connettività IP con il mondo esterno. Il risultato è che la maggior parte degli stabilimenti industriali dispone di una rete OT che funziona da anni senza problemi, e di una rete IT aziendale che collega computer, stampanti e sistemi gestionali. L’IoT industriale richiede che i due dialoghino ed è proprio in questo processo che la maggior parte dei progetti iniziano a incontrare problemi.

La convergenza OT/IT non è un cavo e un interruttore. Si tratta di un progetto di sicurezza, governance e architettura che implica decisioni su quali dati possono attraversare il perimetro tra i due ambienti, con quale frequenza, con quale protocollo di traduzione e con quale sistema di autenticazione. In un progetto pilota con dieci sensori, è possibile creare una soluzione alternativa: un gateway che prende i dati dei sensori e li pubblica sulla rete IT senza toccare la rete OT. Su larga scala, questa soluzione alternativa crea singoli punti di errore, problemi di latenza e superfici di attacco che né i team OT né quelli IT desiderano gestire.

La decisione giusta avviene prima del progetto pilota: definire l’architettura di rete completa per la scala target, compreso il modello di segmentazione, i protocolli di comunicazione tra strati e il modello di governance di chi gestisce cosa. La maggior parte delle aziende prende questa decisione dopo il progetto pilota, quando c’è già pressione sulle scadenze e resistenza interna su entrambi i lati della divisione OT/IT.

Volume dei dati: cosa elaborare, dove e quando

Un sensore di vibrazione dei cuscinetti ad alta frequenza può generare tra 5 e 50 megabyte di dati all'ora. Una telecamera per la visione artificiale per il controllo della qualità può generare gigabyte all’ora. In un progetto con centinaia di punti di monitoraggio, la matematica della trasmissione dei dati al cloud centrale diventa rapidamente irrealizzabile, sia in termini di costo della larghezza di banda che in termini di latenza per le applicazioni che richiedono una risposta in tempo reale.

La decisione su dove elaborare ciò che deve essere fatto prima di ridimensionare l'infrastruttura. Il modello generale che funziona su larga scala distribuisce l'elaborazione su tre livelli: sul dispositivo stesso o su un gateway locale, avviene il filtraggio e la pre-elaborazione che elimina i dati ridondanti e rileva gli eventi che richiedono un'azione immediata. A livello edge (server in fabbrica o in un magazzino tecnico) avviene l'elaborazione di analisi più complessa che non richiede l'invio al cloud, compresi i modelli di rilevamento delle anomalie che richiedono una bassa latenza. Il cloud centrale ospita la cronologia, l'addestramento dei modelli, la correlazione tra più stabilimenti e i cruscotti esecutivi.

Questa divisione sembra ovvia se descritta in questo modo, ma la maggior parte dei progetti pilota sono progettati per inviare tutto nel cloud perché è il modo più semplice per dimostrare il concetto. Quando il progetto viene ridimensionato e il costo della trasmissione dei dati appare sulla fattura del cloud, o quando la latenza della risposta non soddisfa i requisiti operativi, la riprogettazione dell’architettura costerebbe il doppio rispetto a quanto sarebbe stata effettuata dall’inizio.

Gestione dispositivi: il problema che cresce con la piazza

Installare un centinaio di sensori è un progetto di ingegneria. Gestire un centinaio di sensori in tre anni è un'operazione. La differenza tra i due risiede in una serie di sfide che non compaiono nella demo: aggiornare il firmware sui dispositivi sul campo senza interrompere il funzionamento, sostituire i dispositivi difettosi senza perdere il contesto di configurazione, fornire nuovi dispositivi in un tempo accettabile e monitorare lo stato del parco dispositivi per rilevare guasti prima che i dati vadano persi.

I progetti che raggiungono migliaia di dispositivi senza una piattaforma di gestione adeguata scoprono che i costi operativi di manutenzione della flotta superano i benefici delle analisi che il progetto avrebbe dovuto fornire. In un impianto con mille sensori, un tasso di difettosità del 5% all’anno – conservativo per l’hardware in un ambiente industriale – significa cinquanta sostituzioni all’anno. Se il processo di sostituzione prevede la configurazione manuale di ciascun dispositivo, si tratta di tempo da parte del tecnico che non rientrava nel budget.

Le piattaforme di gestione dei dispositivi IoT (AWS IoT Device Management, Azure IoT Hub o soluzioni come Balena per ambienti Linux integrati) esistono esattamente per risolvere questo problema. Ma la decisione di adottarli fin dalla fase pilota ha un costo di implementazione che raramente è incluso nel budget della prova di concetto. Il risultato è che il progetto pilota utilizza la configurazione manuale e script fatti in casa e, quando il progetto si espande, la migrazione su una piattaforma adatta deve avvenire con dispositivi già sul campo, il che è sostanzialmente più complesso rispetto all'implementazione della piattaforma da zero.

Sicurezza negli ambienti OT: un problema diverso rispetto all'IT aziendale

La sicurezza delle reti OT è stata storicamente risolta con l’isolamento fisico: ciò a cui non è possibile accedere dall’esterno non può essere attaccato dall’esterno. L’IoT industriale collega questo ambiente al mondo esterno e i dispositivi aggiunti all’ambiente OT raramente sono stati progettati con lo stesso rigore di sicurezza delle apparecchiature industriali già esistenti. Un sensore di temperatura con firmware obsoleto, accessibile tramite IP, è un vettore di attacco che dieci anni fa non esisteva.

Le implicazioni sono concrete. L’attacco a Colonial Pipeline nel 2021 non ha compromesso direttamente i sistemi OT, ma l’azienda ha spento preventivamente i sistemi a causa della mancanza di visibilità e fiducia nell’integrità della rete. In Brasile, le centrali elettriche, i sistemi idrici e la distribuzione energetica hanno un’esposizione crescente poiché collegano più dispositivi all’ambiente industriale. Il costo di un incidente di sicurezza OT non è rappresentato solo dai tempi di inattività della produzione, ma anche dalla perdita di fiducia nell’integrità dei dati storici, che invalida tutta l’analisi prodotta dal progetto IIoT.

Il modello di sicurezza per l’IoT industriale deve includere la segmentazione della rete che limiti il raggio di impatto di un dispositivo compromesso, l’autenticazione del dispositivo tramite certificato o token che impedisca a un dispositivo non autorizzato di accedere alla rete e il monitoraggio del traffico anomalo che rilevi il comportamento non standard del dispositivo. In linea di principio, questo non è diverso dal modello di sicurezza IT aziendale: è diverso nell’esecuzione, perché i protocolli OT, la latenza accettabile per la scansione di sicurezza e gli strumenti disponibili sono specifici dell’ambiente industriale.

Il modello architettonico scalabile: cosa fanno le aziende di successo in modo diverso

Le aziende che scalano con successo l’IoT industriale condividono una caratteristica: prendono la decisione completa sull’architettura prima di installare il primo sensore e trattano il progetto pilota come una convalida dell’architettura, non come una dimostrazione di capacità tecnologica. Il progetto pilota non dovrà dimostrare che i sensori funzionino, questo è già noto. Il progetto pilota consiste nel verificare che l'architettura di rete, l'elaborazione, la gestione dei dispositivi e la sicurezza scelte gestiranno la scala target.

L'altro elemento comune è la decisione esplicita di chi gestisce ciascun livello del sistema. Negli ambienti industriali, il confine tra IT e OT è un confine culturale oltre che tecnico. I progetti che non definiscono esplicitamente quale team gestisce cosa – e che non creano un modello di escalation per i conflitti tra i due team – scoprono su larga scala che il problema non è la tecnologia, ma la governance. Chi è responsabile del sensore di vibrazione? Da chi è gestito l'edge gateway? Quando i dati non arrivano alla dashboard, qual è il processo di diagnosi e a che punto passa il ticket da un team all'altro?