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

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

1. Brittleness: Each integration is a potential failure point
2. Inconsistency: The same asset might be Pump_101, P-101, or Equipment/Pumps/MainPump
3. Scalability: Adding a new system means building integrations to every existing system
4. 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:

1. Deploy an MQTT broker as the namespace backbone
2. Build translators to extract data from every source system
3. Publish all data to the broker in real-time
4. 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

1. Cross-Source Catalog: Conduit discovers and catalogs data across all source systems
2. Semantic Mapping: We map source system tags to a unified ISA-95 namespace
3. Query-Time Resolution: When you access /site/area/line/temperature, Conduit knows this maps to splunk:index=ot_data tag=T101 and queries it directly
4. Dynamic Discovery: New tags are automatically discovered and suggested for mapping

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

Conduit Resolution:
  └─▶ Maps to: Splunk > index=ot_data > Building_A > T_101_PV
  └─▶ Queries Splunk 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.

Streamlined Infrastructure NATS provides the real-time data plane with sub-millisecond delivery, while the query plane handles on-demand cross-source analysis — both managed by Conduit.

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 (Broker-Only)

1. Deploy an MQTT or NATS broker
2. Build translators for each source
3. Define your namespace hierarchy
4. Begin publishing data

Best for: Greenfield projects with a single data plane requirement.

Option 2: Two-Plane (Conduit)

1. Deploy Conduit translators to existing systems — they auto-register
2. NATS provides sub-millisecond real-time streaming (Real-Time Plane)
3. Cross-source query engine handles on-demand analysis (Query Plane)
4. Dynamic UNS maps NATS subjects to your namespace hierarchy automatically

Best for: Existing environments that need both real-time streaming and cross-source queries without data movement.

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.