Skip to main content
UlexIoTy
Conduitby UlexIoTy
Features
OT Engineers
Query data across historians
IT Directors
Security-first data access
Plant Managers
Real-time operational KPIs
Division Directors
Multi-facility visibility
Routing Intelligence
AI-learned decision routing
All Solutions
View all roles
Use Cases
Blog
Insights and tutorials
ROI Calculator
Calculate your savings
Glossary
Industrial data terminology
ContactRequest Demo
Features
Use Cases
ContactRequest Demo

Footer

UlexIoTy

Conduit — Industrial Context Mesh

The Industrial Context Mesh that adds meaning to your OT data without moving it.

Meaning without movement.

Product

  • Features
  • How It Works
  • Integrations

Resources

  • Use Cases

Company

  • About
  • Contact

Legal

  • Privacy
  • Terms

© 2026 UlexIoTy LLC. All rights reserved.

Press ↑ ↓ to navigate, Enter to select
Getting Started
  • Platform Overview
  • Getting Started
Concepts
  • Context Engine
  • AI-Mediated Collaboration
  • Privacy & Security Model
  • Architecture
  • Mesh Routing Fabric
  • Natural Query Engine (NQE)
Guides
  • Configuration
  • Deployment
  • Multi-Plant Federation
Adapters
  • Splunk Translator
  • OPC-UA Translator
  • MCP IoT Gateway
  • MQTT Translator
API Reference
  • REST API
Reference
  • Query Reference
Need help? Contact us
Docs/Mesh Routing Fabric

Mesh Routing Fabric

Technical deep-dive on Conduit's two-plane architecture — NATS for real-time UNS data, MCP for queries, and standalone translators.

Mesh Routing Fabric

Conduit uses a two-plane architecture to handle both real-time data and analytical queries.

Two Data Planes

Real-Time Plane (NATS)

NATS handles all push-based, real-time data:

  • Tag subscriptions: Subscribe to uns.PlantA.Line3.Filler01.temperature and receive updates in under 1ms
  • Wildcard patterns: uns.PlantA.Line3.> subscribes to everything on Line 3
  • Edge-to-edge: Translators communicate directly through NATS without involving the control plane
  • JetStream: Persistent streams for bulk export and replay after consumer disconnection

NATS subjects map 1:1 to UNS paths. The delimiter changes from / to .:

| UNS Path | NATS Subject | | ----------------------------------- | --------------------------------------- | | PlantA/Line3/Filler01/temperature | uns.PlantA.Line3.Filler01.temperature | | PlantA/Line3/* (wildcard) | uns.PlantA.Line3.> |

Query Plane (MCP over HTTP)

MCP handles all request-response patterns:

  • NQE queries: Natural language to structured query to execution
  • Tool discovery: tools/list aggregates capabilities across all translators
  • Bulk history: Large result sets from Splunk, historians
  • Tool calls: tools/call dispatches queries to specific translators

Message Format

All NATS messages use a compact JSON envelope:

{
  "v": 72.3,
  "ts": 1739462400000,
  "q": "good",
  "u": "degF",
  "src": "opcua-translator-01"
}

| Field | Type | Description | | ----- | ------ | --------------------------------------- | | v | any | Value (number, string, boolean, object) | | ts | number | Unix timestamp (milliseconds) | | q | string | Quality: good, uncertain, bad | | u | string | Engineering unit (optional) | | src | string | Source translator ID |

Translators

Each translator is a standalone Docker container that:

  1. Connects to NATS and publishes tag values
  2. Exposes an MCP server (tools/list, tools/call)
  3. Auto-registers with Conduit Core on startup
  4. Speaks its native protocol (SPL, MQTT, OPC-UA, Modbus, etc.)

Available Translators

| Translator | Native Protocol | Status | | --------------- | ------------------------------- | ---------- | | Splunk | REST / SPL | Production | | MQTT | mqtt.js v5 | Production | | OPC-UA | node-opcua | Production | | MCP IoT Gateway | Modbus, S7, EtherNet/IP, BACnet | Production |

Translator Lifecycle

1. Start → Load config
2. Connect to NATS
3. Connect to native data source
4. Start publishing values to NATS subjects
5. Start MCP server (HTTP)
6. Register with Conduit Core (POST /mcp → initialize)
7. Accept MCP tool calls for queries
8. On shutdown → Deregister → Disconnect

Latency

| Pattern | Latency | | ----------------------------------- | ------------------ | | Single tag subscription (same site) | 0.2-2ms | | Wildcard subscription | 0.5-1ms per update | | Edge-to-edge (same site) | 1-3ms | | Cross-site via federation | 5-25ms | | Historical query (MCP) | 200ms-30s |

Next Steps

  • Federation — Multi-plant setup
  • Architecture — Full system overview
Previous
Architecture
Next
Natural Query Engine (NQE)