Not to my knowledge. I don't believe there's any practical limitation on the number of element levels in AF.
I totally agree with Steve. I would strongly encourage you to use templates, not just for assets but also for any hierarchical levels. Element and attribute categories will also help you later with more efficient searches.
Not that you have to tell us, but I am curious about how many levels deep you think your model will have. Do you have a feel for how many elements overall there will be?
Fully agree regarding the use of templates Rick.
It's still very early days for the company I work for, and we have only just stood up a PI AF server over the past couple of months (it's literally an empty slate at this point in time).
I, along with a couple of colleges are working on how best to structure our data within it. Every stake holder has there own idea how this should be achieved, but the one common theme that has bubble up from numerous discussions is it would be great if the structure in AF could match the physical connectivity model of the electrical utility grid.
As an example (and there are "deeper" ones than this within our distribution network) if I was to model a residential customer electricity supply connection in PI AF, based on the electrical grid connectivity model, it would look something like this (where "->" is a parent-child link):
Company -> GeographicalArea -> GXP -> ZoneSubstation -> 33kVFeeder -> DistributionSubstation -> ABS -> CB -> ABS -> PowerTransformer -> CB -> 11kVBus -> 11kVFeeder -> ABS -> VoltRegulator -> DistributionTransformer -> LVFeeder -> ICP(Customer).
For this customer, there would be 17 levels nested underneath the root element (company), and this is probably one of the least complex feeder circuits from grid to customer.
I'll probably look to follow John Messinger's advice, and break this connectivity model up into parts, most likely based on voltage level. I could then use "shortcuts" or "weak links" (I can't remember the official PI AF name for element references) to represent links between assets in one voltage group, and the beginning of the circuit/equipment it goes onto supply in subsequent voltage groups.
Does this make sense?
1 of 1 people found this helpful
There is no hard limit to the number of element levels you can create, but if you go too deep performance may be impacted. I personally try to limit any hierarchies that I build to no more than 7 levels deep at most, but sometimes a customer's requirements may be otherwise. What is your definition of 'a reasonable number of child element "levels"'?
One approach you may want to look at considering is breaking your tree up into more than one hierarchy. To determine if this could be done, I would ask questions such as 'what is the specific use case for representing all assets in a single hierarchy' and 'do I need to perform calculations from the lowest to highest levels'?
Can you break things up into smaller subsections of your grid? Model down to the substation perhaps, and then use referencing to create a second hierarchy from the substation to the customer LV connection point. Just some thoughts.
In addition to what the others responded, keep in mind what your users will be doing with AF. If they are to search for assets and data points by navigating down the hierarchy, having many nested levels may not be practical. I like John's recommendation to have multiple hierarchies. You could also use different AF databases.
3 of 3 people found this helpful
Digging into help for someone else, I ran across this remark for AFElement.FindElementsByPath :
The performance of finding elements by path can vary depending on the syntax, server version, path length and hierarchy depth. For best performance, make sure you are using the latest AF Server. Simple relative paths (no substitution or navigation up or across the hierarchy) will perform better. Element paths which exceed a length of 420 characters or a depth of 24 levels will execute slower.