TagProvider Services

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

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

Beyond Traditional Tag Management

UNS Services extend the Unified Namespace beyond traditional tag management, enabling dynamic discovery, external storage integration, and third-party module embedding. These services represent a fundamental shift from static configuration to dynamic, runtime-managed connectivity.

Three Service Types:

  • Tag Discovery Service - Dynamic external tag integration
  • Historian Storage Service - Flexible storage locations
  • Module Extension Service - Third-party module embedding

Each service extends ProView DS capabilities while maintaining the unified architecture and consistent user experience.

Service Types

Three distinct services extend ProView DS capabilities while maintaining unified architecture:

Tag DiscoveryConnect external tags without mappingRuntime-managed communicationsMQTT, OPC UA, ControlLogix
Historian StorageUse external historians as storageStorage location flexibilityCanary, OSIsoft PI, InfluxDB
Module ExtensionEmbed third-party modulesNative UNS integrationSorba.AI, custom analytics

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

Local TagsConfiguration timeTag.TagNameSolution-defined
Linked TagsConfiguration timeTag.TagNameSolution structure, external source
Dynamic TagsRuntime on-demandAsset("path")External system

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

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

Module Extension Service

Enables third-party modules to integrate as native ProView DS components with full Designer support:

Integration Process

  1. Partner creates XML descriptor and .NET DLL
  2. Files placed in ProView DS 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

Tag DiscoveryBrowsing/discovery protocol (MQTT, OPC UA)
Historian StorageStorage API interface implementation
Module Extension.NET assembly or REST API

Implementation Considerations

When to Use Each Approach

- Full control over timing required
- Legacy protocols without discovery
- Regulatory compliance demands
- Offline configuration mandatory
- Namespace governance internal		- Discovery protocols supported
- Existing storage infrastructure
- Third-party integration needed
- Dynamic connectivity beneficial
- External namespace governance

Performance Impact

Tag DiscoveryMinimal overheadOn-demand tag creation, automatic cleanup
Historian StorageDepends on externalBatch operations, connection pooling
Module ExtensionVaries by implementationResource pooling, lazy loading

Security Architecture

  • Services inherit ProView DS security model
  • External connections use service-specific authentication
  • Access control applies uniformly to all data
  • Audit trail includes service operations
  • Dynamic 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

Historical Context:

  • Legacy Term: "TagProvider" or "Dynamic TagProvider"
  • Current Term: "UNS Services" (ProView DS 10.1+)
  • Key Patterns: Dynamic Tags (runtime-created in RTDB)

The terminology evolved as functionality expanded beyond simple tag provisioning to include storage services and module extensions.