MQTT, OPC UA o comunicazione diretta con il PLC: come scegliere il modello di scambio dati più adatto in un progetto industriale?

La scelta tra MQTT, OPC UA e la comunicazione diretta con il PLC non è più una decisione puramente tecnica. Oggi incide contemporaneamente sull’architettura del sistema, sui costi di avviamento, sulla ripartizione delle responsabilità tra i fornitori e sui tempi di collaudo. In pratica, non si tratta di stabilire quale protocollo sia “migliore”, ma quale modello di scambio dati risponda alla reale funzione del progetto: se serve una semplice integrazione dei segnali di una singola macchina, la supervisione di una linea, lo scambio dati con sistemi di livello superiore oppure un controllo distribuito destinato a evolversi negli anni. Un errore in questa fase di solito non emerge subito in laboratorio, ma più avanti: durante la messa in servizio, in fase di validazione, al cambio del fornitore del PLC oppure quando il reparto manutenzione cerca di ricostruire la causa di un’anomalia e si scopre che i dati sono incoerenti, in ritardo o privi di contesto.

Dal punto di vista del progetto, l’aspetto più rischioso è adottare un modello di comunicazione “per abitudine”. La comunicazione diretta con il PLC può sembrare allettante, perché consente un accesso rapido ai registri e spesso abbrevia la prima fase dell’implementazione. Tuttavia, questa scelta tende a legare l’applicazione di livello superiore a uno specifico controllore, all’indirizzamento della memoria e al metodo di implementazione del costruttore. Quando cambia la versione del programma, si migra l’hardware o si amplia la linea, il costo riemerge sotto forma di modifiche, test di regressione e controversie sulla responsabilità dei dati di processo. MQTT, invece, funziona bene dove conta una distribuzione leggera delle informazioni e la separazione tra mittenti e destinatari, ma richiede una definizione consapevole della semantica dei dati, della qualità di consegna e delle regole di gestione del broker. OPC UA viene spesso scelto come compromesso tra interoperabilità e struttura dell’informazione, ma neppure questo risolve i problemi da solo: se il modello dati è sbagliato, una comunicazione formalmente corretta continua comunque a produrre decisioni operative errate.

Il criterio pratico per decidere è semplice, anche se spesso trascurato: occorre prima stabilire se il relativo scambio riguarda informazioni, comandi oppure una funzione che influisce sulla sicurezza di funzionamento della macchina. Se il canale serve esclusivamente per monitoraggio, reportistica o trasferimento di ricette in modalità controllata, le soluzioni possono essere confrontate in termini di manutenzione, scalabilità e integrazione. Se però lungo lo stesso percorso devono transitare comandi che incidono sul movimento, sulla sequenza di lavoro, sugli interblocchi o sullo stato di disponibilità dell’apparecchiatura, il tema cessa immediatamente di essere soltanto informatico. In tal caso bisogna valutare non solo il ritardo e l’affidabilità della trasmissione, ma anche la prevedibilità del comportamento in caso di perdita della connessione, riavvio del sistema, cambio di versione del software e interpretazione errata dello stato da parte di un sistema esterno. È il momento in cui la questione confluisce naturalmente in un’analisi degli effetti della comunicazione sulla sicurezza della macchina, oltre che nella analisi pratica del rischio per le decisioni di progetto e, in alcuni casi, anche nell’ambito della protezione contro l’avviamento inatteso.

Un esempio tipico negli stabilimenti produttivi si presenta spesso così: all’inizio l’obiettivo è solo leggere i dati della macchina per la visualizzazione o per un sistema di reportistica, quindi il team sceglie un collegamento rapido direttamente al PLC. Dopo alcuni mesi, lo stesso canale inizia a gestire la scrittura dei parametri, le conferme degli allarmi e, in seguito, anche i comandi remoti di assistenza. Formalmente il sistema continua a “funzionare”, ma l’architettura non corrisponde più alle responsabilità effettive. Non è più chiaro quale livello rappresenti la fonte autorevole dello stato macchina, chi sia responsabile dell’autorizzazione delle modifiche e come dimostrare che la comunicazione esterna non crei una via verso un avviamento non intenzionale. A questo punto emergono domande non solo sul protocollo, ma anche sulla ripartizione delle funzioni tra livello di controllo, supervisione e sicurezza e, negli scenari di comunicazione diretta con il PLC, sulle conseguenze per la parte elettrica e per i collegamenti della macchina.

