Open Platform Communications (OPC) server

An Open Platform Communications (OPC) server acquires data, stores it in an internal cache, and makes that cached data available to one or more OPC clients.

Since the OPC protocol used between OPC clients and OPC servers is standardized, the only real distinguishing feature for any OPC server is from where the data is acquired.

The OPC server acquires its data from the RealTime database (RTDB), via Publish/ Subscribe middleware. The OPC server does not poll the AVEVA Enterprise SCADA PLCs directly; that operation is performed by Omnicomm and its field protocols. When a client writes data back to the OPC server, it writes the data back to the RTDB using either the Business Logic Tier (BLT) middleware or directly through HPDB (High Performance Database). This preference is set in the OPC Server instance’s configuration file, and applies to all clients of that OPC Server.

The OPC server in a AVEVA Enterprise SCADA system is nothing more than a gateway process. It allows clients to read PubSub accessible and write RealTime data by using the OPC protocol. The OPC server can be bypassed entirely by using PubSub and BLT middleware to perform the identical read and write operations from a client application.

The diagram below graphically represents how the OPC server interfaces to our system:

An OPC client is any application that acquires data from one or more OPC servers using the OPC standard protocol. Although OPC clients can also write data back to the server, this is not recommended. Using BLT, it is a slower operation than reading data, and it is not a good design structure if you plan on using an OPC client to push large amounts of data into the RTDB. Using HPDB for writing data is faster, but at the cost of security and Area of Responsibility (AOR) checking.

There are many resources on the internet that describe the OPC protocol in detail. A good starting point would be the links found on the following page: http://www.opcconnect.com/opcintro.php.