The short answer is: anytime real-time data needs to be transferred. While there
are many scenarios to consider, the most common categories are identified below
with brief explanations of the challenges involved and recommendations on how
to best address them using standard OPC components:
||Data Sink (User)
|Controller (ex. PLC)
||Application (Ex. HMI)
||Different vendors’ controllers use their own
protocols. OPC eliminates the need for the HMI to have a ‘custom driver’ for
each Controller in question.
||- Controller: use an OPC Server for Controller X
- Application: usually has an OPC Client built in. If one is not included may
an OPC DA Client for Application Y
|Controller or Device
||Controller or Device
||Controller/Controller communications are different
than Controller/Application communications because both products typically use
their own, vendor specific protocols.
||- Use OPC DA Servers for both Controllers
- Use OPC Data Manager to facilitate intelligently moving
relevant real-time data between the two controllers.
|Controller or Device
||Relational databases communicate using Structured
Query Language (SQL) over the Open DataBase Connectivity (ODBC) protocol while
controllers and devices use their own custom protocols. Finding a data-bridges
is difficult and often requires technical experience to set up.
||- Use an OPC DA Client for ODBC to capture real-time OPC Data and
correctly transfer it to the database via SQL/ODBC.
- se an OPC DA Server for Device X to expose
NOTE: OPC DA is bidirectional so if needed, real-time data may be written from
the database to the device, controller, or application.its data to OPC clients.
||Process historians are designed to capture real-time
data so they often have their own native protocols and custom drivers for
collecting data from various devices and applications. Here again the challenge
is finding a Historian that supports existing equipment as well as future (and
legacy) data sources.
||- Historians typically have their own protocols, almost
all of them also have OPC DA Clients built in. An example of such an OPC
enabled Historian is the OPC Desktop Historian.
- For the data source: use an OPC DA Server for Data Source X
||Traditionally, if the controller or application did
not support device-level redundancy, additional hardware was required to make
two (or more) devices redundant.
||- Devices require: OPC Server for Device X
- Different devices can use different OPC Servers.
- Use OPC Redundancy Broker (ORB) to implement redundancy.
- For an Application (ex. HMI or Historian): use its OPC Client for Application
- If a controller (such as a PLC) only has an OPC Server rather than an OPC
Client, use that OPC Server along with OPC Data Manager to allow ORB and the controller to exchange real-time data
|Remote Devices (SCADA): ex. RTUs
||Communicating with distant devices and data sources in
general is more complex due to communication breakdowns, lower bandwidth, and
is also more expensive. Custom drivers address these challenges with varying
degrees of reliability.
||Use a SCADA Class OPC Server for the Remote device.
Unlike regular ‘plant edition’ OPC servers this class of OPC servers is
designed to work with complex SCADA environments. (ex. MatrikonOPC Server for SCADA Modbus)
No. OPC DA is specifically geared to transferring current values. Once the
current value is passed and the next on is read it, the OPC DA specifications
have no defined interfaces for providing OPC DA Clients with past values. If
you need to transfer historical data, you will need to use OPC Historical Data
Access (OPC HDA) based OPC Clients and OPC Servers which, are geared specifically for that
Usually yes. This assumes the OPC DA Client and the OPC DA Server support the
same revision of the OPC DA Specification (see above) or at least one is