UNS Tag Discovery Reference

Automatically discover new UNS tags.

Reference → Modules → UNS → UI | Engine | Tag Discovery

Three Connection Patterns

Each pattern serves distinct operational needs:

Pattern Selection Guide

Choose based on data characteristics, not development phase:

Pattern 1: Local Tags & Device Points

The Explicit Control Pattern

Traditional SCADA approach where you define tags locally and explicitly map them to device addresses through the Devices Module.

Characteristics:

• Full local governance of names and types
• Explicit communication configuration
• Deterministic polling and scan rates
• Works with any protocol
• Complete offline configuration capability

When This Pattern is Optimal:

• Regulatory compliance (FDA, EPA, etc.)
• Safety-critical control loops
• Legacy protocol integration
• Explicit timing requirements
• Full audit trail requirements

Pattern 2: Linked Tags

The Governed Flexibility Pattern

Maintain local tag definitions while linking them to external sources. Runtime automatically manages communications when tags are accessed.

Characteristics:

• Local governance with flexible sourcing
• Auto-managed communications
• On-demand activation (only polls when used)
• Same tag names across changing sources
• Full UNS features (alarms, historian, etc.)

When This Pattern is Optimal:

• Multi-site deployments with standard models
• Cloud/edge hybrid architectures
• Vendor equipment that may change
• Enterprise data integration
• Systems with many unused points

Configuration Approach

Pattern 3: Smart-Binding

The Dynamic Discovery Pattern

Direct binding to external paths without creating local tags. System dynamically creates communication entries as paths are accessed.

Characteristics:

• No upfront configuration
• Dynamic discovery at runtime
• Lightweight memory footprint
• Direct path access
• Ideal for unknown structures

When This Pattern is Optimal:

• System diagnostics and troubleshooting

• Temporary test connections
• Fleet/rental equipment with changing IDs
• Exploring new data sources
• Integration testing

Access Method:

// Direct access in scripts
value = Asset("/mqtt/plant/tank01/level")

// Direct binding in displays
<TextBox Value="{Asset('/opcua/machine/status')}" />

Mixed-Mode Production Systems

Most production systems use multiple patterns based on specific data requirements:

Typical Architecture

Production System
??? Local Tags (30%)
?   ??? Safety interlocks
?   ??? Control loops
?   ??? Legacy PLCs and Protocols
??? Linked Tags (60%)
?   ??? Enterprise metrics
?   ??? Standard equipment
?   ??? Newer protocols
??? Smart-Binding (10%)
    ??? Enterprise UNS / systems with dynamic external governance
    ??? Temporary sensors or diagnostic overlays
    ??? Maintenance tools

Example Scenarios

Manufacturing Line:

• Local Tags: PLC control for conveyor, safety stops
• Linked Tags: MES data, quality metrics, OEE calculations
• Smart-Binding: Portable test equipment, temporary sensors

Water Treatment Plant:

• Local Tags: Pump control, valve positions, flow control
• Linked Tags: Laboratory data, weather services, reporting
• Smart-Binding: Portable analyzers, maintenance diagnostics

Technical Implementation

Unified Communication Stack

Linked Tags and Smart-Binding share the same runtime infrastructure:

User Configuration
    Linked Tag → LinkedData field → Communication Table
    Asset("path") → Auto-created entry → Communication Table
                            ↓
                    Same Runtime Engine
                    (Polling, Subscription, Caching)

Communication Behavior

• Activation: First use triggers communication
• Caching: Values cached for optimal performance
• Deactivation: Unused paths release after timeout
• Resource Management: Automatic optimization

Error Handling

All patterns handle errors consistently:

• Failed reads return null values
• UI controls handle nulls gracefully
• Scripts should validate returned values
• Quality indicators available for diagnostics

Best Practices

Pattern Selection

• Analyze each data set independently
• Don't force one pattern for everything
• Consider future maintenance requirements
• Evaluate governance needs per data type

Common Pitfalls to Avoid

Using Smart-Binding for safety-critical control

Forcing Local Tags when discovery would simplify

Mixing Device Points and LinkedData for same tag

Ignoring protocol capabilities

Performance Considerations

• All patterns support thousands of tags
• Linked/Smart-Binding activate on-demand
• Local Tags poll regardless of usage
• Consider startup time vs runtime efficiency

Next Steps

Learn More

• [UNS Configuration Guide →] - Detailed setup instructions
• [Protocol Compatibility →] - Full support matrix
• [Performance Tuning →] - Optimization techniques

Related Concepts

• [P1: UNS Foundation →] - Core UNS concepts
• [Devices Module →] - Device Points configuration
• [Runtime Execution →] - How patterns execute

This advanced functionality enables flexible, efficient data connectivity. Choose patterns based on your specific data characteristics and operational requirements, not development phases.

Review and Consolidate

Device Module and TagProviders

While both the Devices module and TagProvider connections enable data exchange with remote systems, they have different focuses and complement each other.

There are features in the Devices module that can't be accomplished using TagProviders, and features from TagProviders that could be emulated with the Devices module.

This section details what these interfaces have in common, where they differ, and provides guidance on how to select what best fits your requirements, keeping in mind that both can be used in the same solution.

On this page:

• Overview
• Configuration Similarities
  • Where the Configuration Differs
  • Which One to Use Depends on Requirements

Configuration Similarities

Before we explore the differences, let's start with what they have in common.

In both cases, we establish a connection with a remote system, and the configuration settings for those connection is essentially the same.

At Devices, you create a Channel a Protocol, configure the ProtocolOptions,  then create a Node to configure the PrimaryStation.

At TagProviders, you select a Protocol, and the configuration of ProtocolOptions and PrimaryStation is on the same dialog.

Despite the fact the TagProvider combines the configuration of Channel and Node, the fields for ProtocolOptions and PrimaryStation are the same, which is the reason why the documentation of the protocol is the same in both cases. 

Where the Configuration Differs

Using Devices, the AccessType can customize the read and write cycles and events, and you can use multiple AccessTypes on the same Node. 

Using TagProviders, there is the ReadCycle and the WriteCycle, which applies to all communication on that TagProvider Connection. 

Finally, on Devices, you create Points and maps to Tags. When working with TagProviders, that steps is not necessary, as you can access directly the address within the connected system. 

In summary:

• Devices Module: Maps locally created Tags with address on the connected devices, offering detailed control over read/write events and diagnostics for each address.

• TagProvider: Establishes dynamic communication with remote sources, enabling direct browsing or writing on the remote data definition without using local tags.

Which One to Use Depends on Requirements

Best Usage for Devices Module:

• Local tag definition is in the solution.
• Utilization of tag fields for attributes and metadata. (like Min, Max, Retentive, and others)
• Validation of address availability.
• Control over communication performance, cycle times, read/write events.
• The solution is a Publisher for that data, that will create the topics in the remote system.

Best Usage for TagProviders:

• Access data already defined in other systems.
• No need for extended tag properties, only variable values.
• Dynamic data definition, adaptable without external source modifications.
• No detailed control required over communication messages or address status.
• The solution is not the original Publisher nor created of the topics on the remote system, but it can perform write operations on existing topics.

In some solutions, it is quite possible that some of the data is better suited for use with the Devices module, while other data in the solution is better acquired using TagProvider.

In this section...