Il rilievo normativo e di conformità di questa scelta emerge quindi quando il modello di scambio dati influisce sul comportamento della macchina in condizioni normali e in presenza di anomalie. Non ogni integrazione rientra subito nell’ambito dei requisiti relativi alle funzioni di sicurezza, ma ognuna dovrebbe essere valutata in base agli effetti dell’errore, della perdita di comunicazione e di una sequenza d’azioni errata. Se tramite un’interfaccia esterna è possibile modificare lo stato della macchina, rilasciare un interblocco, riavviare il ciclo o aggirare la logica prevista localmente, allora la decisione sulla comunicazione deve essere collegata all’analisi del rischio e, nei casi pertinenti, anche ai requisiti per la prevenzione dell’avviamento inatteso. Per questo il tema va affrontato subito, nella fase delle ipotesi iniziali e dell’architettura, e non soltanto al momento della messa in servizio. È proprio in questa fase che si possono ancora definire criteri misurabili: chi è responsabile del modello dati, quale effetto della perdita di connessione è ammissibile, quanti punti di integrazione dovranno essere mantenuti dopo il cambio del PLC e come verrà dimostrato che la comunicazione non trasferisce responsabilità oltre il perimetro previsto del sistema.

Dove più spesso aumentano costi o rischi

La maggior parte dei problemi non deriva dalla scelta in sé tra MQTT, OPC UA e comunicazione diretta con il PLC, ma dall’errata attribuzione del ruolo che questa comunicazione deve avere nell’architettura della macchina o dell’impianto. Il progetto inizia a diventare più costoso quando un canale previsto per lo scambio di dati ausiliari comincia a veicolare decisioni operative da cui dipendono la continuità del processo, lo stato dell’apparecchiatura o il comportamento dell’operatore. In pratica, il team implementa una soluzione apparentemente più economica e più rapida e, in seguito, aggiunge rimedi: segnali hardware supplementari, blocchi locali, eccezioni nella logica del controllore, meccanismi separati di conferma e di ripristino dello stato dopo la perdita della connessione. Sono proprio queste correzioni tardive a generare costi, ritardi e controversie sulle responsabilità tra integratore, fornitore del software e utilizzatore finale. Un criterio pratico di valutazione è semplice: occorre stabilire se, in caso di perdita della comunicazione, il sistema debba semplicemente “smettere di inviare dati” oppure possa entrare in uno stato pericoloso, tecnologicamente errato o produttivamente oneroso.

Nei modelli basati sulla comunicazione diretta con il PLC, il rischio aumenta di solito quando l’interfaccia diventa dipendente da uno specifico costruttore, da una determinata versione del software e dalla struttura di memoria del controllore. In fase di avviamento questo approccio funziona spesso bene, ma il costo emerge al momento della sostituzione del PLC, dell’ammodernamento della linea o dell’integrazione di un ulteriore sistema di supervisione. Ogni modifica di questo tipo richiede una nuova mappatura dei dati, la verifica di tipi, indirizzi, autorizzazioni e del comportamento in caso di errore di trasmissione. Dal punto di vista del proprietario del prodotto, questo aspetto è rilevante perché la manutenzione smette di essere prevedibile: la documentazione perde rapidamente attualità, il know-how resta presso il fornitore e la responsabilità sulla correttezza dei dati si frammenta. Se il team non è in grado di indicare chi sia il responsabile del modello dati e quale sia la procedura per modificarlo dopo un aggiornamento del PLC, il costo della futura integrazione è già incorporato nel progetto, anche se oggi non è ancora visibile.

Con MQTT e OPC UA l’errore più frequente è diverso: si presume che il livello di comunicazione risolva da solo il problema della semantica dei dati e dell’affidabilità delle decisioni. In realtà MQTT è efficace nel trasporto di eventi e telemetria, ma senza una definizione accurata dei topic, della qualità di consegna, della retention e dell’identificazione della sorgente è facile arrivare a una situazione in cui il destinatario riceve dati formalmente corretti, ma inutili oppure in ritardo rispetto al processo. OPC UA, invece, organizza il modello informativo e facilita l’interoperabilità, ma la sua implementazione viene spesso sottostimata se i dispositivi non dispongono di una struttura coerente di oggetti, stati e metodi. Un esempio pratico si presenta nella gestione delle ricette, nella conferma dei lotti o nella ripresa remota del ciclo: se non è stato definito in modo univoco quale parte conferma la ricezione del comando, quale ne conferma l’esecuzione e quale registra soltanto l’evento, dopo il primo incidente diventa difficile dimostrare se l’errore sia nato a livello applicativo, di comunicazione o nella logica della macchina. Un buon criterio decisionale, in questo caso, non è la “modernità” del protocollo, ma la possibilità di descrivere in modo univoco lo stato, l’origine del comando, le condizioni di validità e la modalità di ripristino del funzionamento dopo un’anomalia.

