Dynamic external data integration through runtime-managed discovery and extensibility services.
Platform → Technology → Supporting → TagProvider Services | Concept | Reference
Beyond Traditional Tag Management
UNS Services extend the Unified Namespace beyond traditional tag management, enabling dynamic discovery, external storage integration, and third-party module embedding. These services represent a fundamental shift from static configuration to dynamic, runtime-managed connectivity.
Three Service Types:
- Tag Discovery Service - Dynamic external tag integration
- Historian Storage Service - Flexible storage locations
- Module Extension Service - Third-party module embedding
Each service extends FrameworX capabilities while maintaining the unified architecture and consistent user experience.
Service Types
Three distinct services extend FrameworX capabilities while maintaining unified architecture:
| Service Type | Purpose | Key Benefit | Example Use |
|---|---|---|---|
| Tag Discovery | Connect external tags without mapping | Runtime-managed communications | MQTT, OPC UA, ControlLogix |
| Historian Storage | Use external historians as storage | Storage location flexibility | Canary, OSIsoft PI, InfluxDB |
| Module Extension | Embed third-party modules | Native UNS integration | Sorba.AI, custom analytics |
Tag Discovery Service
The most comprehensive UNS Service, enabling three patterns for connecting external data. The runtime creates actual tags in the real-time database (RTDB) to ensure all modules (alarms, displays, historians) can access the data uniformly.
Connection Patterns
| Pattern | When Created | Access Method | Governance |
|---|---|---|---|
| Local Tags | Configuration time | Tag.TagName | Solution-defined |
| Linked Tags | Configuration time | Tag.TagName | Solution structure, external source |
| Dynamic Tags | Runtime on-demand | Asset("path") | External system |
Runtime Management
- Auto-discovery of external namespaces
- Dynamic tag creation in RTDB when accessed
- Automatic cleanup when no longer needed
- No pre-configuration required
- Resource optimization through on-demand activation
Governance Models
The choice between tag management approaches depends primarily on where namespace governance resides:
Local UNS Governance
- Tags defined in solution configuration
- Manual mapping to external sources
- Full control over namespace structure
- Traditional SCADA workflow
- Applies to: Local Tags and Linked Tags
Dynamic External Governance
- Zero-configuration at runtime
- Adapts to external source namespaces
- Automatic discovery and creation
- Reduced engineering time
- Applies to: Dynamic Tags
Historian Storage Service
Extends the Historian Module to be "storage location agnostic" - the same configuration and runtime logic works regardless of where data is stored:
Architecture
- Historian Tags - What to store (tag selection)
- Historian Tables - When to store (triggers and grouping)
- Storage Location - Where to store:
- Default: SQLite
- SQL Databases: SQL Server, PostgreSQL
- UNS Service: Canary, PI, InfluxDB, Custom
Configuration Comparison
| Standard SQL Storage | UNS Service Storage |
|---|---|
| Configure Historian Tables Group tags into tables Use Dataset.DB.TagHistorian Customize SQL connection | Create UNS Service location Tables reference service location Add tags to tables External system manages storage |
Benefits
- Leverage existing enterprise historians
- Mixed storage strategies per table
- Seamless migration between storage types
- Native integration with external systems
Module Extension Service
Enables third-party modules to integrate as native FrameworX components with full Designer support:
Integration Process
- Partner creates XML descriptor and .NET DLL
- Files placed in FrameworX extensions folder
- Module appears in Designer under UNS → Service Connections
- Configure connection settings
- Add module elements to Asset Tree
Example: Sorba.AI Integration
Once configured, the Sorba.AI module elements appear in the Asset Tree:
- Plant
- Area1
- SorbaModel (Module Extension)
- Predictions
- Anomalies
- Parameters
- ModelStatus
- SorbaModel (Module Extension)
- Area1
The module exposes all properties through standard UNS access patterns, accessible via namespaces like any native module.
Common Characteristics
All Services Share:
- Auto-discovery - Resources discovered at runtime
- On-demand activation - Resources allocated only when needed
- Unified interface - Consistent configuration approach
- Performance optimization - Automatic resource management
- RTDB integration - All data flows through real-time database
Protocol Requirements
| Service | Required Capability |
|---|---|
| Tag Discovery | Browsing/discovery protocol (MQTT, OPC UA) |
| Historian Storage | Storage API interface implementation |
| Module Extension | .NET assembly or REST API |
Implementation Considerations
When to Use Each Approach
| Use Standard Configuration | Use UNS Services |
|---|---|
| - Full control over timing required - Legacy protocols without discovery - Regulatory compliance demands - Offline configuration mandatory - Namespace governance internal | - Discovery protocols supported - Existing storage infrastructure - Third-party integration needed - Dynamic connectivity beneficial - External namespace governance |
Performance Impact
| Service | Impact | Optimization Strategy |
|---|---|---|
| Tag Discovery | Minimal overhead | On-demand tag creation, automatic cleanup |
| Historian Storage | Depends on external | Batch operations, connection pooling |
| Module Extension | Varies by implementation | Resource pooling, lazy loading |
Security Architecture
- Services inherit FrameworX security model
- External connections use service-specific authentication
- Access control applies uniformly to all data
- Audit trail includes service operations
- Dynamic tags respect same security as local tags
Deployment Patterns
Enterprise System
- Local Tags for control logic and setpoints
- Linked Tags for equipment with multiple sources
- Dynamic Tags for enterprise/MES data
- Historian Storage to corporate infrastructure
- Module Extensions for analytics and AI
Edge Device
- Local Tags for field devices
- Dynamic Tags for diagnostic access
- Local historian storage (SQLite)
- Minimal external services
Hybrid Architecture
- Mix governance models per subsystem
- Critical control: Local Tags
- Enterprise data: Dynamic Tags
- Flexible equipment: Linked Tags
Decision Strategy
- Assessment - Identify data governance requirements
- Pilot - Test with non-critical subsystem
- Validation - Verify performance meets requirements
- Rollout - Expand systematically by area or function
- Optimization - Tune resource allocation
<ac:structured-macro ac:name="info"> <ac:parameter ac:name="title">Terminology Evolution</ac:parameter> ac:rich-text-body
Historical Context:
- Legacy Term: "TagProvider" or "Dynamic TagProvider"
- Current Term: "UNS Services" (FrameworX 10.1+)
- Key Patterns: Dynamic Tags (runtime-created in RTDB)
The terminology evolved as functionality expanded beyond simple tag provisioning to include storage services and module extensions.
In this section...