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 Modified

Service ArchitectureTypes

Three distinct services extend FrameworX capabilities while maintaining unified architecture:

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

Runtime Management

• Auto-discovery of external namespacesOn-demand activation based on usage
• Dynamic tag creation in RTDB when accessed
• Automatic cleanup when no longer needed
• No pre-configuration requiredAutomatic resource optimization
• 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 sourcessource 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
• Storage Location - Where to store
• • , Custom

Configuration Comparison

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

1. Partner creates XML descriptor and .NET DLL
2. Files placed in FrameworX extensions folder
3. Module appears in Designer under UNS → Service Connections
4. Configure connection settings
5. 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

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

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

Implementation Patterns

Enterprise System Configuration

• Local Tags for control logic
• Tag Discovery for enterprise data
• Historian Storage to corporate historian
• Module Extensions for analytics

Edge Device Configuration

• Local Tags for field devices
• Smart-Binding for diagnostics
• Local historian storage
• Minimal external services

Utilization Strategy

1. Identify candidates - Which data fits service model
2. Pilot testing - Start with non-critical data
3. Performance validation - Verify meets requirements
4. Gradual rollout - Expand usage systematically

<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+)
• Functionality: Expanded beyond tag provisioning to include storage and modules

Performance Considerations

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

UNS Integration and Data Access

Service Types Overview

Local UNS Governance

• Tags defined in solution
• Manual mapping to sources
• Full control over namespace
• Traditional workflow

• Dynamic

• Zero-configuration at runtime
• Adapts to external sources
• Automatic discovery
• Reduced engineering time

Image Removed

Tag Discovery Service

The most comprehensive of the UNS Services, enabling three distinct patterns for connecting external data without traditional device mapping.

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

[Full Tag Discovery Service Documentation →]

Historian Storage Service

Extends the Historian Module to use any third-party historian as a storage location while maintaining the same configuration interface and runtime behavior.

How It Works

The Historian Module in FrameworX is "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

Configuration

Configure Historian Tables

Configure Historian Tags grouping into the tables

Keep the Storage Location to Dataset.DB.TagHistorian 

Customize the TagHistorian connection as needed

Create a Storage Location using UNS Services

Define Historian Tables to use that location

Add Historian Tags to those tables

Storage managed by external system

Benefits

• Leverage existing infrastructure - Use enterprise historians already deployed
• Mixed storage - Different groups can use different storage locations
• Seamless migration - Change storage without reconfiguring groups
• Native integration - External historians appear as standard options

Supported External Historians

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

Module Extension Service

Enables third-party modules to integrate directly into the UNS, appearing as native FrameworX components with full Designer support.

Use Cases

This service addresses scenarios where:

• 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
4. User configures connection settings
5. Module elements can be added to Asset Tree

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

Example: Sorba.AI Integration

• 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

1. Assessment - Identify data governance requirements
2. Pilot - Test with non-critical subsystem
3. Validation - Verify performance meets requirements
4. Rollout - Expand systematically by area or function
5. 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:

Once configured, the Sorba.AI module extension allows:

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

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

• Auto-discovery - Services discover available resources
• On-demand activation - Resources allocated when needed
• Unified interface - Consistent configuration approach
• Performance optimization - Automatic resource management

Configuration Approach

1. Enable service in UNS → Service Connections
2. Configure connection parameters
3. Service auto-populates available resources
4. Use resources through standard FrameworX methods

Protocol Requirements

Implementation Considerations

When to Use UNS Services

Use Standard Approach When:

• Full control over communication timing is required
• Working with legacy protocols without discovery
• Regulatory compliance demands explicit configuration
• Offline configuration is mandatory

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

Security Considerations

• Services inherit FrameworX security model
• External connections use service-specific authentication
• Access control applies 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

Enterprise System:

• Local Tags for control logic
• Tag Discovery for enterprise data
• Historian Storage to corporate historian
• Module Extensions for analytics

Edge Device:

• Local Tags for field devices
• Smart-Binding for diagnostics
• Local historian storage
• Minimal external services

Migration Strategy

1. Identify candidates - Which data fits service model?
2. Pilot testing - Start with non-critical data
3. Performance validation - Verify meets requirements
4. Gradual rollout - Expand usage systematically

Terminology Evolution

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