Un’ulteriore fonte di costo è la commistione tra requisiti di esercizio e requisiti di sicurezza e conformità. Se tramite MQTT, OPC UA o accesso diretto al PLC è possibile influire sul movimento della macchina, sul rilascio dei blocchi, sulla sequenza di avviamento o su parametri con funzione protettiva, il tema smette di essere esclusivamente informatico. A questo punto il discorso si collega naturalmente a un’analisi pratica degli effetti della comunicazione sulla sicurezza della macchina nelle decisioni di progetto: non bisogna valutare il protocollo in sé, ma le conseguenze di un comando errato, della perdita di attualità dei dati, della modifica non autorizzata delle impostazioni e dell’incoerenza tra stato locale e stato esterno. Negli attuatori, compresi quelli idraulici, la scelta del modello di comunicazione può incidere sul modo in cui vengono realizzate le funzioni di arresto, scarico, blocco del movimento e ritorno sicuro al lavoro, e può quindi essere collegata ai requisiti progettuali applicati nella valutazione di conformità. Se l’interfaccia esterna inizia a influire su funzioni protettive o su comportamenti che l’operatore percepisce come parte della protezione, deve essere trattata come elemento dell’architettura di sicurezza e non come un semplice accessorio di integrazione.

Dal punto di vista della gestione del progetto, la decisione più sicura è quella che può essere difesa non solo sul piano tecnico, ma anche su quello organizzativo. Per questo, prima di scegliere il modello di scambio dati, vale la pena definire alcuni criteri misurabili: il tempo necessario per ripristinare il corretto funzionamento dopo la perdita della connessione, il numero di punti in cui deve essere mantenuta la mappatura dei dati, il metodo di versionamento del modello informativo, l’estensione dei test di regressione dopo una modifica del PLC e la prova che la comunicazione esterna non aggiri i meccanismi di protezione locali. Quando le risposte a queste domande non sono chiare, il progetto entra di norma già in un ambito in cui la sola decisione relativa alla comunicazione dovrebbe essere sottoposta a una valutazione del rischio più formale e, in alcune applicazioni, anche coordinata con i requisiti progettuali relativi agli attuatori e ai dispositivi di blocco. È questo il momento in cui la scelta tra MQTT, OPC UA e comunicazione diretta cessa di essere una questione di preferenza tecnica e diventa una decisione che riguarda i costi di manutenzione, il confine delle responsabilità e la robustezza dell’intera soluzione rispetto all’errore.

Come affrontare il tema nella pratica

In pratica, la scelta tra MQTT, OPC UA e la comunicazione diretta con il PLC conviene impostarla partendo non dalla tecnologia, ma dalla domanda su quale effetto operativo debba produrre lo scambio dati e su chi si assuma la responsabilità del suo esito. Se i dati servono esclusivamente per il monitoraggio, la reportistica o l’alimentazione dei sistemi di livello superiore, la priorità sarà la robustezza dell’integrazione rispetto ai cambiamenti e un modello informativo chiaro. Se invece dall’altro lato compaiono comandi che incidono sul ciclo, sulle ricette, sugli stati operativi o sulle condizioni di avvio, la decisione smette di essere soltanto informatica. A quel punto il modo in cui avviene la comunicazione incide già sul confine delle responsabilità tra integratore, costruttore della macchina, manutenzione e proprietario del processo. Questo ha conseguenze dirette sul progetto: cambia l’estensione delle prove di accettazione, cambia la documentazione delle modifiche, cambia l’entità delle regressioni dopo la modifica del programma del controllore e cambia il costo di mantenimento dopo la messa in esercizio.

Un buon criterio decisionale è stabilire dove debba trovarsi la fonte autorevole sullo stato della macchina e sulla logica che abilita il funzionamento. La comunicazione diretta con il PLC può essere giustificata dove contano la semplicità del percorso esecutivo, il numero ridotto di intermediari e la piena prevedibilità del comportamento lato controllore. Il prezzo da pagare è in genere un forte legame della soluzione con uno specifico programma PLC, con un determinato indirizzo dati e con le pratiche di un singolo fornitore. OPC UA è una scelta sensata quando il progetto richiede un modello dati più stabile, una migliore separazione del livello applicativo dal programma del controllore e una semantica dei segnali più chiara. MQTT funziona soprattutto quando i dati devono essere distribuiti a più destinatari, oltre il singolo rapporto tra sistema e controllore, e quando è accettabile un modello di comunicazione mediato. Non si tratta però di una scelta neutra: quanto più aumentano i livelli intermedi, i broker, i traduttori e le mappature, tanto più cresce la superficie di errore e tanto più diventa difficile dimostrare che una modifica sul lato integrazione non violi le ipotesi adottate per il controllo locale.

