Un PLC che espone variabili, un MES che deve calcolare l’OEE, un ERP che riceve avanzamenti e un cloud che raccoglie dati da più stabilimenti pongono una domanda concreta: OPC UA vs MQTT, quale protocollo conviene adottare? La risposta non dipende da quale sia “migliore” in assoluto, ma da dove nasce il dato, chi deve...
OPC UA vs MQTT: differenza di impostazione
OPC UA è uno standard industriale progettato per rendere interoperabili sistemi di automazione, macchine e software di supervisione. Non si limita al trasporto del dato. Definisce un modello informativo con oggetti, variabili, tipi di dato, metodi, eventi, allarmi, qualità del dato e meccanismi di sicurezza. Un client può interrogare un server OPC UA, esplorare il suo address space e capire, se l’integrazione è progettata correttamente, che cosa rappresenta ogni informazione.
MQTT è invece un protocollo di messaggistica leggero basato sul modello publish/subscribe. Un dispositivo o un’applicazione pubblica un messaggio su un topic, mentre gli altri soggetti interessati si iscrivono a quel topic tramite un broker. È particolarmente adatto a connessioni con banda limitata, reti geograficamente distribuite e architetture cloud-native.
La differenza centrale è questa: OPC UA porta con sé semantica e servizi industriali; MQTT porta messaggi in modo semplice, scalabile e disaccoppiato. MQTT non impone che il payload contenga un dato di produzione, un allarme o una temperatura con un significato standard. Quel significato deve essere definito dall’azienda o dall’integratore, ad esempio con convenzioni sui topic, JSON strutturati, Sparkplug B o un modello dati condiviso.
Quando OPC UA è la scelta più naturale
OPC UA è spesso la scelta corretta nel livello di fabbrica, soprattutto quando occorre collegare un MES a PLC, CNC, robot, linee di confezionamento, sistemi di visione o macchine con interfacce già disponibili. È diffuso nell’automazione industriale e permette di gestire letture cicliche, sottoscrizioni a variazione di valore, eventi e informazioni diagnostiche.
Per un responsabile di produzione, il vantaggio non è solo leggere il contapezzi. È poter associare al valore timestamp, qualità della comunicazione, stato macchina e contesto gerarchico. Se una variabile non è aggiornabile o perde qualità, il sistema a valle può riconoscerlo invece di calcolare KPI su dati apparentemente validi ma incompleti.
OPC UA è indicato quando servono:
- acquisizione diretta e controllata da macchine o PLC;
- navigazione di un modello dati industriale strutturato;
- gestione di allarmi, eventi, metodi e diagnostica;
- comunicazione sicura tra componenti OT e software di fabbrica;
- integrazioni in cui il dato deve mantenere significato tecnico e tracciabilità.
Va però considerato un limite pratico: la qualità dell’integrazione dipende da come il costruttore della macchina ha implementato il server OPC UA. Un address space ben organizzato semplifica il progetto; uno spazio di indirizzi composto da variabili poco documentate richiede mappatura, test e validazione funzionale. OPC UA è uno standard, ma non trasforma automaticamente un dato grezzo in un dato utile per il MES.
Sicurezza e gestione delle connessioni OPC UA
OPC UA integra autenticazione, certificati, firma e cifratura dei messaggi. Queste caratteristiche sono rilevanti quando la comunicazione attraversa segmenti di rete diversi o collega infrastrutture OT e IT. Richiedono però una gestione disciplinata dei certificati: emissione, scadenza, rinnovo, trust list e procedure di manutenzione.
In uno stabilimento con molte macchine, aprire connessioni dirette da ogni applicazione verso ogni PLC non è sempre una buona architettura. Aumentano dipendenze, superfici di attacco e attività di gestione. Un agente edge o una piattaforma di raccolta dati può centralizzare le connessioni, normalizzare le variabili e limitare l’accesso ai dispositivi di campo.
Quando MQTT porta più efficienza
MQTT funziona molto bene quando il dato deve essere distribuito oltre il perimetro della singola macchina. Un gateway può pubblicare stati di produzione, consumi, allarmi o parametri di processo verso un broker, rendendoli disponibili a più applicazioni senza creare una connessione punto-punto per ciascuna.
Questo modello è utile, ad esempio, quando una linea deve alimentare contemporaneamente una dashboard di stabilimento, un data lake, un sistema di manutenzione predittiva e un’applicazione cloud per il monitoraggio multi-sito. Il produttore pubblica una volta; i consumatori ricevono solo i topic a cui sono interessati.
MQTT offre livelli di Quality of Service, sessioni persistenti e messaggi retained. Sono funzioni utili, ma vanno configurate in base al processo. Il QoS 0 privilegia velocità e leggerezza, ma non garantisce la consegna. Il QoS 1 garantisce almeno una consegna, con la possibilità di duplicati che l’applicazione deve saper gestire. Il QoS 2 riduce ulteriormente il rischio di duplicazione, ma introduce più overhead e raramente è necessario per telemetria ad alta frequenza.
MQTT non è però un sostituto diretto di un protocollo macchina. Il broker non conosce automaticamente la differenza tra un pezzo buono, uno scarto, un cambio formato o un fermo per mancanza materiale. Senza una tassonomia coerente, i topic possono diventare un insieme difficile da governare, soprattutto dopo l’aggiunta di nuove linee e stabilimenti.
Topic e payload: il punto in cui si decide la manutenibilità
In un progetto MQTT, la convenzione di naming è un requisito architetturale, non un dettaglio. Un topic come `stabilimento/linea/macchina/stato` è più leggibile e governabile di nomi generici o codici non documentati. Lo stesso vale per il payload: deve includere timestamp, unità di misura, qualità, identificativo della macchina e, dove necessario, lotto, ordine o ricetta.
È altrettanto importante distinguere i flussi real-time dai dati storici. Pubblicare ogni variazione di ogni tag PLC può generare volumi inutili e costi di elaborazione. Per OEE e avanzamento produzione spesso servono eventi significativi, contatori validati e stati macchina normalizzati, non un flusso indiscriminato di variabili.
OPC UA e MQTT nella stessa architettura
L’architettura più efficace in molti casi segue un percorso chiaro: la macchina espone i dati tramite OPC UA o un driver nativo; un componente edge li acquisisce e applica logiche locali; i dati normalizzati vengono inviati via MQTT o API ai servizi centrali. In questo modo ogni protocollo svolge il compito per cui è più adatto.
Sul lato edge è possibile gestire buffering in caso di perdita della connettività esterna, controllo della qualità, conversione delle unità di misura e associazione del dato al contesto produttivo. Sul lato cloud, il dato diventa disponibile per dashboard, report, integrazione con ERP e analisi trasversali tra reparti o stabilimenti.
Per un MES cloud-native, questo approccio riduce la necessità di server locali dedicati e limita le modifiche alla rete OT. PLCinCloud, ad esempio, può valorizzare protocolli industriali come OPC UA nella raccolta dati e adottare logiche di integrazione adatte alla distribuzione dei flussi, mantenendo l’operatività focalizzata su KPI, tracciabilità e interconnessione con i sistemi aziendali.
Come scegliere nel progetto reale
La decisione dovrebbe partire dal caso d’uso, non dalla preferenza per un protocollo. Se l’obiettivo è connettere una macchina a un MES, leggere stati, pezzi, scarti e allarmi con un contesto industriale definito, OPC UA è normalmente il punto di partenza più solido. Se invece occorre distribuire telemetria a molte applicazioni, collegare asset remoti o costruire un flusso event-driven verso il cloud, MQTT è spesso più efficiente.
Prima di definire l’architettura, conviene verificare quattro aspetti: quali interfacce sono effettivamente disponibili sulle macchine, quali dati servono per i KPI e per la tracciabilità, quali sistemi devono consumarli e che cosa deve accadere se la connessione verso l’esterno si interrompe. Sono domande che incidono più della semplice compatibilità di protocollo.
Anche i requisiti Transizione 4.0 richiedono attenzione. Né OPC UA né MQTT, da soli, garantiscono la conformità. Il requisito riguarda l’interconnessione effettiva, lo scambio bidirezionale dove necessario, la disponibilità dei dati e la coerenza documentale del progetto. Il protocollo è un elemento dell’architettura, non la prova completa del risultato.
La scelta più utile non è quindi dichiarare vincitore OPC UA o MQTT. È progettare un flusso in cui il dato nasce affidabile, mantiene il proprio significato durante il trasferimento e arriva alle persone e ai sistemi che devono trasformarlo in decisioni operative. Quando questo percorso è definito bene, la fabbrica ottiene meno complessità tecnica e più controllo misurabile sul processo produttivo.