OPC UA: cos'è e come funziona, da modelli informativi e PubSub a sicurezza e FX

OPC UA (Open Platform Communications Unified Architecture) è lo standard con cui le macchine industriali espongono i propri dati insieme al loro significato. Una macchina esegue un server OPC UA che pubblica un modello strutturato e tipizzato di sé stessa: questa è una pompa, ha una velocità in giri al minuto, una temperatura del cuscinetto, uno stato di marcia e un metodo Start. Un client come uno SCADA, un MES o un gateway edge può esplorare quel modello, leggere e scrivere valori, sottoscrivere le variazioni e chiamare metodi, il tutto su una connessione cifrata e autenticata.

La OPC Foundation ha rilasciato OPC UA nel 2008 come successore indipendente dalla piattaforma di OPC Classic, legato a Windows attraverso COM/DCOM di Microsoft. La specifica è mantenuta dalla Foundation come serie OPC 10000, pubblicata gratuitamente sul suo sito di riferimento, ed è standardizzata a livello internazionale come serie IEC 62541. Questa guida tratta il modello informativo, i due schemi di comunicazione, la sicurezza, le companion specification, la più recente estensione per il livello di campo chiamata OPC UA FX e il rapporto tra OPC UA, MQTT e Sparkplug.

Quale problema risolve OPC UA?

Un PLC che parla Modbus offre registri numerati: il registro 40001 contiene un valore, e solo la documentazione dice che è la velocità del motore in decimi di punto percentuale. Ogni integrazione parte da un foglio di calcolo che associa indirizzi e significati, e ogni nuova macchina ripete il lavoro.

OPC UA porta quel significato dentro il protocollo. Il server dice al client che cos’è ogni valore, di che tipo è e in quale unità ingegneristica, come si collega ad altri valori e a quale tipo di apparecchiatura appartiene. Un client scritto una volta per un modello standard di pompa o di robot può collegarsi all’implementazione di quel modello di qualsiasi produttore. È la promessa di interoperabilità, ed è il motivo per cui OPC UA compare nella maggior parte delle architetture di riferimento di Industria 4.0.

Come funziona il modello informativo?

Tutto ciò che un server espone vive nel suo spazio degli indirizzi (address space), un grafo di nodi collegati da riferimenti tipizzati. Il modello dello spazio degli indirizzi definisce un piccolo insieme di classi di nodo: Object (una pompa, un sensore, una cartella), Variable (un valore di temperatura con il suo timestamp e il suo stato), Method (Start, Reset), i corrispondenti ObjectType e VariableType, i ReferenceType che danno un nome alle relazioni come HasComponent o Organizes, i DataType e le View.

Sono i tipi a rendere utile il modello. Un produttore definisce un PumpType con i componenti attesi, ogni pompa della linea ne è un’istanza, e un client che conosce PumpType le gestisce tutte senza conoscere l’impianto. I tipi possono ereditare da altri tipi, quindi un tipo di pompa centrifuga può estendere un tipo di pompa generico. Ogni variabile porta un valore, un timestamp della sorgente e un codice di stato, così il client distingue una lettura fresca e valida da una vecchia o incerta.

In che cosa differiscono client/server e PubSub?

Lo schema originale è client/server. Il client apre un SecureChannel, poi una Session, e chiama i servizi: Browse per esplorare lo spazio degli indirizzi, Read e Write per i valori, Call per i metodi e CreateSubscription con i monitored item, così è il server a inviare le variazioni invece di essere interrogato a ciclo. Il trasporto abituale è il protocollo binario OPC UA TCP, sulla porta 4840 registrata presso IANA; per i client web esistono mappature su HTTPS e WebSocket. Il client/server è adatto a configurazione, diagnostica e letture di supervisione, dove ogni client ha bisogno della propria vista.

Il PubSub (Parte 14) aggiunge uno schema uno a molti. Un publisher invia DataSet, gruppi di valori con un nome, senza sapere chi li riceve. La specifica prevede due forme: senza broker, in cui i messaggi viaggiano come datagrammi UDP (spesso multicast) o frame Ethernet in una codifica binaria compatta chiamata UADP, e con broker, in cui i messaggi passano per un broker MQTT o AMQP in UADP o JSON. Il PubSub senza broker è adatto a scambi rapidi e frequenti dentro una cella; la forma con broker porta lo stesso modello di dati fino al cloud. Publisher e subscriber non devono essere per forza server o client.

Come si protegge OPC UA?

