Asset Topology as a Graph: Why Industrial Hierarchies Lose Information

#Abstract

Industrial asset registers are modelled as hierarchies because the standards that govern them describe hierarchies. Physical plants are not hierarchical, and forcing the topology into a tree either duplicates nodes or misrepresents connectivity. This report characterises the mismatch, proposes retaining the standard hierarchy as one edge type within a multi-relational graph, and reports what changes in query behaviour.

#The mismatch

Standards for enterprise and control system integration define an equipment hierarchy of enterprise, site, area, work centre and work unit [1]. This is genuinely useful: it gives a shared vocabulary and a boundary between operational and enterprise systems.

Three common physical arrangements violate the tree:

1. Shared headers. A distribution header serves units in several areas. Under a tree it belongs to one area and its relationship to the others is unrepresentable.
2. Site utilities. Instrument air, cooling water and power cross the entire site. Their correct parent is the site, and their functional relationships are with equipment several levels down.
3. Shared spares and swing equipment. A unit that can be lined up to either of two trains belongs to both, and to neither exclusively.

The two available responses under a tree are duplication, which breaks identity, and arbitrary assignment, which makes the structure lie about connectivity. Both are observed in operating asset registers.

#What the distortion looks like in a register

An abstract statement that trees cannot represent shared resources is easy to accept and easy to underestimate. A small concrete fragment shows what the register actually ends up containing.

1physical reality                       as recorded in a tree register
2
3   [instrument air header]             Site
4     |        |         |               +- Area 100
5     v        v         v               |    +- V-101   (air-operated)
6   V-101    V-205     V-310             |    +- ...
7  (A100)   (A200)    (A300)             +- Area 200
8                                        |    +- V-205   (air-operated)
9   one header, three areas              +- Utilities
10                                             +- AIR-HDR-01
Copy

The header exists in the register, filed under a utilities branch, and its relationship to the three valves it actually supplies exists nowhere. The information is not wrong. It is absent, and its absence is invisible, because the register looks complete.

The consequence appears when somebody asks a question the register was never able to answer. Taking the air header down for maintenance affects those three valves and whatever they control. Under the tree the only way to establish that is to consult the drawings, which is what people do, which is why the register is not trusted for this class of question and why a parallel understanding lives in the heads of the people who have been there longest.

A register that cannot answer the questions people actually ask does not get corrected. It gets worked around, and the workaround is somebody's memory.

#Construction

The proposal is to represent topology as a labelled multi-relational graph in which the standard hierarchy is one edge type among several rather than the structure of the data [2].

1contains        the ISA-95 hierarchy, retained and queryable as before
2feeds           process connectivity, from the drawings
3measured_by     instrumentation attached to equipment
4isolates        valves and their isolation relationships
5spare_for       swing and shared equipment
Copy

The hierarchy remains fully available: a query for everything under an area is a traversal restricted to contains edges. What changes is that connectivity questions no longer have to be answered through the hierarchy, which is what forced the distortions.

#Questions that become answerable

The argument for the change is not representational elegance. It is a specific set of questions that move from unanswerable to a traversal, and it is worth listing them because they are the ones that justify the work to the people paying for it.

• What is affected if this is taken offline. A traversal over feeds and isolates from the asset, bounded by isolation points. Under a tree this requires the drawings.
• What can measure this. Instrumentation attached directly, plus instrumentation on connected equipment that carries indirect evidence. The second set is what an experienced engineer reaches for when the direct instrument is unavailable, and it is entirely absent from a hierarchy.
• What is the isolation boundary for this work. The set of valves that must be closed to separate a piece of equipment, which is a graph cut and not a subtree.
• What else looks like this. Equipment with similar connectivity and similar instrumentation, which is a structural similarity question and is the basis for transferring a failure mode from one unit to another.

Only the first of these was requested. The other three emerged once the topology was queryable, which is the ordinary experience with representation changes: the value is mostly in questions nobody thought to ask while the answer was impossible.

#What the graph makes harder

