UNS Tag Discovery Service provides 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.
Key Requirement: These are advanced technics, master the traditional SCADA/HMI concept of creating tags and mapping to devices before learning about those other alternatives.
Advanced Topic This content covers advanced functionality not required for most projects. Start and learn Local Tags mapping to devices first, use this section when dynamic discovery or auto-managed communications is required.
On this
Pagepage:
Table of Contents maxLevel 2 minLevel 2 indent 10px exclude Steps style none
Three Connection Patterns
Each pattern serves distinct operational needs:
| Pattern | Control Model | Best For | Access Syntax |
|---|---|---|---|
| Local Tags & Device Points | Explicit control | Critical control, legacy protocols, regulated systems | Tag.TagName |
| Linked Tags | Governed flexibility | Stable models, changing sources, enterprise data | Tag.TagName |
| Smart-Binding | Dynamic discovery | Diagnostics, ephemeral assets, unknown structures | Asset("path") |
Pattern Selection Guide
Choose based on data characteristics, not development phase:
| If Your Data... | Use This Pattern | Why | Access Syntax |
|---|---|---|---|
| Requires deterministic polling | Local Tags & Device Points | Explicit control over timing | Tag.TagName |
| Uses legacy/proprietary protocols | Local Tags & Device Points | Only option for non-discovery protocols | |
| Needs local governance with flexible sources | Linked Tags | Stable names, changing connections | |
| Has stable structure but multiple sites | Linked Tags | Template once, link many | |
| Is temporary or diagnostic | Smart-Binding | No configuration overhead | |
| Has unknown/changing structure | Smart-Binding | Dynamic 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
| Panel | ||||||
|---|---|---|---|---|---|---|
| ||||||
Configuration Approach: 1. Create Tags in UNS |
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
| Panel | ||||||
|---|---|---|---|---|---|---|
| ||||||
Configuration Approach:1. Create Tags in UNS LinkedData Field Example: Tag: TankLevel |
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:
| Code Block | ||||
|---|---|---|---|---|
| ||||
// 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
| Info | ||
|---|---|---|
| ||
Rarely a "Typical" profile matches exactly the field requirements, reason why we keep all those options. Therefore the numbers provided are merely illustrative, reach out the community and support as needed when applying those concepts to specific case. |
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
Protocol Support
| Protocol | Local Tags | Linked Tags | Smart-Binding | Notes |
|---|---|---|---|---|
| MQTT Client | ? | ? | ? | Full discovery support |
| OPC UA | ? | ? | ? | Browse and subscribe |
| ControlLogix | ? | ? | ? | Tag discovery available |
| Modbus | ? | ? | ? | No discovery capability |
| DNP3 | ? | ? | ? | Explicit mapping only |
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.
In this section...
| Page Tree | ||||
|---|---|---|---|---|
|