Page History

One linerDynamic external data integration through runtime-managed discovery and extensibility services.

Platform → Technology → Supporting → Tag Provider TagProvider Services | Concept | Reference

Each service extends FrameworX capabilities while maintaining the unified architecture and consistent user experience.Image Added

Service Types

Image Removed

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

Key Capabilities

• Dynamic discovery of external tags
• Runtime-managed communications
• Three connection patterns (Local Tags, Linked Tags, Smart-Binding)
• Auto-activation based on usage

Quick Reference

. 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

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

How It Works

be "storage location agnostic" - the same configuration and runtime logic works regardless of where data is stored:

Historian Configuration
    ??? Historian Tags: what to store. Group tags to a Historian Table
    ??? Historian Tables: when to store (Triggers). The where is a link to Storage Location object.
    ??? Storage Location: where to store. ← UNS Service extends this
        ??? Default: SQLite
        ??? SQL Databases: SQL Server, PostgreSQL
        ??? UNS Service: Canary, PI, InfluxDB, Custom

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

Configure Historian Tags grouping into the tables

Keep the Storage Location to TagHistorian  the TagHistorian as needed a Storage Location using UNS ServicesDefine Historian Tables to use that Historian Tags those Storage managed by external system

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

Supported External Historians

• Canary Historian
• OSIsoft PI
• InfluxDB
• Custom implementations via API

Module Extension Service

Enables third-party modules to integrate

as native FrameworX components with full Designer support

Use Cases

:

Integration

How It Works

ac:layout <ac:layout-section ac:type="single"> ac:layout-cell

Process

1. Partner creates XML descriptor and .NET DLL
2. Files placed in FrameworX extensions folder
3. Module appears in Designer under UNS → Service Connections

User configures

1. Configure connection settings

Module

1. Add module elements

can be added

1. to Asset Tree

</ac:layout-cell> </ac:layout-section> </ac:layout>

Example: Sorba.AI Integration

Once configured, the Sorba.AI module

elements appear in the Asset Tree:

UNS Asset Tree
??? Plant
?   ??? Area1
?   ?   ??? SorbaModel (Module Extension)
?   ?       ??? Predictions
?   ?       ??? Anomalies
?   ?       ??? Parameters
?   ?       ??? ModelStatus

• Plant
  • Area1
    • SorbaModel (Module Extension)
      • Predictions
      • Anomalies
      • Parameters
      • ModelStatus

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

The SorbaModel object exposes all necessary properties and methods to interact with Sorba.AI directly through the UNS, including:

• Model predictions as tag values
• Anomaly detection results
• Configuration parameters
• Performance metrics

Benefits

• Native feel - Third-party modules appear as built-in components
• Unified configuration - All settings in Designer
• Standard access - Use Tag.Path syntax for module data
• Full integration - Alarms, historian, displays work normally

Common Characteristics

All UNS Services share fundamental behaviors:

Runtime Management

• On-demand activation - Resources allocated only when needed
• Unified interface - Consistent configuration approach
• Performance optimization - Automatic resource management

Configuration Approach

• RTDB integration - All data flows through real-time database

Protocol Requirements

Implementation Considerations

When to Use

Each Approach

Use UNS Services When:

• External systems support discovery protocols
• Storage infrastructure already exists
• Third-party modules need deep integration
• Dynamic connectivity is beneficial

Performance Impact

• Tag Discovery: Minimal overhead, on-demand activation
• Historian Storage: Performance depends on external system
• Module Extension: Varies by implementation

Performance Impact

Security Architecture

• Services inherit FrameworX security model
• External connections use service-specific authentication
• Access control applies uniformly to all
service
• data
• Audit trail includes service operations

Best Practices

Service Selection

• Evaluate each data source independently
• Consider long-term maintenance requirements
• Assess existing infrastructure
• Plan for mixed configurations

Common Configurations

• Dynamic tags respect same security as local tags

Deployment Patterns

Enterprise System

• Local Tags for control logic
Tag Discovery
• and setpoints
• Linked Tags for equipment with multiple sources
• Dynamic Tags for enterprise/MES data
• Historian Storage to corporate
historian
• infrastructure
• Module Extensions for analytics and AI

Edge Device

• Local Tags for field devices
Smart-Binding for diagnostics
• Dynamic Tags for diagnostic access
• Local historian storage (SQLite)
• Minimal external services

Migration Strategy

Hybrid Architecture

• Mix governance models per subsystem
• Critical control: Local Tags
• Enterprise data: Dynamic Tags
• Flexible equipment: Linked Tags

Decision Strategy

1. Assessment - Identify data governance requirements
2. Pilot - Test
3. Identify candidates - Which data fits service model?
Pilot testing - Start
4. with non-critical
data
5. subsystem
Performance validation
6. Validation - Verify performance meets requirements
Gradual rollout
7. Rollout - Expand
usage
8. systematically

Terminology Evolution

1. by area or function
2. 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

The new terminology better reflects the comprehensive nature of these services, which now include storage, modules, and discovery capabilities.

Next Steps

Detailed Documentation

• [Tag Discovery Service →] - Complete guide to three connection patterns
• [Historian Configuration →] - Storage setup procedures
• [Module Development →] - Creating extensions

Related Concepts

• [P1: UNS Foundation →] - Core UNS concepts
• [Devices Module →] - Traditional mapping approach
• [Runtime Execution →] - How services execute

to include storage services and module extensions.

In this section...