OPC UA vs MQTT: come scegliamo il protocollo per un IoT industriale

In tutti i progetti di Industria 4.0 che abbiamo seguito negli ultimi cinque anni — da Carpigiani a STOMMPY a IMA — c’è sempre lo stesso bivio iniziale: OPC UA o MQTT?. La risposta non è mai “uno è meglio dell’altro”, ma “dipende da dove sta il dato e da chi deve consumarlo”.

I due mondi in due righe

OPC UA è nato per parlare con il mondo OT (Operational Technology): PLC, drive, controllori industriali. È session-based, fortemente tipizzato, con un information model che descrive non solo i valori ma anche la loro semantica.

MQTT nasce per il mondo IT: telemetria, publish/subscribe leggero, payload arbitrari. Va d’accordo con cloud, broker scalabili, microservizi.

Quando preferiamo OPC UA

Quando dobbiamo:

• Leggere o scrivere variabili dentro un PLC Siemens, Beckhoff, Rockwell. La maggior parte oggi espone un server OPC UA nativo.
• Mantenere il mapping semantico dei dati: una temperatura non è “un numero”, è una variabile con unità di misura, range valido, allarmi associati.
• Sottoscrivere variabili con dead-band: il server invia un aggiornamento solo quando il valore esce da una fascia di tolleranza, riducendo il traffico senza polling.

import { OPCUAClient, AttributeIds } from "node-opcua";

const client = OPCUAClient.create({ endpointMustExist: false });
await client.connect("opc.tcp://192.168.10.50:4840");
const session = await client.createSession();

const dataValue = await session.read({
  nodeId: "ns=4;s=|var|PLC.LineSpeed",
  attributeId: AttributeIds.Value,
});
console.log("Velocità linea:", dataValue.value.value, "m/min");

Quando preferiamo MQTT (e MQTT-SN)

Quando il dato deve:

• Lasciare il campo e finire in cloud (AWS IoT Core, Azure IoT Hub, HiveMQ).
• Essere consumato da molti subscriber indipendenti: dashboard, sistema di allarmi, machine learning pipeline.
• Viaggiare su link instabili o vincolati: in quei casi MQTT-SN su LoRa o cellulare diventa quasi obbligatorio.

import mqtt from "mqtt";

const client = mqtt.connect("mqtts://iot.fancypixel.cloud:8883", {
  username: process.env.MQTT_USER,
  password: process.env.MQTT_PASS,
});

client.on("connect", () => {
  client.subscribe("plant/+/line/+/speed");
});

client.on("message", (topic, payload) => {
  const speed = JSON.parse(payload.toString());
  console.log(`[${topic}]`, speed.value, speed.unit);
});

Il pattern che usiamo (quasi) sempre

In nove progetti su dieci finiamo per usare entrambi:

1. Sul campo, un gateway parla in OPC UA con i PLC.
2. Il gateway mappa le variabili in topic MQTT secondo una convenzione predefinita.
3. Verso il cloud parla MQTT, con TLS e autenticazione per device.

Il gateway è la “membrana” tra OT e IT. Lì applichiamo throttling, normalizzazione delle unità di misura, eventuale enrichment con dati contestuali (turno, batch, operatore).

Il rischio peggiore in questi progetti non è scegliere il protocollo sbagliato. È non disegnare la membrana: ed esporre PLC sensibili direttamente a un broker accessibile da Internet. L’abbiamo visto succedere, e non finisce bene.

Letture consigliate

Un piccolo set di risorse che teniamo sotto mano:

• OPC UA Part 1 — Overview and Concepts (PDF gratuito sul sito OPC Foundation).
• MQTT Version 5.0 (OASIS standard).
• Sparkplug B: la specifica Eclipse Foundation che porta semantica industriale sopra MQTT — vale la pena conoscerla anche se non la si adotta.

Nel prossimo articolo entreremo nel dettaglio di Sparkplug B e mostreremo un esempio reale di “store and forward” per linee con connettività intermittente.