OPC UA, MQTT e Modbus a confronto

Una lettura della potenza attiva può attraversare tutti e tre i protocolli prima di arrivare a una piattaforma energetica. Lascia il contatore come due registri Modbus senza unità, ora o stato. Un PLC può esporla come nodo OPC UA con un tipo di dato, uno StatusCode e due timestamp. Lascia il sito come messaggio MQTT in un formato concordato in anticipo fra mittente e destinatario. Ogni passaggio può perdere parte di quel significato, e tutti i guasti di messa in servizio elencati più avanti si verificano in uno di questi passaggi.

Confronto

Registri Modbus e mappe dei registri

Quasi tutti i contatori elettrici, gli inverter e gli azionamenti hanno un'interfaccia Modbus. Il protocollo definisce quattro tabelle: coil e ingressi discreti (1 bit), registri di ingresso e registri holding (16 bit). Gli ingressi discreti e i registri di ingresso sono di sola lettura. Le coil e i registri holding consentono letture e scritture dove il dispositivo le permette. La funzione 03 legge i registri holding e la funzione 04 quelli di ingresso, fino a 125 registri contigui in una richiesta. La risposta non indica il significato dei bit. Unità, fattore di scala, tipo di dato e ordine delle word provengono dalla mappa dei registri del produttore; il protocollo non ha timestamp né stato. La guida alle mappe dei registri Modbus spiega cosa registrare per ogni punto.

Su RS-485, Modbus RTU è abbastanza lento da richiedere il dimensionamento dell'elenco di interrogazione. Con 8 bit di dati, parità pari e 1 bit di stop, ogni carattere occupa 11 bit. Una lettura di due registri comprende una richiesta da 8 byte e una risposta da 9 byte. A 9600 baud, quei 17 caratteri richiedono 19,5 ms sul filo. Aggiungi un intervallo silenzioso di 3,5 caratteri (4,0 ms) dopo ogni frame e il ritardo di risposta del contatore riportato nella sua scheda tecnica. Se ogni transazione richiede in totale 60 ms, 20 contatori con 4 letture ciascuno richiedono 4,8 s per scansione. Un bus RTU può essere interrogato da un solo master.

Modbus TCP elimina il limite della velocità di trasmissione ma introduce un limite alle connessioni. Molti contatori accettano solo poche connessioni TCP contemporanee e alcuni ne accettano una sola. Se un BMS e un gateway interrogano lo stesso contatore, uno dei due può perdere la connessione o andare in timeout senza un errore chiaro.

Spazio degli indirizzi, stato e sicurezza di OPC UA

OPC UA, definito nella serie OPC 10000 (IEC 62541), rappresenta un sistema come uno spazio degli indirizzi composto da nodi. Un client può esplorare, a partire da una pompa, la sua velocità, le ore di funzionamento e gli allarmi. Ogni lettura di una variabile restituisce un DataValue: il valore, il tipo di dato, uno StatusCode, un timestamp della sorgente dal dispositivo o dal PLC e un timestamp del server OPC UA.

I due bit più significativi dello StatusCode ne indicano la gravità (parte 4, 7.38.1): Good è 00, Uncertain è 01 e Bad è 10. Per esempio, UncertainLastUsableValue (0x40900000) significa che l'elemento che aggiornava il valore si è fermato. BadCommunicationError (0x80050000) significa che il server ha perso la sorgente. Un client che conserva il valore ma scarta lo StatusCode li trasforma in normali letture.

Le unità ingegneristiche non fanno parte di ogni nodo. La parte 8 definisce EngineeringUnits come proprietà opzionale delle variabili analogiche. Molti server espongono variabili semplici senza unità: in tal caso l'unità deve provenire dall'elenco dei punti.

OPC UA protegge ogni connessione con certificati applicativi. Il server offre endpoint, ciascuno con una policy di sicurezza e una modalità: None, Sign o SignAndEncrypt. Gli utenti si connettono in forma anonima, con nome utente e password oppure con un certificato. Disabilita l'endpoint None sul server. Se resta abilitato, un client configurato per accettare qualsiasi endpoint può connettersi senza firma né cifratura.

La guida all'identità dei nodi OPC UA spiega identificatori e namespace, mentre la guida alla migrazione da OPC DA tratta il passaggio da OPC Classic.

Broker, topic e contratti di payload MQTT

MQTT è un protocollo di trasporto. Un publisher invia un messaggio a un topic su un broker, che lo consegna a ogni client sottoscritto a quel topic. Publisher e subscriber non si connettono fra loro. Il broker diventa l'unico componente che tutti devono poter raggiungere e deve essere protetto. Un publisher non può sapere se un subscriber ha ricevuto un messaggio: serve una conferma applicativa o un messaggio di stato.

