 Primo livello: Field Management. A questo livello le informazioni sono relative ai dispositivi di campo  Secondo livello:

Presentazione sul tema: " Primo livello: Field Management. A questo livello le informazioni sono relative ai dispositivi di campo  Secondo livello:"— Transcript della presentazione:

1 http://www.opcfoundation.org/

2  Primo livello: Field Management. A questo livello le informazioni sono relative ai dispositivi di campo  Secondo livello: Process Management. Comprende i Sistemi di Controllo Distribuiti (DCS) e i sistemi SCADA per il controllo dei processi  Terzo livello: Business Management. In questo livello si integrano le informazioni raccolte dal processo con i sistemi per la gestione finanziaria. Integrazione delle Informazioni

3  Necessità di accedere ai dati di campo da qualunque parte dell’impianto  Visione omogenea dei dati  superamento di differenti codifiche client/server  Indipendenza dei programmi dalle caratteristiche hardware/software della sorgente dati  nessuna necessità di sviluppare driver

4 OPC: OLE for Process Control  Scopo: fornire una visione unica ed indipendente dalla sorgente dei dati prodotti in un impianto industriale  Si basa su tecnologie consolidate in ambiente Windows:  Distributed Component Object Model (DCOM). Modello per la comunicazione tra applicazioni Windows attraverso reti di comunicazione.  Component Object Model (COM). Modello per la comunicazione tra applicazioni Windows locali.  OLE 2  XML Web Services

5  OPC è un’architettura client/server che permette ad una qualsiasi sorgente di dati (Server) di comunicare in modo standard con qualsiasi altro processo (Client) dotato della stessa interfaccia.  I fornitori hardware offrono un Server OPC, che permette a qualsiasi applicazione Client di accedere ai dati da esso pubblicati.  Vantaggio principale di OPC:  Indipendenza da una tecnologia proprietaria. OPC: OLE for Process Control

6

7 Storia di OPC  Lo sviluppo di prodotti informatici nel campo dell'automazione ha comportato la necessità di sviluppare centinaia di drivers di comunicazione per garantire l'interoperabilità tra prodotti diversi  Lo sviluppo ed il mantenimento di drivers comporta "spreco" di risorse  Nel 1995 la Fisher-Rosemount, Intellution, Intuitive Technology, Opto22, Rokwell e la Siemens AG decisero di creare un gruppo di lavoro per risolvere il problema  Membri di Microsoft furono invitati per il necessario supporto

8 Storia di OPC  L'obiettivo del gruppo di lavoro fu quello di definire uno standard per accedere ad informazioni in ambiente Windows, basandosi sulla (allora) corrente tecnologia (OLE)/COM  La tecnologia sviluppata fu chiamata OLE for Process Control (OPC)  Nell'Agosto del 1996 fu definita la prima versione di OPC (1.0)  Nel Settembre 1996 la OPC Foundation fu presentata alla riunione annuale ISA a Chicago  www.opcfoundation.org

9 Storia di OPC  Nel Settembre 1997 è stata prodotta la versione 1.0A  Nell'Ottobre 1998 è stata prodotta la versione 2.0 della Data Access Specification  Attualmente vi è la versione 3.0 della Data Access Specification  Nel 2002 è stata prodotta una specifica per integrare OPC con XML

10  OPC Overview v1.0  OPC Common Definitions and Interfaces v1.0  OPC Data Access Specification v3.0  OPC Alarm&Event Specification v1.02  OPC Historical Data Access Specification v1.1  OPC Batch Specification v2.0  OPC Security Specification v1.0  OPC & XML Draft v0.6 Specifiche OPC

11  Allarme: si verifica quando una pre-definita "condizione" si verifica (diviene attiva).  Es.: Una temperatura che supera una certa soglia.  Evento: è un avvenimento (es.guasto di un dispositivo, superamento di una soglia) che ha un significato per l’OPC Server, per l'apparecchiatura che rappresenta e per i suoi OPC Client.  Differenti eventi possono essere associati ad una variabile. Per una temperatura si possono fissare 4 valori di soglia e, dunque, possono accadere 4 diversi eventi (a seconda della soglia)  Un evento può segnalare l'occorrenza di un allarme OPC Alarm&Event Specification

12  Un OPC Client può ricevere la notifica dell'occorrenza di uno o più eventi che l'OPC Server supporta.  Vengono definiti 3 tipi di eventi  Eventi legati a Condizione. Viene notificata l'avvenuto allarme  Eventi la cui causa non è all'interno del processo (es.intervento dell'operatore) e che debbono essere monitorati  Eventi Semplici (es.guasto di un dispositivo).  Sono disponibili servizi per la definizione di condizioni per gli eventi del primo tipo. OPC Alarm&Event Specification

13  Gli historical engines forniscono una fonte aggiuntiva d’informazioni che devono essere distribuite agli utenti e ai software a cui servono:  Raw Data. Dati storici memorizzati  Aggregated Data. Dati estratti da quelli storici, come richiesto dal client  Nell’ottica dell’integrazione dei dati a tutti i livelli, le informazioni storiche possono essere considerate come un altro tipo di dati da condividere ed integrare. OPC Historical Data Access Specification

14  Vengono supportati due tipi di server Storici:  Simple Trend Historical Data Servers. Questi server permettono l’immagazzinamento di dati in piccole quantità di tipo semplice (raw data).  Complex Data Compression and Analysis Servers. Questi server provvedono all'analisi dei dati. Sono capaci di fornire dati riassuntivi o un loro processamento (Es.valori medi, valor massimo, minimo ecc). OPC Historical Data Access Specification

15  Un OPC Data Access Server può offrire due sorgenti di dati: Cache e Device.  Un OPC Data Access Server offre variabili (item) che possono essere selezionate (creando gruppi) da un OPC Data Access Client  Gli OPC Item rappresentano connessioni a sorgenti dati all’interno del server.  Ogni item ha associato un: Value, una Quality e un TimeStamp  Si noti che gli Item non sono le sorgenti dei dati, ma solo i collegamenti ad esse  Per ciascun gruppo, il Client può associare la frequenza con cui un OPC Server può aggiornare i dati relativi agli OPCItem contenuti nel gruppo. OPC Data Access Specification

16  Le specifiche OPC contengono due set di interfacce:  Custom Interfaces: sono usate in linguaggi (es.C++) che supportano i puntatori a funzioni.  Automation Interfaces: sono usate in linguaggi (es.VB) dove non è possibile utilizzare puntatori a funzioni. In tal caso, i metodi vengono chiamati attraverso un nome e non da puntatori. Interfacce Custom e Automation

17  Fornisce al programmatore Visual Basic delle interfacce più semplici;  viene creato un wrapper DLL (involucro) per gli OPC Custom Interface Servers già esistenti;  viene fornito così un meccanismo automatico per accedere alle stesse funzionalità ottenibili dalla interfaccia Custom. Interfaccia OPC Automation Automation Client (VB) OPC Automation Wrapper Custom Interface (COM / DCOM) OPC Custom Interface Server Automation Interface