OPC XML Data Access Specification
http://www.opcfoundation.org/
Perché OPC si è mosso verso i Web Services ?
 OPC DCOM-based funziona bene e durerà per molti
anni
 Ci sono applicazioni in cui OPC DCOM-based ha dei
limiti:
Vi sono alcuni field devices "embedded" che non hanno
supporto COM, ma hanno lo stack TCP/IP
Le applicazioni HMI possono sfruttare i Web Services per
lavorare su Internet, meglio di quanto faccia DCOM (spesso
il traffico DCOM è bloccato da firewall)
Tutti i Client Non-Microsoft (senza supporto COM) possono
avere un maggiore possibilità di connessione tramite i Web
Services
OPC e XML
 Il Working Group "OPC and XML" iniziò il lavoro di
definizione dello standard nel Marzo del 2000 (conclusione
2002)
 Obiettivi erano:
 Integrazione di OPC con Microsoft BizTalk
 Integrazione di OPC in applicazioni Web utilizzando XML
 Le tecnologie utilizzate sono: XML, Web Services, SOAP,
BizTalk
 Le specifiche definiscono un servizio OPC XML come Web
Service (uso di WSDL)
OPC/XML vs OPC/DCOM
Le specifiche OPC XML Data Access si differenziano da quelle
basate su tecnologia COM, per motivi legati alla tecnologia
XML/HTTP
1.Tipologia di Codifica:
 OPC-DCOM utilizza una codifica binaria efficiente
 OPC-XML serializza ogni dato da trasmettere in
messaggi XML
 Per minimizzare i tempi di accesso, in XML si hanno
meno primitive di servizio, ciascuna delle quali
trasporta più informazioni
OPC/XML vs OPC/DCOM
2. Gestione della connessione e dello stato:
OPC-DCOM si basa su scambi informativi connection-oriented (possibilità di
memorizzare tutta la storia delle comunicazioni) che includono callback
 OPC-XML è tipicamente connectionless e non sono possibili le callback
 non prevede di default, ma permette, la memorizzazione della storia
trasmissiva di un client
 In .NET c’è il file Global.asax (facoltativo)
 Conseguenze in OPC-XML:
 non è possibile implementare il meccanismo di call back



Esiste il meccanismo della subscription per sopperire a tale lacuna
non esistono Oggetti e non è possibile memorizzare la storia di ciascun
cient

Ad eccezione dello scambio dati basato su subscription
OPC/XML vs OPC/DCOM
3. Rilevazione dei Server OPC in un nodo:
 OPC-DCOM permette ad un client di conoscere la lista
dei server OPC in un nodo (indirizzo IP)
 OPC-XML non prevede tale meccanismo. E' il client che
deve conoscere l'URL di ogni Web Service presente sul
nodo.
Alcuni metodi presenti in OPC XML
GetStatus
Browse
GetProperties
Read
Write
Ritorna informazioni sullo stato del server: fornitore, versioni
XML-DA supportate, istante in cui il server è stato avviato
Permette al client di conoscere i nomi e il relativo percorso
degli items (tags) presenti e disponibili nel namespace
gerarchico del server
Ritorna informazioni dettagliate sulle proprietà (Nome,
Descrizione, Valore) di particolari items specificati dal client
Il client specifica il path di items, il tipo di dato richiesto
(eventuale conversione da parte del server), freshness dei
dati richiesta (ms, 0 se il dato deve essere letto dal device). Il
server fornisce il valore, la qualità e il timestamp per gli item
richiesti.
Permette ad un client di modificare valori di uno o più
items.
Meccanismo di Sottoscrizione
in OPC XML
 Il meccanismo di CallBack viene "sostituito" da una lettura
ciclica stimolata dal client
 La lettura ciclica è subordinata ad una fase preliminare
chiamata sottoscrizione.
 Con la sottoscrizione, il Client specifica una lista di items
presenti nel Server per cui vuole applicare la lettura ciclica
 Alla sottoscrizione del client (elenco di item), il server
associa un handle univoco
 Ogni qual volta il client desidera conoscere i valori degli
items relativi alla sottoscrizione, egli dovrà utilizzare l'handle
fornito dal Server
Meccanismo di Sottoscrizione
in OPC XML
Subscribe
SubscriptionCancel
SubscriptionPolledRefresh
Permette ad un Client di specificare una lista di items per
i quali il client vuole essere continuamente aggiornato.
Permette ad un Client di rimuovere una lista di items
indicata in una precedente Subscribe
Con questo servizio il Client ottiene dal Server tutti i
valori di items indicati in una precedente subscription che
hanno subito una modifica del loro valore entro
l'intervallo specificato dal client.
Meccanismo di Sottoscrizione
in OPC XML
 Esistono due meccanismi di sottoscrizione:
