"I have been recently introduced to the concept of OPC. I know it is a standard manner by which applications share data and that compliance is necessary to say your tools use "OPC"? Granting this, why would I ever need to worry that different OPC software will not talk with each other?"
What you have described about OPC is definitely correct, but there is more to understand about OPC for it to be applicable. It is not enough to merely say a given piece of software is "OPC Compliant".
First of all, any OPC connection needs both an OPC Client (to make requests) and an OPC Server (to get data in proprietary format and serve it using OPC). OPC clients will not talk directly with other clients nor will servers talk to servers.
Secondly there are multiple different OPC specifications with which Client or Server software can be compliant. These are based over the underlying type of data that is being passed. The main three are:
- 1) DA (Data Access) - Used for real-time data whereby the only the latest value is stored by the OPC server, new updates will effectually over-write the old one.
- 2) HDA (Historian Data Access) - Used to interface an archive of information and make "chunks" of data available via OPC HDA transactions.
- 3) A&E (Alarm and Events) - Used to track the systems alarm states and event message notifications which might or might not be related to real-time values.
Many OPC Servers can be compliant to more than one specification. For example an OPC Server for Aspentech InfoPlus.21 may be both DA and HDA compliant.
Lastly, the specifications undergo occasional updates and it is unfortunately not implied that an OPC tool will be backwards compatible. For example an OPC Server for Aspentech InfoPlus.21 may be HDA 1.2 compliant without necessarily being HDA 1.1 compliant.
Based on these requirements, a statement like "My OPC Server and OPC Client are both Data Access 2.0 compliant" effectively ensures they will communicate.
Get your answers by emailing us at opcexperts@matrikonopc.com