Un errore tipico di progettazione consiste nel fatto che il team sceglie un modello comodo per l’integrazione nella fase di avviamento, per poi scoprire solo dopo il costo del mantenimento. Un esempio pratico: il sistema di livello superiore deve scrivere le ricette e commutare le modalità operative di più stazioni. Se lo si realizza tramite scrittura diretta nelle aree di memoria del PLC, inizialmente la soluzione sarà rapida, ma ogni modifica della struttura dati nel controllore attiverà test su entrambi i lati dell’interfaccia e la responsabilità della coerenza delle ricette inizierà a diventare meno definita. Se lo stesso caso viene basato su oggetti e stati definiti in modo univoco lato OPC UA, diventa più facile separare la modifica del programma macchina dalla modifica nel sistema di livello superiore, ma occorre mantenere il modello informativo e il suo versionamento. L’uso di MQTT in uno scenario del genere, invece, ha senso solo quando serve davvero distribuire i dati a più sistemi e quando il controllo dei ritardi, della conferma di consegna e del ripristino dello stato dopo la perdita di connessione è stato descritto e verificato nei test. In caso contrario, il team si compra una flessibilità che non utilizzerà e si ritrova con ulteriori punti di guasto.

Questo è anche il momento in cui il tema passa naturalmente a un’analisi pratica del rischio per le decisioni di progetto. Se il canale di comunicazione può modificare lo stato della macchina, sbloccare una sequenza, riprendere il funzionamento dopo la perdita di connessione oppure influire indirettamente sugli attuatori, occorre valutare non solo l’affidabilità della trasmissione, ma anche gli effetti di un comando errato o tardivo. In una parte delle applicazioni questo aspetto tocca già i requisiti relativi alla protezione contro l’avviamento inatteso, perché anche un’integrazione tecnicamente corretta non può creare una via che aggiri le misure locali di blocco o le procedure di sezionamento dell’energia. In questo ambito la scelta della comunicazione dovrebbe essere coordinata con l’architettura di controllo, con il livello elettrico e con le regole di modifica del software, e non assunta come decisione di integrazione autonoma. Dal punto di vista del manager, questo si traduce in una regola semplice: il modello di scambio dati è corretto solo se si può dimostrare chi approva la modifica, come viene ripristinato lo stato sicuro dopo un guasto e quali KPI saranno misurati dopo l’implementazione, per esempio il tempo di ripristino del funzionamento, il numero di incidenti dopo le modifiche e il numero di punti in cui viene mantenuta la mappatura dei dati.

A cosa prestare attenzione in fase di implementazione

In fase di implementazione, il rischio maggiore non è generato dalla sola scelta tra MQTT, OPC UA e comunicazione diretta con il PLC, ma dalle ipotesi implicite che il team adotta senza una conferma formale. Nella pratica progettuale, le situazioni più costose sono quelle in cui il modello di scambio dati viene scelto per dimostrare una funzione, e non in base alle reali modalità di esercizio, di manutenzione e di responsabilità sulle modifiche. MQTT viene talvolta implementato con l’idea di un semplice trasferimento dati verso i sistemi di livello superiore, per poi iniziare dopo pochi mesi a trasportare comandi operativi. OPC UA viene scelto come soluzione “universale”, ma senza definire quali servizi, modelli dati e meccanismi di autorizzazione saranno effettivamente utilizzati. La comunicazione diretta con il PLC sembra la via più breve, finché non emerge che ogni ulteriore destinatario dei dati richiede una mappatura dedicata, test di regressione e accordi con il fornitore del controllore. Per il manager questo comporta una conseguenza semplice: il costo dell’implementazione non si esaurisce con l’attivazione della connessione, ma si estende all’intero ciclo di modifiche, guasti e collaudi tecnici.

