Studio di un recente Standard di Comunicazione e Integrazione Dati in ambito industriale: OPC Unified Architecture - Ingegneria Informatica
←
→
Trascrizione del contenuto della pagina
Se il tuo browser non visualizza correttamente la pagina, ti preghiamo di leggere il contenuto della pagina quaggiù
Scuola Politecnica e delle Scienze di Base Corso di Laurea in Ingegneria Informatica Elaborato finale in Reti di Calcolatori Studio di un recente Standard di Comunicazione e Integrazione Dati in ambito industriale: OPC Unified Architecture Anno Accademico 2018/2019 Candidato: Francesco Garofalo matr. N46000830
Verso l’infinito e oltre. Toy Story.
Indice
Indice.................................................................................................................................................. III
Introduzione ......................................................................................................................................... 4
Capitolo 1: Industry 4.0 Communication Protocols ............................................................................ 7
1.1 Classic OPC ............................................................................................................................... 9
1.2 OPC Data Access ..................................................................................................................... 10
1.3 OPC Alarm & Events............................................................................................................... 12
1.4 OPC Historical Data Access .................................................................................................... 13
Capitolo 2: OPC UA .......................................................................................................................... 14
2.1 OPC UA Software Layers........................................................................................................ 16
2.2 Information Model ............................................................................................................. 18
2.2.1 AddressSpace .................................................................................................................... 19
2.2.2 Node Model ...................................................................................................................... 19
2.2.3 Reference .......................................................................................................................... 20
2.2.4 View .................................................................................................................................. 21
2.2.5 Namespace ........................................................................................................................ 21
Capitolo 3: OPC UA IMPLEMENTATION ..................................................................................... 22
3.1 Data sharing service (Read and Write) .............................................................................. 23
3.2 Subscription Service .......................................................................................................... 24
3.3 OPC UA OpenSource example .......................................................................................... 26
3.3.1 Preparing ........................................................................................................................... 26
3.3.2 Running the Server ........................................................................................................... 27
3.3.3 Running the Client ............................................................................................................ 28
3.3.4 Connect ............................................................................................................................. 28
3.3.5 Browse .............................................................................................................................. 29
3.3.6 Subscribe ........................................................................................................................... 29
3.3.7 Write and Read ................................................................................................................. 30
Conclusioni ........................................................................................................................................ 31
Bibliografia ........................................................................................................................................ 33
Introduzione
Il principale sforzo nello sviluppo del software di automazione negli anni passati è stato
l'accesso ai dati di automazione, in dispositivi in cui viene utilizzato un numero
innumerevole di diversi sistemi bus, protocolli e interfacce.
Un problema simile esisteva per le applicazioni software all’accesso alle stampanti, in cui
ogni applicazione doveva scrivere i propri driver per ogni stampante supportata.
MS Windows ha risolto il problema incorporando il supporto della stampante nel sistema
operativo.
Questa interfaccia del driver forniva servizio a tutte le applicazioni che avevano bisogno
dell’utilizzo della stampante. Questi driver sono forniti dai produttori della stampante e non
dagli sviluppatori delle applicazioni.
Poiché i fornitori di software HMI (Human Machine Interface) e SCADA (Supervisory
Control and Data Acquisition) avevano problemi simili, nel 1995 è stata fondata una task
force avviata dalle società Fisher-Rosemount, Rockwell Software, Opto 22, Intellution e
Intuitive Technology. L'obiettivo della task force era definire uno standard Plug & Play per
i driver di dispositivo, che fornisse un accesso standardizzato ai dati di automazione sui
sistemi basati su MS Windows. Il risultato è stata la specifica di accesso ai dati definita OPC
(OLE for Process Control), rilasciata dopo poco tempo nell'agosto1996. L'organizzazione
no-profit che sta mantenendo questo standard è la Fondazione OPC.
4
Quasi tutti i fornitori di sistemi per l'automazione industriale sono diventati membri
dell’OPC Foundation. Uno dei motivi di questo successo è stata la riduzione delle
funzionalità principali e la restrizione alla definizione di API (Application Protocol
Interface) che utilizzano le tecnologie Microsoft Windows Component Object Model
(COM) e Distributed COM (DCOM), interfacce che permettono la comunicazione tra
processi. L’esperienza maturata ha portato ad una nuova versione della specifica: OPC Data
Access, che è stata introdotta nel 1998. Questa versione ha consentito ad una maggiore
diffusione dello standard. La seconda versione di OPC Data Access è l'interfaccia più
importante dei prodotti OPC.
Sistemi SCADA e HMI, gestione dei processi e sistemi di controllo distribuito (DCS),
sistemi di controllo basati su PC e Manufacturing Execution Systems (MES) devono
supportare le interfacce OPC oggi. OPC è lo standard, universalmente accettato, che offre
la possibilità di scambiare dati tra diversi sistemi di automazione industriale, nell'industria
manifatturiera e di processo. Negli ultimi anni la Fondazione OPC ha definito una serie di
interfacce software
per standardizzare il flusso di informazioni dal livello di processo al livello di gestione.
OPC è un’architettura client/server che permette ad un qualsiasi processo (Client) basato su
OPC di accedere a qualsiasi sorgente di dati (Server) dotata di interfacce OPC. Il primo
standard OPC di successo è stato - OPC Data Access COM/DCOM, concepito per definire
interfacce Client/Server per l’accesso in lettura scrittura ai dati di processo, permettendo
una semplice integrazione di tutti i dispositivi hardware/software per l’automazione.
OPC-DA non è stato ampiamente adottato nei sistemi di automazione industriale che non
utilizzavano standard COM, e dalle limitazioni dei meccanismi forniti per l’accesso remoto
da DCOM.
Poi altri standard come OPC Alarms and Events e OPC Historical Data Access, ampiamente
accettati nel settore e implementati da quasi tutti i sistemi destinati all’automazione
industriale. Ora OPC Foundation ha rilasciato una nuova generazione di specifiche OPC
denominate OPC Unified Architecture.
5
OPC Unified Architecture unifica le specifiche precedenti in un unico spazio di indirizzi in
grado di gestire i dati correnti, gli allarmi e gli eventi, la cronologia dei dati correnti e degli
eventi. Un notevole miglioramento di OPC UA è il modello di spazio degli indirizzi, grazie
al quale i fornitori possono esporre un modello informativo ricco ed estensibile utilizzando
tecniche orientate agli oggetti.
OPC UA si adatta bene a dispositivi intelligenti, controller, sistemi DCS e SCADA fino a
sistemi MES e ERP.
6
Capitolo 1: Industry 4.0 Communication Protocols
L’industria 4.0 di cui spesso si sente parlare, è un processo di cambiamento all’adozione
nelle fabbriche di sistemi di lavorazione intelligenti e totalmente automatizzati.
Si adottano nelle aziende impianti a macchine robotizzate, in grado di prendere delle
decisioni in maniera autonoma (machine learning, data mining). Vengono adottati inoltre
Cyber-Physical System. I CPS sono dei sistemi informatici che permettono alle macchine
di comunicare e operare a stretto contatto con il mondo reale.
La smart factory è proprio questa, è un’azienda intelligente. Nell’Industria 4.0 ci sono due
elementi fondamentali, gli oggetti IoT, dispositivi sempre connessi all’Internet of Things, e
i Big Data. Questi sono legati con i sistemi CPS.
Sostituire le macchine tradizionali con gli oggetti dell’Internet of Things consentirà alle
imprese di tenere sotto controllo e in tempo reale tutti i processi aziendali e di raccogliere
dei dati da utilizzare in molteplici modi. I Big Data, consentono di effettuare delle analisi
predittive, ossia di fare delle previsioni e delle simulazioni in diversi campi di applicazione.
Quindi un’infrastruttura di comunicazione affidabile, stabile e sicura è un requisito
importante per la quarta rivoluzione industriale che possiamo definirla come la
digitalizzazione della produzione e pertanto la disponibilità di una rete di comunicazione
avanzata è diventata essenziale nel processo produttivo.
7
L’automazione industriale vive una costante evoluzione, favorita dal sempre maggior
impiego dell’intelligenza distribuita, con la necessità di far dialogare piattaforme differenti
e caratterizzate da un proprio linguaggio. La crescente presenza di soluzioni di Networking
nel mondo industriale deriva quindi dal fatto che esiste una sempre più forte esigenza di
condivisione delle informazioni. Tali applicazioni richiedono soluzioni di Networking
omogenee, che possano integrare i dati di processo e diagnostica con la rete IT di
stabilimento, la sicurezza dati e la sicurezza funzionale, PLC, I/O distribuiti e azionamenti
con dispositivi standard Ethernet (PC, telecamere, router per accesso remoto via web).
Ethernet è un insieme di tecnologie standardizzate nate per la connessione di dispositivi
diversi come ad es. personal computer e stampanti in reti locali. L’Industrial Ethernet
sfruttando le basi e i vantaggi dello standard Ethernet è stato creato per l’applicazione in
campo industriale. Altra grossa differenza è che Ethernet non nasce come protocollo di
comunicazione deterministico, i dati trasmessi se non corretti vengono ritrasmessi, la
comunicazione avviene con tempi variabili, e questo non costituisce nelle reti Office o
Home una criticità, mentre in ambiente industriale il determinismo della trasmissione dati è
fondamentale e vitale per il funzionamento delle automazioni. Per tale motivo l’industria
usa le basi Ethernet ma con profili e protocolli appositamente studiati per garantire il
determinismo nella trasmissione dati.
Tra i più diffusi protocolli industriali deterministici abbiamo: PROFINET RT/IRT,
EtherNet/ IP, POWERLINK.
CC-Link IE (Industrial Ethernet) e CC-Link sono invece reti industriali aperte che
consentono ai dispositivi di molti produttori diversi di comunicare tra loro. Vengono
utilizzate prevalentemente in applicazioni di controllo per macchinari, celle o processi nelle
industrie manifatturiere e di produzione, ma possono essere impiegate anche per gestire gli
impianti e informatizzare gli edifici.
8
CC-Link IE (Industrial Ethernet), attualmente è l’unico protocollo aperto con rete Ethernet
industriale in grado di operare a velocità Gigabit rendendolo la scelta ottimale per le
applicazioni Industry 4.0 emergenti. CC-Link IE è disponibile in due versioni: CC-Link IE
Control, destinata a essere utilizzata come “dorsale” di comunicazione per intere fabbriche,
e CC-Link IE Field, per il collegamento dei controller ai dispositivi di campo. Entrambe
funzionano a 1 Gigabit al secondo.
1.1 Classic OPC
OPC è basata su un’architettura Client-Server, è tipico che un’applicazione rivesta entrambi
i ruoli, perchè spesso nei dispositivi fisici è integrato anche il lato Server (comunicazione
device to device). In base ai requisiti delle applicazioni industriali OPC ha tre specifiche
OPC: DA, A&E, HDA.
• L’accesso ai dati di processo correnti sono descritti nelle specifiche DA.
• A&E definisce l’interfaccia per le info basate sugli eventi e conferma degli allarmi
di processo.
• HDA descrive le funzioni per accedere ai dati archiviati.
Tutte le interfacce offrono un modo per navigare nello spazio degli indirizzi e fornire
informazioni sui dati disponibili. Si avrà un Server OPC che incapsula le informazioni e le
rende disponibili tramite un’interfaccia.
9
Figura 1
Il vantaggio di questo approccio è stata la riduzione del lavoro delle specifiche, ci sono
diverse API per diverse esigenze specializzate, senza la necessità di definire un protocollo
di rete o un meccanismo per la comunicazione tra processi. COM e DCOM forniscono un
meccanismo trasparente a un Client per chiamare metodi su un oggetto COM in un Server
in esecuzione nello stesso processo, in un altro processo o su un altro nodo di rete. L'utilizzo
di questa tecnologia disponibile su tutti i sistemi operativi Windows ha ridotto i tempi di
sviluppo delle specifiche dei prodotti e il time-to-market di OPC.
I due principali svantaggi sono la dipendenza da piattaforma Windows di OPC e i problemi
DCOM quando si utilizza la comunicazione remota. DCOM è difficile da configurare, ha
time-out molto lunghi e non configurabili e non può essere utilizzato per le comunicazioni
Internet.
1.2 OPC Data Access
L'interfaccia di accesso ai dati OPC consente la lettura, la scrittura e il monitoraggio di
variabili contenenti i dati di processo correnti. Il caso d'uso principale è quello di spostare i
dati in tempo reale da PLC, DCS e altri dispositivi di controllo, verso HMI e altri client di
visualizzazione. OPC DA è l'interfaccia OPC più importante.
Oggi è implementato nel 99% dei prodotti utilizzando la tecnologia OPC.
Altre interfacce OPC sono per lo più implementate in aggiunta a DA.
10methods on a COM-object in a server running in the same process, in another
process, or on another network node. Using this technology available on all PC-
based Windows operating systems reduced the development time of the specifica-
tions and products and the time-to-market for OPC. This advantage was important
for the success of OPC.
The two main disadvantages are the Windows-platform-dependency of OPC
and the DCOM issues when using remote communication with OPC. DCOM is
difficult
I client OPCto DA
configure, has very long
selezionano and non-configurable
esplicitamente timeouts,
le variabili and cannot
(elementi OPC)be che desiderano
used for internet communication.
leggere, scrivere o monitorare nel server. Il client OPC stabilisce una connessione al server
creando
1.2.1unOPC
oggetto
DataOPCServer.
Access
L'oggetto Server offre metodi per navigare attraverso la gerarchia dello spazio degli indirizzi
The OPC Data Access interface enables reading, writing, and monitoring of vari-
ables
per trovarecontaining
gli oggetticurrent
e leprocess data. The main
loro proprietà, come useilcase
tipoisditodati
movee real-time data
i diritti di accesso.
from PLCs, DCSs, and other control devices to HMIs and other display clients.
OPC DA is
Per accedere ai the
datimost important
il Client OPC interface.
seleziona It is implemented
le variabili (OPC items) in che
99% vuole
of the leggere, scrivere
products using OPC technology today. Other OPC interfaces are mostly imple-
mented in addition
o monitorare sul Server.to DA.Il Client raggruppa gli elementi con impostazioni identiche come
OPC DA clients explicitly select the variables (OPC items) they want to read,
write, orilmonitor
ad esempio tempo indithe server. The OPC
aggiornamento, inclient establishes
un oggetto a connection
OPCGroup to the1.1).
(Figura
server by creating an OPCServer object. The server object offers methods to navi-
gate through
Quando vengono the aggiunti
address spacea unhierarchy
gruppo,to find
gli items and possono
oggetti their properties
essere likeletti o scritti su
data type and access rights.
For accessing the data, the client groups the OPC items with identical settings
OPCServer.
such as update time in an OPCGroup object. Figure 1.3 shows the different objects
the OPC client creates in the server.
Fig. 1.3 Objects created by an OPC client to access data
Figura 2.1
Tuttavia, il modo preferito per la lettura ciclica dei dati da parte del Client, è il monitoraggio
delle modifiche del valore nel server. Il Client definisce un tasso di aggiornamento sul
gruppo contenente gli elementi di interesse. Il tasso di aggiornamento viene utilizzato nel
Server per verificare ciclicamente i valori. Dopo ogni ciclo, il Server invia al Client solo i
valori modificati.
OPC fornisce dati in tempo reale che potrebbero non essere accessibili in modo permanente,
ad esempio quando la comunicazione con un dispositivo viene temporaneamente interrotta,
OPC gestisce questo problema fornendo timestamp e un valore di qualità per i dati forniti.
La qualità, specifica se i dati sono accurati (buoni), non disponibili (cattivi) o sconosciuti
(incerti).
111.3 OPC Alarm & Events
L'interfaccia OPC A & E consente la ricezione di notifiche di eventi e notifiche di allarme.
Gli eventi sono notifiche singole che informano il Client dell'avvenimento di un evento. Gli
allarmi sono notifiche che informano il Client sul cambiamento di una condizione nel
processo. Tale condizione può essere il livello di un serbatoio ad esempio, un cambiamento
di condizione può verificarsi quando viene superato un livello massimo o scende al di sotto
di un livello minimo. Molti allarmi includono il requisito che l'allarme debba essere
riconosciuto. OPC A & E offre quindi un'interfaccia flessibile per la trasmissione di allarmi
e eventi di processo da diverse fonti di eventi.
Per ricevere notifiche, il Client OPC A & E si connette al server, si abbona per le notifiche
e riceve tutte le notifiche attivate nel server. Per limitare il numero di notifiche, il client OPC
può specificare determinati criteri di filtro.
Il client OPC si connette creando un oggetto OPCEventServer nel server A & E e genera un
OPCEventSubscription utilizzato per ricevere i messaggi di evento.
I filtri per questi messaggi di evento possono essere configurati separatamente per ogni
abbonamento. La Figura 1.2 mostra i diversi oggetti creati dal client OPC nel server.
Figura 1.2
121.4 OPC Historical Data Access
OPC Historical Data Access consente di accedere ai dati che sono già archiviati. Da un
semplice sistema di registrazione dati seriale, a un sistema SCADA complesso, gli archivi
storici possono essere recuperati in modo uniforme.
Il client OPC si connette creando un oggetto OPCHDAServer nel server HDA. Questo
oggetto offre tutte le interfacce e i metodi per leggere e aggiornare i dati storici. Un secondo
oggetto OPCHDABrowser è definito per la navigazione nello spazio degli indirizzi del
server HDA.
La funzionalità principale è la lettura dei dati storici in tre modi diversi. Il primo
meccanismo legge i dati grezzi dall'archivio in cui il Client definisce una o più variabili che
vuole leggere e il dominio temporale. Il Server restituisce tutti i valori archiviati per
l'intervallo di tempo specificato dal Client. Il secondo meccanismo legge i valori di una o
più variabili per i timestamp specificati. Il terzo meccanismo di lettura preleva i dati
aggregati (provenienti da più sistemi) nel database storico per il dominio temporale
specificato per una o più variabili. I valori includono sempre la qualità e il timestamp
associati. Oltre ai metodi di lettura, OPC HDA definisce anche i metodi per l'inserimento,
la sostituzione e l'eliminazione dei dati nel database della cronologia.
13Capitolo 2: OPC UA
OPC Unified Architecture come già detto precedentemente nasce dalla volontà di creare un
sostituto di tutte le versioni COM-based senza perdita di nessuna funzionalità e senza alcun
problema di efficienza.
Le specifiche OPC UA sono suddivise in diversi componenti, necessarie anche per la
standardizzazione IEC.
La seguente figura mostra una panoramica di tutte le parti specifiche, suddivise nelle
componenti principali che definiscono la base per OPC UA.
Figura 2.1
14La struttura OPC-UA è strutturata in diversi strati (Figura 2.2). I componenti fondamentali
di OPC Unified Architecture sono i meccanismi di trasporto e il Data Modeling (Information
Model).
Nel livello di trasporto sono definiti due diversi meccanismi:
• Un protocollo TCP binario per la comunicazione intranet ad alta performance;
• Un protocollo basato sui Web Services per la comunicazione internet firewall-
friendly.
Entrambi utilizzano lo stesso modello di sicurezza message-based utilizzato nei Web
Services.
Figura 3.2
L’Information Model definisce le regole e i blocchi di base necessari per esporre un modello
di informazioni OPC UA. Definisce anche i punti di ingresso nello spazio degli indirizzi e i
tipi di base utilizzati per costruire una gerarchia di tipi. Questa base può essere estesa
mediante modelli di informazioni che si basano sui concetti di modellazione astratta.
I servizi UA costituiscono interfacce tra Server e Client, i primi intesi come fornitori di
modelli informativi e gli altri come “consumatori” di tali modelli. Per coprire tutte le
funzionalità di successo note da Classic OPC, l’Information Model è definito da OPC UA
in cima alle specifiche di base.
Vediamo i diversi strati del modello informativo OPC UA:
15DA definisce estensioni automation-data-specific, come i modelli per la descrizione di dati
analogici e digitali, e come esporre la qualità del servizio. Tutte le altre funzionalità di DA
sono già coperte dalla base. Alarm & Conditions (AC) specifica un modello avanzato per la
gestione degli allarmi di processo e il monitoraggio delle condizioni. L'Historical Access
(HA) definisce i meccanismi per accedere ai dati storici e agli eventi storici. Programs
(Prog) specifica un meccanismo per avviare, manipolare e monitorare l'esecuzione dei
programmi.
Altre organizzazioni possono costruire i loro modelli sopra la base UA o sopra il modello
di informazioni OPC, esponendo le loro informazioni specifiche tramite OPC UA.
Figura 2.3
2.1 OPC UA Software Layers
I servizi UA costituiscono interfacce tra Server e Client, i primi sono fornitori di modelli
informativi, i secondi sono consumatori di tali modelli, in OPC UA è tipico che
un’applicazione rivesta ruoli sia di client che di server.
Una tipica applicazione è composta da tre strati software descritti da questa figura:
16Figura 2.1.1
L’UA Stack software può essere realizzato nei linguaggi C, C++, NET o JAVA, questo ha
il compito di convertire le API Calls in Messages. Inoltre l’UA Stack riceve i Messages
spedendoli al Client o al Server attraverso le API.
L’API (Application Process Interface) isola il codice Client/Server dall’OPC UA Stack,
questa espone o “consuma” dati attraverso lo Stack (che implementa soltanto i meccanismi
di comunicazione) e OPC-UA SDK (Software Development Kit).
L’utilizzo di una SDK riduce lo sforzo in fase di sviluppo e facilita una veloce
interoperabilità.
OPC UA definisce tre livelli Stack e diversi profili per ogni livello:
• Il livello di codifica dei messaggi (Encoding) definisce la serializzazione dei
parametri di servizio in formato binario e XML.
• Il livello di sicurezza dei messaggi (Secure Channel) specifica come i messaggi
devono essere protetti utilizzando gli standard di sicurezza dei Web Service.
• Il livello di trasporto (Transport) dei messaggi definisce il protocollo di rete
utilizzato, che potrebbe essere UA TCP o HTTP e SOAP per i servizi Web.
La seguente figura illustra i diversi livelli di Stack di comunicazione UA.
17Figura 2.1.2
2.2 Information Model
Nell’Information Model OPC UA le informazioni vengono esposte su Oggetti, Tipi di Dati
e Metodi, sotto forma di Nodi. Differenti semantiche possono essere definite per i Nodi
tramite l’uso di metadati e References. Nei precedenti standard OPC, la codifica della
semantica era impossibile, per esempio, nel caso della temperatura misurata da un sensore,
le sole informazioni disponibili per comprendere la semantica del dato erano il nome della
variabile e pochi altri elementi come l’unità di misura. Inoltre l’Information Model è
facilmente estendibile in termini di nuovi tipi di dati e di nuove relazioni tra i Nodi. OPC
UA Information Model è sempre lato server. I servizi UA sono usati per accedere agli
oggetti e ai loro componenti, come leggere o scrivere un valore di una variabile, chiamare
un metodo o ricevere eventi dall'oggetto. Il servizio di navigazione può essere utilizzato per
esplorare le relazioni tra gli oggetti e i loro componenti.
18Figura 2.2. 1
2.2.1 AddressSpace
L'insieme di oggetti e le informazioni correlate che il server OPC UA mette a disposizione
dei Client è il suo spazio di indirizzamento. Gli oggetti e i loro componenti sono
rappresentati nello spazio degli indirizzi come un insieme di Nodi descritti da attributi e
interconnessi da References.
Figura 2.2 2
2.2.2 Node Model
I nodi possono essere di differenti NodeClasses in base al loro obiettivo specifico.
Esistono 8 NodeClasses:
Variable, Object, Method, View, DataType, VariableType, ObjectType, ReferenceType.
Figura 2.2.3
19In base alla NodeClass un nodo può avere un differente set di attributi; Alcuni di essi sono
comunque presenti in tutti i nodi. I NodeClass vengono derivati da una BaseNodeClass.
Alcune NodeClasses sono:
• NodeClass Variable: i nodi rappresentano un valore; i client possono leggerlo,
scriverlo, effettuare una Subscription ad esso. Si distinguono in: DataVariables
(rappresentano valori fisici dei processi). Properties (meta-data che descrivono i
Nodi).
• NodeClass Method: rappresentano metodi con parametri di input e di output che i
client possono richiamare mediante il servizio Call per ottenere un risultato. Possono
essere metodi, ad esempio quelli per aprire una valvola, avviare un motore, o anche
calcolare i risultati di una simulazione in base ai parametri d’ingresso forniti.
• NodeClass Object: systems, system components, real-world objects e software
objects. Ad esempio, definizione di un Device (elenco di hardware, software, dati).
Contiene attributi. Raggruppa DataVariables, Methods o altri Objects. Permette di
realizzare un EventNotifier a cui i client possono registrarsi. Non contiene dati ma
può contenere (tramite una reference particolare) uno o più DataVariable che
specifica valori. Esiste una tipologia di Object (OPC UA Folder Object) che realizza
solo "directory/folder" il quale non rappresenta informazioni ma serve solo per
organizzare tutti i Nodi dell'AddressSpace.
2.2.3 Reference
Una Reference descrive la relazione tra due nodi; E’ identificata univocamente da una
coppia di nodi e dalla sua direzione.
Considerare le References come puntatori ad altri nodi aiuta a capire meglio il loro ruolo.
20Le References sono istanze di ReferenceType NodeClass, OPC UA definisce un certo
insieme di ReferenceType di base, ma ogni server può definire un proprio specifico set
estendendo quello di base. I ReferenceTypes vengono esposti esposti nell’Address Space
come nodi e ciò consente ai client di recuperare facilmente le informazioni sulle References
utilizzate dall’OPC UA server di interesse. I ReferenceType inoltre possono essere
simmetriche e non simmetriche; nelle prime la direzione non è significativa, nelle seconde
la direzione può indicare “has parent” oppure “is child of” nell’altra direzione.
2.2.4 View
Una View viene usata per restringere il numero di nodi e References visibili in un Address
Space esteso. Con le Views i server possono fornire all’esterno diverse rappresentazioni del
proprio Address Space in base a particolari casi d’uso.
Una View è rappresentata nell’Address Space come un nodo che fornisce un punto
d’ingresso ai dati che si vogliono mostrare. Tutti i nodi che fanno parte di una View sono
accessibili a partire dal nodo di partenza.
2.2.5 Namespace
I server possono supportare più Information Model allo stesso momento, quindi l’Adderss
Space di un server offre Nodes realativi a differenti Information Models. Ciascun Server
espone una variabile chiamata NamespaceArray, definito come un array di URI dello spazio
dei nomi. Gli indici nella tabella NamespaceArray sono indicati come NamespaceIndexes.
Quindi il NodeId identifica il Node all’interno di un NamespaceIndex, e la coppia NodeId-
NamespaceIndex identifica in modo univoco il Node nell’Address Space di un server.
21Capitolo 3: OPC UA IMPLEMENTATION
Come già detto precedentemente OPC UA si base su un modello di comunicazione Client-
Server, che prevede il mantenimento di informazioni di stato. Tali informazioni sono
mantenute all’interno di una sessione. Una Sessione è definita come una connessione logica
tra Client e Server e questa è indipendente dal protocollo di comunicazione sottostante. Le
Sessioni terminano su espressa richiesta di Client o Server, o sulla base della loro inattività.
Figura 3.0
L’Application Layer come possiamo osservare dalla figura precedente viene usato per la
trasmissione di informazioni tra Client e Server che hanno stabilito una Session.
La OPC UA Session viene stabilita su un canale Secure Channel che rende sicuro lo scambio
dei dati di una sessione attraverso cifratura, e integrità attraverso firma digitale. Il Transport
Layer è il livello fisico responsabile della trasmissione e ricezione dei dati.
22Per stabilire una Session su una connessione sicura tra Client e Server:
• Il Client seleziona un Session Endpoint, ovvero invia una Request al Discovery
Endpoint (ovvero dove sono registrati tutti i server attivi) del server a cui vuole
collegarsi, se ne verifica il certificato.
• Il Client fa una richiesta di apertura di un Secure Channel, se il Server accetta invia
richiesta al Client.
• Viene creata una Session.
• Si attiva la Session ed il Client può quindi iniziare ad accedere ai dati di processo del
Server.
3.1 Data sharing service (Read and Write)
Il modo più semplice per lo scambio dei dati è il Read e Write Service set, ovvero i servizi
che permettono di leggere o scrivere i valori degli attributi dei Nodi. Questi servizi sono
ottimizzati per trasferire gruppi di dati e non per singoli valori.
Per il Read Service, il Server dovrà sempre restituire un valore che sia stato aggiornato più
recentemente, ovvero si usa un parametro MaxAge; questo se impostato a 0, obbliga il server
a restituire un valore attuale.
Altro parametro importante è il Timestamp, in OPC UA ne sono definiti due: Source e
Server.
Poi la lista dei Nodi e dei relativi attributi da leggere:
• NodeId (NameSpaceIndex, Id).
• AttributeId.
• DataEncoding: nel caso si si voglia leggere il Value di una Variabile.
23Per il Write Service:
• Source e Server Timestamp
• NodeId
• AttributeId
• Valore da scrivere
3.2 Subscription Service
OPC UA offre una funzionalità più elegante, la cosiddetta Subscription. Un client UA può
abbonarsi a dei Nodi di interesse e consentire al server di monitorare questi elementi. Solo
in caso di modifiche, ad es. ai loro valori, il server notifica al client tali cambiamenti. Questo
meccanismo riduce la quantità di dati trasferiti. Oltre alla riduzione della larghezza di banda,
questo meccanismo introduce ulteriori vantaggi ed è il meccanismo consigliato per
"leggere" le informazioni da un server UA. Un client può sottoscriversi a diversi tipi di
informazioni fornite da un server OPC UA. Lo scopo di un “abbonamento” è raggruppare
insieme queste fonti di informazioni, denominate voci monitorate, formando
un'informazione chiamata notifica. La figura seguente mostra i servizi coinvolti quando un
client si iscrive a modifiche ed eventi dei dati.
Figura 3.2.1
24Una Subscribe consiste di almeno un oggetto monitorato, deve essere creato nel contesto di
una sessione e può essere trasferito a un'altra sessione. Per creare una sessione, è necessario
stabilire un canale sicuro tra il client e il server come già detto precedentemente.
Esistono tre diversi tipi di "changes" a cui un Client può sottoscriversi quando aggiunge
elementi da monitorare:
• Può effettuare una Subscribe alle modifiche dei Value delle Variabili (attributo valore
di una variabile).
• Subscribe ad Eventi di Oggetti (attributo EventNotifier di un oggetto e set di filtri di
eventi).
• Subscribe a Value che sono calcolati in intervalli di tempo definiti dal client, in base
ai Value correnti.
Figura 3.2.2
L'intervallo di campionamento definisce individualmente per ciascun elemento monitorato,
un intervallo di tempo. Questa è la periodicità con cui il server controlla i dati per le
modifiche. Il campionamento può essere impostato molto più rapido della notifica al client,
in qual caso il server può accodare i campioni e pubblicare la coda completa. I filtri
contengono diversi criteri per distinguere quali modifiche o eventi devono essere segnalati
e quali devono essere bloccati.
Un server UA può supportare l'accodamento di campioni di dati o eventi. La dimensione
della coda, ovvero il numero massimo di valori che possono essere accodati, può essere
configurata per ciascun articolo monitorato. Quando i dati vengono consegnati al Client, la
coda viene svuotata. Ogni coda ha una politica di scarto (ad es. Scarta il meno recente) nel
25caso si verifichi un overflow. Impostando la modalità di monitoraggio, il campionamento e
il reporting dei dati possono essere abilitati o disabilitati.
Dopo ogni intervallo di pubblicazione le notifiche raccolte nelle code vengono consegnate
al client in un messaggio di notifica (Pubblica risposta). Il Client deve assicurare che il
server abbia ricevuto un numero sufficiente di Token di Pubblicazione (Richieste di
Pubblicazione), in modo tale che quando l'intervallo di pubblicazione è scaduto e una
notifica sia pronta per l'invio, il server utilizza tale token e invia i dati all'interno di una
Request di pubblicazione. Nel caso in cui non vi sia nulla da segnalare (ad esempio, nessun
valore è stato modificato) il server invierà una notifica al client, che è una pubblicazione
vuota, per indicare che il server è ancora attivo. L'invio del messaggio di notifica può essere
abilitato o disabilitato modificando l'impostazione Pubblica abilitata.
3.3 OPC UA Open Source example
In questo Paragrafo si mostra un esempio di implementazione di una comunicazione Client
Server OPC UA; Utilizziamo Stack e SDK dello sviluppatore Milo che fornisce una
distribuzione su GitHub. L’esempio che mostreremo viene eseguito sull’IDE Eclipse, e
caricato utilizzando Maven che è uno strumento di gestione di progetti software su Java e
build automation. Maven usa un costrutto conosciuto come POM, un file XML che descrive
le dipendenze fra il progetto e le varie librerie. Maven effettua automaticamente il download
di librerie Java e plug-in Maven dai vari repository.
Quindi una volta scaricato Maven e una versione Java JDK compatibile, per installarlo si
può eseguire da riga di comando: mvn package.
3.3.1 Preparing
Possiamo eseguire da riga di comando il comando: mvn clean install. Oppure dall’IDE
Eclipse: build clean, e build install come nella figura seguente, per installare tutte le
funzionalità OPC UA.
26Figura 3.3.1
3.3.2 Running the Server
Affinché il Server possa avviarsi correttamente nel nostro esempio, deve essere in grado di
collegarsi alla porta locale TCP 4840. Il server verrà avviato e verrà elencato per le
connessioni sulla porta 4840.
Figura 3.3.2
273.3.3 Running the Client
Gli esempi di Client presenti in Milo OPC UA richiedono un'istanza del server OPC UA in
esecuzione.
Figura 3.3.3
3.3.4 Connect
L'esempio si collegherà al server OPC UA remoto e mostrerà l'output sulla console. L’
output che indica una connessione riuscita sarà: Wait for completion… Connected Bye bye.
Figura 3.3.4
283.3.5 Browse
Il Client visita l’Address Space. Il browsing si basa totalmente sui References dei Nodi.
Dato un nodo di partenza, il servizio di browsing permette di scoprire tutti i References di
quel Nodo. Come possiamo vedere dalla figura seguente, il server restituisce per ogni Nodo
iniziale, la lista dei Nodi ad esso connessi.
Figura 3.3.5
3.3.6 Subscribe
Questo si iscriverà all'attributo "Value" dei “Nodi ns = 1; i = 114” e “ns = 1; i = 117” e
stamperà le modifiche alla console. L'applicazione verrà eseguita per 15 minuti e quindi
terminata.
Figura 3.3.6
293.3.7 Write and Read
Il Write scriverà un valore booleano sull’applicazione remota sul Nodo “ns=1; i=117”; Il
Read lo andrà ovviamente a leggere.
Figura 3.3.7
30Conclusioni
Un pilastro fondamentale dell’OPC UA è la sicurezza, uno degli elementi principali da
tenere in considerazione nella scelta di quest’ultimo come protocollo di comunicazione.
L’OPC UA è una tecnologia che si integra perfettamente con i firewall, grazie alla
disponibilità di una serie di controlli. Infatti ci sono diversi protocolli che offrono opzioni,
come il trasporto ultra veloce binario OPC, o il più universalmente compatibili SOAP
HTTPS. I messaggi vengono inviati in modo sicuro tramite crittografia a 128 o 256 bit e
quelli firmati sono ricevuti esattamente come sono stati spediti. I pacchetti sono inviati
sequenzialmente, così l’esposizione ad attacchi che sfruttano le funzionalità di risposta ai
messaggi, viene eliminata grazie alla gestione della sequenza. Inoltre ciascun Client e Server
UA è identificato tramite certificati OpenSSL. Un altro obiettivo raggiunto è quello
dell’estensibilità, ovvero la possibilità di aggiungere nuove funzionalità senza toccare le
applicazioni esistenti. L’architettura multi-livello di OPC UA mette a disposizione un
framework pronto anche per le evoluzioni future. Tecnologie e metodologie innovative,
come nuovi protocolli per il trasporto dei dati, algoritmi di sicurezza, standard di codifica o
servizi applicativi, possono essere integrati mantenendo la compatibilità con i prodotti
precedenti.
31Qualunque sia il settore in cui si opera, industria di processo, manifatturiero, controllo delle
macchine, produzione di energie, smart grid o, per esempio, gestione del traffico, è possibile
integrare tutti i dispositivi, i sistemi di automazione e le applicazioni software presenti in
fabbrica, utilizzando una piattaforma standard indipendente e sicura. A chi realizza
dispositivi e macchinari è possibile rendere i propri prodotti interoperabili con quelli di altri
produttori, consentendo di creare sistemi completi. Utilizzando una tecnologia
standardizzata e sicura l’integrazione diventa più stabile e i costi si riducono.
32Bibliografia
[1] Prof. Ing. Salvatore Cavalieri, Studenti Alberto Bruccini, Giovanni Torrisi, OPC
Unified Architecture (OPC UA) Concetti e documentazione dei servizi.
[2] Wolfgang Mahnke, Stefan-Helmut Leitner, Matthias Damm, OPC Unified,
Springer, 2009.
[3] Prof. Salvatore Cavalieri, OPC UA Openness, Productivity, Connectivity Unified
Architecture.
[4] Libero Tecnologia, https://tecnologia.libero.it/che-cose-la-smart-factory-13603,
2018.
[5] Unified Automation, Embedded OPC UA Stack 1.0.0.125,
http://documentation.unified-automation.com/uasdkhp/1.0.0/html/index.html, 2018.
[6] Wikipedia, https://it.wikipedia.org/wiki/Apache_Maven, 2018.
[7] eclipsecon.org, Developing OPC UA with Eclipse Milo,
https://www.eclipsecon.org/europe2017/session/developing-opc-ua-eclipse-milo milo-
ece2017.
[8] Automazionenews, Uno standard a prova di futuro scalabile ed estendibile,
http://www.automazionenews.it/uno-standard-prova-futuro-scalabile-ed-estensibile/, 2018.
33Puoi anche leggere
