If you've been following trends in industrial data architecture, you've likely encountered the term "Unified Namespace" or UNS. It's become a hot topic in manufacturing and process industries, but there's considerable confusion about what it actually means and how to implement it.

In this post, we'll demystify the Unified Namespace concept, explore its benefits and challenges, and show how Conduit's approach offers a practical path forward.

The Traditional Industrial Data Architecture

Before diving into UNS, let's understand the problem it solves.

Traditional industrial environments look something like this:

┌─────────────┐     ┌─────────────┐     ┌─────────────┐
│   SCADA 1   │     │   SCADA 2   │     │  Historian  │
└──────┬──────┘     └──────┬──────┘     └──────┬──────┘
       │                   │                   │
       ▼                   ▼                   ▼
┌─────────────┐     ┌─────────────┐     ┌─────────────┐
│    MES 1    │────▶│    MES 2    │────▶│     ERP     │
└─────────────┘     └─────────────┘     └─────────────┘

Each system has its own data model, naming conventions, and interfaces. Getting data from SCADA into the ERP requires point-to-point integrations. With N systems, you potentially need N×(N-1)/2 integrations.

The Problems This Creates

Brittleness: Each integration is a potential failure point
Inconsistency: The same asset might be Pump_101, P-101, or Equipment/Pumps/MainPump
Scalability: Adding a new system means building integrations to every existing system
Context Loss: Data loses meaning as it moves through transformation layers

Enter the Unified Namespace

The Unified Namespace is an architectural pattern that addresses these challenges by creating a single, hierarchical namespace for all industrial data.

The Core Concept

Instead of point-to-point integrations, all systems publish to and subscribe from a central namespace:

                    ┌─────────────────────┐
                    │  Unified Namespace  │
                    │                     │
                    │  /enterprise        │
                    │    /site            │
                    │      /area          │
                    │        /line        │
                    │          /cell      │
                    └──────────┬──────────┘
           ┌──────────┬────────┼────────┬──────────┐
           │          │        │        │          │
           ▼          ▼        ▼        ▼          ▼
       ┌──────┐   ┌──────┐ ┌──────┐ ┌──────┐  ┌──────┐
       │SCADA │   │ MES  │ │Hist. │ │ ERP  │  │ ML   │
       └──────┘   └──────┘ └──────┘ └──────┘  └──────┘

The namespace follows a hierarchical structure, typically based on ISA-95:

/enterprise/
  /site/
    /area/
      /line/
        /cell/
          /asset/
            - temperature
            - pressure
            - state

Benefits of UNS

1. Single Source of Truth Every system references the same namespace. There's no ambiguity about what Pump_101 means.

2. Publish-Subscribe Decoupling Systems don't need to know about each other. They publish to topics and subscribe to topics. Adding a new consumer doesn't require changing producers.

3. Consistent Data Model The ISA-95 hierarchy provides a standard way to organize assets, processes, and data.

4. Simplified Integration Adding a new system means connecting it to the namespace once, not to every other system.

The Traditional UNS Challenge

If UNS is so great, why isn't everyone using it? Because traditional implementations require moving data.

The standard approach:

Deploy an MQTT broker as the namespace backbone
Build adapters to extract data from every source system
Publish all data to the broker in real-time
Build new applications that consume from the broker

This works, but creates significant challenges:

Data Movement: You're duplicating data, often petabytes of it
Latency: Real-time publishing requires significant infrastructure
Governance: Multiple copies of data create compliance concerns
Cost: MQTT infrastructure at scale is expensive
Historical Data: Most UNS implementations focus on real-time; history is an afterthought

Conduit's Approach: The Dynamic UNS

Conduit takes a fundamentally different approach. Instead of moving data into a UNS, we create a virtual namespace that provides UNS benefits without data movement.

How It Works

Federated Catalog: Conduit discovers and catalogs data across all source systems
Semantic Mapping: We map source system tags to a unified ISA-95 namespace
Query-Time Resolution: When you access /site/area/line/temperature, Conduit knows this maps to PI:Tag_T101 and queries it directly
Dynamic Discovery: New tags are automatically discovered and suggested for mapping

User Query: /factory/building-a/line-1/mixer/temperature

Conduit Resolution:
  └─▶ Maps to: PI System > Building_A > Mixer_Temps > T_101_PV
  └─▶ Queries PI directly
  └─▶ Returns: 72.4°C @ 2024-01-20T14:23:15Z

Benefits of the Dynamic Approach

No Data Movement Your data stays where it is. Conduit provides the unified view without the infrastructure burden.

Instant Historical Access Because we query source systems directly, you get full historical depth immediately. No waiting for data to accumulate in a new system.

Reduced Infrastructure No need to provision MQTT brokers, build publishing adapters, or manage message queues.

Easier Adoption Start with the systems you have. No "rip and replace" required.

Building Your Namespace Hierarchy

Whether you use a traditional or dynamic UNS, the namespace design is critical. Here's a practical approach:

Start with ISA-95

The ISA-95 standard provides a proven hierarchy:

Enterprise
  └─ Site (Physical Location)
      └─ Area (Functional grouping)
          └─ Work Center (Production unit)
              └─ Work Unit (Equipment/Process Cell)
                  └─ Equipment Module

Add Asset Attributes

Under each equipment module, organize by attribute type:

/site-chicago/
  /production/
    /line-1/
      /mixer-m101/
        /process/
          - temperature
          - pressure
          - speed
        /status/
          - state
          - mode
          - alarms
        /quality/
          - batch_id
          - spec_limits

Consider Context Requirements

Think about how users will query:

By location: "All temperatures in Building A"
By equipment type: "All mixer speeds"
By process: "All fermentation parameters"

Design your hierarchy to support the most common access patterns.

Getting Started

If you're ready to implement a Unified Namespace:

Option 1: Traditional (MQTT-Based)

Deploy HiveMQ, EMQX, or similar broker
Build SparkplugB adapters for each source
Define your namespace hierarchy
Begin publishing data

Best for: Greenfield projects or when you need true real-time pub-sub.

Option 2: Dynamic (Conduit)

Connect Conduit adapters to existing systems
Let auto-discovery catalog your data
Map discovered tags to your namespace hierarchy
Start querying immediately

Best for: Existing environments where data movement is impractical.

Conclusion

The Unified Namespace is a powerful architectural pattern that solves real problems in industrial data integration. But the traditional approach—moving all data to a central broker—isn't always practical.

Conduit's dynamic UNS provides the benefits of a unified namespace without requiring data movement. You get consistent naming, simplified access patterns, and cross-system queries while keeping data where it lives.

Want to see how a dynamic UNS works with your existing systems? Request a demo and we'll show you how to build a unified namespace over your current infrastructure.

What is a Unified Namespace (UNS) and Why It Matters