Modbus o OPC UA? Differenze e quando usarli

Modbus in breve

Modbus nasce nel 1979 per i controllori Modicon ed è rimasto, per la sua semplicità, il linguaggio di contatori, analizzatori di rete, inverter e strumenti di ogni marca. Funziona a richiesta e risposta: un client (nella terminologia originale, il master) chiede un valore a un server (lo slave) e lo riceve. Su Ethernet è Modbus TCP, sulla porta 502; su linea seriale RS-485 è Modbus RTU.

Il modello dati è una tabella di quattro blocchi, senza nomi e senza tipi: i dati sono solo bit e registri a 16 bit, identificati da un indirizzo.

Le conseguenze pratiche sono tre. Primo, un valore a 32 bit o in virgola mobile occupa due registri, e l'ordine di parole e byte non è fissato dalla specifica: ogni produttore sceglie, e il manuale dello strumento è l'unica fonte. Secondo, un valore con decimali è di solito un intero scalato (l'energia in decimi di kWh), e il fattore sta di nuovo nel manuale. Terzo, gli indirizzi dei manuali usano a volte una numerazione che parte da 1 e un prefisso (come 40001 per il primo holding register), mentre sul filo l'indirizzo parte da 0: il più comune errore di messa in servizio è uno scarto di uno.

Modbus non ha sicurezza nativa: non autentica chi chiede e non cifra, e chiunque raggiunga la porta 502 può leggere e, dove consentito, scrivere. Esiste una variante con TLS (Modbus/TCP Security, porta 802), poco diffusa sui dispositivi. Non ha sottoscrizioni: chi vuole il valore aggiornato deve richiederlo a intervalli (polling), e il dato non porta un'ora di misura né un indicatore di qualità.

OPC UA in breve

OPC UA (norma IEC 62541) è un'architettura client-server, non un semplice elenco di registri. Il server espone uno spazio degli indirizzi: un albero di nodi (oggetti, variabili, metodi) che il client può esplorare, il browsing, senza avere un manuale. Ogni nodo ha un identificativo (un indice di namespace e un nome o un numero), un tipo di dato e attributi: unità di misura, intervallo, descrizione.

Un valore letto porta con sé il tipo, l'ora della sorgente e un codice di qualità: un dato scaduto o senza sensore si distingue da uno zero reale. I client possono anche chiamare metodi, per esempio per avviare una ricetta, e le companion specification definiscono modelli standard per intere famiglie di macchine.

Per ricevere dati non serve interrogare di continuo: il client crea una sottoscrizione su uno o più nodi (monitored item), indica ogni quanto il server deve campionare e un'eventuale soglia di variazione (deadband), e il server invia i valori solo quando cambiano. Il server ascolta di solito sulla porta 4840 (indirizzo opc.tcp://host:4840), anche se molti prodotti ne usano un'altra; per trovare i server si possono usare i servizi di discovery.

La sicurezza è nel protocollo. Si sceglie una security policy (per esempio Basic256Sha256 o Aes128_Sha256_RsaOaep; le più vecchie, come Basic128Rsa15, sono deprecate) e una modalità del messaggio: nessuna, firma, oppure firma e cifratura. Client e server si riconoscono con certificati X.509 che l'amministratore deve approvare, e l'utente può autenticarsi con nome e password o con certificato. È più da configurare di Modbus, ma è il più completo dei tre quanto a protezione del canale.

Tabella di confronto (dati, sicurezza, scoperta, costo)

E i PLC Siemens S7?

I PLC Siemens parlano S7comm, un protocollo proprietario su TCP, incapsulato nello standard ISO-on-TCP, sulla porta 102. Un client (una libreria, un gateway o un sistema come Muvia Industrial) legge e scrive porzioni della memoria del PLC indicando l'area, l'indirizzo e la lunghezza: un data block (DB), gli ingressi, le uscite, i merker.

Sui PLC S7-1200 e S7-1500 l'accesso di questo tipo è disabilitato per impostazione predefinita, per ragioni di sicurezza: nelle proprietà della CPU va abilitato il permesso di accesso con comunicazione PUT/GET da un partner remoto, e i data block a cui si accede per indirizzo devono avere l'accesso ottimizzato ai blocchi disattivato, altrimenti l'offset dei dati non è fisso. Sono impostazioni del programma del PLC, quindi vanno concordate con chi lo ha scritto.

L'alternativa, dove c'è, è OPC UA: le CPU S7-1500 hanno un server OPC UA integrato; per le altre famiglie dipende dal modello, dal firmware e dalla licenza. Un server OPC UA espone variabili con il loro nome e non obbliga a conoscere gli offset dei data block. Se il PLC non lo ha, S7 per indirizzo resta il canale pratico.

Serve un gateway?

Un gateway serve quando il protocollo che la macchina parla non è quello che il sistema a valle sa leggere. I casi tipici:

• Linea seriale: uno strumento in Modbus RTU su RS-485 non ha una porta Ethernet. Un convertitore da RTU a TCP lo rende raggiungibile in Modbus TCP, e i driver di Muvia Industrial leggono Modbus solo su reti TCP.
• Protocollo non disponibile: una macchina che parla solo il suo bus di campo o un protocollo proprietario si collega con un gateway che lo espone in Modbus TCP o in OPC UA.
• Sicurezza di rete: un server OPC UA o un gateway nel livello di rete giusto evita di aprire le porte 502 e 102 dei PLC a tutta la rete dello stabilimento. Il PLC parla con il gateway, e la rete aziendale solo con il gateway.
• Un'unica porta per molte macchine: raccogliere i dati di più PLC in un server OPC UA e leggere solo quello.

Non serve un gateway se la macchina ha già una porta Ethernet con uno dei protocolli che il sistema legge. Prima di acquistare qualsiasi cosa, fatevi confermare dall'ingegnere della macchina quale interfaccia espone e come si abilita: spesso c'è già, e si tratta solo di attivarla.

MQTT: dove si colloca

MQTT non è un concorrente di Modbus e OPC UA, ma un'altra cosa: un trasporto leggero di messaggi con il modello publish/subscribe. I dispositivi pubblicano su un topic e un broker li distribuisce a chi si è iscritto; ci sono tre livelli di garanzia di consegna (QoS 0, 1 e 2) e le porte consuete sono la 1883 e la 8883, con TLS. MQTT non dice cosa c'è dentro il messaggio: per darlo un significato industriale esistono specifiche come Sparkplug B, e OPC UA PubSub può viaggiare anch'esso su MQTT.

Il suo posto è più spesso a monte che a bordo macchina: porta i dati da un sito a un sistema centrale, su reti con collegamenti lenti o instabili. Dal PLC al nodo di raccolta, nello stabilimento, i protocolli sono ancora quelli di questa guida. I driver di Muvia Industrial sono Siemens S7, OPC UA, Modbus TCP, tabelle SQL Server e SEW-Eurodrive: una macchina che pubblica soltanto su MQTT si collega interponendo un gateway che la esponga in uno di questi.

Dalla macchina al cruscotto

Quale che sia il protocollo, il percorso è lo stesso, in cinque passi:

• Scegliere l'interfaccia che la macchina espone, con l'ingegnere che la conosce, e abilitarla (PUT/GET, server OPC UA, porta Modbus).
• Elencare le variabili che servono, con indirizzo o nodo, tipo, scala e unità. Poche e utili: contapezzi, stato, causale di fermo, un paio di temperature e pressioni.
• Dare a ciascuna un nome di tag leggibile e stabile, che sopravviva a una sostituzione del PLC.
• Scegliere come leggere: a intervalli regolari, o per sottoscrizione dove il protocollo la prevede, con l'intervallo che serve davvero (leggere ogni secondo ciò che cambia ogni ora spreca solo risorse).
• Portare i dati dove si usano: cruscotti, allarmi, calcoli, report.

Con Muvia Industrial i driver girano sul nodo vicino alle macchine, leggono le variabili che scegliete e le trasformano in tag con un nome; se il collegamento al cloud cade il nodo conserva i dati in un buffer locale. Dove il protocollo lo prevede si può anche scrivere (Siemens S7 e OPC UA), e un simulatore permette di costruire cruscotti e allarmi prima di collegare la linea. I dati arrivano quindi nelle stesse fonti di Muvia di gestionale e CRM, per incrociare ciò che fa la macchina con ordini e articoli. Un percorso di esempio è il caso d'uso sulle macchine connesse per i costruttori; le grandezze che si ricavano si leggono nella guida ai KPI di produzione.