Asle Frantzen

AF "Repository Template"?

Discussion created by Asle Frantzen Champion on Aug 1, 2011
Latest reply on Aug 8, 2011 by Asle Frantzen

Hi vCampus

 

I've been working on creating a well structured AF hierarchy for one of our clients for the last weeks now, and as I start to see the end of it there's something I'd like to suggest - and get some feedback on.

 

 

 

Situation / issue 

 

While creating templates for these oil wells, I discovered a lot on inconsistencies in both the number of attributes for each well - and the naming convention for the PI tags. This would have been much easier to solve if the AF hierarchy was created before - or at the same time as the PI tags, but sadly I have to deal with what they have.

 

After a lot of research I came up with approximately 20 unique attributes for one of the four hierarchies I was building. But only 1 attribute was present in all 34 wells, and only 2 attributes existed in more than 25 wells. Even though this wasn't ideal for templatizing, I did create three derived templates - and copy/pasted the rest of the attributes by hand. The other three hierachies had somewhat better template conditions - but still not ideal.

 

Moving over to the naming convention of the PI tags, I was also slapped in the face with the fact that out of the few attributes common to all elements, there could be 3-4 different naming structures for the PI tags used. 60% could use the normal naming, 30% another naming - and the rest could be just about anything.

 

 

 

Suggestion / solution 

 

So this got me started thinking what would be ideal for these conditions.

 

What I would really like to have is a special purpose element template which allows you to create a repository of these 20 unique attributes, and when you start adding the elements representing your wells (assets) you could simply check off the attributes you need for each one. This "repository template" or "dynamic template" would then control the attributes as normal - but only changes to the selected attributes for each element would be propagated down to the element itself.

 

This could also solve my other problem - with the naming conventions. If I discover that the attribute "Downhole pressure sensor" uses two general ways of naming the PI tags I could create two AF Attribute templates suited for each way, and selecting the appropriate one when creating the element.

 

 

 

Conclusion 

 

I really like the idea of templates as we're used to, and it's perfect when you start with a new PI system - allowing you to plan the asset hierarchy just as you want it. I'm also exited by the idea of creating the AF hierarchy before creating the tags, i.e. letting AF actually create the PI tags by checking off the "Create PI Point" box.

 

But I feel that a new "repository template" could simplify the lives of us dealing with older tag-only based PI systems. The more human readable AF hierarchies really lower the threshold for new PI users, but I feel like I'm using much longer time than necessary when setting them up.

 

 

Outcomes