Page History

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

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

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

Service Types

Three distinct services extend FrameworX capabilities while maintaining unified architecture:

Advanced Functionality: UNS Services are advanced features that extend beyond basic SCADA/HMI requirements. Most projects can successfully operate using only standard Local Tags and built-in modules.

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

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

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:

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

Configure Historian Tags grouping into the tables

Keep the Storage Location to

Group tags into tables Use Dataset.DB.

TagHistorian 

TagHistorian Customize

the TagHistorian

SQL connection

as needed

Create

a Storage Location using UNS ServicesDefine Historian Tables to use that

UNS Service location Tables reference service location Add

Historian Tags

tags to

those

tables

Storage managed by external system

External system manages storage

Benefits

• Leverage existing

• enterprise historians

• Mixed storage

• strategies per table
• Seamless migration

• between storage types
• Native integration

Supported External Historians

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

• with external systems

Module Extension Service

Enables third-party modules to integrate

as native FrameworX components with full Designer support

Use Cases

:

• Third-party integration requires custom configuration beyond standard connectors
• The module needs to appear in the UNS tree with custom properties
• Integration should feel native to FrameworX users
• Configuration and execution should remain within FrameworX

How It Works

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

Integration 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...