IEC 81346 · Part 2 of 3 · The aspect model
One object.
Several views.
A pump is not a function, a product and a location squeezed into one code. It is one object that can be represented through several structures, each answering a different question.
TL;DR
Change the lens.
Keep the object.
Aspect-oriented structures let different disciplines navigate the same technical reality without forcing every concern into one brittle tag.
=asks what purpose the object serves.-asks how the system is realised.+and++provide host and site installation views in manufacturing.%links an occurrence to a defined type structure.
Look at the pump again.
Consider one process-water pump in a manufacturing facility. Operations cares what service it supports. Engineering cares how it is constructed. A technician needs to know where it is installed. A specification system may care which reusable type it represents.
Those are not competing truths. They are governed views of the same object. Select a lens:
What purpose does this object serve?
=H1.PA1.GPB1The object remains stable while the selected constituent relationship changes. Each occurrence provides a route through one structure. Together, the views become more useful than a single overloaded identifier.
Do not compress the facility into one clever tag. Let each structure answer its own question.
Seven symbols, six structural roles.
For a manufacturing-oriented implementation aligned with IEC 81346-14, use the following names and distinctions. The values shown here are schematic; applicable class codes and hierarchy rules belong in the owner RDS.
| Identifier | Name | Question |
|---|---|---|
<> | Topnode | Which independent system provides context? |
= | Function aspect | For what purpose or task is the object considered? |
- | Product aspect | How is the system constructed or realised? |
+ | Host installation aspect | In or on which host is the object installed? |
++ | Site installation aspect | Where is it situated in the site or plant structure? |
% | Type aspect | Which defined set of characteristics is represented? |
# | Other aspect | Which documented additional structure is required? |
+ represents the location aspect. IEC 81346-14 specialises manufacturing use into host and site installation views.A set is stronger than a super-tag.
One object can have several reference designations because it can occur in several structures. When designations relate to the same object, they form a reference designation set.
This lets each structure follow its own lifecycle. The pump can move to another room while remaining the same product occurrence. A product can be replaced while the functional occurrence and its operational history remain relevant. A type definition can evolve without pretending that every installed occurrence changed identity overnight.
A modern system may also maintain a stable canonical object identifier. Reference designations remain standards-based business identifiers and navigation routes rather than being forced to act as immutable database keys.
Topnode is context, not the first level.
The top node represents the considered system at the top of a structure. Its identifier can be shown before a reference designation when independent systems need to be distinguished:
<L1>=H1.PA1.GPB1
Context first. Designation second.
The identifier inside angle brackets qualifies the context. It is not itself a single-level reference designation and does not become part of the multi-level designation inside that system.
This matters when several sites, packaged systems or independently developed models are combined. Topnode prevents local uniqueness from being mistaken for global uniqueness.
A class code is not a description.
Letter codes classify objects according to a stated classification scheme. They should not carry every fact a person may want to read from the tag.
| Structural identity | Governed properties beside it |
|---|---|
| Aspect paths and reference designations | Name, description and operational role |
| Object class | Manufacturer, model and serial number |
| Object occurrence | Asset number, status and maintenance criticality |
| Type relationship | Dimensions, performance and configuration |
Readable information remains essential. It simply belongs next to the designation as governed metadata. Encoding volatile properties into identity creates avoidable renaming and duplicated semantics.
International-looking punctuation is not enough.
# must be explicitly documented.The final article moves from correct interpretation to practical implementation: structured fields, procurement rules, validation and the difference between decorative and canonical RDS.

