Page History
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
Table of Contents maxLevel 2 minLevel 2 indent 10px exclude Steps style none
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...
| Page Tree | ||||
|---|---|---|---|---|
|