La sicurezza fa parte del modello di sicurezza di base, non è un’aggiunta. Ogni applicazione, client o server, ha un certificato di istanza dell’applicazione, un certificato X.509 che identifica quell’installazione del software. Quando si apre un SecureChannel, ciascuna parte verifica il certificato dell’altra rispetto a una lista di fiducia (trust list), poi le due concordano una security policy (la suite di algoritmi) e una modalità di sicurezza: None, Sign o SignAndEncrypt. La specifica richiede che None sia disattivata per impostazione predefinita. Sopra il canale, gli utenti si autenticano con nome utente e password, un certificato X.509 o un JSON Web Token, e i ruoli possono limitare che cosa ogni utente può esplorare, scrivere o chiamare. Il PubSub usa un Security Key Service che distribuisce le chiavi simmetriche condivise da un gruppo di publisher e subscriber.

Il punto debole, in pratica, è la gestione dei certificati. Negli stabilimenti con molti server si finisce per cliccare “trust” su ogni nuovo certificato o, peggio, per lasciare gli endpoint in modalità None. Un Global Discovery Server può fare da gestore dei certificati e distribuire certificati e trust list alle applicazioni, ed è la risposta che scala. Vale la stessa disciplina PKI descritta nella guida all’identità dei dispositivi, e i prodotti OPC UA vengono spesso valutati rispetto alla IEC 62443.

Che cosa sono le companion specification?

Una companion specification è un modello informativo standard per un tipo di apparecchiatura, scritto di solito dalla OPC Foundation insieme a un’associazione di settore. Il sito di riferimento ne elenca molte: OPC 10000-100 per i dispositivi in generale, OPC 40001-1 per gli elementi base delle macchine, OPC 40010-1 per la robotica, OPC 40501-1 per le macchine utensili, OPC 40223 per pompe e pompe da vuoto, OPC 30050 per le macchine di confezionamento PackML, e decine di altre. Ognuna definisce gli ObjectType che una macchina conforme espone, pubblicati come file NodeSet leggibili dalle macchine che server e client possono caricare.

È nelle companion specification che la promessa di interoperabilità viene mantenuta o tradita. Un server che espone solo una cartella piatta di tag con nomi decisi dal produttore è tecnicamente OPC UA, ma fa risparmiare poco all’integratore. Quando acquisti un’apparecchiatura, chiedi quali companion specification implementa.

Che cos’è OPC UA FX?

OPC UA FX (Field eXchange) estende OPC UA fino al livello di campo, dove controller e dispositivi si scambiano dati di processo in tempo reale, il territorio di PROFINET, EtherCAT e degli altri bus di campo. È pubblicato come Parti da 80 a 84. La versione attuale copre la comunicazione da controller a controller: le connessioni vengono configurate attraverso il modello informativo e trasportano i dati via PubSub, eventualmente su Time-Sensitive Networking per una latenza limitata, con OPC UA Safety per la sicurezza funzionale. Gli scambi da controller a dispositivo e da dispositivo a dispositivo, e le connessioni via client/server, sono previsti in versioni successive. FX è agli inizi: per ora progetta le reti di cella attorno al bus di campo supportato dal fornitore del controller e considera FX una direzione da seguire.

Come si confronta OPC UA con MQTT e Sparkplug?

MQTT trasporta byte su topic e non dice nulla del loro significato. Sparkplug, una specifica Eclipse pubblicata come ISO/IEC 20237, aggiunge sopra MQTT un namespace dei topic, un formato di payload per le variabili di processo e regole per lo stato delle sessioni. OPC UA porta il modello più ricco e la sicurezza integrata più robusta, al prezzo di stack più complessi.

Aspetto	OPC UA client/server	OPC UA PubSub	MQTT con Sparkplug
Schema	Richieste e sottoscrizioni per sessione	Uno a molti, senza broker o con broker	Uno a molti tramite broker
Modello dei dati	Spazio degli indirizzi tipizzato, companion spec	Stesso modello, inviato come DataSet	Metriche con nome, tipo e metadati
Sicurezza	Certificati, canale firmato e cifrato	Chiavi di gruppo da un key service	TLS verso il broker, regole di accesso
Collocazione tipica	Macchina e cella, SCADA, MES	Da cella a cella, da cella a cloud	Dallo stabilimento all’azienda e al cloud

L’architettura più comune usa entrambi. Le macchine espongono server OPC UA; un gateway edge li legge e ripubblica su MQTT, spesso con Sparkplug, verso un broker i cui topic vengono sottoscritti dal resto dell’azienda. Scegli OPC UA quando devi esplorare, scrivere, chiamare metodi o contare su una companion specification; scegli MQTT e Sparkplug per distribuire i dati a molti consumatori su più siti. La guida a MQTT tratta il lato broker.

Per continuare

Industrial IoT: una guida pratica colloca OPC UA nell’architettura dello stabilimento.
La guida a MQTT tratta il broker che trasporta il traffico PubSub e Sparkplug.
Identità dei dispositivi, certificati e PKI per l’IoT spiega il lavoro sui certificati dietro la sicurezza di OPC UA.
La guida ai gemelli digitali mostra dove viene usato poi un modello tipizzato della macchina.

Argomenti: OPC UA, protocolli industriali, IIoT, PubSub, Sparkplug