Please ensure Javascript is enabled for purposes of website accessibility
Powered by Zoomin Software. For more details please contactZoomin

PI AutoPointSync

Method 1: Data source tags partitioned between instances

Method 1: Data source tags partitioned between instances

  • Last UpdatedMar 07, 2023
  • 5 minute read

Unless the following two prerequisites cannot be satisfied, Method 1 is preferable to Method 2 described later. The first prerequisite is that the PI APS Connector for the interface must support either the Tag Selection feature or some other connector-specific option for selecting a subset of the data source tags for available points. See the documentation for the specific PI APS Connector. The second prerequisite is that criteria can be formulated which select a unique subset of data source tags for each interface instance. Then, PI APS for each interface instance can be configured to own and manage a specific subset of data source tags. When devising the selection criteria, it is mandatory that no overlap in tag ownership occurs between the multiple interface instances. Also, the criteria must anticipate future additions to the data source by ensuring that any new tag satisfies one (and only one) of the selection criteria.

Data source tags partitioned by criteria

The following figure shows how the criteria partition the data source tags.

In the figure, each rectangle represents the set of tags that meet one criterion. In each rectangle, the shaded area represents the tags in the data source that meet the criterion, and the unshaded area represents tags that, if added to the data source, would meet the criterion. As shown, the sets represented by the rectangles satisfy the requirement that the sets must not overlap. Also, the rectangles cover the entire space; no gaps are present. Complete coverage is not mandatory, but tags that fall into any gaps are not detected as available points when PI APS is configured according to this method.

When each PI APS instance is configured to restrict itself to the data source tags that satisfy one of the criteria, the rectangles also correspond to the sets of tags managed by each PI APS instance. From the figure, it is easy to see that this configuration complies with the two rules stated earlier: 1) each data source tag is only managed by one PI APS instance, and 2) each PI APS instance ignores the existing points of the other interfaces.

A simplistic example of partitioning the data source tags into disjoint subsets for two interface instances is to assign the tags to interfaces based on the first letter of their names. That is, one interface instance is configured to scan tags whose names begin with the letters A through L, and the other interface instance is configured to scan tags whose names begin with the letters M through Z. If an objective of having multiple interfaces is for each interface to scan roughly half of the points, you would need to know that the tag names are evenly distributed over the alphabet. This example also illustrates a possible flaw in the criteria. Names can also begin with digits or some punctuation characters, and tags with such names will not be managed by either interface instance.

Although Method 1 is recommended because it is easier to understand and is more efficient in most respects, you should be aware of one possible disadvantage. Without a connector-specific feature for selecting a subset of the data source tags (which requires supporting functions in the data source programming interface), the general Tag Selection feature retrieves all tags in the data source in order to evaluate the selection conditions. Using the Tag Selection feature, each PI APS instance enumerates all tags in the data source during each synchronization scan. Enumerating all tags is unavoidable for many data sources because their programming interfaces do not provide a function for selectively enumerating tags. (The PI to PI Interface - APS Connector is an example of a connector where a function is available for enumerating a selective subset of tags in the source PI Server.) You need to assess the impact on your data source of multiple enumerations. If the impact on the data source from multiple searches for available points is unacceptable, use Method 2, where only one instance is configured to enumerate the data source tags.

This method may not be feasible if PI APS is being configured for existing interface instances and points were not assigned to the interface instances based on a categorization system that can be adapted for this method. That is, if the categorization system is based on data source tag attributes that are not supported by the tag selection facilities of the PI APS Connector (or no categorization system was used), the existing points must be reorganized before Method 1 can be used. If it is not possible to reassign existing points to interface instances based on selection criteria that are supported by the PI APS Connector, then Method 2 must be used instead.

Note: Before allowing a PI APS instance to automatically create or delete points, every existing point for all interface instances for a single data source must satisfy the selection criterion for the interface instance that services the existing point.

If this prerequisite is not satisfied for an existing point, the consequence is that PI APS attempts to create duplicate points for the same data source tag or deletes the point from one interface instance and creates a new point for another interface instance. Any history for the deleted point is lost, which is probably undesirable. Usually, this prerequisite is only a concern when an interface instance has existing points at the time it is registered with PI APS. In this case, using PI APS to store available points and deleted points may be helpful for verifying that existing points satisfy the criteria of their respective interface instances.

Note: Initially configure the Points Not in PI rule to Store in Available Points database and the PI Points That No Longer Exist on the Data Source rule to Store in PI in Point Deletes database.

Carefully review the results from one or more synchronizations for each interface instance for unexpected available or deleted points. When all available points are legitimate, automatic operation can be selected by changing the Points Not in PI rule to Create automatically. Similarly, one of the automatic rules can be selected for PI Points That No Longer Exist on the Data Source.

TitleResults for “How to create a CRG?”Also Available in