Modbus, MQTT, OPC-UA: quale protocollo industriale scegliere nel 2026?

· 15 minuti di lettura
15 min read
Team Eziwan
Team Eziwan
Infrastruttura IoT

La domanda “quale protocollo utilizzare per il mio progetto IoT industriale?” ricorre sistematicamente nei progetti di modernizzazione degli stabilimenti. Modbus, MQTT e OPC-UA sono i tre protocolli più citati, ma non sono alternative equivalenti. Operano a livelli diversi, rispondono a esigenze diverse e spesso si completano a vicenda piuttosto che essere in concorrenza tra loro.

Questo articolo chiarisce le loro differenze fondamentali, i loro punti di forza e i loro limiti, e offre una guida decisionale per scegliere il protocollo più adatto al proprio caso d'uso.

Prima di tutto, capire: protocolli di natura diversa​

Prima di procedere al confronto, è necessario comprendere che Modbus, MQTT e OPC-UA non operano allo stesso livello:

Modbus è un protocollo di lettura dei dati: consente di interrogare un dispositivo per leggerne i registri (misure, stati). Si tratta di un protocollo di campo, master/slave, progettato per l'acquisizione di dati da dispositivi industriali.

MQTT è un protocollo di messaggistica: consente di pubblicare e sottoscrivere flussi di dati tramite un broker centralizzato. Si tratta di un protocollo di trasporto dei messaggi, non di acquisizione diretta da un dispositivo.

OPC-UA è un'architettura di servizi: integra l'acquisizione dei dati, l'accesso al modello di dati, la sicurezza, gli allarmi e la cronologia in un unico standard industriale unificato. È la soluzione più completa — e la più complessa.

In pratica: La maggior parte delle moderne architetture IoT industriali utilizza tutte e tre. Modbus per leggere i dispositivi di campo. MQTT per trasmettere i dati al cloud. OPC-UA per l'interoperabilità tra sistemi complessi.

Modbus RTU e Modbus TCP​

Che cos'è Modbus?​

Modbus è stato creato nel 1979 da Modicon (oggi Schneider Electric). È il protocollo industriale più antico ancora in uso — e di gran lunga il più diffuso nel settore industriale francese.

Modbus RTU funziona su una connessione seriale RS-485 (o RS-232). È un protocollo asincrono, master/slave, con una topologia a bus lineare (multidrop). Su un unico bus RS-485 possono essere collegati fino a 247 slave.

Modbus TCP è il protocollo Modbus incapsulato in pacchetti TCP/IP. Funziona su Ethernet, porta 502. Mantiene il modello master/slave ma consente topologie di rete arbitrarie (a stella, ad albero). Non vi è alcun limite rigido al numero di slave a livello di rete.

Cosa permette di leggere Modbus​

Modbus espone 4 tipi di dati:

  • Coils (0x): uscite digitali in lettura/scrittura (booleani)
  • Discrete Inputs (1x): ingressi digitali di sola lettura (booleani)
  • Input Registers (3x): registri a 16 bit di sola lettura (misure dei sensori)
  • Holding Registers (4x): registri a 16 bit di lettura/scrittura (setpoint, parametri)

Per leggere un valore di temperatura da un sensore: il master invia una richiesta "leggi i registri da 3x01 a 3x02", lo slave risponde con i due registri contenenti il valore (in genere un numero in virgola mobile a 32 bit distribuito su due registri contigui).

Punti di forza di Modbus​

Universalità assoluta: Se disponete di un'apparecchiatura industriale dotata di una porta RS-485 o di una porta Ethernet e non sapete quale protocollo utilizzi, provate innanzitutto con Modbus. È molto probabile che supporti Modbus.

Semplice: Il protocollo è semplice: registri numerati, funzioni standard di lettura/scrittura. Qualsiasi sviluppatore può implementare un client Modbus in poche ore.

Resilienza: Nessuna dipendenza da un broker o da un server centrale. Il master interroga direttamente ogni slave. Un guasto del master non influisce sui rapporti tra gli slave.

Maturità: 45 anni di diffusione industriale. Le librerie Modbus sono disponibili in tutti i linguaggi di programmazione (Python, C, Java, JavaScript...).

Limiti di Modbus​

Architettura esclusivamente pull: Il master deve interrogare in modo proattivo ogni slave. I dispositivi non inviano dati spontaneamente. Su un bus con 50 slave interrogati ogni secondo, la frequenza effettiva per slave può scendere a 20 secondi.

Assenza di sicurezza nativa: Modbus RTU e Modbus TCP non dispongono di alcun meccanismo di autenticazione né di crittografia. Qualsiasi dispositivo presente sulla rete può leggere o scrivere nei registri di un’apparecchiatura Modbus esposta. La sicurezza deve essere garantita a livello di rete (VPN, segmentazione).

