Un PLC espone una variabile, un MES deve interpretarla, l’ERP richiede un dato coerente e il responsabile di produzione vuole vedere un KPI aggiornato. Il problema non è solo far transitare un valore da A a B: è conservarne significato, origine, qualità e sicurezza. Capire come funziona OPC UA serve proprio a questo:...
Come funziona OPC UA: dati con contesto, non solo segnali
Nei protocolli più tradizionali, un sistema legge spesso registri, indirizzi o tag definiti dal costruttore. Il valore è accessibile, ma il software che lo riceve deve sapere autonomamente cosa rappresenti: un contatore pezzi, una temperatura, un codice ricetta o un allarme. Questa logica può funzionare su un singolo impianto, ma diventa onerosa quando il parco macchine è eterogeneo.
OPC UA organizza invece le informazioni in uno spazio di indirizzamento strutturato, chiamato Address Space. Ogni elemento, o nodo, non contiene soltanto un valore. Può includere attributi come nome, tipo di dato, timestamp, stato di qualità, unità di misura, descrizione e relazioni con altri nodi.
Per esempio, il dato “pezzi prodotti” può essere esposto come una variabile associata a una specifica linea, a un turno o a un ordine di produzione. Un’applicazione MES non deve quindi limitarsi a leggere un intero numerico: può riconoscere l’oggetto produttivo a cui quel valore appartiene e trattarlo secondo regole coerenti.
Questa è la differenza più rilevante: OPC UA non è un semplice canale di comunicazione, ma un’architettura per rappresentare e scambiare dati industriali con un significato condiviso.
Il modello client-server
Nella configurazione più comune, un dispositivo o un software agisce da server OPC UA e pubblica i propri dati. Un altro sistema agisce da client OPC UA e si connette al server per leggere variabili, scrivere valori autorizzati, ricevere eventi o richiamare metodi.
Un PLC può quindi esporre tag di processo tramite il proprio server OPC UA integrato o attraverso un gateway. Un MES può collegarsi come client, selezionare le variabili utili e acquisire, ad esempio, stato macchina, velocità, quantità prodotte, scarti, fermi e allarmi.
La lettura può avvenire in polling, cioè con interrogazioni a intervalli definiti, oppure mediante subscription. Con le subscription, il client si iscrive ai cambiamenti di uno o più nodi e il server invia le notifiche quando cambiano i valori o si verificano eventi. Per monitoraggi real-time e raccolta dati di produzione, questo approccio riduce traffico inutile e ritardi legati a interrogazioni frequenti.
PubSub per distribuzioni dati più ampie
OPC UA include anche il paradigma PubSub, publish-subscribe. In questo caso chi produce il dato lo pubblica su un canale e i sistemi interessati lo ricevono senza dover stabilire necessariamente una relazione diretta client-server con ogni sorgente.
PubSub è utile quando gli stessi dati devono raggiungere più applicazioni o quando l’architettura richiede una distribuzione più ampia, ad esempio verso sistemi edge, piattaforme cloud o componenti analitici. Non sostituisce sempre il client-server: la scelta dipende da topologia di rete, quantità di destinatari, vincoli di latenza e funzioni richieste.
Sicurezza OPC UA: identità, cifratura e autorizzazioni
In fabbrica, collegare una macchina alla rete aziendale non significa automaticamente renderla pronta allo scambio dati con sistemi gestionali. La sicurezza deve proteggere sia il trasporto sia l’accesso alle informazioni e ai comandi.
OPC UA integra meccanismi basati su certificati digitali. Client e server possono verificare reciprocamente la propria identità prima di instaurare una sessione. I messaggi possono essere firmati e cifrati, così da ridurre il rischio di intercettazione o alterazione dei dati in transito.
L’autenticazione dell’utente o dell’applicazione può avvenire attraverso credenziali, certificati o altri meccanismi previsti dall’infrastruttura. A questo si aggiungono autorizzazioni granulari: un sistema può essere abilitato alla lettura dei dati di produzione, ma non alla scrittura di setpoint, ricette o comandi macchina.
La presenza di queste funzioni non elimina la necessità di una corretta progettazione. Certificati scaduti, policy permissive, porte esposte senza segmentazione di rete e account condivisi possono indebolire anche un’architettura ben standardizzata. OPC UA fornisce gli strumenti, ma la cybersecurity industriale richiede regole operative, gestione degli asset e responsabilità chiare tra IT, OT e fornitori.
Dal PLC al MES: il percorso del dato
Un progetto OPC UA efficace parte dai dati necessari alle decisioni operative, non dall’elenco completo dei tag disponibili. Acquisire migliaia di variabili senza un modello di utilizzo aumenta complessità, traffico e manutenzione, senza migliorare la visibilità dello stabilimento.
Per una linea produttiva, il set iniziale può comprendere stato macchina, codice allarme, contapezzi buoni e scarti, velocità istantanea, tempi di fermo, programma o ricetta attiva e identificativo dell’ordine. Il MES acquisisce questi dati, li normalizza e li mette in relazione con turni, operatori, articoli e commesse. Da qui diventano disponibili per dashboard, calcolo OEE, tracciabilità e consuntivazione.
Il passaggio critico è la normalizzazione. Due macchine possono esporre lo stesso concetto con tag diversi, tipi di dato differenti o logiche opposte. Un fermo può essere codificato come stato numerico in un PLC e come evento in un altro. Il livello di integrazione deve trasformare queste differenze in una struttura operativa uniforme, mantenendo però la possibilità di risalire alla sorgente originale.
In un’architettura cloud-native, un agente leggero on-premise può gestire la connessione con le reti di fabbrica e il trasferimento controllato dei dati verso la piattaforma. In questo modo non è necessario introdurre server locali dedicati per ogni progetto di raccolta dati, pur mantenendo separati e protetti i domini IT e OT. PLCinCloud utilizza questo approccio per collegare protocolli e sistemi produttivi a una piattaforma MES accessibile via browser.
Cosa verificare prima di integrare OPC UA
Non tutte le macchine offrono lo stesso livello di supporto OPC UA. Un PLC recente può includere un server nativo, mentre macchinari meno recenti potrebbero richiedere un gateway, un driver specifico o l’accesso tramite un protocollo differente. La compatibilità dichiarata va verificata sul modello effettivamente installato, sulla versione firmware e sulle licenze disponibili.
Occorre poi distinguere tra disponibilità tecnica del dato e qualità del dato. Se il PLC non raccoglie una causale di fermo affidabile, OPC UA può trasmettere lo stato ma non può inventare l’informazione mancante. Analogamente, un contatore pezzi utile alla manutenzione non sempre è sufficiente per una rendicontazione di produzione: potrebbero servire logiche di validazione, reset controllati e associazione all’ordine.
Anche la frequenza di acquisizione va dimensionata con criterio. Per KPI come quantità, stati e allarmi, aggiornamenti a evento o intervalli di pochi secondi sono spesso adeguati. Per applicazioni che richiedono sincronizzazione stretta, motion control o controllo in ciclo macchina, OPC UA non è automaticamente la scelta appropriata. Il suo valore principale è l’interoperabilità sicura tra livelli di automazione e sistemi informativi, non la sostituzione indiscriminata dei bus deterministici di campo.
Una progettazione che produce risultati misurabili
L’adozione efficace di OPC UA richiede una sequenza concreta: censire macchine e protocolli, identificare i dati necessari, verificare la disponibilità dei server o dei gateway, definire sicurezza e segmentazione, mappare i tag verso un modello produttivo e validare i risultati con casi reali di turno, lotto e fermo.
La fase di collaudo dovrebbe confrontare i dati acquisiti con ciò che accade realmente a bordo macchina. Se il sistema indica 500 pezzi prodotti e il conteggio fisico è diverso, il problema non va compensato in dashboard: va individuato nella logica sorgente, nel reset del contatore, nella gestione degli scarti o nella mappatura.
Quando OPC UA viene progettato come parte di un percorso MES, il suo risultato non è una connessione in più. È la disponibilità di dati affidabili per decidere con maggiore velocità: capire dove si perdono minuti, quali allarmi si ripetono, quanto incidono gli scarti e se una commessa sta rispettando tempi e quantità previste. È da questa continuità tra segnale di fabbrica e decisione operativa che l’interconnessione comincia a generare valore.