MAGGIO 2014
FIELDBUS & NETWORKS
89
mentre il client è la controparte demandata al ‘consumo’ di queste.
È inoltre contemplata la possibilità di aggregazione dei server in un
singolo spazio di indirizzamento. Lo standard non definisce specifi-
che implementazioni dello stack su client e server, bensì soltanto i
servizi per lo scambio dei messaggi tra di essi. Tali servizi sono del
tutto generici; esiste per esempio un solo servizio ‘Read’ utilizza-
bile da un client per la lettura di un attributo presso il server e tale
attributo può rappresentare astrattamente sia delle proprietà sia
dei dati. Per ogni
servizio (ne sono
previsti 34 in to-
tale) sono speci-
ficati i messaggi
di richiesta e le
risposte attese.
Sono previsti, tra
gli altri, servizi
per la gestione
delle query, lo
scorrimento dello
spazio di indiriz-
zamento, la ge-
stione dei nodi,
la sottoscrizione
di dati, la crea-
zione della con-
nessione, oltre
che ovviamente gli aspetti di sicurezza. Lo spazio di indirizzamento
di un server ne definisce il proprio meta-modello, descritto in una
rappresentazione orientata a oggetti che parte, come mostrato in fi-
gura 3, dal concetto di ‘nodo’ come classe base, per arrivare a quelli
di ‘oggetto’, ‘variabile’, ‘dato’ e
‘vista’. Il supporto per i concetti di
polimorfismo, ereditarietà e astra-
zione dei dati consentono espan-
dibilità e personalizzazione per i
vari vendor.
Lo standard OPC UA prevede,
quindi, esplicitamente, due di-
versi schemi di mapping di proto-
collo per il livello di trasporto dei
messaggi, demandato alla tra-
smissione delle informazioni sulla
rete, ovvero ‘UA Web Service’ e
‘UA Native’. Il primo, opzionale, si
basa su protocollo XML-Soap/http
ed è correntemente supportato in
diversi ambienti, come Java e
.NET; il secondo, mandatorio, si
basa invece su comunicazione
TCP/IP, offrendo migliori presta-
zioni e richiedendo minori risorse,
assicurando nel contempo mi-
gliore interoperabilità. Ne esiste anche un’implementazione ‘ibrida’
che poggia su Https.
Un occhio di riguardo per la sicurezza
La specifica OPC Classic non definiva in maniera propria le procedure
di sicurezza, ma mostrava piuttosto come configurare i servizi di si-
curezza intrinseci del protocollo di comunicazione Dcom adottato. La
specifica OPC UA, invece, non definendo un singolo protocollo di tra-
sporto, al fine di risultare indipendente dalla piattaforma, prevede
raccomandazioni esplicite sugli aspetti di sicurezza. Sono coperti
gli aspetti di codifica e segnatura dei messaggi, identificazione e
assicurazione della comunicazione, gestione dei diritti di accesso,
gestione dei firewall e auditing. In generale, l’insieme di tali mec-
canismi di sicurezza è in grado di garantire comunicazione sicura
anche attraverso reti pubbliche, evitando la necessità di configurare
per questo reti VPN (Virtual Private Network). Codifica e segnatura
dei messaggi assicurano, per esempio, la sicurezza dei messaggi a
livello di trasporto. L’implementazione dei servizi da parte del server
è opzionale; i client al momento della connessione possono rilevare
quelli implementati e quindi scegliere tra questi quali (finanche nes-
suno) eventualmente utilizzare. L’identificazione delle applicazioni
è invece visto come servizio mandatorio o, quantomeno, tutte le
applicazioni devono supportare questo per poter essere certificate;
Figura 3 - Schema del meta-modello implementato dall’architettura OPC UA
Figura 2 - Schema di principio
dell’architettura OPC UA
Fonte: blog.ivci.com
