AF discovery

The PI System Connector periodically checks (discovers) for changes on the replicated AF objects in source AF system, then updates the objects on the destination. These changes include additions, updates, and deletions.

Note: When a source element is replicated, additions to the source element hierarchy are the only elements added to the destination.

Reconciliation

PI System Connector uses the PI AFSDK Import functionality to replicate AF objects on the destination. Currently, the import functionality only supports a merge. A merge does not support removal of objects like attributes, or attribute templates.

To synchronize a remove on the source to the destination, discovery will execute a reconciliation on the updated objects. Reconciliation only applies to objects that have child properties like attributes, attribute templates, ports, and enumeration values. Reconciliation is an extra step done by the connector to verify that the attributes, attribute templates, and enumeration values on the destination match the source exactly. The following is a reconcile example for an element:

A source element is created, E1, with 3 attributes A1, A2 and A3. This is replicated to the destination. Now the destination contains an E1 with attributes A1, A2, and A3. The user deletes the attribute A2 on the source. When the update E1 is discovered, the E1 is updated on the destination, and then the reconciliation step is executed on the element E1. The destination E1 is compared to the source E1, and since the attribute A2 is deleted, the attribute A2 on the destination is removed.

Note: Manual changes to AF configuration on the destination AF Server are not supported and will not be preserved. The next time PI System Connector detects a change on the source AF Object, any manual changes to the destination will be overwritten.

Rename

Discovery does support the rename of AF objects. There is a caveat for certain AF objects like attributes, attribute templates, and ports. A rename for these objects means the object on the destination is deleted and recreated.

Path Resolution

Depending on the Root PI Asset Path configuration on the PI Connector Relay, the paths on the destination may or may not match the source exactly. Elements replicated from the source will be replicated to the destination under the root PI asset path, when specified on the PI Connector Relay. See Figure 5 and Figure 6 below.

Figure 5: Source element path

Figure 6: Destination with root PI asset path

Part of the replication action is to fix these paths so the reference object can be found on the destination.

Collisions

If two or more PI System Connectors are replicating data from multiple data sources with different source AF servers through the same PI Connector Relay, then possible collisions might occur. Generally, collisions only affect library objects. An AF event frame can exist in the same hierarchy level with other event frames with the same name. An AF element cannot exist in the same hierarchy level with other elements with the same name and could result in a collision when replicated. Library objects, like element templates, require unique names. Collisions for library objects with the same name can be avoided by specifying a unique Destination AF Library Prefix per data source configuration.

An example of a collision is as follows:

PI System Connector is replicating data from AF database Database1, and it includes an element template called Template1. Template1 has three attribute templates, A1, A2, and A3. A1’s value type is double.

Another PI System Connector is replicating data from AF database Database2. It also includes an element template Template1. Template1 has two attribute templates, A1, and A4. A1’s value type is Int32.

Both connectors are started and they begin the replication process. Database1’s Template1 is the first to arrive.

Next, Database2’s Template1 arrives. Now the destination Template1 looks similar to the following:

Because an initial database replication does not include reconcile, the attribute templates from Database1’s Template1 and Database2’s Template1 are combined. In addition, the value type for A1 has changed from double to Int32.

Now the user updates Database1’s Template1 description. The discovery sees this change and replicates it to the destination. Also, the reconcile step is executed in the discovery as well. The destination Template1 now looks like the following:

Due to the reconcile step, the attribute template A4 is removed. A1’s value type is changed to double.

Orphaned Elements and Event Frames

Normally, an element or event frame has a parent object of an AF database or another element or event frame, respectively. There are certain situations where this parent relationship is broken, and the element or event frame is not parented by either. This circumstance is referred to as an orphaned element or orphaned event frame. If a search is executed on the containing AF database, the element or event frame will appear in the search results, but further inspection shows there is no parent.

Since the PI System Connector’s AF discovery can see changes on these orphaned objects, then the object and the changes are replicated to the destination. On the destination, the orphaned object would not be created as an orphan but would be parented to the destination AF database. This, of course, is undesirable behavior and, to prevent it, the AF discovery filters out changes on orphaned objects by checking for a parent before replicating the AF object to the destination.

AF Analytics Output Configuration and Performance

When configuring the output of an expression analysis in AF Analytics, we recommend either a PI Point data reference (storing the results in a PI Tag) or an analysis data reference (no history is stored). Otherwise, the PI System Connector’s AF discovery interprets every new calculation result as a change to the entire AF element and attempts to replicate that information. This creates unnecessary updates and slows down overall performance of the PI System Connector.