mjarvis

Guidelines for PI Cloud Connect Template and Data Replication within a Company

Discussion created by mjarvis Employee on May 28, 2014

Issue

If you are a customer who is implementing PI Cloud Connect to aggregate data from different locations, this article is for you. This is going to give you guidelines for deciding which assets to replicate, and the direction of replication. This will also give you some tips to organize the information.
 

Use case

I am a customer who is implementing PI Cloud Connect inside my organization to let my asset models sync themselves. I need guidelines for organizing my data sharing through PI Cloud Connect template and data replication.
 

Solution

In general, you will want to build AF Element Templates on the top level PI AF Server. Each company may have a different name for the top level PI AF Server, such as: Corporate, Central Location, Business Unit, or Functional Center. This top level PI AF Server may or may not be a collective. The individual sites can subscribe to the Corporate AF Templates, and all elements can have a common set of attributes. The idea is to use the least common denominator of attributes that most sites will have, in the corporate template. The individual sites can always append attributes, more on that later.

Chistoph the Corporate Engineer would say “The sites will use the template I maintain to model the Fermenter Asset. Each Fermenter will need to have 8 variables for reporting at the corporate level.”

 

Template Flow.png

 

The corporate templates should be defined in their own AF Database "Template Database", this database will only include Corporate AF Templates. Only Administrators for the PI System need to have 'read' access to the "Template Database", other users can have read access to this database, but the AF Templates are generally not consumed by an end user using PI ProcessBook. Removing 'read' access to the "Template Database" is not required, but will reduce confusion of corporate users who only need access to the "Corporate Asset" Database. It is best to prepend "Corp_" to the template names to self-document the fact that the templates are being maintained at the corporate level. The diagram above shows “CORP_” prepended to the element template names.

 

The Corporate PI AF Server will publish element templates only using the PI Cloud Connect Portal. The "Select AF Templates" is one of two types of publications available in PI Cloud Connect, a simple drop down box in the tenant portal will allow this option.

 

Templates Only.png

 

A PI Connect node separate from the PI Server may be used inside a DMZ to connect to the Microsoft Azure service bus via port 443 and to the Corporate PI AF Server. The Hess Corporation demonstrated in their Users Conference 2014 presentation “Experience with PI Cloud Connect for JV Data Sharing” how they temporarily used a machine which runs PI ProcessBook for their PI Connect node, as this node has access to both the PI AF Server and the internet. Each site will subscribe to the Corporate AF Element Templates. As you will be subscribing to your own data, your experience in the PI Cloud Services Portal will be different than if you were publishing data for another organization to subscribe. To subscribe to your own data, you will have a button on the publication, shown below. For another organization to subscribe to your data, you will need to first give them permission.

 

Tenant Subscription.png

 

Next, the sites can build their PI AF Structure based on the corporate PI AF Templates. This allows everyone in the company to use the same jargon to discuss technical aspects of similar assets. The sites can add additional PI AF Templates as they build their own AF Structure, so the sites are not restricted to using only the PI AF Templates which were provided by the corporate location. An important point to make is the sites should NOT be modifying the "CORP_" PI AF Templates, as these are being replicated via a Subscription. It is best for sites to use derived templates if additional attributes are required on corporate templates.

 

derivedtemplates.png

 

The Derived Template allows sites to append attributes to the corporate storage tank template, for their unique needs. The individual sites should NOT modify the corporate templates, as these templates are designed to be shared by all sites in the corporation. The derived templates should be named with a prefix for the site identifier, so that each derived template will document itself.

 

site template.png

 

Samuel the Site Engineering Expert would say “The corporate storage tank template does not contain an elevation attribute. Elevation is obviously required at my site as we use gravity feeding for some tank material transfers. The rest of the sites do not need an elevation attribute, as the other sites are FLAT! I will build a derived template for the Palo Alto Storage Tanks.”

 

Once the sites have begun building the PI AF Structure, you should determine which part of the AF Hierarchy you want to replicate to the Corporate location using the "Select AF Elements" Publication. It is not important to build a comprehensive asset model at the site before syncing the PI AF Structure. PI Cloud Connect is designed to handle modifications and changes in the AF Hierarchy. Start small!

 

In this case, our Silicon Valley customer has a small plant in Palo Alto, CA. The AF Hierarchy is below, and shows the Product Department view. The "Production Area" is the Data Source for the Publication for "Select AF Elements" in PI Cloud Connect, this is the part of the AF hierarchy that will be replicated to the corporate location.

 

datasource.png

 

There is also a Maintenance Department view, which contains site specific needs of the Maintenance Department. The equipment maintenance view contains short-cuts to some of the other assets. The maintenance specific views do not concern the corporate location, so this part of the asset model is not transferred to corporate. Not all Elements used by the Palo Alto site, or any site, will be required at the corporate location, as some elements will only contain information important to the site.

 

The general architecture for sending the asset data to the corporate location could be similar to this:

 

Asset Flow.png

 

The Corporate Asset Model is what the corporate business location needs to perform aggregate analysis. This asset model is in the main AF Database in the Corporate AF Collective, named something similar to "Corporate Assets". At the Corporate level, a hierarchy is built with locations of all of the plants. The "Palo Alto" AF Element is the Destination Data Source for PI Cloud Connect.

 

destination.png

 

Now the Palo Alto site is sending data to the corporate level, and the asset-based model is turning the data into information. When the asset model at the individual site is modified, the changes are immediately reflected at the corporate level. When the corporate engineers need to append, edit, or delete attributes in a template from all sites, the corporate engineers need to make the modification in only one location - on the Corporate AF Collective "Template Database", these changes are automatically propagated to the individual sites. The Corporate engineers should not be modifying the assets in the "Corporate Assets" database, as these elements are being replicated via a Subscription from the sites.


Guideline Review

Use a separate database on the Corporate AF Server "Template Database" for maintaining all corporate AF Templates.
Prepend characters to the name of AF Element Templates maintained at corporate with "CORP_" or similar.
Do not modify the AF Element Templates which are prefixed with "CORP_" at the site level.
Use derived templates to append or edit attributes from the "CORP_" templates. Use a site identifier prefix in the name of Element Templates for the derived templates at the site.
The main asset model in the Corporate AF Collective "Corporate Assets" will be in a separate database from the standard set of corporate templates.
Choose one part of the AF Hierarchy to sync to corporate, and go ahead and sync the data. There is no need to have a comprehensive asset model before sending data up to the corporate level.
Do not modify the AF Elements under the Subscription Root Element in the "Corporate Assets" database.

 


Asset sharing will help your organization use the same jargon when discussing technical aspects of a process. Asset sharing will also help your organization turn data into information.

Outcomes