I design a UNS topic hierarchy by borrowing two standards, not inventing a third. ISA-95 (IEC 62264) supplies the role-based equipment hierarchy, enterprise, site, area, work center, work unit, for the structure above the production line. ISA-88 (IEC 61512) supplies the physical model, process cell, unit, equipment module, control module, for the structure below it. One rule governs everything that follows: every segment of a topic path describes WHERE a piece of data lives in the business, never WHAT type it is or HOW it gets transported. Get that rule right and a plant engineer who has never seen a wiring diagram can predict a topic path from memory.
If you are arriving at this series cold, here is the one-paragraph version of what came before. A unified namespace is a broker, a semantic hierarchy, and live retained state, combined so every system publishes its current value to one shared tree instead of wiring directly to every other system. That first article defined the term and placed it as a backbone spanning ISA-95 Levels 0 through 4. The second article showed why the bespoke interfaces a UNS replaces fail hardest at exactly the ISA-95 level boundaries, because that is where both the protocol and the owning team change. This article stays on the namespace side of that trade: how to design the topic tree itself, so the one shared structure every system publishes to is actually worth sharing.
Key Takeaways
- A UNS topic path borrows its upper levels from ISA-95 (enterprise, site, area, work center, work unit) and its lower levels from ISA-88 (process cell, unit, equipment module, control module), meeting at the Area.
- The one rule that governs every segment: the path is a location, not a data type. Encode WHERE data lives, never WHAT it is or HOW it moved.
- Depth is a design decision, not a default. Model down to the equipment level a business consumer asks questions about, not down to every I/O point.
- Five concrete anti-patterns, over-nesting, inconsistent casing, data type in the path, path as a database, and no schema versioning, each produce a specific, named downstream failure.
- In a GxP plant, the chosen hierarchy is a controlled structure. Renaming or restructuring topics is a change-control event under GAMP 5, which is the argument for getting the naming rules right before the tree goes live.
How Do You Design a UNS Topic Hierarchy with ISA-95?
You design the tree top-down and bottom-up at the same time, because the two standards that inform it were written from opposite ends of the plant. ISA-95’s equipment hierarchy (enterprise, site, area, work center, work unit) reads top-down, from the company toward the floor. ISA-88’s physical model (enterprise, site, area, process cell, unit, equipment module, control module) reads bottom-up, from a single piece of equipment toward the plant. ISA-95’s own equipment model explicitly incorporates the ISA-88 physical model beneath the Area, which is exactly why a UNS topic tree can use both without a seam.
At Westbridge, that produces one path with no ambiguity about which standard is speaking at each level: auralis is the enterprise, westbridge is the site, blister-packaging is the area, blst-01 is the work center (a production line, in ISA-95 terms; a process cell, in ISA-88 terms), and checkweigher is the work unit (a unit, in ISA-88 terms). Nothing in that path names a protocol, a data type, or a vendor. That is not an accident. It is the one rule in practice.
The One Rule: The Path Is a Location, Not a Data Type
Every naming decision in this article traces back to a single test: does this segment describe a place in the business, or does it describe something else? A segment like checkweigher passes. A segment like oee_percent_float fails, because percent_float describes a data type, not a location, and it has no business being in the address at all. I apply this test to every topic I design, and it resolves most naming disputes before they start.
What Is the ISA-95 Equipment Hierarchy for Your Upper Topic Levels?
ISA-95.00.01 (IEC 62264-1), the models-and-terminology part of the standard, defines the equipment hierarchy as a set of roles rather than a fixed list of physical objects, which is why the same handful of levels fits both a discrete packaging line and a batch process cell. A role is a function a piece of the organization performs, not a specific box on a floor plan, so ISA-95 does not care whether “work center” describes a conveyor line or a fermenter. It only cares that the level performs the work-center role: a coordinated group of equipment executing a defined production activity.
Enterprise, Site, Area: The Levels Everyone Agrees On
The top three levels are the ones almost every industrial standard converges on, because they describe organizational boundaries, not equipment choices. Enterprise is the company: auralis. Site is the physical plant: westbridge. Area is a functional zone within that plant: blister-packaging, bottle-packaging, dispensing, palletizing. These three rarely change once set, which is why I put them first in every topic path regardless of how small the deployment starts.
Work Center and Work Unit: Where Lines and Cells Live
Below the Area, ISA-95 names a Work Center: a production line or process cell, blst-01 or btl-01 at Westbridge. Below the Work Center sits a Work Unit: an individual unit or work cell, checkweigher on blst-01. These two levels are where ISA-95’s equipment hierarchy formally hands off to the ISA-88 physical model, because ISA-95 defines Work Center and Work Unit as roles that ISA-88 equipment fills. ISA-95 tells you these levels exist; ISA-88 tells you what to call the equipment inside them.
The ISA-88 Physical Model: How Deep Should the Tree Go?
ISA-88.00.01 (IEC 61512-1), the batch-control models-and-terminology standard, is where the vocabulary for equipment below the line actually comes from. Its physical model runs Enterprise, Site, Area, Process Cell, Unit, Equipment Module, Control Module, and the bottom rung, Control Module, is deliberately granular: a single valve, drive, or sensor loop. That granularity is useful for control-system design. It is almost always the wrong depth for a UNS topic tree, and the standard itself is not the thing that tells you where to stop; the business questions asked of the data are.
From Process Cell Down to Control Module
At Westbridge, the ISA-88 physical model names every cell on blst-01: the blister former and filler, the checkweigher, the cartoner, the serialization vision station, and the case packer. Each maps cleanly to an ISA-88 Unit or Equipment Module. Below that sits the Control Module layer, the individual actuators and sensors inside the checkweigher: a load cell, a reject-gate solenoid, an encoder. I do not give those a topic branch of their own. They stay inside the checkweigher’s payload as fields, because exposing every control module as its own branch turns a navigable tree into a directory nobody can browse.
The Depth Heuristic: Model What the Business Asks About
The heuristic I use is simple: model down to the level a business consumer asks a question about, and stop. Somebody asks “what is the checkweigher’s OEE.” Nobody asks “what is control module 14’s discrete input 3.” The first question defines a topic; the second defines a payload field inside that topic. In a GxP plant like Westbridge, this depth decision is not a style preference. GAMP 5 treats the topic hierarchy as a controlled structure, so changing the depth after publication is a change-control event, not a quiet refactor, which is reason enough to get the heuristic right before go-live.
How Do ISA-95 and ISA-88 Combine into One Topic Tree?
ISA-95 and ISA-88 were not written as competing standards. They share their top three levels, Enterprise, Site, Area, by design, and ISA-95’s own equipment model incorporates the ISA-88 physical model beneath the Area. For a UNS, I take the union of the two: ISA-95 supplies the enterprise-facing structure above the Area, ISA-88 supplies the equipment-facing structure below it, and the two standards meet at the Area, the one level both fully agree on.
Walking the full canonical Westbridge path segment by segment makes the handoff concrete. auralis is Enterprise under both standards, westbridge is Site under both, blister-packaging is Area, the shared boundary. blst-01 is Work Center under ISA-95 and Process Cell under ISA-88, the same physical thing named by two roles. checkweigher is Work Unit under ISA-95 and Unit under ISA-88, again the same equipment. Everything left of checkweigher is location hierarchy. Everything right of it, status/oee, is the information leaf: a controlled-vocabulary label and a metric name, the point where hierarchy design ends and payload design (covered in a later article) begins.
What Naming Convention Rules Govern the Westbridge Topic Tree?
<!– [UNIQUE INSIGHT: personal experience] –>
Every UNS naming disagreement I have sat through comes down to one of five unresolved rules, so I write them down as rules rather than leaving them as taste. First, pick one consistent case and enforce it everywhere: lower-kebab-case at Westbridge, so blister-packaging, never BlisterPackaging or Blister_Packaging. Second, always publish the full path from enterprise down, even at a single site with one line, so growth never forces a rename; I established this as a principle in the first article of this series and this is where it becomes a concrete rule. Third, use stable, human-readable identifiers such as blst-01, never an IP address, a PLC register name, or a vendor serial number, because all three change for reasons that have nothing to do with the equipment’s identity.
Fourth, keep segment names singular and predictable, and restrict the information leaf to a small controlled vocabulary (status, state, config, cmd) rather than letting every team invent its own term. Fifth, reserve a place in the schema for a version marker rather than encoding a version number into the path itself.
The MQTT topic-string rules constrain this only lightly. The OASIS MQTT 5.0 specification uses the forward slash as the topic-level delimiter, disallows the wildcard characters + and # in a published topic name (they are reserved for subscription filters), and treats topic names as UTF-8 strings, which is why a lower-kebab-case path like Westbridge’s works cleanly with no escaping required. I cover MQTT’s quality-of-service levels, retained-message semantics, and sessions properly in the next article; here they only bound what a legal topic string looks like.
Casing, Delimiters, and Stable Identifiers
Consistency in casing and delimiters is not cosmetic. A single mixed-case segment, BLST_02 next to blst-01 in the same tree, silently breaks any subscription or access-control rule written as a case-sensitive string match, because blst-02 and BLST_02 are different topics to the broker even though they mean the same line to a human. I pick the convention once, document it, and treat any deviation as a defect, not a style choice.
A Controlled Vocabulary for the Information Leaf
The information leaf is the last place I let discipline slip, and it is exactly where it matters most, because it is the segment every consuming application actually subscribes to. A fixed, small vocabulary (status, state, config, cmd) means a new subscriber can predict the leaf without reading documentation, the same way it can predict checkweigher from blst-01. Free-form leaves, one team writing oee, another writing OEE_current, another writing oee_value, defeat that guessability one topic at a time.
What Are the Five Topic-Hierarchy Anti-Patterns, and Why Does Each Fail?
I have watched each of these five mistakes happen on a real plant floor, and each one produces a specific, nameable failure rather than a vague sense that something is wrong.
Over-nesting models every valve and sensor as its own topic branch instead of stopping at the equipment level. At Westbridge that would mean a separate topic for the checkweigher’s load cell, reject-gate solenoid, and encoder, instead of one checkweigher topic carrying all three as payload fields. The concrete failure: thousands of topics nobody subscribes to, and a wildcard subscription like blst-01/# returns so much noise no dashboard can use it.
Inconsistent casing or mixed delimiters, blst-01 in one branch and BLST_02 in another, silently breaks case-sensitive topic access-control rules and subscriptions, because the broker treats them as different strings even when a human reads them as the same line.
Baking the data type into the path, .../checkweigher/oee_percent_float instead of .../checkweigher/status/oee, couples the address itself to the payload’s current shape. The concrete failure: the moment the metric changes from a float to a structured object with units, every subscriber’s hardcoded topic string breaks, and the fix is a forced rename across every consumer rather than a payload-only change.
Treating the topic path as a database, encoding a batch ID or date into the address, .../checkweigher/batch/2026-07-20/oee instead of .../checkweigher/status/oee with the date inside the payload, explodes the topic count by one new branch per batch or per day and defeats retained state, because the broker now retains one value per date instead of one current value per metric.
No schema versioning, publishing oee today and quietly changing what that field means next quarter with no version marker anywhere in the topic or payload, leaves no way to evolve the topic’s meaning without a breaking rename across every subscriber. In a GxP plant this is also a validation deviation waiting to happen, since GAMP 5 expects a controlled, traceable path from one schema version to the next, not a silent redefinition.
Frequently Asked Questions (FAQ) on UNS Topic Hierarchy Design
Do I have to follow ISA-95 exactly, or can I add my own levels?
No. ISA-95 defines roles, not a rigid list you must match segment for segment. I add levels where a plant genuinely has them, a sub-area, a shift, and skip levels it does not have. What matters is that the levels stay in ISA-95’s role order (enterprise above site, site above area) and that you apply the same set consistently across every branch, so no two lines describe the same kind of thing with a different number of segments.
Should the topic path include the data type or units?
No. That is the one rule from earlier in this article stated as a direct answer: the path is a location, never a data type. Units, quality codes, and value types belong in the payload at the information leaf, not as additional path segments. Putting _float or _percent in the topic string couples the address to a schema decision, and the address should outlive that decision.
How is an ISA-95 topic tree different from a Sparkplug B topic namespace?
Sparkplug (the Eclipse Foundation’s specification, currently version 3.0.0) prescribes a fixed namespace shape: namespace/group_id/message_type/edge_node_id/device_id, built around edge-node lifecycle messages like NBIRTH and DBIRTH and metric aliasing for compact payloads. An ISA-95-based UNS tree like Westbridge’s is organized around business meaning (enterprise, site, area, line, cell), not edge-node lifecycle state. The two are not mutually exclusive, a Sparkplug-compliant broker can sit underneath a business-meaningful topic structure, but that combination is a protocol-layer decision I treat fully in a dedicated article on Sparkplug B later in this series.
How do I change the hierarchy later without breaking every subscriber?
Reserve a version marker before you need one, in the schema or a dedicated version segment, rather than renaming live topics after subscribers already depend on them. In a regulated plant this is a GAMP 5 change-control event: document the old and new shapes, run both in parallel until every subscriber migrates, and retire the old topic only once nothing still reads it. A clean topic tree is also the prerequisite for topic-level access control lists and the zone-and-conduit design IEC 62443 calls for, which I cover in a later article of this series.
References
- ISA-95.00.01-2010 (IEC 62264-1:2013), Enterprise-Control System Integration, Part 1: Models and Terminology, International Society of Automation, isa.org
- ISA-88.00.01-2010 (IEC 61512-1:1997), Batch Control, Part 1: Models and Terminology, International Society of Automation, isa.org
- OASIS, MQTT Version 5.0 Specification (2019-03-07), docs.oasis-open.org
- Eclipse Foundation, Sparkplug Specification, Version 3.0.0, sparkplug.eclipse.org
- HiveMQ, Build Industrial IoT Systems with Unified Namespace, hivemq.com
- HiveMQ, Designing Your UNS Semantic Information Hierarchy, hivemq.com
- Cirrus Link Solutions, Sparkplug Specification Documentation, docs.chariot.io
- Walker Reynolds / 4.0 Solutions, Unified Namespace video series, youtube.com/@4.0Solutions
- ValidatedState, What Is a Unified Namespace? A Ground-Up Definition, validatedstate.com
- ValidatedState, Why Point-to-Point Integration Fails at Scale, validatedstate.com