OPC Server: le basi

[VRI]

Buondì
sento sempre di più parlare di OPC server nel forum e purtroppo, non essendo nel mondo dell'automazione industriale, non ho mai avuto possibilità di parlare con qualcuno che l'ha utilizzato o di metterci le mani in prima persona.
qual è l'architettura hardware di un sistema di automazione con un OPC server?
Potrei avere una sommaria descrizione di come funziona?
perché viene utilizzato? (forse a questa domanda potrei rispondermi conoscendone il funzionamento )

Grazie

[eAlucarD]

in pratica un bel giorno del '96 qualcuno si è chiesto perché non sfruttare la tecnologia OLE (quella che ti fa inserire immagini e altra roba in un foglio word per esempio) anche per l'automazione
in modo da poter sviluppare software (quasi) funzionante sul sistema operativo "Finestre" di Redmond
assemblando oggetti a mattoncino

come anche OLE,COM e DCOM e per una serie di motivi tra cui la multiutenza, il fatto che è basato su TCP e altro

OPC ha una parte server ed una client

per info meno maccheroniche
http://www.kepware.com/

[VRI]

Lato client, quindi lato PLC, come si integra la comunicazione con il server OPC? Tramite le librerie per i socket?

[WALTERmwp]

Ciao VRI ...

Lato client, quindi lato PLC, come si integra la comunicazione con il server OPC? Tramite le librerie per i socket?

cioè ?
Facciamo così, io torno alle domande del Post d'apertura.

qual è l'architettura hardware di un sistema di automazione con un OPC server?

quella che ritieni opportuna per il tuo sistema di controllo e supervisione ma, riducendo ai minimi termini, può essere anche costituita da un PC (ad esempio) e da un PLC (ad esempio); a questa allora facciamo riferimento nel presente Post.

perché viene utilizzato?

