Basic HTML Version
MAGGIO 2012
FIELDBUS & NETWORKS
60
Fieldbus & Networks
Building
blocks
(
L
a serie di standard OPC (OPen Con-
nectivity) fu originariamente svilup-
pataper risolvereunproblemamolto
comune nel campo dell’automa-
zione, quello della grande difficoltà
e incertezza nel far comunicare tra loro appli-
cativi software e dispositivi hardware etero-
genei. Nelle realizzazioni classiche, quando si
volevano per esempio raccogliere dati da un
PLC e visualizzarli su un PC all’interno di un
software Scada, era necessario che lo svilup-
patore di quest’ultimo scrivesse l’opportuno
‘driver’ per comunicare con lo specifico mo-
dello di PLC installato nell’impianto. Nella ‘preistoria’
informatica, in cui il sistema operativo dominante era
ancora DOS, anche i più diffusi software per ufficio
avevano lo stesso problema. Per esempio, la prima
versionedel programmaWordveniva fornitaconun in-
numerevolebagagliodi driverper lestampanti. Peccato
che quando si cambiava la stampante e non si dispo-
neva del driver per i propri programmi preferiti, non ci
fosse verso di stampare alcunché. Lo stesso accadeva
nel mondo dell’automazione. Per ogni PLC, terminale
operatore, softwareScadaoHMI e viadicendo serviva
sempre la corretta combinazione di driver, altrimenti
non c’era verso di comunicare. Con l’avvento di Win-
dows diventò comune un approccio diverso, in quanto
Microsoft inserì nel sistema operativo le funzionalità di
driver universale e diventò più semplice far stampare
qualunque programma senza che il suo sviluppatore
si dovesse preoccupare di scrivere i driver per le innumerevoli stampanti. Lo
standardOPCadottò lo stessoapproccio (basandosi sulle tecnologieOLE com
eDcomsviluppate daMicrosoft) per far comunicare applicativi e hardware in
modostandardizzato, semplificandolavitaaiprogrammatorieliberandolidalla
necessità di scrivere i driver.
Come funzionano lecomunicazioni OPC
L’idea di base degli standard OPC è creare un livello di astrazione tra le fonti
che generano dati in un impianto automatizzato (per esempio un PLC) e i sof-
tware che intendono acquisire quei dati (per
esempio un pacchetto HMI/Scada), in modo
che i due terminali estremi dellacomunicazione
non debbano conoscere i rispettivi dettagli tec-
nici legati agli specifici protocolli di comunica-
zione fisica e all’organizzazione interna dei dati
gestiti (figura 1).
Ai dispositivi hardware e ai pacchetti applica-
tivi basta sapere come comunicare in modo
standardizzato da e verso il livello di astrazione
costituito da OPC. Questo livello di astrazione è
costituito in pratica da due componenti distinti:
OPC Client e OPC Server (figura 2). Se un appli-
cativo software e un dispositivo hardware riescono a
comunicare tra loro tramiteOPC, però, ciò non significa
che non siano più necessari i rispettivi protocolli na-
tivi per lo scambio dati o che siano sostituiti da OPC.
Al contrario, i vari protocolli di comunicazione nativi
rimangono presenti, ma in un impianto che sfrutta
l’architetturaOPC essi comunicano solamente con uno
dei due componenti che costituiscono lo stato di astra-
zione OPC. In pratica, i protocolli nativi dell’hardware
comunicanocon il soloserverOPC, i protocolli nativi del
software comunicano con il solo client OPC (figura 3). I
due componenti OPC si scambiano le informazioni tra
loro e il ciclo si chiude: l’hardware parla con l’applica-
tivo softwaree viceversa senza che i due si conoscano.
Detta così non sembra cambi molto: anziché avere un
solo driver nativo a gestire la comunicazione, ne ser-
vono addirittura due. Ma l’esperienza ha dimostrato
che l’architettura OPC offre vantaggi enormi. Quello principale è costituito
dal fatto che un’applicazione software di automazione può essere sviluppata
senza doversi preoccupare di sapere a quale hardware specifico verrà colle-
gata, perciò, per esempio, uno Scada potrà acquisire dati da una qualunque
risorsahardwarecompatibileOPCraggiungibile inrete. Inoltre, lastessaappli-
cazionepotràparlareconqualunquenumerodi sorgenti dati diverse, inquanto
non vi è alcuna limitazione inerente al numero di connessioni che si possono
instaurare. Allo stesso modo, l’hardware diventa di fatto intercambiabile e
può essere aggiornato nel tempo senza problemi: è sufficiente che venga
LO STANDARD OPC È IL ‘COLLANTE’ DELLE
COMUNICAZIONI: GRAZIE AI DRIVER UNIVERSALI OPC,
APPLICATIVI SOFTWARE E DISPOSITIVI HARDWARE
DI PRODUTTORI DIVERSI RIESCONO A PARLARE
LA STESSA LINGUA
OPC: IL DRIVER
UNIVERSALE
di Stefano Cazzani
Figura 1 - OPC introduce un livello software di
astrazione tra i pacchetti applicativi e i dispositivi
di automazione con i quali desidera comunicare
Figura 2 - Il livello di astrazione OPC
è composto da due moduli software:
il client OPC e il server OPC, ognuno
dei quali comunica con i protocolli
nativi delle rispettive applicazioni e i
dispositivi hardware con i quali sono
collegati