OPC XML Data Access Specification

1. OPC XML Data Access Specification http://www.opcfoundation.org/

2. 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

3. 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)

4. 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 • 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

5. OPC/XML vs OPC/DCOM • 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

6. OPC/XML vs OPC/DCOM • 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.

7. Alcuni metodi presenti in OPC XML Ritorna informazioni sullo stato del server: fornitore, versioni XML-DA supportate, istante in cui il server è stato avviato GetStatus Permette al client di conoscere i nomi e il relativo percorso degli items (tags) presenti e disponibili nel namespace gerarchico del server Browse GetProperties Ritorna informazioni dettagliate sulle proprietà (Nome, Descrizione, Valore) di particolari items specificati dal client Read 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. Write Permette ad un client di modificare valori di uno o più items.

8. 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

9. Meccanismo di Sottoscrizione in OPC XML Permette ad un Client di specificare una lista di items per i quali il client vuole essere continuamente aggiornato. Subscribe SubscriptionCancel Permette ad un Client di rimuovere una lista di items indicata in una precedente Subscribe SubscriptionPolledRefresh 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.

10. Meccanismo di Sottoscrizione in OPC XML • Esistono due meccanismi di sottoscrizione: • 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. • 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).

11. Basic Polled Refresh Approach

12. 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.

13. 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)

14. 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

15. 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

16. 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)

17. 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

18. 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