AnsweredAssumed Answered

What is a good AF structure/hierarchy regarding many analyses?

Question asked by JoakimNäsström on Oct 13, 2020
Latest reply on Oct 14, 2020 by ChristophRose

Hi,

I would like to get some input into what is a good structure/hierarchy in AF. Most tutorials and guides about AF uses simple sites with one or two components, each component having one or two analyses. I'd like to get some comments regarding what you think is a good approach for structuring data in AF with respect to analyses and how this could be scaled up.

 

In programming you learn a lot about keeping functions small and that they should only do one thing (single purpose). If the function is large, you try to split it into smaller pieces in a way that they can be reused. Is there a similar strategy that you should use in AF?

 

For example, on each of our site we have a number of different components. Take for example a pump which we call Pump01. In AF there would be a corresponding element Pump01 which organizes the information about the pump, such as.

  • Temperature
  • Current
  • Vibration
  • RPM

 

Assume we want to have multiple analysis on the pump. I can see two ways of structuring information in AF with regards to building up analyses:

  1. Define all analyses on the element Pump01 (actually the pump template). Several attributes would be needed, such as configuration parameters and output points/attributes, organized/grouped by the analysis. With many analyses, the attribute list would become rather long. Also, each pump may only use some of the analysis and others may need two different similar analysis. This results in large elements and unused attributes. The benefit is that a new analysis could easily be created for all pumps by updating the pump template.
  2. Define/create child-elements which contains the analysis (like single purpose functions). To trend the temperature and warn on HI/LO, one would create a child element for Pump01 specific for trending temperatures and raising warnings. This could even be based on a generic "HILOTrend" template. This has the advantage analyses being selective and the attributes in the "analysis element" would only contain the configuration/input/output values to that single analysis. The disadvantage however is that it becomes more tricky to create new analysis for all pumps as you have to create child elements in order to do that, not just updating the pump template. Also presenting this information in PI Vision using context switching might become problematic.

 

An visual view of what I tried to explain above, 1 or 2:I visual view of what I tried to explain above, 1 or 2:

 

 

What do you think is a good structure? Or would you do this in another way? Maybe using different AF databases for running analysis, calculating states and presenting information in PI Vision.

 

I know that this is very dependent on our setup and what we want to accomplish. Also that we should test and try. But I would like to know how others are doing to get some inspiration for a better solution.

 

Br

Joakim

Outcomes