Lavori nell’automazione industriale, senti spesso parlare di OPC UA e vuoi capire cos’è e come usare questo protocollo?
Sei capitato nel posto, giusto!
In questa serie di articoli andremo a vedere più da vicino cos’è OPC UA e come poter sviluppare delle applicazioni client e server utilizzando le API .NET fornite dalla OPC Foundation.
Direi di cominciare con una breve introduzione sulla piattaforma!
OPC Classic
Fino agli anni 90, quando si doveva integrare un dispositivo industriale in un’interfaccia grafica, era necessario innanzitutto capire che protocollo andare ad usare.
Sebbene esistessero già protocolli largamente diffusi, spesso i dispositivi da integrare ne usavano di diversi, rendendo il lavoro dello sviluppatore molto dispendioso.
Poichè le interfaccie grafiche venivano nella totalità dei casi sviluppate in ambiente Windows, si decise di semplificarsi la vita introducendo una nuova piattaforma di comunicazione, tuttoggi utilizzata, chiamata OPC (Open Platform Communication).
L’OPC basa il suo funzionamento sulle intefaccie proprietarie Microsoft COM (Component Object Model) e DCOM (Distributed Component Object Model) le quali permettono la comunicazione tra processi in esecuzione.
Grazie a queste, lo sviluppatore HMI può comunicare con un OPC Server che agisce da interfaccia con i dispositivi esterni.
Il produttore di un componente industriale, deve semplicemente sviluppare un driver di comunicazione OPC Client per rendere la sua integrazione molto più immediata.
La trasmissione di dati tra client e server in OPC Classic avviene attraverso diverse interfaccie definite a seconda dello scopo, le principali sono:
- DA (Data Access): permette ai client di leggere, scrivere e monitorare variabili in real time;
- HA (Historical Access): utilizzato per accedere a dati già immagazzinati;
- A&E (Alarms and Events): gestisce allarmi e notifiche di eventi.
OPC UA
Con il passare degli anni, l’utilizzo nell’industria di dispositivi Unix ha portato rapidamente alla necessità di estendere le funzionalità di questa piattaforma altrimenti applicabile solo ai sistemi Windows.
Oltre a questo, OPC Classic risultava uno strumento povero nello scambio dati, permettendo di trasferire unicamente tipi di dato primitivo.
Intorno al 2008 nasce, quindi, la seconda versione chiamata OPC Unified Architecture la quale, tra le tante cose, offre:
- piena compatibilità con i sistemi operativi più diffusi (Windows, Linux e Mac);
- supporto ai protocolli internet per la comunicazione distribuita;
- descrizione di modelli di dato complessi con un approccio molto simile al paradigma OOP;
- possibilità di esporre metodi remoti;
Punti di Forza
Possiamo affermare che OPC UA si basa su 3 pilastri fondamentali: il meccanismo di trasporto, la gestione di chiamate a metodi remoti e il modello di descrizione dei dati.
Per quanto riguarda il primo punto, OPC UA supporta sia un protocollo binario basato su TCP che garantisce elevate prestazioni in trasmissione, sia due protocolli di comunicazione web ampiamente diffusi quali HTTPS e SOAP.
Ciò permette di estendere la precedente versione, aggiungendo di fatto la possibilità di comunicare anche via Internet tra dispositivi diversi.
La possibilità, poi, di chiamare metodi remoti, rende il protocollo uno strumento incredibile per espandere le potenzialità di dispositivi quali i PLC. Per chi non lo sapesse, il PLC è un controllore programmabile ampiamente utilizzato nell’automazione industriale per la sua affidabilità e stabilità. Di contro, i sistemi PLC sono molto grezzi e non offrono le stesse possibilità che un PC può dare.
Per fare un esempio, se volessimo che un PLC scriva in un database, dovremmo per forza utilizzare un PC come mediatore e implementare, poi, metodi complessi e difficili da gestire per permettere la comunicazione tra i il PLC e il PC.
OPC UA in questo senso, estende le caratteristiche dei PLC, rendendo semplice e immediata la chiamata a metodi remoti.
Un PC con un OPC Server, quindi, può esporre dei metodi più o meno sofisticati, come delle funzioni di lettura/scrittura a database, che possono essere evocate dal PLC al bisogno.
Parlando infine di Data Modeling, OPC UA offre un completo sistema di modellazione che permette di descrivere dati di complessità variabile.
Questo è senz’altro il punto di forza più importante di tutta la piattaforma in quanto è possibile creare sistemi in cui lo scambio dei dati avviene con un’infrastruttura completamente decentralizzata.
Automation Pyramid
Per capire meglio le implicazioni di quanto appena detto, è necessario introdurre il concetto di piramide dell’automazione.
L’automation pyramid è una struttura che descrive i differenti livelli di automazione in un impianto produttivo ed è un ottimo esempio di come la tecnologia viene interpretata in ambito industriale.
Alla base della piramide abbiamo il livello di campo. Questo rappresenta dipositivi, attuatori e sensori che vengono installati in una linea di produzione.
Il successivo prende il nome di livello di controllo. In questo caso si fa riferimento a PLC e PID, quei dispositivi che si occupano di gestire il livello di campo. Un PLC, ad esempio, raccoglierà i dati dai sensori installati sulla linea, invierà comandi agli attuatori e prenderà decisioni su quale logica eseguire.
Il terzo livello della piramide prende il nome di livello supervisione. Se nel precedente facevamo uso di PLC, in questo caso si fa uso degli SCADA (Supervision Control and Data Acquisition).
Uno SCADA non è altro che uno strumento che combina i livelli precedenti permettendo di visualizzare i dati e controllare gli elementi sul campo da un unico punto. Normalmente ciò è possibile grazie anche all’aiuto di un’interfaccia, nota come HMI.
Si tende a confondere spesso lo SCADA con l’HMI, ciò perchè il più delle volte queste due entità sono fuse insieme.Per capire la reale differenza, vale la pena ricordare che uno SCADA può monitorare e controllare diversi sistemi installati in uno stabilimento e non è limitato ad una singola macchina come invece avviene per le HMI.
Il quarto livello della piramide è chiamato livello di pianificazione. Qui si fa uso di sistemi conosciuti sotto il nome di MES (Manufacturing Execution System) i quali hanno il compito di monitorare l’intero processo produttivo in un impianto: dal materiale grezzo fino al prodotto finito.
L’ultimo livello infine prende il nome di livello di gestione. In questo caso si fa uso di sistemi chiamati ERP (Enterprise Resource Planning).
OPC UA e Smart Manufacturing
Una struttura come quella appena presentata è necessaria quando si ha a che fare con dispositivi che sono in grado di trasmettere solo dati grezzi.
Questi, prima di essere presentati ad un livello superiore, devono essere raccolti ed interpretati.
Con l’avvento del concetto di industria 4.0 questa visione sta via via venendo soppiantata da un’altra struttura totalmente decentralizzata conosciuta anche come smart manufacturing.
L’idea è quella di avere dispositivi sufficientemente sofisticati da inviare dati in autonomia ai vari strumenti di controllo, SCADA, MES o ERP che siano.
Così facendo, ad esempio, anzichè lasciare al PLC l’onere di raccogliere dati da sensori dummy, per poi organizzare l’informazione e presentarla al piano dello SCADA, si può lasciare che siano i sensori stessi ad inviare dati complessi direttamente allo SCADA, lasciando al PLC l’unico compito di gestire l’andamento della produzione.
Per poter fare ciò, è fondamentale avere un protocollo di comunicazione che consenta di gestire dati complessi.
Proprio in questo scenario OPC UA fa il suo ingresso e cambia le carte in gioco, permettendo di rappresentare l’informazione in unità chiamate nodi.
Per fare un parallelo in termini OOP, un nodo non è altro che una classe la quale può essere composta da attributi e metodi.
Come una classe, ciascun nodo, una volta descritto, può essere istanziato in diversi oggetti dando vita a modelli a complessità crescente.
Conclusioni
In questo articolo abbiamo fatto un breve excursus prettamente teorico su cos’è OPC UA e quali sono i suoi punti di forza.
Nei prossimi articoli andremo ad analizzare più a fondo le caratteristiche del data modeling, creando un modello che descrivere una semplice linea produttiva e pubblicando questo modello su un OPC Server progettato con le librerie .NET fornite dalla OPC Foundation.
Proseguiremo il nostro viaggio poi con un ulteriore articolo dove vedremo come sviluppare un semplice OPC Client, sempre basato sulle stesse librerie.
Scrivi un commento