La domanda decisionale più importante non dovrebbe quindi essere “che cosa riusciamo ad avviare più rapidamente”, ma “dove finisce la responsabilità sul significato dei dati e sugli effetti del loro utilizzo”. Se la comunicazione serve esclusivamente a osservare il processo, i criteri di valutazione saranno diversi rispetto al caso in cui lo stesso canale debba influire su ricette, parametri di lavoro, interblocchi o sequenze di comando. A questo punto il tema porta naturalmente a un’analisi pratica del rischio per le scelte progettuali: occorre valutare non solo la probabilità di perdita della comunicazione, ma anche se un valore errato, un aggiornamento ritardato o una mappatura ambigua di una variabile possano provocare un funzionamento non corretto della macchina o della linea. Se la risposta è affermativa, l’architettura di comunicazione cessa di essere una questione puramente di integrazione. Diventa un elemento che incide sulla funzione di controllo, sul collaudo del sistema e sulla responsabilità dell’integratore nel collegamento dei sottosistemi.

In pratica lo si vede bene in uno scenario semplice: il sistema di supervisione deve leggere gli stati da più controllori e, dopo l’avvio del progetto, l’utente chiede anche la modifica remota dei setpoint. Nella comunicazione diretta con il PLC, questo spesso finisce con l’aggiunta di ulteriori registri, eccezioni e soluzioni di aggiramento dipendenti dal singolo costruttore. In MQTT il problema è spesso la perdita di univocità: il messaggio arriva, ma senza un contesto ben definito il destinatario non sa se il valore è attuale, confermato e da quale modalità operativa proviene. In OPC UA l’insidia non è il protocollo in sé, ma l’assunto troppo ottimistico che il modello informativo lato dispositivo corrisponda a ciò che richiede l’applicazione di livello superiore. Per questo il criterio pratico di valutazione dovrebbe comprendere tre aspetti: chi è il proprietario della semantica dei dati, come viene confermata la validità e l’attualità dei valori e come si presenta la procedura di modifica dopo la messa in servizio. Se a una qualsiasi di queste domande il team risponde in modo generico oppure in funzione del fornitore, significa che il costo delle modifiche future è stato appena trasferito alla fase di manutenzione. In questo contesto, l’architettura di comunicazione nell’automazione industriale non può essere valutata solo in base alla facilità di integrazione.

Un’altra insidia è la sottostima degli effetti fisici e impiantistici. Nei progetti in cui la scelta del modello di scambio dati influisce sulla collocazione dei dispositivi intermedi, sull’alimentazione aggiuntiva, sull’instradamento dei cavi o sulla separazione delle reti, il tema inizia a coinvolgere la progettazione della parte elettrica e dei collegamenti nella macchina. Ciò riguarda soprattutto le soluzioni con gateway di comunicazione aggiuntivi, computer industriali o switch che nella documentazione sembrano innocui, ma che nel quadro elettrico significano spazio, raffreddamento, protezioni, assistenza e ulteriori punti di guasto. In questi casi la decisione sulla comunicazione non può essere separata dal progetto esecutivo. Il team dovrebbe essere in grado di indicare che cosa accade in caso di mancanza di alimentazione del dispositivo intermedio, come verrà ripristinato lo stato della comunicazione e se un guasto del livello di trasmissione possa creare una rappresentazione ambigua dello stato della macchina per l’operatore o per il sistema di livello superiore. Per questo, il dimensionamento del modello di comunicazione in fase di progettazione della macchina deve tenere conto anche delle conseguenze installative.

Il riferimento ai requisiti di conformità emerge solo quando il canale di scambio dati incide sulla funzione di controllo, sul modo d’uso della macchina o sui confini di responsabilità tra i fornitori. In questo ambito non basta affermare che il protocollo è “industriale” o ampiamente utilizzato. Occorre dimostrare che l’architettura adottata è stata valutata nel contesto degli stati di guasto prevedibili, delle modifiche in esercizio e delle interfacce tra sottosistemi, il che in pratica conduce a una valutazione metodica del rischio coerente con il campo di applicazione del progetto. Se il sistema è composto da moduli pronti, controllori e livelli di comunicazione provenienti da soggetti diversi, cresce anche l’importanza dell’attribuzione formale delle responsabilità dell’integratore. Di solito è questo il momento in cui conviene fermare il progetto e verificare non solo lo schema di scambio dati, ma anche i limiti delle modifiche dopo il collaudo, le regole di validazione delle modifiche e i KPI di manutenzione: tempo di ripristino della comunicazione, numero di incidenti dopo gli aggiornamenti e numero di interfacce che richiedono mappatura manuale. In tali casi è utile considerare anche l’analisi degli effetti della comunicazione sulla sicurezza della macchina e l’impatto dell’architettura di comunicazione sulla conformità della macchina.