Quando si parla di protocolli industriali moderni, il rischio è sempre lo stesso: mettere nello stesso contenitore tecnologie che in realtà nascono per scopi diversi. È quello che succede spesso con Sparkplug, OPC UA FX e DDS-XRCE. Da fuori sembrano tre modi alternativi per far circolare dati tra dispositivi industriali. In pratica, però, lavorano su livelli diversi dello stack e rispondono a esigenze progettuali diverse. Non si tratta di capire quale protocollo sia “più evoluto” o più di moda. Si tratta di capire quale architettura si sta costruendo: una pipeline broker-based per telemetria e stato nodo, una comunicazione field-level aperta tra controller e dispositivi, oppure un’estensione embedded di un ecosistema DDS già esistente.
Il tema si collega bene sia a ciò che abbiamo già visto su TSN nell’automazione industriale, quando il problema diventa il determinismo della rete, sia a Edge AI industriale, quando il nodo locale non si limita più a trasportare dati ma inizia anche a filtrarli, classificarli o decidere localmente. Qui, però, il focus è più basso nello stack: modello di comunicazione, interoperabilità, footprint e criteri di scelta.
Perché il confronto tra protocolli industriali è spesso impostato male
Il primo errore è confrontare questi protocolli industriali come se fossero tre varianti dello stesso oggetto. Non lo sono.
Sparkplug si appoggia a MQTT e rafforza il suo uso in ambito industriale con un namespace definito, payload coerenti e una gestione più rigorosa dello stato dei nodi. OPC UA FX estende il mondo OPC UA verso il field level, con un focus netto su interoperabilità, semantica e comunicazione controller-to-controller. DDS-XRCE, invece, serve a portare nodi molto piccoli dentro un ecosistema DDS attraverso un modello client-agent.
Se il progetto è impostato bene, questa distinzione emerge presto. Un gateway edge che raccoglie dati da più macchine e li espone a SCADA, historian e cloud ha un problema diverso rispetto a una linea che deve far parlare controllori e dispositivi in modo aperto. E un microcontrollore che deve entrare in un sistema basato su DDS ha vincoli ancora diversi.
Il secondo errore è guardare solo ai pacchetti. Si tende a parlare di overhead, latenza o QoS senza considerare il contesto. Ma il comportamento reale di un protocollo industriale dipende da più fattori: presenza o meno di broker, toolchain, sicurezza attiva, modello dati, ciclo di engineering e footprint sul nodo. Guardare solo il trasporto porta quasi sempre a conclusioni sbagliate.
Il terzo errore è ancora più comune. Si sceglie il protocollo prima di avere chiarito l’architettura. Invece il processo corretto è l’opposto: prima si definisce dove vive l’intelligenza, dove si fa il buffering, dove si chiude il controllo e dove si integra il dato. Solo dopo si sceglie il protocollo industriale più adatto.
Sparkplug: MQTT quando smette di essere generico
Il punto chiave è semplice: MQTT da solo trasporta messaggi, ma Sparkplug gli dà una struttura utile davvero in ambito industriale.
Cosa aggiunge Sparkplug a MQTT
MQTT, da solo, è un protocollo industriale publish/subscribe leggero e flessibile. È uno dei motivi per cui continua a essere usato in scenari IoT e IIoT molto diversi tra loro. Il problema è che questa flessibilità, in ambito industriale, può diventare un difetto. Se ogni integratore inventa il proprio schema di topic, il proprio payload e il proprio modo di gestire le riconnessioni, il risultato non è interoperabilità ma frammentazione.
È esattamente qui che entra in gioco la specifica Sparkplug 3.0. Sparkplug prende MQTT e gli impone una disciplina industriale: namespace coerente, payload strutturato, gestione dello stato di sessione, eventi di nascita e morte dei nodi, convenzioni chiare per edge node e device. In pratica, riduce lo spazio per le interpretazioni arbitrarie e rende più prevedibile l’integrazione tra sistemi.
Questo punto è più importante di quanto sembri. Nella vita reale, il problema raramente è “mandare un valore”. Il problema è sapere se un nodo è online, se ha perso connessione, se il dato che stai leggendo è attuale oppure è rimasto fermo da dieci minuti, se l’edge gateway è stato riavviato, se il payload che stai parsando appartiene davvero a quel tipo di dispositivo. Sparkplug affronta proprio questo livello di maturità.
Dove Sparkplug ha senso
Sparkplug è molto forte quando il problema è telemetria industriale strutturata. Qui rientrano gateway edge, raccolta dati da PLC o sensori, publishing verso broker, integrazione con SCADA, historian, MES o piattaforme cloud. È il terreno in cui MQTT, se lasciato “nudo”, rischia di trasformarsi in una serie di convenzioni locali non replicabili, mentre Sparkplug lo rende molto più governabile.
In pratica, è una buona scelta quando il sistema deve essere robusto, leggibile da più attori e facile da estendere nel tempo. Il modello broker-based aiuta perché disaccoppia publisher e subscriber, facilita buffering, fan-out, diagnostica e integrazione con il software a valle. Se il tuo obiettivo è costruire una dorsale OT/IT ordinata, Sparkplug è oggi uno dei protocolli industriali più sensati da considerare.
Dove Sparkplug non basta
Detto questo, Sparkplug non è un fieldbus e non è nato per fare controllo deterministico di campo. Questo va detto senza ambiguità.
Se il progetto richiede sincronizzazione stretta tra controllori, comportamento temporale più prevedibile o un livello di interoperabilità di campo che va oltre il semplice scambio dati via broker, Sparkplug non è la risposta giusta. Può convivere con quei mondi, può trasportare telemetria e stato, ma non sostituisce una comunicazione field-level progettata per altri vincoli.
Ed è esattamente qui che il confronto si sposta su OPC UA FX. Questo però non basta per tutti gli scenari: quando il problema non è solo pubblicare dati ma costruire interoperabilità di campo, il discorso cambia parecchio.
OPC UA FX: field level, semantica e interoperabilità
Qui il focus si sposta: con OPC UA FX non si parla più solo di trasporto, ma di modello dati, interoperabilità e comunicazione field-level.
Da OPC UA PubSub a OPC UA FX
Per capire bene OPC UA FX, bisogna partire da OPC UA PubSub. La differenza rispetto a molte implementazioni industriali tradizionali è che OPC UA non si limita a un solo modello di middleware. Lo standard prevede sia una modalità broker-less, in cui i messaggi vengono scambiati direttamente sulla rete, sia una modalità broker-based, in cui si appoggia a un broker come intermediario.
Questo significa che OPC UA non è confinato a un solo paradigma. Può lavorare in architetture più vicine al field level, dove il broker è un elemento superfluo o persino indesiderato, ma può anche integrarsi con schemi più vicini al mondo IT.
Un altro punto importante è il mapping del dato. In OPC UA PubSub si può usare JSON, utile quando serve maggiore leggibilità o integrazione con software enterprise, oppure UADP, che offre una codifica binaria più efficiente e supporta meglio i meccanismi di message security. Questa flessibilità è importante, ma non è il centro della questione. Il vero punto di OPC UA FX è che punta a portare nel field level non solo un trasporto, ma una semantica condivisa e testabile.
Perché OPC UA FX è interessante oggi
Il valore di OPC UA FX non sta nel fatto che “usa OPC UA” in più. Sta nel fatto che prova a costruire una base comune per comunicazione industriale aperta tra controller e dispositivi. Questo significa meno integrazioni proprietarie, meno adattatori scritti ad hoc e più possibilità di far convivere componenti diversi dentro una logica comune.
La certificazione OPC UA FX per i controller è un segnale importante. Non perché da sola garantisca adozione universale, ma perché indica che il lavoro si sta spostando dal piano delle promesse al piano dei test reali, con script, profili e verifiche concrete. Per un progettista esperto, questo conta più di qualsiasi slogan.
OPC UA FX ha quindi senso quando il problema progettuale è interoperabilità field-level, comunicazione controller-to-controller e riduzione del lock-in. In una macchina modulare, in una linea composta da sistemi di vendor diversi o in un progetto che vuole ragionare in ottica architetturale e non solo di integrazione punto-punto, è una direzione molto più interessante di quanto fosse OPC UA client/server usato da solo qualche anno fa.
Dove OPC UA FX può essere eccessivo
Anche qui, però, serve realismo. OPC UA FX non è la risposta giusta a tutto.
Se stai progettando un nodo edge che deve raccogliere dati e portarli a un broker o a un backend analytics, adottare OPC UA FX può essere sproporzionato rispetto al problema. Lo stack è più ricco, il modello è più ampio, il lavoro di engineering è più pesante. È una soluzione forte quando il problema è davvero di architettura field-level e interoperabilità. Non quando serve semplicemente un canale di telemetria ben organizzato.
Questo è il punto in cui molti progetti sbagliano. Si sceglie OPC UA FX perché “sembra più industriale”, ma senza un caso d’uso che giustifichi davvero il suo costo di integrazione. Non sempre, però, serve uno stack così ricco: se il nodo è molto piccolo e l’ecosistema attorno è già DDS, conviene ragionare in un altro modo.
DDS-XRCE: quando il nodo è piccolo ma il sistema è DDS
Qui il problema è diverso: non si tratta di scegliere un protocollo generico, ma di far entrare un nodo embedded molto leggero in un’architettura DDS.
Cos’è davvero DDS-XRCE
DDS-XRCE è forse il più facile da fraintendere. Se lo si guarda superficialmente, può sembrare l’ennesimo protocollo industriale leggero. In realtà non nasce come alternativa generica né a Sparkplug né a OPC UA FX.
L’OMG lo definisce come specifica per ambienti extremely resource constrained. E la documentazione di Micro XRCE-DDS in micro-ROS chiarisce bene il modello: il dispositivo embedded molto piccolo non entra direttamente nel DDS Global Data Space come un peer completo, ma lo fa tramite un agent che media la sua presenza. Questo è il cuore del protocollo.
Quindi DDS-XRCE non va pensato come un protocollo general purpose per tutto l’IIoT industriale. Va pensato come il modo corretto di estendere un’infrastruttura DDS fino ai nodi con risorse molto limitate.
Il tema del footprint
Qui i numeri aiutano a capire se siamo nel campo del concreto o della teoria. La documentazione eProsima mostra che il client Micro XRCE-DDS può rimanere sotto i 2 KB di RAM per casi semplici, mentre micro-ROS, con un’applicazione publisher/subscriber già più realistica, parla di circa 3 KB di RAM e meno di 75 KB di flash. Per chi lavora su MCU davvero piccoli, non sono dettagli secondari.
Questa leggerezza non nasce per magia. Nasce dal fatto che molta della complessità viene spostata lato agent. E questo è anche il motivo per cui DDS-XRCE ha senso solo se l’ecosistema attorno è coerente con questa scelta. Se il sistema a monte è già DDS, allora questa architettura è naturale. Se non lo è, si rischia di introdurre una catena tecnica raffinata ma fuori scala rispetto al problema.
Quando DDS-XRCE conviene davvero
DDS-XRCE è molto sensato in robotica, in ambienti ROS 2, in sistemi distribuiti data-centric e in tutti i casi in cui il nodo embedded deve parlare con un’infrastruttura DDS senza portarsi addosso il peso di uno stack completo. Qui non è solo una scelta elegante: è spesso la scelta corretta.
Se invece il tuo progetto è una classica architettura edge-to-cloud con broker, historian e applicazioni enterprise, DDS-XRCE raramente è il primo candidato da considerare. Può funzionare, certo, ma spesso non è la soluzione più lineare né la più facile da mantenere.
A questo punto il confronto diventa più chiaro: non stiamo guardando tre alternative equivalenti, ma tre modelli architetturali distinti.
Tre protocolli industriali, tre modelli architetturali
La scelta vera parte sempre dal contesto: stesso impianto, stessi dati e stessi vincoli hardware possono portare a decisioni molto diverse.
A questo punto il quadro si semplifica molto. Sparkplug è il protocollo industriale da considerare quando il modello è broker-centric e il focus è telemetria, stato nodo e integrazione OT/IT. OPC UA FX è il protocollo industriale da considerare quando il modello è field-level interoperabile e il focus è far comunicare in modo aperto sistemi e controllori. DDS-XRCE è il protocollo industriale da considerare quando il modello è data-centric distribuito e il focus è far partecipare nodi embedded piccoli a un dominio DDS.
Questa distinzione vale più di qualsiasi benchmark isolato. Perché il protocollo, da solo, non determina la bontà del sistema. È il suo incastro con il resto dell’architettura a determinarla.
Quale protocollo industriale scegliere in pratica
Se devi fare telemetria edge e integrazione OT/IT
In questo caso, Sparkplug è il candidato più naturale. Hai un broker, vuoi pubblicare dati e stato in modo coerente, vuoi facilitare l’integrazione con SCADA, MES, historian o cloud, e ti serve una convenzione industriale sopra MQTT. È esattamente il suo mestiere.
Se devi fare comunicazione tra controllori e field level aperto
Qui ha molto più senso OPC UA FX. Non perché sia “più potente” in astratto, ma perché è stato pensato per una convergenza tra semantica, engineering e comunicazione di campo che altri protocolli non stanno cercando di risolvere allo stesso livello.
Se hai un nodo embedded piccolo dentro un ecosistema DDS
Qui il discorso cambia di nuovo. Se il sistema più ampio è già DDS o ROS 2, DDS-XRCE è la scelta tecnica coerente. Forzare il nodo in un altro paradigma solo perché più familiare al team può complicare inutilmente il progetto.
Gli errori da evitare
Il primo errore è scegliere il protocollo industriale in base alla moda del momento. Il secondo è sceglierlo in base al fatto che un vendor lo presenta come “la base del futuro”. Il terzo, il più grave, è ignorare il livello dello stack a cui appartiene il problema.
Sparkplug non è il protocollo giusto per chiudere un anello di controllo di campo. OPC UA FX non è la scelta più razionale per ogni semplice pipeline di telemetria. DDS-XRCE non è una risposta universale per l’IIoT embedded. Ognuno funziona bene quando viene usato nel problema per cui è stato progettato.
È qui che si vede se un’architettura è stata pensata o solo assemblata.
Conclusione
La sintesi utile, per chi progetta davvero, è questa. Sparkplug ha senso quando serve telemetria industriale strutturata su infrastruttura broker-based. OPC UA FX ha senso quando il progetto richiede interoperabilità field-level, controller-to-controller e una prospettiva aperta e certificabile. DDS-XRCE ha senso quando il nodo è piccolo ma il sistema complessivo è già DDS o deve diventarlo.
Il protocollo industriale giusto, quindi, non è quello più moderno né quello con la brochure migliore. È quello che appartiene al livello giusto dello stack e riduce, invece di aumentare, la complessità complessiva del sistema.
