In quasi tutti i progetti IIoT salta fuori la stessa domanda: OPC UA o MQTT? A volte dietro c'è un reale bisogno di decidere. Spesso c'è la speranza che esista una risposta netta: «prendi X e hai finito».
La risposta onesta è: dipende. Ma «dipende» è utile solo se si sa da che cosa dipende. È proprio quello che provo a spiegare qui, dal punto di vista di chi usa regolarmente entrambi i protocolli in ambienti di produzione reali.
Che cos'è OPC UA, e che cosa non è
OPC UA (Open Platform Communications Unified Architecture) è uno standard di comunicazione industriale pubblicato nel 2008 dalla OPC Foundation. Il punto decisivo: OPC UA non è solo un protocollo di trasporto. Definisce anche un modello di dati semantico.
Che cosa significa in concreto? Se un PLC Siemens S7 esporta via OPC UA un punto dati «velocità del mandrino», un client OPC UA non sa soltanto che il valore è 3.200. Sa anche che cosa significa questo valore, qual è la sua unità di misura, quali valori limite valgono e quando è stato modificato l'ultima volta.
È questo il grande vantaggio di OPC UA: i dati portano con sé il proprio significato. L'integrazione diventa così molto più robusta, perché tra mittente e destinatario bisogna concordare meno conoscenza implicita.
Che cos'è MQTT, e perché è diventato così popolare
MQTT (Message Queuing Telemetry Transport) è stato sviluppato da IBM nel 1999 per applicazioni in ambienti con connessioni di rete scadenti: in origine per oleodotti nel deserto. Leggero, robusto, bassa latenza, overhead minimo (l'header occupa solo 2 byte).
MQTT è un puro protocollo pub/sub: i dispositivi (publisher) inviano messaggi a dei topic. Un broker (p. es. Mosquitto o HiveMQ) li distribuisce a tutti i subscriber. Funziona benissimo, ma MQTT di per sé non definisce che cosa c'è in questi messaggi. Mittente e destinatario devono concordarlo in anticipo.
Se una macchina invia via MQTT un valore «3200», il destinatario per il momento non ne sa nulla, a parte ciò che si ricava dal nome del topic. Che si tratti di giri al minuto, watt o grammi dipende interamente dall'implementazione.
Il confronto diretto
| Aspetto | OPC UA | MQTT |
|---|---|---|
| Origine | Standard industriale (OPC Foundation, 2008) | Protocollo IoT (IBM, 1999) |
| Architettura | Client-server & pub/sub (dalla v1.04) | Pub/sub (basato su broker) |
| Modello di dati | Tipizzato, semantico (address space) | Agnostico rispetto al payload (binario, JSON ecc.) |
| Semantica | Integrata: i dati hanno un significato | Nessuna: il significato va concordato |
| Sicurezza | TLS + certificati nativi | TLS opzionale, l'implementazione varia |
| Overhead | Più elevato (XML/binario, handshake) | Molto basso (header: 2 byte) |
| Latenza | Da bassa a media | Molto bassa |
| Idoneità | Collegamento macchine, integrazione OT | Sensore→cloud, edge→backend |
Quando consiglio OPC UA
OPC UA è la scelta giusta quando al centro c'è il collegamento al controllo della macchina, cioè quando vuole leggere i dati direttamente da un PLC, da un controller CNC o da un sistema SCADA.
- Collegamento delle macchine: Siemens, Beckhoff, B&R, Bosch Rexroth: questi PLC supportano OPC UA in modo nativo. L'integrazione è pulita, tipizzata e ben documentata.
- Interoperabilità: Se si devono integrare macchine diverse di costruttori diversi, con OPC UA esiste uno standard comune. Con MQTT deve definire una struttura di topic propria per ogni macchina.
- Integrazione IT/OT: OPC UA ha un quadro di sicurezza chiaro (certificati, autenticazione, sessioni cifrate). Questo conta negli ambienti regolamentati e ovunque si colleghino reti IT e OT.
- Requisiti semantici: Se i punti dati devono essere interpretati in modo coerente in sistemi diversi, p. es. contemporaneamente nell'historian, nello SCADA e negli analytics, il modello di dati tipizzato di OPC UA è un vantaggio notevole.
Quando consiglio MQTT
MQTT è la scelta giusta per tutto ciò che avviene tra dispositivo edge e backend, soprattutto quando bisogna trasmettere molti punti dati ad alta frequenza e la connessione di rete può essere inaffidabile.
- Collegamento dei sensori: Raspberry Pi, Arduino, ESP32: questi dispositivi implementano raramente OPC UA. MQTT gira su tutti, con risorse minime.
- Funzionamento offline: I broker MQTT possono mettere in buffer i messaggi (QoS livello 1 e 2) finché il subscriber non è di nuovo raggiungibile. Negli ambienti di produzione con una rete instabile è prezioso.
- Throughput elevato: Se si devono trasmettere 500 punti dati al secondo, MQTT, grazie al suo overhead minimo, è nettamente più efficiente di OPC UA.
- Collegamento al cloud: AWS IoT Core, Azure IoT Hub: le grandi piattaforme IoT cloud parlano MQTT in modo nativo. Lì OPC UA ha sempre bisogno di un adattatore.
La risposta più frequente nella pratica: entrambi
In quasi tutti i progetti che realizziamo si usano entrambi i protocolli, in punti diversi dell'architettura. Tipicamente si presenta così:
PLC (Siemens S7) ──OPC UA──▶ Gateway edge
Gateway edge ──MQTT──▶ Broker (Mosquitto/HiveMQ)
Broker ──MQTT──▶ InfluxDB / Grafana / Backend
OPC UA legge il controllo della macchina: in modo tipizzato, semanticamente corretto, con autenticazione tramite certificati. Il gateway edge (tipicamente un PC industriale o un Raspberry Pi) normalizza i dati e li inoltra via MQTT: leggero, funzionante offline, compatibile con il cloud.
Non è un compromesso. È l'architettura che sfrutta i punti di forza di entrambi i protocolli nel posto giusto.
Guida pratica alla scelta
La macchina ha OPC UA nativo?
→ Usare direttamente OPC UA.
La macchina ha un'interfaccia proprietaria (FOCAS, SHDR, Siemens S5)?
→ Adattatore sul gateway edge, uscita via MQTT.
Sensore senza protocollo di rete (I/O analogico, digitale)?
→ Gateway edge con hardware per sensori, uscita via MQTT.
I dati devono andare su una piattaforma cloud (Azure, AWS)?
→ MQTT verso il broker, poi oltre.
Bisogna uniformare più macchine di costruttori diversi?
→ OPC UA come protocollo di destinazione, adattatori dove necessario.
Frequenza dei dati molto elevata (>100 punti/s)?
→ Preferire MQTT.
Ambiente regolamentato, requisiti di audit?
→ OPC UA, per il suo quadro di sicurezza e autenticazione.
Che cosa cambia con MQTT Sparkplug B
Una breve indicazione per chi vuole approfondire: MQTT Sparkplug B è una specifica basata su MQTT che definisce un modello di dati e una struttura dei topic standardizzati per le applicazioni industriali. Cerca di trasferire su MQTT il vantaggio semantico di OPC UA.
Nella pratica vediamo Sparkplug B soprattutto in progetti greenfield con un'infrastruttura omogenea. Per ambienti misti con macchine legacy, OPC UA resta la scelta più robusta a livello macchina.
Conclusione
OPC UA e MQTT non sono concorrenti: risolvono problemi diversi in punti diversi di un'architettura IIoT. La domanda «OPC UA o MQTT?» spesso è la domanda sbagliata. Quella giusta è: «Che cosa deve essere trasmesso, dove, a quali condizioni e con quali requisiti di sicurezza e semantica?»
Se vuole discutere queste domande per la Sua situazione concreta (quali macchine ha, quali protocolli parlano e come potrebbe essere un'architettura pragmatica): si faccia sentire.