Specifications

B - 16 RSLinx – Training Guide
Application OPC I/F
OPC
Server
OPC I/F
SCADA
System
Physical I/F
Physical I/F
Physical
I/O
Physical
I/O
Figure 0-4 - OPC Client/Server Relationship
General OPC Architecture and Components
OPC specifications always contain two sets of interfaces; Custom Interfaces and
Automation interfaces. This is shown in Figure 0-5.
C++ Application
VB Application
OPC Custom I/F
OPC Automation I/F
OPC Server
(In-Proc, Local, Remote,
Handler)
Vendor Specific Logic
Figure 0-5 - The OPC Interfaces
The OPC Specification specifies COM interfaces (what the interfaces are), not the
implementation (not the how of the implementation) of those interfaces. It specifies the
behavior that the interfaces are expected to provide to the client applications that use them.
Included are descriptions of architectures and interfaces that seemed most appropriate for
those architectures. Like all COM implementations, the architecture of OPC is a client-
server model where the OPC Server component provides an interface to the OPC objects
and manages them.
There are several unique considerations in implementing an OPC Server. The main issue is
the frequency of data transfer over non-sharable communications paths to physical devices
or other data bases. Thus, we expect that OPC Servers will either be a local or remote EXE
which includes code that is responsible for efficient data collection from a physical device
or a data base.
An OPC client application communicates to an OPC server through the specified custom
and automation interfaces. OPC servers must implement the custom interface, and
optionally may implement the automation interface. In some cases the OPC Foundation
provides a standard automation interface wrapper. This “wrapperDLL” can be used for any
vendor-specific custom-server.