Presenting only the gains would be dishonest, and two things genuinely become more difficult.

Roll-ups lose their obvious meaning. Under a tree, the cost of an area is the sum over its subtree, and every node is counted once because every node has one parent. In a graph, a shared header is reachable from three areas, and any aggregate must state which edge type it traverses and how it treats equipment reachable from several roots. The hierarchy is retained precisely so that financial and organisational roll-ups continue to work unchanged, and the discipline required is that such reports traverse contains edges only. Nothing enforces that, and a report written against the general graph will double count.

Access control by subtree stops being sufficient. Permissioning a user to an area is natural under a tree. In a graph, a traversal from an asset the user may see can reach an asset they may not, and the honest options are to filter results, which produces confusing partial paths, or to restrict traversal, which produces wrong answers silently. This is unresolved in the implementation described, which filters, and the partial paths do confuse people.

#Getting there from an existing register

No operating site will accept replacing its asset register, and a proposal that requires it will be declined for good reasons. The migration that works is additive.

The existing hierarchy is imported as contains edges, unchanged and complete, so that on day one the graph answers every question the register answered and no others. Nothing has improved and nothing has broken, which is the only acceptable starting position.

Additional edge types are then populated per source, each independently useful. Instrumentation edges come from the control system information model as described below. Process connectivity comes from intelligent drawings where they exist and from manual entry where they do not, and it is added for one unit at a time rather than site-wide, since a partially populated feeds relation is useful for the part that is populated and a half-finished site-wide import is useful for nothing.

The register remains the system of record throughout. The graph is derived, which means it can be rebuilt, and being rebuildable is what makes it acceptable to add speculatively.

#Why the information model matters more than the values

Interoperability protocols for industrial equipment carry an address space with typed nodes, references between them and attached semantics [3]. A client that reads only values discards the type information and the reference structure, then reconstructs both by hand, per site, from documentation.

Importing the information model rather than the tag list is therefore the practical route to a populated graph. The mapping is performed once per site by type instead of once per point.

#Ranking and explanation

Once topology is a graph, the operational question becomes what is related to a given asset, which requires ranking. A hop-decayed product of edge confidence and type weight, optionally augmented with a centrality term [4] and structural link prediction over shared neighbours [5], is sufficient in practice.

The finding worth reporting is that ranking quality was not the limiting factor on adoption. A ranked list without a stated reason was not used by operators. Rendering the shortest path as a sentence, using one phrase per edge type, changed the feature from ignored to used, and no amount of weight tuning produced a comparable effect.

#Security constraint

Populating the graph requires data from control systems, which are protected deliberately. An architecture in which the monitoring path is one way by construction rather than by policy [6] is what makes the deployment acceptable to the organisation responsible for the control system, and it constrains the design from the beginning rather than at review.

#Limitations

No user study supports the explanation finding. It rests on observed usage before and after the change on a small number of sites, with no controlled comparison, and it is the claim in this report most in need of proper evaluation.

The edge type vocabulary above is drawn from process industry practice [7] [8] and is not proposed as a standard. Whether a common vocabulary across industries is achievable is not addressed, and the reference architecture work on digital twin manufacturing frameworks suggests the answer differs by sector [9].

No performance figures are given. Traversal cost on a plant-scale graph, the depth at which queries stop being interactive, and the storage overhead relative to the register are all unmeasured. Plants are large but not internet-scale, so I expect this not to be the binding constraint, and expecting is not measuring.

The access control problem described above is stated and not solved. For a deployment where the topology itself is sensitive, rather than merely the values on it, the filtering approach used here is probably inadequate and the design would need revisiting.

Finally, the population of the graph beyond the hierarchy depends on source data whose quality varies enormously between sites. Where drawings are current and intelligent, the feeds relation is cheap to populate. Where they are scanned images from the 1980s annotated by hand, it is a manual data entry project of considerable size, and nothing in this report reduces that cost. The construction is worth the effort only where the effort is affordable, which is a site-by-site judgement rather than a general recommendation.