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.
Table of Contents maxLevel 2 minLevel 2 indent 10px exclude Solution-Level style none
For the distinction between enterprise and solution-level UNS,
check out the article: Local UNS vs Enterprise UNS: The Pragmatic Path to Unified Namespace.
Table of Contents maxLevel 2 minLevel 2 indent 10px exclude Solution-Level style none
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:
| Protocol | Function | Configuration |
|---|---|---|
| MQTT Broker | Publish UNS as MQTT topics | Enable checkbox, set visibility |
| OPC UA Server | Expose UNS as OPC nodes | Enable 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...
| Page Tree | ||||
|---|---|---|---|---|
|