Opc interface to the pi system

Configuration Diagrams

Configuration 1: Preferred Configuration

This configuration is the simplest, and allows data buffering on the interface node.

Configuration 2: Common Configuration

This configuration allows data buffering on the interface node and it is recommended to have all machines in the same domain.

Configuration 3: Alternate Configuration

This configuration is possible, but not the preferred configuration. Having the interface and the PI Server compete for resources can impair efficiency.



Note: All configurations require DCOM settings and it is recommended that buffering be used even when the interface runs on the PI Server node, because OPC Server sometimes sends data in bursts, with all values coming in within the same millisecond.

Principles of Operation

The PI OPC Interface is an OPC Data Access (DA) client that allows process data to be passed between an OPC DA Server and a PI Server. The PI OPC Interface is designed to provide connection to only one OPC Server and run multiple instances of the interface simultaneously. More than one interface may be configured to connect to the same OPC Server.

At start up, the PI OPC Interface tries to establish connection to both the OPC and PI Servers. After connection is successfully established, it periodically checks its clock against that of the OPC Server and against that of the PI Server to eliminate any differences in clock speeds. This procedure is also important to provide positive feedback to the interface that the OPC Server is still up and running, even if all points are configured for ‘Advise’ (i.e., the OPC Server sends data whenever a new value is read into the server’s cache) and no data has come in for some time. If the interface cannot communicate with the OPC Server, the interface will periodically try to reestablish the connection. Once the connection to the OPC Server is reestablished, the interface will recreate its groups and items on the server and resume data collection.

Once startup is complete, the Interface enters the processing loop, which includes:

• 
  Servicing scheduled input points. Each Scan Class is processed in turn.
  
• 
  Servicing output points as events arrive.
  
• 
  Servicing triggered input points as events arrive.
  
• 
  The PI Point Database is checked every 2 minutes for points that are added, edited, and deleted. If point updates are detected, the points are loaded (or reloaded) by the Interface as appropriate. The 2-minute update interval can be adjusted with the /updateinterval command-line parameter discussed in the UniInt Interface Users Manual. The Interface will only process 25 point updates at a time. If more than 25 points are added, edited, or deleted at one time, the Interface will process the first 25 points, wait 30 seconds (or by the time specified by the /updateinterval parameter, whichever is lower), process the next 25 points, and so on. Once all points have been processed, the Interface will resume checking for updates every 2 minutes (or by the time specified by the /updateinterval parameter). All tag edits are performed in the following way: old versions of edited tags are deleted from the interface; new versions are added in. With some OPC Servers, this operation can require more time and more system resources. Therefore, it is more efficient to stop and restart the interface if a large number of tags are edited.
  

The PI OPC Interface is designed to constantly send messages about its operation to the pipc.log file. This file will contain the following information about the PI OPC Interface:

• 
  Informational messages on interface startup and shutdown;
  
• 
  The scan rate for each scan class and the actual update rate provided by the OPC Server.
  
• 
  A count of the points in each scan class (i.e., Polled tags), the number of Output points, and a count of the Advised tags and Event tags;
  
• 
  Error messages for points rejected by the interface because they are configured incorrectly;
  
• 
  Error messages for points rejected by the OPC Server or error messages sent from the OPC Server;
  
• 
  Notification for all connections and disconnections from the server (e.g. when the connection with the OPC Server is lost and the interface attempts to reconnect)
  

Note: The PI OPC Interface can be configured to run on the same system as the OPC Server, PI Server or on another system. The configuration affects the specific system settings needed for the interface to be installed and perform correctly. Therefore, it is crucial to know the operational details of the interface presented in this section before installing and running it.

Failover

This interface supports three types of failover: Server-Level Failover, Interface-Level Failover using Microsoft Clustering, and Interface-Level Failover using UniInt. Refer to the OPC DA Interface Failover Manual for configuring the interface for failover.

Overview of OPC Servers and Clients

OPC (referred to as Open Connectivity via Open Standards) is generally accepted as one of the popular industrial standards for data exchange between software components from different manufacturers. OPC is based on Microsoft’s COM/DCOM (Component Object Model/Distributed Component Object Model) technology for the implementation of distributed systems. By using a standard method for passing information between COM objects (i.e. software applications) the objects can share their information with other COM objects within that network and ignore their physical location. All OPC clients and servers are built on COM/DCOM technology and use the OPC standard specifications to exchange the information.

The PI OPC Interface is an OPC client that allows the PI System and other software applications to exchange data across a network. During installation of the interface entries are put into the Windows Registry, which then allow the Windows system to locate the OPC Server whenever an OPC client wants to connect to it. If the PI OPC Interface and an OPC Server are running on different machines, the user can use the OPCEnum tool to locate those registry entries on the other machine. The OPCEnum tool is explained later in this manual.

Data exchange between an OPC client and an OPC Server is performed in Groups, not individual tags. The Groups are created and defined by the client, or more rarely are configured within the OPC Server. The OPC client can choose what tags within the group to read or write. The PI OPC Interface can add tags to Groups, but they must be tags that the OPC Server recognizes as valid tags.

The OPC Server has a data cache where it keeps the most recent data. A client can specify that the data should be read out of the cache, which is very fast, or read directly from the device, which can be slow and will block all other reads and writes until the device read is finished. The PI OPC Interface by default does all reads from the cache of an OPC Server, and all writes to the device, except where the OPC standard does not allow the client to specify whether to use the cache or device. When the interface creates a Group, it specifies how often the cache values for the points in that Group should be updated. The requested update rate is usually the same as the scan rate for those points. Since this is a requested update rate, the OPC Server may not accept the requested rate, and will return the update rate that it will support for that group. The update rate to which the server agrees will be noted in the pipc.log file. All tags in a group must be in the same scan class.