IEC 81346 · Part 3 of 3 · Owner implementation
From notation to infrastructure.
An RDS becomes valuable when the owner treats it as authoritative information: defined early, stored structurally, validated automatically and governed long after project handover.
TL;DR
Authority is a behaviour,
not a format.
A designation is not canonical because it looks compliant. It is canonical when the organisation trusts it, governs it and rejects information that cannot be traced to it.
- Store aspects as separate governed fields, not one concatenated master tag.
- Define owner structures before procurement decisions harden.
- Validate deliveries at design review, FAT, SAT and handover.
- Keep RDS connected to BIM, OPC UA and EAM without forcing one identifier to do every job.
Does the organisation mean it?
IEC 81346 creates lasting value only when the RDS is authoritative. If it is an optional drawing field or something added just before handover, it will lose every conflict against supplier-native tags and platform-specific structures.
Canonical does not mean replacing every database key, asset number or operational tag. It means the owner-governed structure is authoritative and every local representation can be traced to it.
One decorates the data. The other changes how the facility is owned.
Do not make one string carry the model.
A robust implementation stores aspect values independently. A display designation can be composed when needed, while systems retain access to each governed route and its context.
| Field | Purpose |
|---|---|
| Canonical object ID | Stable internal identity across designation changes. |
| Topnode | Independent system context. |
| Function aspect | Canonical function-oriented designation. |
| Product aspect | Canonical product-oriented designation. |
| Host installation | Installation relative to a host. |
| Site installation | Site or plant installation context. |
| Type aspect | Relationship to a governed type structure. |
| Other aspect | A documented additional aspect when required. |
| Associative relations | Governed links between object occurrences. |
This separation prevents a common failure: treating the human-readable tag as both database primary key, integration contract, lifecycle identity and complete semantic model. No string should have to perform all four roles.
Give every platform the right job.
RDS is a stable identity and structure layer. Other standards and platforms remain responsible for their own concerns. The connections must be explicit, but the systems do not all need the RDS string as their primary internal key.
For OPC UA
Expose aspect values as structured metadata or properties. Let the operational browse tree remain suited to diagnostics and operation.
For BIM
Associate reference designations with model objects without asking BIM to become the master of operational semantics.
For EAM and CMMS
Keep asset numbers, serial numbers, criticality and maintenance history as attributes linked to the governed object.
Standard syntax. Owner meaning.
IEC 81346-1 provides a construction for designating associative relations between object occurrences:
Object 1|relation code|Object 2
The syntax is standard. The relation vocabulary is governed.
The standard does not define a universal classification of relation kinds. If an owner uses codes for assignment, connection or composition, those meanings must be documented as an owner vocabulary rather than presented as universal IEC definitions.
Short fields are projections
Implementation fields such as Short_Function, Short_Product or Short_Site installation can be useful in constrained interfaces. They are not separate IEC aspects. A last-two-level display convention is an owner rule, not a consequence of Rule 19.
RDS is not an ontology
IEC 81346 does not by itself define signal states, event payloads, all domain properties, geometry, maintenance strategy or the complete relationship model of a digital twin. Use it as durable structural infrastructure, then connect the standards that answer those other questions.
Start before the first integration.
- Choose the applicable parts of the IEC/ISO 81346 series for each domain.
- State the source of every class code and project-defined relation code.
- Define canonical fields, projection rules and the owning system.
- Require supplier mappings to owner objects rather than accepting isolated local tags.
- Validate designations at design review, FAT, SAT and handover.
- Preserve mappings to legacy identifiers instead of silently rewriting history.
- Give every exception an owner, reason, approval and expiry.
The best time to agree on identity is before the first integration. The second best time is before the next one.
Automation amplifies its foundation.
A half-adopted RDS can be worse than an honest local convention. It creates the appearance of order while the real meaning still lives in supplier tags, mapping files and people's heads.
Maturity has little to do with how elaborate a designation looks. A mature implementation has clear ownership, controlled rules, machine validation, change governance and consequences for nonconforming deliveries.
With canonical object identity, automation connects and scales. Without it, automation makes ambiguity move faster.
The standard becomes valuable when it is part of how the facility is procured, changed and operated, not merely how a project is documented.

