Key takeaways
- 01Separate identity from location: an equipment item keeps one durable identifier for life, and its position in the hierarchy is a relationship that can change without touching its history.
- 02ISO 14224 gives a nine-level taxonomy that distinguishes use and location levels from equipment subdivision levels; inspection hierarchies break when they blur the two.
- 03A graph of nodes with roles handles reorganizations, shared components and multi-site views; a fixed-depth tree forces a re-key every time the organization changes.
- 04CMLs, welds and damage mechanisms attach to components, not to units, so a unit rename or a site sale leaves the thickness history untouched.
The alkylation unit becomes part of a combined "South Complex." Two years later the complex is split back into three areas under a new operations model. Then the site is sold, and the buyer's numbering scheme prefixes every tag with a new site code. Through all of this, the exchanger E-2104 has not moved an inch, and its CMLs have been measured on schedule. Whether its twelve years of thickness history survive the third reorganization depends entirely on how the hierarchy above it was designed. Asset hierarchy design for inspection is not a data modelling exercise. It is the decision about what stays fixed when everything organizational changes.
Why do asset hierarchies break when the organization changes?
Hierarchies break for one reason: they encode something that changes into something that must not.
The most common form is identity embedded in position. A tag like carries the complex, the unit and the equipment in one string. When the complex is dissolved, the tag is wrong. Either it stays wrong forever, and new staff learn that "SC" means nothing, or it is re-keyed, and every record, report, drawing and external reference that held the old tag has to be migrated.
The second form is a fixed-depth tree. Site, unit, equipment, component: four levels, every item at exactly one place. It works until a unit is split across two operating areas, a component is shared between two equipment items, or a corporate integrity function wants to see every reformer across ten sites regardless of which unit holds them. Each of those needs an item to belong to two things, and a tree cannot express that without duplicating the item.
The third form is organizational levels in the equipment hierarchy. A "department" level, a "contractor" level, a "cost centre" level. These describe who is responsible today, not what the equipment is. They change with every restructure and drag the equipment with them.
The fourth is history attached too high. When inspection records are filed against the unit rather than the component, renaming the unit orphans the records or forces a migration.
Each of these is a design decision made early, usually for convenience, that presents its bill at the first reorganization.
What does ISO 14224 say about equipment taxonomy?
ISO 14224 exists to make reliability and maintenance data comparable across companies. To do that it defines an equipment taxonomy with nine levels, and the structure of those levels is directly useful for inspection hierarchies even where the standard itself is not mandated.
The levels run from the general to the specific:
- Industry
- Business category
- Installation
- Plant or unit
- Section or system
- Equipment unit
- Subunit
- Component or maintainable item
- Part
The standard's own framing is the useful part. Levels one to five describe use and location: where the equipment is and what it is for. Levels six to nine describe equipment subdivision: what the equipment is made of. The two groups change for different reasons. Use and location change when the organization changes. Equipment subdivision changes only when the equipment is physically modified.
An inspection hierarchy that keeps these two groups distinct survives reorganization, because a reorganization touches only the first group. The exchanger E-2104 is an equipment unit (level six). Its shell, channel and tube bundle are subunits or components (seven and eight). Its CMLs measure components. None of that changes when the alkylation unit is renamed, because the unit is level four.
ISO 14224 also provides equipment class definitions and a boundary concept, which states explicitly what is inside and outside an equipment unit for data collection purposes. Boundaries settle arguments about whether the inlet piping belongs to the exchanger or to the piping system. For inspection data, that decision determines where a CML lives, so it should be made once and recorded.
Tree or graph: which structure should an inspection hierarchy use?
A tree is the natural first model. Every node has one parent, depth is fixed, and it draws well. Inspection systems built as trees run into the same set of problems within a few years.
- A shared component, such as a common header serving two vessels, must be duplicated or arbitrarily assigned.
- A unit split across two operating areas requires choosing one, or duplicating the unit.
- A multi-site view (every pressure vessel of a given class across the company) has to be built as a query outside the hierarchy, because the hierarchy only knows one grouping.
- Welds and CMLs on piping that crosses unit boundaries belong to a line that belongs to two units.
- Reorganizations are re-parenting operations that, in a fixed-depth tree, usually mean re-keying.
A graph resolves these. Nodes carry a type or role (company, site, facility, asset, component, weld) and relationships between nodes carry their own type (contains, is part of, feeds, is located in). An equipment node can be contained by a unit and also grouped by an equipment class and also located at a site. A reorganization adds or ends a relationship; it does not touch the node or anything attached to it.
The cost of a graph is discipline. Without fixed depth, someone will attach a CML directly to a site. The mitigation is role-based rules: a CML node may attach only to a component node; a component only to an asset; geometry only at facility or company. intelliSPEC's asset hierarchy is a graph of nodes with roles, migrated from a fixed four-level tree precisely because the tree could not represent what plants actually look like, and its 3D geometry attaches only at company or facility nodes for the same reason.
How should identity be separated from location?
The single most protective design decision is that an equipment item has one identifier for life, and that identifier says nothing about where the item is.
In practice:
- A system identifier that is opaque and permanent. It is never displayed as the primary name, never encodes site or unit, and never changes. Every record, reading, attachment and relationship references it.
- A display tag that follows the plant's convention, including a site prefix if the convention requires one. The display tag is an attribute of the node, so it can be renamed without touching history, and old tags are kept as aliases so the record is findable under any name it ever had.
- Location as a relationship to the facility, unit or system node, with a start date and an end date. Moving an item, or renaming the unit that contains it, ends one relationship and starts another. The item's history shows both.
- External identifiers as attributes. The tag in the maintenance system, the number on the P&ID, the identifier in the previous inspection system. None of them is the identity; all of them are ways to find it.
This design has a cost in user interface, because people want to search by the tag they know. The alias list solves that. It has a benefit that shows up every reorganization: the migration is a relationship update, executed in an afternoon, and the thickness history at every CML is untouched because it never referenced the unit at all.
Identity is what the equipment is. Location is where the organization has put it this year.
Where do CMLs, welds, and damage mechanisms sit in the hierarchy?
Inspection data has its own layer below the equipment unit, and getting its attachment right is what keeps history stable.
- Components (shell, head, nozzle, channel, tube bundle, a pipe spool or segment) attach to the equipment unit. They are the level at which material, nominal thickness and design inputs are meaningfully constant.
- CMLs attach to components. A CML carries its own design inputs where they differ from the component, its location description, its grid geometry, and its full reading history. In intelliSPEC a CML record carries 64 fields for exactly this reason: the inputs that govern the calculation live with the point that is measured.
- Welds are nodes in their own right, attached to the components they join. A weld inspected by radiography holds its examinations and interpretations; a weld that crosses a component boundary attaches to both.
- Damage mechanisms (thinning, cracking, CUI and others) are first-class records attached to the component or CML where they are active, with their own status and history. A mechanism that spans a whole circuit is attached at the circuit and inherited.
- Circuits for piping are a grouping relationship over components and CMLs with common service and corrosion behaviour, not a level in the containment hierarchy. A CML belongs to a component and is grouped by a circuit.
The test of correct attachment: rename the unit, move the equipment to another facility node, sell the site. If any thickness history, mechanism record or weld examination has to be edited, something is attached too high.
How do you design for the reorganization you cannot predict?
The next reorganization is unknown. The design can still be tested against the kinds of change that always come.
- Rename a unit. Should be a display attribute change on one node. If it cascades, identity is embedded in position.
- Split a unit into two. Should be new unit nodes and a relationship change for each equipment node. Equipment identifiers unchanged.
- Merge two sites. Should be a relationship change at the facility level. Display tags may gain a prefix; aliases keep the old ones searchable.
- Share a component between two equipment items. Should be a second relationship, not a duplicate node.
- Show every vessel of one class across the company. Should be a query over node type and class attribute, not a walk of the tree.
- Sell a site. Should be an export of the site node and everything beneath it, with history, and the ability for the buyer to place it under their own company node without re-keying.
- Load a new 3D model of the facility. Should update the same asset nodes in place, so inspection history stays attached to geometry that has changed shape but not identity.
Run these as design reviews before data is loaded. Each one that requires a migration rather than a relationship change is a defect in the hierarchy, and it is far cheaper to fix on paper than after ten thousand CMLs are attached.
Two further habits help. Keep organizational responsibility (who owns, who inspects, which contractor) as attributes or role assignments on nodes, never as levels. And version the hierarchy itself, so a report can be regenerated as the hierarchy stood on the date of the inspection, not as it stands today.
How intelliSPEC handles it
intelliSPEC's asset hierarchy is a graph of nodes with roles: company, site, facility, asset, component and weld. It replaced a fixed four-level tree because the tree could not represent shared components, cross-unit piping or multi-site views without duplication. Relationships between nodes are data, so a unit rename or a site merge is a relationship change and the records beneath it are untouched. Data entitlement is applied at the node level over the same graph, so access to a facility or a unit follows the hierarchy rather than a separate list.
CML records attach to components and carry 64 fields including nominal thickness, tMin and its method, design inputs, grid geometry, the latest thickness and three corrosion rates, so the inputs that govern a calculation live with the point that is measured. Damage mechanisms are first-class records. The intelliINTEGRITY calculations read from these records and route minimum thickness by equipment type to ASME B31.3, ASME VIII Division 1 or API 653, returning the code and the formula with the number.
3D context follows the same rule. intelliVISION converts Navisworks models to glTF or streamed 3D Tiles, geometry attaches only at company or facility nodes, and a new model version updates the same asset nodes in place so inspection history is preserved across model revisions. The hierarchy is loaded through workbook import, CSV or the open API, and every change to it is written to the hash-chained audit trail. Programs in chemical and oil and gas facilities, where units are renamed and sites change hands most often, are where this design earns its keep.
