UNS Services (Concept)

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.

Service Types Overview

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

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

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

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

UNS Services represent the extensibility layer of FrameworX, enabling seamless integration with external systems while maintaining the platform's unified architecture and ease of use. Choose services based on your infrastructure and operational requirements.

In this section...