Five names. One pump. No shared reality.

A machine supplier has one structure. Electrical design has another. Automation introduces PLC and SCADA tags. BIM has model-object identifiers. Maintenance adds an asset number. Every identifier may be useful locally, yet nobody can reliably answer whether the records refer to the same thing.

Integration teams respond with mapping tables. Those tables grow into private spreadsheets, scripts and tribal knowledge. Then a supplier leaves, a platform is replaced or a project moves into operation. The facility remains, but its meaning has to be reconstructed.

The problem is not that any one identifier is badly written. The problem is that the relationships between them are accidental. A new integration starts by rediscovering what the organisation already knew.

Names are cheap. Shared identity is infrastructure.

The code is only the surface.

IEC 81346 is often introduced as a naming standard. That is a convenient shorthand, but it encourages teams to begin with punctuation and tag templates. The standard asks more fundamental questions first:

The reference designation comes last. It expresses a path through a selected structure to an object occurrence. Starting with a desired string can create something that resembles IEC 81346 while omitting the structural logic that gives it meaning.

Object, aspect and object occurrence.

Object

An object is anything that needs to be considered during the lifecycle of a system. It can be physical, functional, spatial, typological or informational. The test is not whether you can touch it. The test is whether the organisation needs to distinguish and reason about it.

Aspect

An aspect is a selected way of viewing and structuring objects. It works like a lens: function asks what purpose is served, product asks how the system is realised, and installation asks where the object sits in its context.

Object occurrence

An object occurrence is the representation of an object within an aspect-oriented structure. The same pump can therefore occur in a functional structure, a product structure and installation structures without becoming several unrelated pumps.

This distinction is the conceptual unlock. The object is not compressed into one overloaded string. It remains one object, connected to several governed views.

Less detective work across the lifecycle.

The value is not that every code becomes instantly readable to every person. The value is that every designation can be resolved, governed and connected to the right context.

Good structure is often quiet. People find what they need. Systems agree. Components can change without losing history. The absence of friction is the result.

A backbone, not the whole body.

IEC 81346 supplies aspect-oriented structure, classification hooks and reference designation principles. It does not by itself provide a complete ontology, signal model, asset database, BIM model or data-exchange architecture.

That boundary is a strength. RDS can provide durable identity and navigation while OPC UA models operational interfaces, IFC carries geometry, an EAM system manages work history and controlled vocabularies provide domain semantics.

Punctuation can imitate compliance. Only the model can provide meaning.

The next article follows one object through the available views and explains why a reference designation set is more powerful than one giant tag.