Information architecture · From reference to meaning
One machine.
Different questions.
IEC 81346, ISA-95 and Brick are often treated as competing ways to describe the same thing. They become more useful when each is given the job it was designed to do.
TL;DR
Reference.
Belonging.
Meaning.
Execution.
One technical object can be described correctly in several ways because people and systems need different truths about it.
- IEC 81346 provides governed technical structures and reference designations.
- ISA-95 provides manufacturing-operational context, equipment roles and physical-asset assignments.
- Brick provides machine-readable building-domain classes and semantic relationships.
- A CMMS/EAM manages maintenance work, condition, cost and asset lifecycle.
- Preferred names make objects recognisable. Canonical identity keeps every representation connected.
One tag is asked to carry the whole facility.
A process-water pump has a supplier tag. Electrical design gives it another reference. Automation creates a PLC name. Operations calls it by the service it provides. Maintenance assigns an asset number. A building model stores its own object identifier.
Every identifier may be useful locally. The trouble begins when the organisation tries to make one of them authoritative for every purpose.
The chosen tag grows until it contains site, area, line, function, equipment type, sequence number and perhaps a vendor abbreviation. It looks informative, but its meaning is brittle.
Move the equipment and the location becomes wrong. Replace the product and the serialised identity changes. Reorganise the production line and the operational path changes. Translate the interface and the preferred name changes.
The object did not necessarily become a different object each time. One of its representations changed.
One tag can be convenient. It cannot be complete.
The answer is not a longer tag. It is a clear division of responsibility between identity, names, structures, classifications, relationships and lifecycle systems.
One pump. Several valid answers.
Consider a pump that circulates process water in a bakery. The answer changes with the question.
Recognisable language for operators and other people.
| Need | Illustrative representation | What can change it? |
|---|---|---|
| Human recognition | Process-water pump 1 | Language or operating convention |
| Operational belonging | Enterprise / Site / Area / Work Center / Work Unit | Reorganisation or reassignment |
| Function aspect | =H1.PA1.GPB1 | Change to the function-oriented structure |
| Product aspect | -GPB1 | Change to the product-oriented structure |
| Semantic class | brick:Pump | Vocabulary or modelling decision |
| CMMS functional position | PWP-01 | Maintenance-system convention |
| Installed asset | A-18472 | Physical replacement |
| Canonical identity | urn:owner:object:7421 | The intended entity ceases or is redefined |
The strings are schematic. The important point is that every value has a declared scope and an authority.
A path explains belonging. A graph explains relationships. A designation provides a governed route. None of them is the object itself.
Give every model the right job.
No standard has failed because it cannot do everything. Problems begin when we ask one standard to do another standard’s job.
IEC 81346: technical structure and reference
IEC 81346 begins beneath the name. It asks which objects need to be considered, how they occur in selected aspect-oriented structures and how those occurrences can be referenced unambiguously.
The Function aspect asks for what purpose or task an object is considered. The Product aspect asks how a system is constructed or realised. In the manufacturing application, the Host installation aspect and Site installation aspect provide installation-oriented views. The Type aspect and a documented Other aspect provide further governed structures where required.
<> Topnode= Function aspect- Product aspect+ Host installation aspect++ Site installation aspect% Type aspect# Other aspectThe result is not necessarily one definitive tag. One object can have several connected reference designations because it can occur in several structures.
IEC 81346 is an address, not a sentence.
ISA-95: operational belonging
ISA-95, also published internationally as IEC 62264, addresses enterprise-control system integration in manufacturing. Its models cover much more than hierarchy, but its role-based equipment model provides a useful answer to one practical question: where does this resource belong in the organisation of production?
Work Centers and Work Units take forms appropriate to the production model, including Production Line, Process Cell, Production Unit, Work Cell, Unit, Storage Zone and Storage Unit. Equipment Modules and Control Modules provide further decomposition where applicable.
An owner may create a readable browse path such as Production / Bakery / North Plant / Building 4 / Baking / Line 2 / Oven 3. That path crosses purpose, portfolio, installation and operational structures. It is a useful owner projection aligned with ISA-95 where applicable, not a universal ISA-95 designation.
Technical structure explains the system. Operational belonging explains the work.
Brick: semantic meaning and relationships
Brick is an open ontology for describing physical, logical and virtual entities in buildings and the relationships between them. It can classify pumps, air-handling units, sensors, commands and spaces, then state how those entities are connected.
Instead of relying on a point name such as B4_AHU03_SAT, a Brick model can state that an entity is a supply-air temperature sensor, that it is a point of AHU 3, and that the air-handling unit feeds a particular air system or zone.
That is closer to how people think: pump, sensor, room, feeds, is part of. But Brick still does not provide the preferred name that operators use. It provides a governed vocabulary from which applications can understand meaning.
Brick can provide the noun. The owner still has to provide the language.
CMMS/EAM: maintenance execution and lifecycle
A CMMS or EAM platform, such as Maximo, manages the operational consequences of owning technical assets. It records work orders, preventive maintenance, inspections, failures, condition, cost, materials, installed assets and lifecycle history.
It may also provide locations, asset hierarchies, classifications and configurable relationships. That makes it operationally indispensable. It does not make its local tag an enterprise semantic standard.
The CMMS tag tells maintenance where to place the work. Canonical identity tells the enterprise what the work was performed on.
The role can survive the asset.
The phrase “the pump” often hides two different entities.
The first is a persistent role: process-water pump 1 must circulate water for this part of production. The second is a physical asset: manufacturer X, model Y, serial number 12345 currently fulfils that role.
ISA-95 distinguishes logical equipment from physical assets. The logical equipment can remain while the physical device changes. IEC 81346’s function-oriented and product-oriented structures offer another useful separation between required purpose and realised construction. A CMMS/EAM can represent the functional position and the installed asset as different records.
This distinction preserves the history people actually need. Operations can follow the enduring role. Maintenance can follow each product. Engineering can follow its relevant structural occurrences. The semantic model can classify and relate the entities without pretending they are one record.
The role can survive the asset. The records should explain both.
Canonical does not mean one master string.
The standards and systems need a way to agree which intended entities their records concern. That is the role of canonical identity.
No standard discussed here mandates this exact mechanism. It is an owner architecture decision: a controlled way to keep several authoritative representations aligned without collapsing them into one record.
Canonical identity is not another human tag and not another attempt to replace every local identifier. It is a stable, system-neutral reference used to connect governed representations.
| Information | Purpose |
|---|---|
| Canonical entity ID | Stable cross-system identity |
| Entity kind | Role, physical asset, space, system, point or representation |
| Preferred names | Human-readable and multilingual language |
| IEC 81346 designations | Technical routes through aspect-oriented structures |
| ISA-95 representation | Operational role and belonging |
| Semantic classes | Brick or another controlled vocabulary |
| CMMS/EAM references | Maintenance locations, assets and records |
| Source references | PLC, OPC UA, BIM, historian and document identifiers |
| Assignments and relations | Which asset fulfils which role, where and when |
| Authority and provenance | Who owns each assertion and where it came from |
The information backbone does not need to copy every work order, drawing or time-series value. It needs enough identity, context and provenance to resolve the authoritative source.
Store the meaning centrally. Leave the payload with its authoritative system.
This is why the models should be aligned instead of collapsed. A Brick entity can map to a canonical entity. An ISA-95 role can be represented as another entity. An IEC 81346 object occurrence can provide a governed designation. A CMMS asset can point to the physical product. Equivalence should only be asserted where the scopes genuinely match.
One shared reality does not require one monolithic model.
Boundaries are part of the information model.
An immature architecture chooses one system and calls it the master of everything. A mature architecture states what each model owns, how the representations are linked and what happens when they disagree.
| Accidental architecture | Governed architecture |
|---|---|
| One visible tag becomes the integration key | Stable canonical identity links local designations |
| Hierarchy levels are generic folders | Every level and relationship has declared meaning |
| A Brick class is copied into a description | Semantic class and human name remain distinct |
| ISA-95 becomes a home-made tag syntax | Operational levels are stored as typed structures |
| IEC 81346 is reduced to punctuation | Designations are generated from governed aspect structures |
| The CMMS asset number becomes the machine | Role and physical asset remain distinguishable |
| Replacement overwrites history | Assignments retain effective dates and provenance |
| Every integration creates another mapping table | Alignments are governed information products |
The test is not whether every system displays the same identifier. The test is whether the organisation can resolve each representation to the correct entity, understand its scope and trace who has authority to change it.
Do not ask a designation to become an ontology. Do not ask an ontology to become a work-order system.
The standards do not need a winner. The architecture needs boundaries.
Different truths · One governed reality
The next question is not which standard should win.
IEC 81346 can provide a governed route to the object. ISA-95 can place it in operations. A CMMS/EAM can tell us what happened to it. Preferred names let people recognise it. Canonical identity keeps the representations coherent.
But how does another application understand that the object is a pump, that it feeds a process-water system, that it has a discharge-pressure sensor and that the sensor measures a condition affected by the pump?
That is where Brick begins.Sources and further reading
- IEC 81346-1:2022, Industrial systems, installations and equipment and industrial products, structuring principles and reference designations
- IEC 81346-14:2026, Manufacturing and processing systems
- ISA-95, Enterprise-Control System Integration
- OPC UA for ISA-95, equipment element levels
- OPC UA for ISA-95, equipment roles and physical assets
- Brick, a uniform schema for representing metadata in buildings
- IBM Maximo Application Suite