Nessun rilevamento automatico: Non esiste un meccanismo di rilevamento dei dispositivi Modbus su un bus. È necessario conoscere l'indirizzo slave e gli indirizzi dei registri di ciascun dispositivo.

Nessuna denominazione semantica: Il registro 40001 non indica cosa contiene — occorre consultare la documentazione del produttore per sapere che si tratta della "temperatura dell'acqua in ingresso". Nessuna autodescrizione.

Quando utilizzare Modbus​

  • Lettura dei dati dalle apparecchiature sul campo (contatori di energia, sensori di pressione, variatori, controllori PLC)
  • Reti di campo esistenti con cablaggio RS-485 già installato
  • Progetti con apparecchiature eterogenee di diversi produttori (Modbus è il protocollo più universale)
  • Budget limitati o team privi di competenze specialistiche

MQTT (Message Queuing Telemetry Transport)​

Che cos'è MQTT?​

MQTT è stato creato nel 1999 da IBM per la telemetria su collegamenti satellitari a bassa velocità. È stato standardizzato da OASIS nel 2014 (MQTT 3.1.1) e nel 2019 (MQTT 5.0).

MQTT è un protocollo publish/subscribe: i publisher inviano messaggi su determinati topic, mentre i subscriber ricevono i messaggi relativi ai topic a cui sono iscritti. Un broker MQTT centrale si occupa di instradare i messaggi tra publisher e subscriber.

Architettura MQTT​

Il broker è il cuore dell'architettura MQTT. I client (publisher e subscriber) si connettono al broker: non comunicano mai direttamente tra loro.

Punti di forza di MQTT​

Architettura push: Gli editori inviano i dati quando hanno qualcosa da comunicare. Nessun polling: l'abbonato riceve i dati immediatamente al momento della pubblicazione. Latenza tipica: 10-50 ms end-to-end.

Leggerezza: Il protocollo è stato progettato per dispositivi con risorse limitate (microcontrollori, modem 2G). Un messaggio MQTT può occupare solo 2 byte (header minimo). Molto efficiente in termini di larghezza di banda.

QoS configurabile: Tre livelli di qualità del servizio: QoS 0 (al massimo una volta), QoS 1 (almeno una volta), QoS 2 (esattamente una volta). Per le applicazioni critiche, il QoS 2 garantisce la consegna esattamente una volta.

Interoperabilità cloud: Tutti i principali provider cloud (AWS IoT Core, Azure IoT Hub, Google Cloud IoT) mettono a disposizione un broker MQTT nativo. MQTT è il protocollo di fatto per le architetture IoT cloud.

TLS nativo: MQTT supporta nativamente TLS 1.3. La sicurezza è integrata nel protocollo, non è un'aggiunta.

Limiti di MQTT​

Non è possibile leggere direttamente i dispositivi: un dispositivo Modbus RTU non supporta nativamente il protocollo MQTT. È necessario un gateway o un passerella che legga i dati Modbus e li pubblichi in formato MQTT. Ecco perché Modbus e MQTT vengono spesso utilizzati insieme nelle architetture IoT industriali.

Dipendenza dal broker: Se il broker MQTT smette di funzionare, l'intera architettura di messaggistica crolla. La resilienza del broker è fondamentale. I broker gestiti (AWS IoT, HiveMQ Cloud) sono molto affidabili, ma creano una dipendenza da un servizio esterno.

Mancanza di un modello di dati standardizzato: MQTT non definisce né il formato dei messaggi né la struttura degli argomenti. Ogni implementazione è libera, il che compromette l'interoperabilità. Due sistemi MQTT di produttori diversi non comunicano necessariamente tra loro senza un adeguamento.

Nessuna richiesta/risposta nativa: MQTT è orientato agli eventi unidirezionali. Per implementare un modello richiesta/risposta (ad es.: richiedere un parametro a un dispositivo), è necessario utilizzare MQTT 5.0 con argomenti di risposta correlati — è possibile, ma più complesso.

Quando utilizzare MQTT​

  • Trasferimento dei dati dal campo al cloud (Modbus → Gateway → MQTT → Cloud)
  • Architetture basate sugli eventi in cui i dati cambiano in modo irregolare
  • Implementazioni IoT embedded su microcontrollori o dispositivi con risorse limitate
  • Integrazione con broker cloud nativi (AWS IoT, Azure IoT Hub)

OPC-UA (OPC Unified Architecture)​

Che cos'è l'OPC-UA?​

