Con l’aiuto di Micaela Caserza Magro, Direttore Tecnico del GFCC (Genoa Fieldbus Competence Center) apriamo un dibattito sull’impatto che l’Intelligenza Artificiale può avere nell’automazione industriale, in particolare per superare le difficoltà di dialogo tra i vari protocolli di comunicazione (PROFINET, EtherCAT, EtherNet/IP, POWERLINK, Modbus TCP…).
Nel mondo dell’automazione industriale esistono battaglie apparentemente senza fine. Una di queste è certamente la “guerra dei bus”: PROFINET contro EtherCAT, EtherNet/IP contro POWERLINK, Modbus TCP che spunta sempre ovunque… E le macchine realizzate con dispositivi di automazione di produttori diversi continuano a parlare lingue diverse, complicando la vita, non poco, agli end user.
Naturalmente esistono i gateway con convertitori di protocollo, capaci di connettere, ad esempio, dispositivi Profibus a PLC EtherCAT, ma è lecito ipotizzare (o sognare) uno scenario in cui l’osannata e apparentemente onnipotente IA possa porre fine, definitivamente, a questa guerra?!?
In questo articolo poniamo alcune domande, volutamente ingenue e provocatorie a Michaela Caserza Magro, Direttore Tecnico del GFCC (Genoa Fieldbus Competence Center) allo scopo di aprire un dibattito su questo tema.
Se bus diversi hanno connettori fisici diversi, servirà comunque un gateway. Gateway sul quale potrà risiedere anche il software di traduzione del protocollo, come accade già ora. Che vantaggio porterebbe l’IA?
Michaela Caserza Magro: “Ovviamente, se il livello fisico è diverso, un convertitore sarà sempre necessario. L’IA può però cambiare radicalmente ciò che sta dentro il gateway. Oggi questi dispositivi sono, in larga parte, traduttori dei livelli di collegamento dati e applicazione, che effettuano la traduzione applicando regole fisse, preimpostate dall’utente. L’IA potrebbe trasformarli da semplici convertitori a interpreti intelligenti, in grado di:
• riconoscere automaticamente il protocollo osservando il traffico, e guidare quindi verso una configurazione automatica del dispositivo;
• integrare funzionalità di diagnostica sul traffico che lo attraversa;
• rilevare anomalie nei telegrammi, nelle sequenze o nei tempi;
• agire come analizzatore di protocollo interno, capace di “spiegare” cosa sta succedendo sul bus;
• apprendere la struttura dei dati senza intervento dell’operatore.
Quindi sì, l’hardware rimarrà, perché un convertitore di livello fisico è essenziale, ma il cervello al suo interno può diventare molto più evoluto”
Un gateway “intelligente” di questo tipo sarebbe completamente Plug’n’Play…
Michaela Caserza Magro: “Sì, è perfettamente plausibile immaginare un sistema capace di riconoscere la struttura dei dati, senza che l’operatore debba più definire offset, variabili e tabelle interminabili. Questo perché, per quanto eterogenei, i protocolli industriali non sono un far west binario: usano formati ricorrenti, cicli di scambio ripetitivi, campi ricorrenti, e sequenze che possono essere analizzate e comprese. Un modello di IA ben progettato potrebbe osservare il traffico, distinguere ciò che è ciclico da ciò che è evento, individuare blocchi logici coerenti, inferire tipi di dati e riconoscere comportamenti tipici dello specifico protocollo.
Quando poi si lavora con protocolli standardizzati, la situazione diventa ancora più favorevole. Le specifiche sono pubbliche e documentate, per cui un sistema intelligente non dovrebbe “partire da zero”, ma conoscerebbe a priori il formato generale dei frame, le regole di comportamento e le logiche di scambio. E potrebbe interpretare ciò che il dispositivo sta realmente facendo sul campo, anche quando la sua implementazione è – come spesso accade – un po’ “creativa”.
Questa stessa capacità di comprendere profondamente il traffico diventa un vantaggio anche in chiave cyber: un sistema che conosce contenuti, strutture e tempi della comunicazione, è anche in grado di accorgersi di eventuali anomalie: ritardi insoliti, sequenze inconsuete, pacchetti fuori posto o strani comportamenti emergerebbero subito come deviazioni dai pattern attesi. Non parliamo di un firewall o di un IDS nel senso classico del termine, ma di un osservatore estremamente sensibile, capace di cogliere cambiamenti sottili che, spesso, sono i primi segnali di problemi tecnici o attacchi”.
Qualora si operasse in uno scenario di connettori comuni – stesso strato fisico – è possibile ipotizzare un utilizzo dell’IA senza gateway per far comunicare tra loro dispositivi su bus industriali diversi?
Michaela Caserza Magro: “Qualora i dispositivi condividessero lo stesso connettore, l’aspetto fisico smetterebbe di essere un problema. In linea teorica, dunque, sì: potremmo pensare all’IA che fa da traduttore. Potrebbe effettuare la conversione dei dati “on the fly” e integrare diagnostica e analisi comportamentale tipiche di un protocol analyzer evoluto.
Non è però possibile trascurare un aspetto fondamentale: il determinismo! Ed è proprio questo aspetto a riportarci un po’ con i piedi per terra.
PROFINET, EtherNet/IP ed EtherCAT, ad esempio, non sono solo linguaggi diversi. Sono anche filosofie temporali diverse, con requisiti in termini di:
• cicli di scambio in millisecondi;
• jitter ridottissimi;
• comportamenti real-time;
• sincronizzazione;
• priorità e scheduling dettati dallo stack del protocollo di comunicazione.
Un’IA può comprendere la struttura e la semantica dei dati, ma non può garantire, da sola, il determinismo richiesto da applicazioni motion o controllo sincrono, perché la sua logica implica tempi di inferenza variabili e comportamenti statistici, non certi.
Per tutto ciò che richiede tempi strettissimi, jitter minimo e cicli garantiti, continueranno dunque a essere necessari dell’hardware ottimizzato, stack certificati, processi deterministici nativi.
L’IA potrà affiancare questa struttura, ma non sostituirla”.
Qual è lo strato fisico/connettore comune più promettente, con il quale è ipotizzabile una traduzione esclusivamente software?
Michaela Caserza Magro: “Ethernet standard IEEE 802.3, purché senza alcuna sincronizzazione fisica dedicata e nessun meccanismo a latenza rigidamente deterministica (che richiederebbe hardware specializzato).
Esempi di protocolli convertibili via software sono: PROFINET RT (non IRT), EtherCAT, EtherNet/IP, Modbus TCP, POWERLINK (versione non TSN), OPC UA / OPC UA Pub/Sub (su Ethernet standard), TCP/IP industriali proprietari e, in generale, qualsiasi protocollo applicativo che usi Ethernet come semplice mezzo di trasporto. Tutti questi protocolli condividono lo stesso strato fisico e lasciano l’onere del determinismo (quando richiesto) agli strati superiori, non al livello elettrico o MAC.
Ancora a proposito di strato fisico, il wireless potrebbe semplificare le cose?
Michaela Caserza Magro: “Risposta secca: no! Anche nel mondo wireless convivono più strati fisici completamente diversi, con caratteristiche, modulazioni e prestazioni non confrontabili tra loro.
Abbiamo ad esempio il Wi-Fi (IEEE 802.11), caratterizzato da banda larga, latenza variabile, throughput elevato, e per questo ottimo per traffico IP non deterministico. Abbiamo poi il Bluetooth / BLE, caratterizzato da bassissima potenza, throughput ridotto, latenza non garantita, ottimo per sensori o piccoli payload. E ancora abbiamo LoRa / LoRaWAN, di lunghissima portata ma con bassissimo bitrate, adatto solo a telemetria sporadica, o WirelessHART / ISA100, progettato per la sensoristica.
Non esiste un unico “wireless industriale” standardizzato dal punto di vista fisico, esattamente come non esiste un unico bus cablato.
Il wireless, dunque, non semplifica la parte fisica e introduce, anzi, nuove variabili: bande diverse, portate diverse, modulazioni diverse, affidabilità e latenza molto differenti, canali condivisi con traffico non industriale.
Da un punto di vista prestazionale, e oltre al già citato determinismo, soluzioni hardware dedicate come quelle di HMS – Anybus, Hilscher, ODOT Automation, cosa offrirebbero in più rispetto a una soluzione puramente software?
Michaela Caserza Magro: “Oltre al determinismo temporale, un hardware dedicato offrirebbe – o potrebbe offrire – maggiori prestazioni (tempi di ciclo nell’ordine delle decine di microsecondi, jitter prossimi allo zero), stack protocollari certificati e affidabilità 24/7/365.
Tutti elementi di indubbia importanza, ma il più grosso limite di una soluzione software basata su IA resta il non-determinismo. In pratica, una soluzione puramente software / IA è ipotizzabile solo per protocolli non real-time o soft real-time, mentre per protocolli hard real-time è indispensabile il solito “ferro” ottimizzato.
Su quale dispositivo dovrebbe risiedere questa fantomatica IA?
Michaela Caserza Magro: “Domanda lecita: dove la mettiamo, tutta questa intelligenza, senza creare colli di bottiglia o aggiungere latenza? L’IA dovrebbe risiedere abbastanza vicino al traffico da poterlo osservare senza ritardi, in un “cervello” abbastanza potente da poterlo analizzare, e dovrebbe essere abbastanza integrata da poter intervenire. Il luogo più naturale è il gateway. C’è comunque una seconda opzione, altrettanto sensata in funzione delle architetture: un dispositivo edge industriale, che offre più potenza di calcolo rispetto al gateway e può quindi ospitare modelli di IA più complessi senza introdurre latenza critica nel percorso dati. In questo secondo caso, il gateway potrebbe continuare a occuparsi del determinismo mentre, l’IA sull’edge si occuperebbe di elaborare, apprendere, diagnosticare e suggerire configurazioni o adattamenti”.
Sembra si stia delineando uno scenario preferenziale: l’IA non sostituirà l’hardware, ma si integrerà al suo interno…
Michaela Caserza Magro: “In effetti, gateway capaci di collegare praticamente qualunque bus con qualunque altro esistono già da anni, e funzionano benissimo. Il loro maggior limite è la rigidità, ed è proprio qui che l’IA potrebbe rivelarsi più utile.
Un gateway potenziato con IA potrebbe configurare i flussi I/O senza che un operatore debba interpretare manuali o analizzare telemetrie, e soprattutto potrebbe adattarsi con facilità a dispositivi o comportamenti “non perfettamente canonici” che, come abbiamo già ricordato, nella pratica sono tutt’altro che rari.
I vantaggi si vedrebbero soprattutto in fase di integrazione: il tempo di avviamento si ridurrebbe, si minimizzerebbero gli errori di configurazione, e il sistema diventerebbe più flessibile ad eventuali cambi a livello di dispositivo, firmware o set di variabili.
In altri termini: meno lavoro umano, meno configurazioni rigide e una flessibilità molto maggiore nel mettere in comunicazione pezzi eterogenei di un impianto, anche quando parlano protocolli molto diversi tra loro. Con un interprete intelligente al centro, collegare dispositivi disparati potrebbe diventare quasi banale. Senza scordare già citati benefici in ambito analisi, diagnostica, cyber security”.
La tanto agognata standardizzazione, vedi OPC UA FX, o più in generale OPC UA, serviranno ancora?
Michaela Caserza Magro: “La standardizzazione resta, a buona logica, la via preferenziale, dato che in uno scenario completamente standardizzato l’interoperabilità sarebbe qualcosa di naturale e scontato, e non – com’è oggi – una conquista tecnologica”.
Con buona pace di traduttori, hardware o software, intelligenti o meno…
Michaela Caserza Magro: “Da questo punto di vista, OPC UA ha un ruolo essenziale, perché non è semplicemente “un protocollo in più”: rappresenta un modello di interoperabilità completo, pensato per far parlare tra loro sistemi industriali eterogenei, ma in modo nativo, strutturato e già integrato nell’hardware di controllo.
È un dettaglio che spesso passa in secondo piano, ma che è fondamentale: OPC UA è ormai integrato direttamente nei PLC e nei controllori industriali; quindi, non si tratta di “aggiungere” un protocollo, bensì di utilizzare qualcosa che è già dentro al dispositivo, certificato dal costruttore e supportato lungo l’intero ciclo di vita del prodotto”.
Concludendo: l’IA metterà davvero fine alla guerra dei bus? Se si, in quanto tempo?
Michaela Caserza Magro: “No, l’IA non basterà. I bus industriali continueranno a esistere, perché rispondono a esigenze diverse, hanno storie diverse. E i protocolli hard real-time continueranno a pretendere l’hardware dedicato che li rende deterministici.
Quello che l’IA potrà fare – e che farà entro pochi anni – sarà rendere queste differenze meno complesse da gestire. La configurazione sarà più semplice, la traduzione più automatica, la diagnostica più intelligente. In altre parole, la guerra non finirà, ma smetterà di farci perdere tempo.
Ecco alcune milestone verosimili: entro 5 anni vedremo l’IA entrare nei gateway/edge; entro 10 anni, la traduzione tra protocolli potrà essere perlopiù automatizzata; entro 15 anni, l’integrazione di dispositivi eterogenei potrebbe essere così naturale da farci chiedere perché per decenni ci siamo complicati la vita”.
di Nicoletta Ghironi