MQTT offre opzioni di consegna (QoS 0, 1 e 2), messaggi conservati e un last will. Con un intervallo keep-alive diverso da zero, un broker che non riceve alcun pacchetto di controllo MQTT da un client per 1,5 volte quell'intervallo chiude la connessione. Un will registrato viene pubblicato dopo la chiusura della connessione, secondo le regole di Will Delay e della sessione; non compare necessariamente alla soglia del keep-alive. La guida alla QoS di MQTT spiega le opzioni di consegna e la guida a MQTTS tratta TLS e i permessi sui topic.

MQTT non definisce il contenuto del messaggio. MQTT 5 aggiunge un indicatore del formato del payload, un tipo di contenuto e proprietà utente, ma non nomi di campi o unità. Ogni integrazione richiede un contratto di payload: struttura dei topic, nomi dei campi, unità, formato dei timestamp e modo di indicare i dati non validi. Se la piattaforma destinataria definisce un proprio formato, procurati la specifica di topic e payload prima della messa in servizio.

Due standard definiscono un contratto sopra MQTT. Sparkplug B (Eclipse Foundation, ISO/IEC 20237:2023) usa topic nella forma spBv1.0/group/message_type/edge_node/device e un payload Protocol Buffers. I messaggi NBIRTH e DBIRTH dichiarano ogni metrica e il suo tipo di dato. NDEATH è registrato come will del nodo. I messaggi dati (NDATA, DDATA) vengono pubblicati con QoS 0 e un numero di sequenza da 0 a 255 consente all'applicazione host di rilevare un messaggio perso e richiedere un nuovo messaggio birth. Anche OPC UA PubSub (parte 14) può usare un broker MQTT come trasporto, con codifica UADP o JSON. Con MQTT 3.1.1 i subscriber devono essere configurati in anticipo per la codifica.

Una lettura attraverso tutti e tre

Un contatore misura 200,5 kW di potenza attiva. La mappa dei registri colloca il valore nei registri holding 0 e 1, come float IEEE 754 a 32 bit con la word più significativa per prima.

Su Modbus, il gateway legge i due registri e ottiene 0x4348 e 0x8000. Uniti con la word più significativa per prima danno 0x43488000, ossia 200,5. Se il gateway mette prima la word meno significativa, ottiene 0x80004348, circa -2,4 × 10⁻⁴¹. Una dashboard lo visualizza come zero e il guasto sembra un carico inattivo. Il decoder dei registri Modbus mostra tutti e quattro gli ordini delle word per una coppia di registri.

Su OPC UA, un PLC che legge lo stesso contatore può esporlo come nodo ns=2;s=Meter1.ActivePower. Una lettura restituisce 200,5 come Float, con StatusCode Good (0x00000000), l'ora in cui il PLC lo ha campionato e quella in cui il server ha risposto. Se il PLC perde il contatore, il server può continuare a restituire 200,5 con UncertainLastUsableValue. Il valore è valido solo mentre lo stato è Good.

Su MQTT, un contratto JSON può trasportare il punto come {"point":"meter1/active_power","value":200.5,"unit":"kW","ts":"2026-09-24T10:15:00Z","quality":"good"}. Con Sparkplug B, lo stesso valore è una metrica Float in un messaggio DDATA sul topic spBv1.0/site-a/DDATA/gateway-1/meter-1, con timestamp in millisecondi dall'epoca Unix. Sparkplug non prevede un campo standard per lo StatusCode OPC UA. Concorda come trasmettere un valore Uncertain o Bad, per esempio come metrica null, prima di avviare il sito.

Guasti da provare durante la messa in servizio

La guida ai gateway di protocollo spiega cosa specificare per ogni punto tradotto. La guida all'ora della sorgente e di arrivo indica quale timestamp conservare.

Scegliere

La guida BACnet e Modbus tratta l'ambito degli edifici.

OPC UA, MQTT e Modbus con Edge

Edge sul Gateway ZGW-20 svolge il ruolo di gateway. Legge apparecchiature Modbus TCP e RTU. È anche un client OPC UA che legge nodi variabile a un intervallo impostato, da 1 s a 86.400 s. Supporta le modalità di sicurezza None, Sign e SignAndEncrypt, con accesso anonimo, tramite nome utente o tramite certificato. Mantieni corretto l'orologio del Gateway, perché la validazione dei certificati dipende da esso. I dispositivi wireless EpiSensor, i sensori LoRaWAN e i controllori BACnet/IP confluiscono nello stesso modello di dati.

Edge legge OPC UA tramite interrogazione periodica. Non usa sottoscrizioni OPC UA né PubSub, quindi non usa deadband lato server e può perdere una variazione più breve dell'intervallo di interrogazione. Ogni punto porta il timestamp dell'ora di lettura pianificata, non il timestamp della sorgente OPC UA. Il punto memorizzato non porta lo StatusCode OPC UA. L'indicatore di qualità di Edge è la quota delle letture attese arrivate in una finestra mobile di 15 minuti: è una misura diversa. Verifica come i valori Uncertain e Bad del server appaiono in Edge prima di fare affidamento su di essi.

Edge invia dati verso monte tramite MQTTS o HTTPS. Può anche presentare a un BMS i punti mappati come registri Modbus TCP, su un listener proprio alla porta 10502, non 502.