Local-scope UNS orchestrating built-in namespaces, user data, and external connections.

Platform → TechnologyCoreReal-Time | AI-Ready | .NET | Native | UNSPython 


Solution-Level Unified Namespace

FrameworX implements a native Unified Namespace at the solution level, providing the primary abstraction for organizing and accessing all system data. Unlike enterprise-wide UNS concepts that span organizations, our native UNS operates at the solution scope while supporting both consumption from and contribution to enterprise systems.


For the distinction between enterprise and solution-level UNS, check out the article: Local UNS vs Enterprise UNS: The Pragmatic Path to Unified Namespace.


Native Organization

The FrameworX UNS doesn't just organize user-created tags, it encompasses the entire software structure:

  • User-defined tags and assets in hierarchical folders
  • Built-in system namespaces (Server, Alarms, Devices, Scripts)
  • Runtime properties and status information
  • All accessible through the same unified interface

See  Built-In Namespaces for system namespace details.


Core Capabilities

Hierarchical Organization

Create context through folder structures that mirror your physical or logical organization:

  • ISA-95 equipment hierarchies
  • Geographic locations
  • Functional areas
  • Custom organizational models

Data Types

  • Simple tags - Basic data points with full .NET type support
  • User-defined types - Complex templates for equipment models
  • Arrays and structures - Multi-dimensional data organization

Dynamic Extensions

Beyond traditional UNS capabilities, FrameworX extends dynamically to external sources without import or mapping:

Live External Connections

  • Ephemeral assets - Connect to systems where asset definitions change dynamically
  • Database tables - Direct mapping to SQL tables as UNS nodes
  • External systems - OPC UA servers, MQTT brokers, other FrameworX systems

These appear as folders in the UNS tree but maintain live connections to their sources. Changes in the external system immediately reflect in the native UNS.

Third-Party Module Integration

External modules and add-ons register their configuration within the unified namespace, maintaining single-point access to all system components.

Details:


Native Protocol Exposure

The native UNS can be exposed through industry-standard protocols with simple configuration:

ProtocolFunctionConfiguration
MQTT BrokerPublish UNS as MQTT topicsEnable checkbox, set visibility
OPC UA ServerExpose UNS as OPC nodesEnable checkbox, configure security

No republishing or mapping required—the UNS structure automatically transforms to the target protocol format.

Visibility Control

Granular control over external exposure:

  • Public - Visible to external systems
  • Protected - Visible with authentication
  • Private - Internal only

Apply at any level—folders inherit parent visibility unless overridden.



Solution Scope and Enterprise Integration

Operating Modes

Depending on , the native UNS can:

  • Originate - Create and publish data to enterprise UNS
  • Consume - Subscribe to enterprise UNS data
  • Bridge - Both consume and originate (hybrid solutions)

Typical Architectures

  • Edge solutions - Primarily originate, publishing to enterprise
  • HMI solutions - Primarily consume from enterprise sources
  • Gateway solutions - Bridge between systems



Architectural Foundation and Related Concepts

The native UNS orchestrates multiple underlying technologies:

  • Real-Time Database - Runtime storage and event engine
  • TagProvider Services - External system integration
  • Communication Protocols - MQTT, OPC UA native support
  • Security Module - Access control and authentication

As the central abstraction, the UNS provides unified access to all these technologies through a single, consistent interface.

Related Concepts

  • - System namespace structure
  • - Underlying runtime engine
  • - External integration
  • - Configuration interface

In this section...