1. Basic Polled Refresh Approach.


Il Client realizza un polling (gestione del timer)
Ad ogni richiesta del client, il Server invia gli item i cui campi Valore o
Qualità sono cambiati rispetto l’ultima richiesta.
2. Advanced Polled Refresh Approach. Viene
utilizzato per simulare meglio il meccanismo di
CallBack.



Il Client delega il Server a realizzare il meccanismo di attesa (Timer)
Il Client invia una richiesta al Server (legandola al completamento del
processamento dei dati ricevuti)
Ad ogni richiesta del Client, il Server realizza un meccanismo di
attesa e ritorna i valori se sono cambiati e dopo un intervallo minimo
(HoldTime) ed entro un intervallo massimo (WaitTime).
Basic Polled Refresh Approach
Advanced Polled Refresh Approach
Se all’interno del Wait Time si verifica una modifica di
qualche Item, il Server invia al Client gli Item modificati
Se allo scadere del HoldTime+WaitTime non si ha nessuna
modifica, il Server ritorna una risposta senza alcun item.
Meccanismo di Sottoscrizione
in OPC XML
 I parametri più importanti che il Client può richiedere al
Server nella sottoscrizione, sono:
 SamplingRate (ms). E’ la frequenza alla quale il Server deve
aggiornare la Cache associata ad ogni Item. Il controllo del
cambiamento degli Item viene fatto sul valore mantenuto nella
Cache
 EnableBuffering. E’ posibile richiedere l’abilitazione di un buffer (di
dimensione legata alle risorse del Server) in cui vengono
memorizzati tutti i valori di item che subiscono una modifica
nell’intervallo tra due accessi del client, in funzione del
SamplingRate
 DeadBand. Permette di indicare la soglia di variazione desiderata dal
client per ogni item (è una percentuale del full engineering unit)
Meccanismo di Sottoscrizione
in OPC XML
 Nella procedura di sottoscrizione il client specifica:
 Lista items. Per ogni item viene specificato:
Tipo Richiesto (errore se il server non supporta la conversione)
RequestedSamplingRate.
EnableBuffering.
Deadband.
 Indicazione se nella risposta (alla sottoscrizione) del Server devono
essere ritornati i valori attuali degli item
 SubscriptionPingRate (ms). Indicazione sul tempo dopo il quale il
Server (in assenza di richieste dal Client) libera le risorse allocate
con la sottoscrizione.
Può essere messo a 0 (NON CONSIGLIATO), ma in tal caso il Server
sceglierà un suo algoritmo per testare l’esistenza in “vita” del client
Meccanismo di Sottoscrizione
in OPC XML
 Nella procedura di sottoscrizione il Server invia in risposta al
Client:
 Lista items sottoscritti. Per ogni item viene specificato:
Il valore (se richiesto dal Client). Viene tornato l’oggetto di tipo
ItemValue (vedi Servizio Read)
L’effettivo sampling rate che il Server può supportare
 Eventuali Errori
 Server Handle, usato dal Client nelle successive chiamate a
SubscriptionPolledRefresh
Meccanismo di Sottoscrizione
in OPC XML
 Per ogni SuscriptionPolledRefresh, il Client specifica:
 Uno o più handles di sottoscrizione. Se è >1, nella risposta viene
mantenuto l’ordine indicato
 HoldTime. Tempo assoluto fino al quale il Server aspetterà prima di
restituire le informazioni sugli items sottoscritti
 WaitTime. Intervallo di tempo a partire dall’HoldTime durante il
quale il Server non restituirà alcuna risposta in assenza di
cambiamenti da notificare
 Indicazione se il Server deve ritornare TUTTI i valori
indipendentemente se sono cambiati o meno (WaitTime è ignorato
in questo caso)
Meccanismo di Sottoscrizione
in OPC XML
 Per ogni SuscriptionPolledRefresh, il Server invia:
 Lista items. Ogni elemento della lista è formato dai campi:
Array Item sottoscritti (tipo ItemValue). Può non contenere tutti gli item
(quelli senza cambiamenti)
Handle di Sottoscrizione. Permette di distinguere gli items in funzione
della precedente sottoscrizione, nel caso in cui vi siano diversi
ServerHandle
 Eventuali errori
Primitive OPC XML
 Le primitive sono contenute in una classe, che ciascuno può
facilmente creare a partire dal file OpcXmlDa.wsdl
 La classe delle primitive viene ottenuta dal file OpcXmlDa.wsdl
tramite l’eseguibile wsdl.exe contenuto nel Microsoft .NET
Framework SDK
 il file OpcXmlDa.wsdl è distribuito da OPCFoundation e
contiene la descrizione dei web service
 il file OpcXmlDa.wsdl può essere prelevato dall’Appendice B
dello Standard OPC DA XML