PI Theory: PI AF is not a hierarchy

Blog Post created by Kenneth_Barber Champion on Jul 11, 2020

We browse it like a hierarchy, and it looks like a hierarchy, therefore it is a hierarchy, right? Not so fast, because ceci n'est pas une pipe. In this post, we will explore why the PI Asset Framework (PI AF) element "hierarchy" is not a hierarchy, what it really is, and the implications in the context of creating reference types. For brevity, I will refer to the PI AF element hierarchy as simply "PI AF".


What is (not) a hierarchy?


A hierarchy is just a tree. If PI AF were a tree, then it would have these properties:

  • Each element has exactly 1 parent, except for the root element called "Elements", which has no parent.
  • An ancestor cannot be a descendant (i.e. no cycles).


As we will see in more detail, PI AF has neither of these properties and so is not a tree.


"1 parent" counterexample


The structure below is valid in PI AF. Each pump is grouped by equipment type and location. Pump 1 and Pump 2 are children of Pumps because they are both Pumps, but Pump 1 is also a child of Circuit 1 because Pump 1 is part of Circuit 1. Similarly, Pump 2 is also a child of Circuit 2 because Pump 2 is part of Circuit 2. Each pump has multiple parentsThis is not a tree.


CircuitsCircuit 1
CircuitsCircuit 2
Circuit 1Pump 1
Circuit 2Pump 2
PumpsPump 1
PumpsPump 2


In PI System Explorer, the structure looks like this:

Hierarchy in PI System Explorer showing each pump as a child of Pumps and a circuit


PI System Explorer shows this structure as a tree by visually duplicating each pump for each of its parents, but this duplication is not inherent to the structure itself. Internally and intuitively, there is only 1 of each pump. The ability to represent the structure as a tree does not make it a tree.


Of course, assuming that you have used only Parent-Child relationships, the structure formed if you look at only relationships between primary parent and child is a tree, since each child can have only 1 primary parent. However, we are not trying to make PI AF into a tree; we are trying to understand what PI AF is.


"No cycles" counterexample


In PI AF, not only can children have multiple parents, but an ancestor can be a descendant. That is, if you follow the relationships from parent to child, you get a cycle. The structure below is valid in PI AF:


ElementsEquipment 1
Equipment 1Equipment 2
Equipment 2Equipment 1


In PI System Explorer, the structure looks like this:

Equipment 1 is both the parent and the child of Equipment 2


Equipment 1's child is Equipment 2, whose child is Equipment 1, whose child is Equipment 2, … This is definitely not a tree. But if it is not a tree, what is it?


Directed graphs


We usually think of parent elements as being some sort of grouping for its child elements. e.g. a type of equipment, a location, a department. It doesn't have to be this way. To generalize, you can think of a parent-child relationship as a "directional relationship"*, which you can visualize as "parent → child".


*(The proper term is probably "non-symmetric relation" or "directed edge". If you know the proper term, please state it in the comments.)


For example, for Pumps → Pump 1, Pumps is the parent of Pump 1 but not necessarily vice versa, and Pump 1 is the child of Pumps but not necessarily vice versa. (I say "not necessarily" instead of "not" because we could have a Pump 1 → Pumps relationship. The Pumps → Pump 1 relationship doesn't tell us anything about whether or not the Pump 1 → Pumps relationship exists.)


PI AF's element structure is made up of elements that are in this type of relationship with each other, which makes it a directed graph. You can visualize this as elements pointing to each other like in the diagrams below.


"1 parent" counterexample as a directed graph:

The "1 parent" counterexample as a directed graph


"No cycles" counterexample as a directed graph:

The "no cycles" counterexample as a directed graph


However, this is not the only way to visualize a directed graph. Other representations include, but are not limited to, a Parent/Child table or as a hierarchy, both of which we have seen earlier. The hierarchy representation requires duplicating a child to each of its parents if the child has multiple parents, which makes it difficult to find all of the parents of a given element.


Directed graph transformed into a hierarchy by duplicating children across each parent


Now that we can see PI AF as a directed graph consisting of elements in directional relationships, we can now look more closely at what those directional relationships can be.


Reference types as directional relationships


PI AF starts you off with 3 types of relationships, which are called reference types in PI AF:

Reference TypePurpose
CompositionThe child is part of the parent. If the parent is destroyed, the child is necessarily also destroyed.
Parent-ChildThe child is strongly associated with the parent
Weak ReferenceThe child is weakly associated with the parent


However, you have the option of creating your own reference types, and this is your chance to break free from the mentality of parent → child, set → subset, or group → member. The table below shows some ideas of relationships that you can make:

Reference TypePurpose
Upstream Parent → Downstream ChildMaterial/fluid flows from the parent to the child
Primary → BackupThe child is used only when the parent cannot be used

The existence of the child depends on the existence of the parent.

Extends the idea of composition beyond physical objects.

(e.g. dependence of future projects, where the attributes of the elements track mostly forecasts)


Let me know in the comments of any generic custom relationships that you have used, and I will add them to the table.