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