il servizio definisce in definitiva quali client possono connettersi a
uno specifico server o viceversa. A ogni applicazione è associato
per questo un ‘certificato’ e, quindi, una lista di ‘certificati’, corri-
spondenti ad altrettante applicazioni sicure cui potersi connettere.
Il certificato è relativo alla specifica istanza dell’applicazione, nel
senso che la stessa applicazione installata su due macchine diverse
(server o client) può essere configurata con diversi diritti. I certificati
definiscono anche i limiti di accesso ai dati a livello utente; in alter-
nativa, nelle implementazioni più semplici può essere adottato un
semplice schema di autorizzazione mediante user name e password.
Nello specifico, per quanto concerne i protocolli di trasporto previsti
esplicitamente dallo standard OPC UA, il protocollo UA Web Service
segue per gli aspetti di sicurezza dei messaggi la raccomandazione
WS-SecureConversation, compatibile con implementazioni .NET e
Soap. L’implementazione UA Native adotta invece segnatura ed en-
cryption mediante X.509 con chiavi asimmetriche o, eventualmente,
schemi di codifica alternativi come AES-256.
Lo stesso protocollo X.509 è quindi usato anche per l’autentica-
zione e autorizzazione di utenti e applicazioni nell’accesso ai dati.
L’affidabilità della comunicazione è garantita da ‘timeout’ program-
mabili, meccanismi di ‘error detection’ e ‘recovery’, supporto per
architetture ridondate. La connessione è controllabile in entrambe
le direzioni mediante messaggi di heart-beat; in questo modo, sia
client che server possono riconoscere eventuali guasti. È prevista
la memorizzazione (‘buffering’) locale dei dati e il riconoscimento
(‘acknowledge’) della corretta ricezione; nel caso di perdita di con-
nessione è prevista quindi la possibilità di ritrasmissione dei dati.
L’indipendenza dalla piattaforma: chiave
di volta per nuove applicazioni e scenari
Come detto in precedenza, l’indipendenza dalla piattaforma è tra
gli aspetti principali della specifica OPC UA. È in effetti la rispo-
sta alla costante diffusione, anche
nell’ambito proprio dell’automazione
industriale, di sistemi e applicazioni
che non adottano necessariamente
una tradizionale architettura basata
su PC e Windows.
Sempre più applicazioni girano oggi,
per esempio, su smart-phone o tablet
a basso costo, utilizzando processori
ARM o sistemi operativi embedded
come Android.
La possibilità di portare su tali piatta-
forme implementazioni di client OPC
UA apre nuovi scenari di controllo in
mobilità in sicurezza. Più o meno allo
stesso modo, i più recenti progressi
tecnologici nel settore dei semicon-
duttori consentono la realizzazione di
complesse reti di sensori intelligenti;
la capacità di implementare su que-
ste server OPC UA lascia spazio alla
realizzazione di nuove architetture di
controllo remoto distribuito.
Non ultimo, poi, la possibilità di
sviluppare con Linux apre definitiva-
mente all’automazione industriale le porte del mondo ‘open source’,
con la sua incredibile quantità di risorse.
Del resto, non a caso, proprio Linux è stato per lungo tempo nella
lista dei desideri di molti di quelli che operano nel mondo delle
applicazioni di controllo di processo, attratti da una migliore si-
curezza, stabilità e affidabilità e dai costi più contenuti di questa
piattaforma.
Implementazioni di riferimenti e toolkit
di validazione automatica
La Fondazione OPC rende disponibili sul sito web a utenti registrati
e/o membri implementazioni di esempio di client e server compati-
bili con l’architettura UA. È quindi pubblicata una lista dei fornitori
ufficialmente certificati; la certificazione assicura, al solito, l’intero-
perabilità tra i diversi vendor, l’affidabilità dei prodotti e il rispetto
dei requisiti minimi di prestazione. È anche scaricabile, infine, un
test tool per la verifica automatica della compatibilità allo standard
della propria implementazione.
In generale, sono disponibili implementazioni del protocollo in di-
versi linguaggi, inclusi C, C++, .NET e Java. In quest’ultimo caso,
sono state mostrate implementazioni importate in Java mediante
interfaccia JNI o interamente sviluppate in tale ambiente. È il caso
di osservare, poi, che la scalabilità del protocollo consente imple-
mentazioni su piattaforme con risorse limitate.
Nell’ottobre 2012, per esempio, il centro di ricerca Iosb-INA
(Fraunhofer Application Center for Industrial Automation) in col-
laborazione con l’Istituto inIT (Institute for industrial Information
Technologies) ha sviluppato un’implementazione dello stack OPC
UA server che richiede soltanto 15 kB di memoria RAM e 10 kB di
memoria ROM, ideale per applicazioni embedded.
(*) fonte
MAGGIO 2014
FIELDBUS & NETWORKS
90
Fieldbus & Networks
Fonte: www.prodec.co.uk
