Principles of operation for PI APS

The following operational overview of PI APS is a high-level explanation of how PI APS works, specifically the Synchronization Engine. This section contains important concepts that will help you make informed decisions when configuring and using PI APS in your specific environment.

Note: OSIsoft strongly recommends that you read the entire Principles of operation for PI APS section before you begin to install and configure PI APS.

PI Servers

PI APS is primarily a PI SDK application. The PI SDK maintains a list of PI Servers with which it can connect, called the Known Servers Table. Before a PI SDK application like PI APS can use the PI SDK to interact with a PI Server, the PI Server must be in the Known Servers Table. Therefore, the PI Servers that contain the points for the interface instances to be synchronized must be in the Known Servers Table on the computer where PI APS runs.

By default, PI APS considers all PI Servers in the Known Servers Table as potential participants in automatic point synchronization. However, the Known Servers Table is a systemwide resource that is shared by all PI SDK applications on the system. If the Known Servers Table contains PI Servers that PI APS should not use, PI APS can be configured to use only specific PI Servers in the Known Servers Table on the computer where PI APS runs.

Interfaces

The original – and most commonly used – mechanism for bringing data into a PI Server is a classic interface. A classic interface is a client application that uses the PI API (and optionally the PI SDK) in conjunction with a programming interface for a specific data source to form the bridge between a PI Server and a specific data source. The significant features of classic interfaces are the following:

• They periodically send updated data to the PI Server for historization.

• They are standalone programs or Windows services that are frequently installed on nodes other than the PI Server host.

• Multiple copies (or instances) of the same interface can be configured and running concurrently.

The second mechanism, called a PI COM Connector, is only supported by Windows-based PI Servers, not by VMS or UNIX versions of PI Server.

Note: PI COM Connectors no longer function with Data Archive 2018 SP3 Patch 1 (3.4.435.604)+ due to security enhancements made in that version. If you are planning an upgrade to Data Archive across this version boundary, follow the recommendations in this Knowledge Base article for migrating the functionality of your PI COM Connector installation to alternative OSIsoft products prior to performing the upgrade of Data Archive. If you would like to explore OSIsoft Services to assist with the migration, please contact your account representative.

Like a classic interface, a PI COM Connector also uses a programming interface for a specific data source to form a bridge between the PI Server and the data source. The most significant difference is that a PI COM Connector, as its name suggests, is a COM object that implements a specific set of methods defined by the PI Server; the PI Server calls the PI COM Connector to obtain data instead of the PI COM Connector calling the PI API or PI SDK to send data to the PI Server.

PI COM Connectors differ from classic interfaces in three other notable ways:

• The data source is a historian in its own right (either a foreign historian or possibly another PI Server). The PI Server calls PI COM Connector methods to obtain snapshot and history values from the other historian as if they were from the native PI Server snapshot or PI Data Archive.

• PI COM Connectors are much more tightly integrated with the PI Server and, therefore, are always installed on the PI Server node.

• Only one copy of each PI COM Connector is ever loaded by a PI Server (PI COM Connectors never have "instances").

This publication uses the generic term "interface" to mean either a classic interface instance or a PI COM Connector.

Each PI point has a set of attributes that define how data are collected and stored for the point. These attributes first associate each point with a particular interface instance and then with a tag on the data source for the interface instance.

For classic interfaces, the only dedicated attribute is PointSource. The PointSource attribute of each point identifies a group of classic interface instances that are configured to load points with that PointSource string. Usually, all interface instances with a common PointSource string are instances of the same interface. If only one interface instance is configured to use a specific PointSource string, then PointSource alone is sufficient to associate all points that have this string as the PointSource attribute value with the interface instance. If multiple classic interface instances use the same PointSource string, one other attribute is designated by the interfaces in the group as the InterfaceID attribute, which contains the ID number of the interface instance that is associated with each point. (Many interfaces use the Location1 attribute for this purpose.) Each interface instance loads only those points where the PointSource and InterfaceID attributes contain the same values as those configured for the interface instance.

For PI COM Connectors, the only dedicated attribute is ctr_progid. The existence of this attribute in the attribute set of a point tells the PI Server that the point is mapped via a PI COM Connector to another historian system. The ctr_progid attribute contains the COM program ID of the PI COM Connector associated with each point. Since the PI Server only loads one instance of a PI COM Connector with a specific program ID, the ctr_progid attribute is sufficient to identify the points associated with a PI COM Connector.

Since each data source has its own unique requirements, no universal set of rules governs how the PI point attributes are used to identify the data source tag associated with each PI point. PI attributes Location1-Location5, InstrumentTag, and ExDesc are commonly used by classic interfaces to identify tags on the data source. PI COM Connectors primarily use ctr_strmap and ctr_lmap. Developers are free to use these and any other PI point attributes in whatever manner makes sense for the specific interface.