UNS Services provide three distinct patterns for connecting external data to the Unified Namespace. Each pattern is optimized for different data characteristics and operational requirements, and production systems typically use multiple patterns simultaneously based on the specific needs of each data set.

Key Understanding: These are not developmental stages but three equally valid architectural patterns. Choose based on your data's governance needs, stability, and control requirements.


Three Connection Patterns

Each pattern serves distinct operational needs:

PatternControl ModelBest ForAccess Syntax
Local Tags & Device PointsExplicit controlCritical control, legacy protocols, regulated systemsTag.TagName
Linked TagsGoverned flexibilityStable models, changing sources, enterprise dataTag.TagName
Smart-BindingDynamic discoveryDiagnostics, ephemeral assets, unknown structuresAsset("path")


Pattern Selection Guide

Choose based on data characteristics, not development phase:


If Your Data...Use This PatternWhyAccess Syntax
Requires deterministic pollingLocal Tags & Device PointsExplicit control over timingTag.TagName
Uses legacy/proprietary protocolsLocal Tags & Device PointsOnly option for non-discovery protocols
Needs local governance with flexible sourcesLinked TagsStable names, changing connections
Has stable structure but multiple sitesLinked TagsTemplate once, link many
Is temporary or diagnosticSmart-BindingNo configuration overhead
Has unknown/changing structureSmart-BindingDynamic discovery at runtime




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


Configuration Approach:

1. Create Tags in UNS
2. Configure Device Channels
3. Map Points to Tags
4. Define AccessType (read, write or read write)
5. Customize AccessType poling rate as necessary.


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


Configuration Approach:

1. Create Tags in UNS
2. Set LinkedData field to external path
3. Runtime auto-manages communication

LinkedData Field Example:

Tag: TankLevel
Type: Float
LinkedData: /opcua/server/tank/level


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')}" />