Dynamic external data integration through runtime-managed discovery and extensibility services.
Platform → Technology → Supporting → TagProvider Services | Concept | Reference
Beyond Traditional Tag Management
TagProvider Services extend the Unified Namespace beyond traditional tag management, enabling dynamic discovery of external data sources and embedding of third-party modules. These services represent a shift from static configuration to dynamic, runtime-managed connectivity.
Two Service Types:
- Tag Discovery — Connect to external data sources (MQTT brokers, OPC UA servers, PLCs, databases) and auto-discover their namespace. The runtime creates tags on demand without pre-configuration.
- Module Extension — Embed third-party modules (analytics, AI, custom logic) as native UNS components with full Designer support.
TagProvider Services are completely independent from the Devices module. Both can connect to external systems, but TagProvider Services focus on auto-discovery and dynamic namespace integration, while the Devices module provides explicit point-by-point control with full tag metadata.
Some protocols (MQTT, OPC UA, ControlLogix) are available in both, with different workflows..
Service Types
Service Type | Purpose | Key Benefit | Example Use |
|---|---|---|---|
Tag Discovery | Auto-discover external tags without pre-mapping | Runtime-managed, on-demand communications | MQTT, OPC UA, ControlLogix, SQL, Beckhoff |
Module Extension | Embed third-party modules as native UNS components | Full Designer integration, standard UNS access | Sorba.AI, custom analytics |
Not a TagProvider Service
Storage Locations (Historian module) allow archiving to external databases such as Canary, InfluxDB, or GE Proficy. While the underlying library is shared with TagProvider Services, Storage Locations are configured in the Historian module and serve a completely different purpose — they send data out for archiving, not discover data in. See Historian Module for details.
Tag Discovery
The primary TagProvider service. It enables three patterns for connecting external data into the UNS. The runtime creates actual tags in the real-time database (RTDB) so that all modules (alarms, displays, historians) access external data uniformly.
Connection Patterns
Pattern | How It Works | Access Method | DataLink Property |
|---|---|---|---|
Local Tags | Tag created in UNS configuration. No external binding — values come from Devices, scripts, or manual entry. |
| Not set |
Linked Tags | Tag created in UNS configuration with the DataLink property pointing to a TagProvider path. The runtime auto-manages communication to the external source. |
| Set (e.g. |
Dynamic Tags | No tag pre-created. At runtime, |
| N/A — resolved dynamically |
DataLink
DataLink is a property on UnsTags. When set, it binds a local tag to a path in a TagProvider's discovered namespace. The runtime automatically manages the connection — communication is activated on demand when the tag is read, and released when no longer needed. This is the key mechanism behind Linked Tags.
Governance Models
The choice between patterns depends on where namespace governance resides:
Local UNS Governance (Local Tags and Linked Tags):
- Tags defined in solution configuration
- Full control over tag names, types, metadata, alarms, historian
- Solution architect decides the namespace structure
- Linked Tags add DataLink to bind values from an external source while keeping local governance
External Governance (Dynamic Tags):
- Zero pre-configuration — the external source defines what exists
- Tags created at runtime when accessed via
Asset() - Namespace adapts automatically as the external source changes
- Ideal for IIoT monitoring where the broker defines the data model
Module Extension
Enables third-party modules to integrate as native FrameworX components with full Designer support. Shipping ~Q2 2026 with Sorba.AI as the first partner.
Integration Process
- Partner creates XML descriptor and .NET DLL
- Files placed in FrameworX extensions folder
- Module appears in Designer under UNS → TagProvider Services (Extension Module radio button)
- Configure connection settings
- Module elements appear in the Asset Tree
Example: Sorba.AI Integration
Once configured, Sorba.AI module elements appear in the Asset Tree alongside regular tag folders:
- 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 Asset() syntax and standard tag bindings like any native data.
Common Characteristics
Both service types share these runtime behaviors:
- Auto-discovery — Resources discovered at runtime from the external source
- On-demand activation — Communication activated only when data is actually consumed
- Automatic cleanup — Resources released when no longer needed
- RTDB integration — All data flows through the real-time database, so alarms, historian, displays, and scripts work uniformly
- Unified configuration — Both configured in Designer under UNS → TagProvider Services
Service Type | Protocol Requirement | Available Connectors |
|---|---|---|
Tag Discovery | Protocol must support browsing/discovery | ~16 connectors (MQTT, OPC UA, ControlLogix, SQL, Beckhoff, Codesys, and others) |
Module Extension | .NET assembly with XML descriptor | Partner-provided (Sorba.AI first) |
TagProvider Services vs. Devices Module
Both TagProvider Services and the Devices module connect FrameworX to external systems, but they serve different workflows:
Aspect | TagProvider Services | Devices Module |
|---|---|---|
Design philosophy | Auto-discover, bind dynamically | Define explicitly, validate strictly |
Tag creation | Optional (Dynamic Tags need none) | Required — every point maps to a tag |
Namespace control | External source can define structure | Solution architect defines everything |
Metadata (alarms, historian, units) | Full control on Linked Tags; limited on Dynamic Tags | Full control on every point |
Available protocols | ~16 (discovery-capable only) | ~100 (all industrial protocols) |
Best for | IIoT monitoring, dynamic environments, UNS integration | SCADA control, regulatory compliance, FDA validation |
Can coexist? | Yes — same solution can use both, even for the same protocol | Yes |
When to Use Each
Use TagProvider Services | Use Devices Module |
|---|---|
External source has a browsable namespace (MQTT, OPC UA) | Protocol requires explicit point addressing (Modbus registers) |
Data model is dynamic or changes frequently | Fixed, well-known set of control points |
Monitoring and visualization are the primary use case | Tight control loops, setpoint writing, regulatory compliance |
Engineering speed is a priority — minimize configuration | Full metadata (alarms, scaling, units) needed per point |
Deployment Patterns
Enterprise System
- Local Tags for control logic and setpoints
- Linked Tags for equipment with multiple data sources
- Dynamic Tags for enterprise/MES data integration
- Module Extensions for AI and analytics
Edge Device
- Local Tags for field devices via Devices module
- Dynamic Tags for diagnostic and remote monitoring access
- Minimal TagProvider configuration
Hybrid Architecture
- Mix governance models per subsystem
- Critical control: Local Tags with Devices module
- Enterprise data: Dynamic Tags via TagProvider
- Flexible equipment: Linked Tags with DataLink
Under the Hood
TagProvider Services are powered by a protocol library that supports runtime discovery, on-demand communication, and automatic resource management. This same underlying library is also used by the Historian module for Storage Locations (external archiving to Canary, InfluxDB, GE Proficy, etc.).
From the user's perspective, these are separate features in separate modules — TagProvider Services live in UNS, Storage Locations live in Historian. The shared library is an implementation detail, not an architectural relationship.
Partners building Module Extensions or custom connectors may encounter this shared foundation when working with the SDK.
In this section...