Università degli studi di catania facoltà di Ingegneria



Scaricare 3.97 Mb.
Pagina1/17
02.06.2018
Dimensione del file3.97 Mb.
  1   2   3   4   5   6   7   8   9   ...   17



UNIVERSITÀ DEGLI STUDI DI CATANIA

Facoltà di Ingegneria

Corso di Laurea Specialistica in Ingegneria Informatica

Tesina di Informatica Industriale – A.A. 2009-2010



OPC Unified Architecture

Concetti e documentazione dei servizi



Docente:


  • Prof. Ing. Salvatore Cavalieri

Realizzazione a cura di:



  • Alberto Bruccini, A63/000273

  • Giovanni Torrisi, A63/000229

Indice




Introduzione 2

Information modeling 7

I servizi 15

Discovery Services Set 17

Session Service Set 20

View Service Set 23

Read and Write Services 28

Subscription Service Set – Monitored Item Service Set 30

Method Service Set 42

Query Service Set 43

Node Management Service Set 45

Sicurezza 48




Introduzione


Il primo standard OPC di grande successo – OPC Data Access – fu concepito per definire interfacce client/server per l’accesso in lettura e scrittura ai dati di processo, e viene prevalentemente usato in sistemi HMI e SCADA in cui diversi dispositivi hardware per l’automazione, di differenti produttori, riescono a comunicare tramite un’unica interfaccia software.

Oggi, dopo una vasta diffusione, OPC si è imposto come l’interfaccia standard tra sistemi di automazione in molteplici livelli della automation pyramid, ed è utilizzato anche in moltissime aree applicative per le quali non era stato pensato. In ambito industriale, però, non sempre si riesce ad usufruire dei vantaggi offerti dalla piattaforma OPC-DA a causa della dipendenza da COM e delle limitazioni nei meccanismi per l’accesso remoto forniti da DCOM.

La prima risposta di OPC Foundation al problema è stata OPC XML-DA, che manteneva le caratteristiche fondamentali di OPC utilizzando però un’infrastruttura di comunicazione non legata né a un particolare produttore né a una particolare piattaforma software. Tuttavia, la sola conversione delle specifiche OPC-DA in versioni basate sui Web Service non è stata sufficiente a soddisfare la necessità di uno standard di nuova generazione, specialmente a causa delle limitate performance di XML.

OPC Unified Architecture (OPC-UA) nasce quindi dalla volontà di creare un vero sostituto di tutte le esistenti versioni COM-based senza la perdita di nessuna funzionalità e senza alcun problema di efficienza; soddisfa quindi la necessità di interfacce platform-independent e permette la creazione di ricchi ed estensibili modelli dati per descrivere sistemi complessi.

Requisiti soddisfatti con OPC-UA:



Comunicazione tra sistemi distribuiti

Modello Dati

Robustezza e fault-tolerance

Comune per tutti gli OPC data

Indipendenza dalla piattaforma

Orientato agli oggetti

Scalabilità

Tipi estensibili

Alte performance

Metadati

Internet e firewall

Dati complessi e metodi

Sicurezza e controllo degli accessi

Scalabilità da modelli semplici a complessi

Interoperabilità

Modello di base astratto

Ridondanza dei server

Base per altri modelli dati standard

Per raggiungere tali requisiti OPC-UA è strutturata in diversi strati:

Le componenti principali sono i protocolli di trasporto e il modello dei dati. Nel livello di trasporto sono definiti due diversi meccanismi ottimizzati per differenti casi d’uso: un protocollo TCP binario per la comunicazione intranet ad alta performance e un protocollo basato sui Web Services per la comunicazione internet firewall-friendly. Entrambi utilizzano lo stesso modello di sicurezza message-based utilizzato nei Web Services.

Il modello dei dati definisce le regole e gli elementi base necessari per fornire un valido modello informativo e comprende inoltre elementi avanzati come quelli per descrivere le macchine a stati. Gli elementi base possono essere estesi da altri modelli informativi ad un più alto livello.

I servizi UA costituiscono interfacce tra server e client, i primi intesi come fornitori di modelli informativi e gli altri come “consumatori” di tali modelli; essi utilizzano i meccanismi di trasporto per lo scambio dei dati tra client e server.

Uno dei concetti alla base di OPC-UA è che un client può accedere alla più piccola porzione di dati di un sistema complesso senza essere a conoscenza dell’intero modello informativo.

La figura seguente mostra i differenti strati del modello informativo definito da OPC:



DA definisce estensioni automation-data-specific come i modelli per la descrizione di dati analogici e digitali e quelli per la qualità del servizio; tutte le altre caratteristiche di DA sono già ricoperte dall’architettura di base. AC (Alarm & Conditions) consiste in un modello avanzato per la gestione degli allarmi ed il monitoraggio dello stato dei processi. HA (Historical Access) definisce i meccanismi per accedere alla cronologia dei dati e degli eventi. Prog (Programs) specifica i metodi per avviare, manipolare e monitorare l’esecuzione dei programmi.

Nella figura seguente sono rappresentate le varie componenti dello standard OPC-UA, approvate dalla IEC (International Electrotechnical Commission):

In OPC-UA, pur essendo utilizzata un’architettura client-server, è tipico che un’applicazione rivesta entrambi i ruoli, ciò perché spesso nei dispositivi fisici è integrato anche il lato server (comunicazione device to device). Una tipica applicazione OPC-UA è composta da tre strati software descritti nella figura sottostante:




CLIENT



SERVER

L’intero stack software può essere implementato con C,C++,.NET o java; OPC-UA non si limita a tali linguaggi e piattaforme ma questi sono attualmente gli unici sviluppati.

Un’applicazione OPC-UA è un sistema che desidera esporre o “consumare” dati e contiene sia le sue funzionalità specifiche che il loro mapping a OPC-UA attraverso OPC-UA Stack (che implementa soltanto i meccanismi di comunicazione) e OPC-UA SDK (Software Development Kit). L’utilizzo di una SDK riduce lo sforzo in fase di sviluppo e facilita una veloce interoperabilità.

L’OPC-UA Stack implementa i diversi meccanismi di trasporto ed è suddiviso in tre strati:



  • Message Serialization; definisce i metodi per serializzare i dati scambiati in modalità binaria o XML.

  • Message Security; specifica come i messaggi devono essere protetti utilizzando gli standard di sicurezza dei Web Services o una versione binaria di essi.

  • Message Transport; definisce il protocollo di rete utilizzato, che può essere UA TCP o HTTP e SOAP per i Web Service.



elenco: users -> scava -> dispense
dispense -> 1. Definizione di Albero
users -> La geografia (giochi di tragitti, di percorsi, di territori e confini, cacce al tesoro, idee di distanze, di lunghezze) La psicomotricità
users -> Una possibile sequenza di attività (anche di tipo ludico) su questo tema può essere la seguente, sperimentata in una classe 5
users -> Le indagini più recenti del Ministero dell’Istruzione sui dati della dispersione scolastica arrivano a concludere che la dispe
users -> Lezione 2 L'italiano d'oggi: le varietà funzionali, situazionali e strutturali
users -> Distinguiamo tra dimostrazione ed argomentazione; la prima ha carattere di certezza e di incontrovertibilità è usata nella ri
dispense -> Struttura dati Coda
dispense -> La Struttura Dati Astratta (adt) Lista
dispense -> Abstract Data Type (adt) pila
dispense -> Bus di Campo iec 61158: Caratteristiche Principali


Condividi con i tuoi amici:
  1   2   3   4   5   6   7   8   9   ...   17


©astratto.info 2019
invia messaggio

    Pagina principale