UNS (Unified Namespace)

The UNS app defines a shared, human-readable structure for industrial assets and context.
It provides a single hierarchy where teams can align on “what exists” (enterprise → site → line → machine → cell), regardless of where data originates.

Capture’s UNS hierarchy is based on the ISA‑95 equipment object model, and can be extended with custom entries when your organization needs additional levels.

Why a UNS?

A Unified Namespace makes it easier to:

• standardize naming and structure across plants, apps and projects
• keep dashboards and reports consistent (same asset paths everywhere)
• reduce integration friction between OT and IT systems

Scope

The UNS is an organizational model, not a network diagram.
It describes what assets are and where they belong, not how they physically connect.

---

ISA‑95 equipment hierarchy (default structure)

Capture follows the ISA‑95 equipment object model as a foundation.
A typical structure looks like this:

• Enterprise
  Top-level organization (group, OEM, holding company).
• Site
  Plant or facility.
• Production Line
  Line-level grouping (packaging line, assembly line, etc.).
• Machine
  A machine or major asset.
• Work cell
  A functional cell inside or around a machine (station, cell, work area).

Use the default levels when possible

If your teams can describe most assets using the ISA‑95 defaults, you get:

• more consistent reporting
• easier cross-site reuse
• fewer “one-off” structures

---

Custom entries (extend the hierarchy)

Not every organization maps perfectly to the same levels.
That’s why the UNS allows custom entries inside the hierarchy.

Custom entries are useful when you need:

• a site-specific level (e.g., Building, Zone, Hall)
• an organizational level (e.g., Department, Cost Center)
• a process level (e.g., Cell Group, Station, Step)
• a logical grouping (e.g., Pilot, Customer Area, Demo Setup)

Custom does not mean random

Custom levels should be intentional and stable.
Frequent changes to the hierarchy make dashboards, reports, and user expectations harder to maintain.

Recommendation: define a small “allowed set”

If multiple teams create their own custom levels, the UNS can drift quickly.
Consider agreeing on a small list of allowed custom node types and naming rules.

---

How to think about the hierarchy

A good UNS hierarchy answers these questions quickly:

• Where is the asset? (enterprise → site)
• What production context does it belong to? (line / area / cell)
• What is the asset itself? (machine)
• What sub-part is relevant for operations? (work cell / station)

The goal is not to model every bolt and sensor.
The goal is to create a stable structure for navigation, ownership, and reuse.

“Right level of detail”

If users often ask “where do I find this?”, you may need one more level.
If users often say “this is too deep”, you may have too many levels.

---

Best practices (recommended)

Naming

Use names that remain valid over time:

• prefer functional names over temporary project labels
• avoid ambiguous short codes unless your organization standardizes them

Examples:

• ✅ Site: Ghent
• ✅ Line: Packaging Line 1
• ✅ Machine: Case Packer
• ✅ Work cell: Labeling Station
• ❌ Machine: TestMachine2
• ❌ Line: NewLine_Final

Consistency across sites

If you operate multiple sites, keep the shape consistent:

• same level names and conventions
• same naming patterns
• same “where to put what” rules

Keep custom levels limited

Add custom levels only when they provide real operational value:

• navigation improves
• reporting becomes clearer
• responsibilities become easier to assign

Avoid “taxonomy sprawl”

Too many custom node types can make the hierarchy inconsistent and confusing.
If every project invents a new level, the UNS becomes harder to use over time.

---

What’s next

• Create and manage the hierarchy (add / edit / move nodes)
• Custom entries (when to use them and how to name them)
• Linking assets (how other apps reference the UNS structure, if enabled in your environment) ``