Qual è lo scopo dell’OPC?

L’obiettivo di OPC è fornire un’infrastruttura basata su standard per lo scambio di dati di controllo del processo. Ad esempio, i produttori hanno molte origini dati diverse, come PLC, DCS, database, contatori, RTU e altri dispositivi. Queste informazioni sono disponibili attraverso diverse connessioni, come trasmissioni seriali, Ethernet o persino radio. Diversi sistemi operativi come Windows, UNIX, DOS e VMS sono utilizzati anche da molte applicazioni di controllo dei processi.

OPC è uno standard industriale pubblicato per l’interconnessione dei sistemi. La Fondazione OPC mantiene tutte le specifiche OPC. OPC significa OLE per il controllo di processo. Utilizza la tecnologia COMOM e DCOM di Microsoft per consentire alle applicazioni di scambiare dati su uno o più computer utilizzando l’architettura client/server. OPC definisce un insieme comune di interfacce. Pertanto, le applicazioni recuperano i dati esattamente nello stesso formato, indipendentemente dal fatto che l’origine dati sia un PLC , un DCS , un misuratore, un analizzatore, un’applicazione software o qualsiasi altra cosa. Di conseguenza, OPC è una soluzione di comunicazione plug and play pronta per l’uso.

Perché OPC riesce dove i driver personalizzati falliscono?

La chiave del successo di OPC nella creazione di comunicazioni veramente indipendenti dal fornitore è che OPC astrae i dettagli di implementazione di Data Source (ad esempio, PLC) e Data Sink (ad esempio, HMI) da ciascuna parte in modo che i dati possano essere scambiati tra loro senza richiedere loro di sapere nulla sul protocollo di comunicazione nativo dell’altro e sull’organizzazione interna dei dati. Ciò è in netto contrasto con l’approccio del driver personalizzato della scrittura di applicazioni che, per
definizione, sono necessarie per comunicare in modo nativo sia con l’origine dati che con il data sink.

Come funziona la comunicazione OPC?

L’OPC può essere rappresentato come uno strato di “astrazione” che si trova tra l’origine dati e il pozzo di dati, consentendo loro di scambiare dati senza sapere nulla l’uno dell’altro.

L'”astrazione del dispositivo” OPC viene realizzata utilizzando due componenti OPC specializzati chiamati OPC Client e OPC Server. Ciascuno dei quali è descritto in una sezione seguente. Ciò che è importante notare è che solo perché Data
Source e Data Sink possono comunicare tra loro tramite OPC non significa che i rispettivi protocolli nativi non siano più necessari o siano stati sostituiti da OPC. Invece, questi protocolli e/o interfacce nativi sono ancora presenti, ma comunicano solo con uno dei due componenti OPC. A loro volta, i componenti OPC si scambiano informazioni tra loro e il ciclo si chiude. I dati possono viaggiare dall’Applicazione al Dispositivo senza che l’uno
parli direttamente con l’altro

OPC DA (Data Access)

La specifica OPC più comune è OPC DA, che viene utilizzata per leggere e scrivere dati “in tempo reale”. Quando i fornitori si riferiscono genericamente a OPC, in genere intendono OPC DA.
• OPC HDA (Historical Data Access)
• OPC A & E (Allarmi ed eventi)
Queste specifiche OPC si basano sulle tecnologie OLE, COM e DCOM sviluppate da Microsoft per la famiglia di sistemi operativi Microsoft Windows. Questo rende complicato farlo funzionare in una rete moderna! In genere è necessario un software Tunneller per condividere i dati OPC in una rete (tra server e client OPC)

OPC UA (Architettura unificata)

OPC UA risolve i problemi con OPC standard/classico
• Funziona solo su Windows
• Difficile utilizzare OPC in una rete a causa di COM/DCOM
• OPC UA eliminando la necessità di utilizzare una piattaforma basata su Microsoft Windows delle versioni precedenti di OPC.
• OPC UA combina le funzionalità delle interfacce OPC esistenti con nuove tecnologie come XML e Web Services (HTTP, SOAP)
• Multipiattaforma
• Non è più necessario un OPC Server dedicato perché il server può essere eseguito su un sistema embedded

• OPC UA supporta due protocolli.
– Protocollo “UA Binary” opc.tcp://Server
Utilizza un semplice protocollo binario
– Protocollo “UA XML” http://Server
Utilizza standard aperti come XML, SOAP (-> Web Service)
• Questo è visibile all’applicazione programmatori solo tramite modifiche all’URL.
• Altrimenti OPC UA funziona in modo completamente trasparente per l’API.

Differenza tra server OPC classic e server OPC UA

L’OPC classico richiede un sistema operativo Microsoft Windows per implementare la funzionalità del server COM/DCOM. Utilizzando SOA e Web Services, OPC UA è un sistema indipendente dalla piattaforma che elimina la precedente dipendenza da un sistema operativo Windows. Utilizzando SOAP/XML su HTTP, OPC UA può essere distribuito su una varietà di sistemi embedded indipendentemente dal fatto che il sistema sia un sistema operativo generico, come Windows, o un sistema operativo deterministico in tempo reale

Vantaggi dell’utilizzo della connettività OPC

A prima vista, scambiare un singolo driver personalizzato con due componenti OPC (client OPC e server OPC) potrebbe non sembrare un grande miglioramento, ma come l’esperienza ha dimostrato, lo è. Di seguito sono riportati alcuni vantaggi chiave dell’utilizzo di OPC:

1.Un’Applicazione abilitata OPC può comunicare liberamente con qualsiasi Sorgente dati abilitata OPC visibile sulla rete senza la necessità di alcun software driver, specifico per la Sorgente dati.

2. Le applicazioni abilitate per OPC possono comunicare con tutte le origini dati abilitate per OPC di cui hanno bisogno. Non vi è alcuna limitazione OPC intrinseca al numero di connessioni effettuate.

3. Oggi l’OPC è così comune che è disponibile un connettore OPC per quasi tutti i dispositivi moderni e legacy sul mercato. È facile iniziare a utilizzare OPC.

5. Gli utenti sono liberi di scegliere i dispositivi, i controller e le applicazioni più adatti ai loro progetti senza preoccuparsi del fornitore da cui provengono e se comunicheranno tra loro… l’intercomunicazione ora è presupposta!