anticipo questa risposta anche se potrebbe fare parte di quella successiva.
Si ricorre ad una interfaccia di tipo OPC per comunicare con un dispositivo (funzionale all'automazione, in tal caso il PLC) senza ricorrere al driver specifico, necessario in alternativa.

Considera che una applicazione, pur semplice che sia e sviluppata su piattaforma PC, se vuole comunicare con un PLC (riscrivo PLC considerato il tuo riferimento all'automazione) deve(dovrebbe) essere dotata di quella parte di software che le consente di "parlare", appunto, con il PLC; questa parte di "software" è il driver di comunicazione che si basa su regole determinate e definite nel "protocollo di comunicazione", ma ogni "brand" ha il suo protocollo.
Fin qua immagino per te niente di nuovo.
Ora, o tu sviluppi questa parte di software rispettando queste regole, alle quali si attiene anche il PLC (la controparte) altrimenti, in difetto del rispetto di queste regole, col PLC non riesci a scambiare informazioni.
Se il driver non te lo puoi/vuoi sviluppare, lo compri; può essere fornito direttamente da chi produce il device (PLC) o può essere sviluppato e fornito da "terze parti"; in ogni caso compri un prodotto software specifico per comunicare con quel device specifico.
La realizzazione di un driver, per la maggior parte dei casi, ed in modo particolare se "fatto bene", comporta un impegno significativo anche perché, oltre allo sviluppo, deve essere prevista la contestuale verifica di tutte le possibili condizioni che si ritiene possano verificarsi: lo devi "testare".

Per evitare e ovviare a questo onere/inconveniente/problema ( ... dipende dai punti di vista) un po di tempo fa si sono inventati lo OPC (acronimo di OLE for Process Control).
In pratica lo OPC costituisce una sorta di "cuscinetto" (adattatore/traduttore software) da porre tra la applicazione (residente sul PC) e il PLC e consente di fare "parlare" i due mondi senza dover scrivere il protocollo specifico per quel PLC.
Con tale architettura, il "Client-OPC" e il "Server-OPC" vengono "caricati" entrambi sul PC.

Il presupposto all'impiego dello OPC è che la tua applicazione sia dotata di una parte di programma, indispensabile a soddisfare tale condizione, quale è appunto il "Client-OPC"; il produttore del PLC, da parte sua, mette a disposizione un'altra parte di programma costituito dal "Server-OPC".
L'onere di sostenere la comunicazione vera e propria verso il PLC lo sopporta quindi il "Server-OPC" ma, per l'applicazione, questo è trasparente ovvero non è visibile, non è una questione della quale preoccuparsene.

Sul PC ti ritrovi dunque con la tua applicazione, dotata di "Client-OPC", e di un altro programma, costituito dal "Server-OPC".
I due OPC (Client e Server) vengono messi in "contatto" tra loro e comunicano tra loro (tramite le regole OPC) e, rispettivamente, mantengono la "connessione" verso l'applicazione(PC) e verso il PLC.
Ma allora a cosa serve tutto 'sto casino se poi mi devo sviluppare comunque una parte di programma che abbiamo classificato come "Client-OPC" ?
Serve a comunicare con ogni dispositivo (device che vuoi tu) che risulta "attrezzato" con una interfaccia di tipo OPC (cioè che viene distribuito anche con un "Server-OPC").
In tal modo la medesima applicazione può essere utilizzata per comunicare con un PLC (ad esempio "Siemens") piuttosto che con un altro PLC (ad esempio "Schneider") o con un altro ancora, previa opportuna configurazione del "Client-OPC" e del "Server-OPC".
La scelta di dotare/attrezzarsi di una interfaccia OPC è il risultato di più valutazioni e tra queste gioca un ruolo significativo l'aspetto commerciale.

Potrei avere una sommaria descrizione di come funziona?

il suo funzionamento, a livello di concetto, pur in modo approssimativo, credo di averlo scritto qui sopra; come in pratica viene utilizzato è un altro discorso.
Se è questo (o anche questo) che intendi ti posso scrivere che si tratta di accedere ad una interfaccia grafica che ti consente di stabilire una associazione con l'informazione che intendi rilevare e ritieni essere presente sul PLC.
Da una parte, lato "Server-OPC", identifichi la variabile (ad esempio una "word") che vuoi acquisire e a questa associ un alias, un altro nome, che ti ritrovi dalla "altra parte" sul "Client-OPC", a seguito dell'esecuzione di determinate operazioni (sempre a livello di configurazione).
Stabilisci così una associazione univoca.
Puoi configurare più associazioni e più associazioni le puoi aggregare in un gruppo (hai così un gruppo di variabili).
Questo gruppo, poi, può essere opportunamente "caratterizzato" definendo, ad esempio, il tempo di aggiornamento (scansione) delle variabili alle quali fa riferimento.
Naturalmente lo "Server-OPC" deve essere anche configurato in modo tale da specificare la connessione (fisica) che si intende utilizzare per comunicare (tra lo hardware disponibile sul PC) con il device (PLC): la seriale, ethernet, ...

Questo in estrema sintesi, confidando di non avere riportato inesattezze; diversamente qualcun altro può provvedere alla rettifica e, magari, integrare.

Saluti

[VRI]

Quindi posso immaginare una cosa del tipo:
PC con funzione di HMI con software scritto con apposite librerie OPC con funzioni del tipo:
"valore_barra = GetVariabilePLC (a) dove "a" sarà una variabile all'interno del programma del PLC...
Al richiamo di quella funzione, PLC e PC, tramite l'opportuno canale e protocollo (ethernet, seriale ecc. ecc.) si scambieranno quel dato...

è una pensata lecita?

[WALTERmwp]

(...) con funzioni del tipo: "valore_barra = GetVariabilePLC (a) dove "a" sarà una variabile all'interno del programma del PLC... (...)

questa sintassi mi "ricorda" lo script like "C" tipico delle Actions di WinCC, ma potrei anche confondere con altro.
Dovesse essere una cosa del genere direi che nel modo da te indicato andresti a leggere dal database dello SCADA (lo HMI) il valore di una variabile che ne fa parte quindi non sarebbe un accesso tramite OPC in quanto, appunto presumo, agiresti all'interno dello SCADA stesso.
Però, questo prendilo con le "pinze", perché è facile equivocare.

Comunque, se devi acquisire informazioni tramite OPC, prima ti devi preoccupare del fatto che la tua applicazione si agganci al Server OPC (che deve essere presente sul PC e attivo), poi definisci i tuoi "items" (le tue variabili) che prevedi di gestire in lettura e poi quelle che prevedi di gestire in scrittura; magari per la lettura, ma anche per la scrittura, è meglio se le ordini in gruppi.
E' una questione, appunto, di ordine.
Fatto questo, ti gestisci la scansione dei gruppi in base alle esigenze applicative.
Ricordati di interrogare l'esito di ogni azione compiuta: quindi sia per la lettura che per la scrittura perché devi essere certo, per quanto il test ti può restituire, che l'azione ha avuto esito positivo.
Diversamente gestisci l'errore, ma queste sono considerazioni di valenza generale che esulano la specificità.

Al richiamo di quella funzione, PLC e PC, tramite l'opportuno canale e protocollo (ethernet, seriale ecc. ecc.) si scambieranno quel dato

in pratica si, quando vai ad eseguire la "Get..." del caso (la sintassi esatta dipende appunto dalla libreria) attivi una richiesta di lettura verso il "Server-OPC" che, a sua volta, tramite il driver specifico di quel PLC, inoltra la richiesta al PLC in causa.
Il PLC risponde, il "Server-OPC" interpreta la risposta e la mette a disposizione di chi glie l'ha chiesta, ovvero del "Client-OPC" (... quello dal quale è scaturita la "Get...").
Spero di aver chiarito qualche dubbio, altrimenti chiedi e, se posso (e se so), provo a risponderti.

Se disponi della "dll" (e nello specifico dovrebbe essere quella o quelle relative allo OPC DA) dovresti poter risalire o comunque disporre di documentazione che riferisce della sintassi.

Saluti

[VRI]

Mi son schiarito un po' le idee
Purtroppo non ti chiedo di approfondire perché per ora, non andrò ad utilizzarlo ma, ti ringrazio per avermi dato un'infarinata
Grazie WALTERmwp!

[WALTERmwp]

Grazie

prego, figurati.

Mi son schiarito un po' le idee

mi fa piacere; il principio di base è espresso nel Post [4] ed è quello dal quale ripartire con le proprie riflessioni, poi, per farsi un'idea un pochino più definita, bisogna "metterci su le mani".

Saluti

[Candy]

qual è l'architettura hardware di un sistema di automazione con un OPC server?

Solitamente un dispositivo industriale, ma anche non, intelligente, deve interfacciarsi con un supervisore superiore, solitamente un PC su cui girano dei programmi applicativi SCADA e similari. Lo OPC server è lo strato software di un PC server che provvede i dati agli applicativi che si vogliono connettere. Queste server deve avere delle schede hardware che si interfacciano al PLC od altro dispositivo di automazione interessato: Ethernet, bus di campo proprietario o simili.
Lo OPC server è la parte software creata dal costruttore del sistema di automazione in grado di trasportare sul PC supervisore i dati, senza che l'utente debba quindi sviluppare la parte di codice utile ad intefacciarsi al sistema, driver protocolli compresi.

Potrei avere una sommaria descrizione di come funziona?

Praticamente nel thread si è detto tutto l'essenziale.

perché viene utilizzato?

Come detto più sopra, per interfacciare una applicazione più evoluta, solitamente di supervisione, al sistema di automazione, preposto a funzioni più semplici e specifiche.