L'OPC-UA (IEC 62541) è stato sviluppato dalla OPC Foundation a partire dal 2006 come successore dell'OPC Classic (basato su COM/DCOM di Windows). Si tratta dello standard industriale più ambizioso: combina acquisizione dati, modello semantico, sicurezza, cronologia, allarmi e accesso ai metodi in un unico protocollo.

OPC-UA è oggi il protocollo preferito dai produttori di controllori per le architetture Industry 4.0: Siemens TIA Portal (S7-1500), Rockwell ControlLogix, Beckhoff TwinCAT, B&R Automation — tutti supportano OPC-UA in modo nativo già da 5 a 10 anni.

Punti di forza dell'OPC-UA​

Modello di dati semantico: A differenza di Modbus (registri numerati e anonimi), OPC-UA espone un albero di oggetti denominati e tipizzati. Il nodo "ns=2;i=1001" può essere denominato "Macchina1/MotorePrincipale/TemperaturaCuscinetto" con metadati (unità, intervallo, descrizione). L'autodescrizione è nativa.

Sicurezza integrata: autenticazione, autorizzazione, crittografia, integrità dei messaggi — tutto è integrato nel protocollo. OPC-UA supporta diversi profili di sicurezza (None, Sign, SignAndEncrypt) con algoritmi moderni (AES-256, RSA-2048+).

Pubblica/Sottoscrivi tramite OPC-UA PubSub (2017): OPC-UA può ora funzionare in modalità di pubblicazione asincrona (push), non solo in modalità richiesta/risposta (pull). È in grado di pubblicare su broker MQTT, rendendo OPC-UA e MQTT complementari anziché concorrenti.

Accesso ai metodi: OPC-UA consente di richiamare metodi sulle apparecchiature — non solo di leggere i valori. L'azionamento di una valvola, il comando di avvio di un motore — tutto è modellato come un oggetto OPC-UA.

Semantica e interoperabilità: Le "Companion Specifications" OPC-UA definiscono modelli standardizzati per settore: OPC-UA for Plastics, for Robotics, for PackML (imballaggio), for Mining... Un software SCADA compatibile con OPC-UA for PackML può connettersi a qualsiasi linea di confezionamento conforme, senza necessità di configurazioni specifiche.

Limiti dell'OPC-UA​

Complessità: OPC-UA è il protocollo più complesso da implementare e configurare. Le specifiche superano le 1000 pagine. La curva di apprendimento è notevole per i team che non hanno esperienza pregressa con OPC-UA.

Risorse richieste: Un server OPC-UA completo richiede più risorse rispetto a uno slave Modbus. I PLC di vecchia generazione o i microcontrollori con risorse limitate non sono in grado di supportare uno stack OPC-UA completo (esistono tuttavia profili "nano" più leggeri).

Non universalmente diffuso sul campo: Le apparecchiature più vecchie (precedenti al 2010-2015) non supportano OPC-UA. In un parco industriale eterogeneo, si incontreranno molte più apparecchiature Modbus che OPC-UA tra le apparecchiature di campo esistenti.

Overhead di rete: I messaggi OPC-UA sono più voluminosi rispetto a quelli Modbus (XML o binari, a seconda del protocollo di trasporto). Su connessioni 4G a bassa velocità, questo può rappresentare un fattore determinante.

Quando utilizzare OPC-UA​

  • Controllori Siemens S7-1200/1500 di ultima generazione con TIA Portal (OPC-UA nativo)
  • Architetture Industry 4.0 con interoperabilità SCADA/MES/ERP
  • Progetti che richiedono un elevato livello di sicurezza e tracciabilità degli accessi
  • Ambienti multiconstruttore con necessità di interoperabilità semantica

Guida alla scelta: quale combinazione scegliere per il tuo progetto?​

Architettura tipica di un sistema IoT industriale semplice​

Utilizzo: Monitoraggio dei processi, avvisi, cronologia. L'80% dei progetti IoT industriali francesi rientra in questo schema.

Architettura con bus di integrazione cloud​

Utilizzo: Progetti con più utenti dei dati (SCADA + ERP + BI). MQTT come bus di integrazione.

Architettura Industria 4.0 con OPC-UA​

Utilizzo: Impianti dotati di controllori logici programmabili di ultima generazione, progetti Industry 4.0, integrazione MES.

Matrice decisionale​

RequisitiModbus RTUModbus TCPMQTTOPC-UA
Lettura sensori di campo RS-485✓✓———
Lettura PLC in rete✓✓✓—✓
Invio dati al cloud——✓✓✓
Interoperabilità SCADA/MES✗✗Parziale✓✓
Sicurezza integrata✗✗TLS✓✓
Apparecchiature obsolete✓✓✓—✗
Controllori recenti (>2015)✓✓—✓✓
Architetture cloud-native✗✗✓✓✓
PMI senza competenze in materia di protocolli✓✓✓✓✓✗

Come Eziwan gestisce i tre protocolli​

Il gateway Eziwan è indipendente dai protocolli utilizzati sul campo:

  • Modbus RTU: porta RS-485 nativa, modalità master, fino a 247 slave per bus, polling configurabile da 1 s a 15 min
  • Modbus TCP: client Modbus TCP, connessioni simultanee a più server Modbus
  • MQTT: publisher MQTT (pubblicazione dei dati raccolti), possibilità di fungere da subscriber per i comandi
  • OPC-UA: client OPC-UA (lettura dei nodi, sottoscrizione alle variazioni di valore) — disponibile su richiesta per le implementazioni OPC-UA

Per quanto riguarda il cloud, i dati vengono normalizzati internamente e resi disponibili tramite:

  • API REST (JSON) per le applicazioni cloud
  • Webhooks per gli eventi in tempo reale
  • MQTT in uscita per le integrazioni tramite bus

È possibile combinare Modbus RTU sui dispositivi di campo e MQTT verso il proprio cloud AWS/Azure senza modificare nulla: il gateway si occupa della conversione.

Conclusione​

Nel 2026, alla domanda “Modbus, MQTT o OPC-UA?” la risposta è generalmente “tutti e tre insieme”:

  • Modbus per leggere le vostre apparecchiature di campo (è il linguaggio che utilizzano)
  • MQTT per trasferire i dati verso il cloud e distribuirli a diverse applicazioni
  • OPC-UA se disponete di controllori di ultima generazione Siemens/Rockwell/Beckhoff e avete bisogno di interoperabilità SCADA/MES

Non si tratta di una competizione, ma di un'architettura a livelli. La scelta non è "quale protocollo", bensì "quale protocollo a quale livello per quale apparecchiatura".

Domande frequenti — Modbus, MQTT e OPC-UA​

È possibile utilizzare Modbus e MQTT contemporaneamente sullo stesso gateway?

Sì, ed è l'architettura più diffusa nell'IIoT. Il gateway raccoglie i dati dai controllori via Modbus TCP o RTU (livello di campo) e li pubblica tramite MQTT verso il cloud (livello di trasporto). Modbus si ferma al gateway: non viene mai esposto su Internet. MQTT subentra per il trasporto verso il cloud, con TLS 1.3 e autenticazione.

OPC-UA può sostituire Modbus sui controllori esistenti (S7-1200, M340)?

Sui Siemens S7-1200, il server OPC-UA è disponibile solo a partire dal firmware V4.4 e richiede una configurazione esplicita in TIA Portal. Sui modelli S7-1500, è integrato di serie a partire dal firmware V2.0. Sui controllori Schneider M340, OPC-UA non è integrato di serie: è necessario un modulo aggiuntivo. In pratica, per i sistemi esistenti, Modbus TCP rimane la soluzione universale; OPC-UA è indicato principalmente per i nuovi progetti con controllori di ultima generazione.

MQTT con QoS 0 vs QoS 1 vs QoS 2 — quale scegliere per il monitoraggio industriale?

Per il monitoraggio dei dati di processo (temperature, pressioni), il QoS 1 (At Least Once) rappresenta il giusto compromesso: la consegna è garantita anche dopo la riconnessione, con il rischio di qualche duplicato (accettabile per i dati di monitoraggio). Il QoS 2 (Exactly Once) è più oneroso a causa dello scambio di conferme e raramente necessario per le misurazioni. Il QoS 0 (At Most Once) è adatto per dati molto frequenti (> 1/s) in cui è accettabile una perdita occasionale.

È sufficiente un broker MQTT pubblico (HiveMQ, EMQX cloud) per il settore industriale?

Per progetti pilota o applicazioni non critiche, sì. Ma per una produzione soggetta a vincoli di riservatezza (dati di processo, identificativi delle apparecchiature), è preferibile un broker privato ospitato in Francia. I dati MQTT che transitano attraverso broker pubblici statunitensi sono potenzialmente soggetti al CLOUD Act — da valutare in base alla sensibilità dei dati e al settore di attività.

OPC-UA influisce sulle prestazioni del PLC rispetto a Modbus?

OPC-UA richiede notevoli risorse in più in termini di CPU e memoria rispetto a Modbus TCP. Su un S7-1500 con CPU 1511, con un server OPC-UA attivo e 50 connessioni client, il tempo di ciclo può aumentare dal 5 al 15%. Su un S7-1200, le risorse sono più limitate: verificare sistematicamente l’impatto con il programma di produzione completo prima di implementare OPC-UA in produzione.

Per approfondire​

Risorse aggiuntive​