103 OPC UA: Companion Models and Implementation
103.1 Start With the Story
A secure OPC UA connection can exchange data, but two machines still need shared meanings for assets, states, and measurements. The team must choose companion models, map them into the plant, and test whether the implementation preserves semantics as well as transport security.
103.2 Overview
This route applies companion specifications, implementation choices, interpretation guidance, semantic integration, and practical deployment evidence.
This is part 2 of 2. Review OPC UA: Architecture, Models, and Security when you need the first route.
103.3 Learning Objectives
By the end of this chapter, you will be able to:
- choose OPC UA companion specifications for a domain
- plan an implementation with semantic and security evidence
- evaluate OPC UA integration in a practical plant workflow
103.4 Chapter Roadmap
Follow the original sections below in order. They begin at the reviewed split boundary and keep every worked example, figure, check, and supporting banner with the section that owns it.
103.5 Companion Specifications
OPC-UA foundation provides base specifications, but industry-specific companion specifications define standardized information models:
Key companion specifications:
- OPC UA for Machinery: General manufacturing baseline machine model.
- PackML: Packaging state machines and production counters.
- EUROMAP: Plastics and rubber machine integration.
- MTConnect: CNC and machining-center data models.
- ISA-95: Enterprise integration between MES and ERP layers.
- PLCopen: Motion-control coordination and reusable machine logic.
Benefits of companion specifications:
- Plug-and-play: Machines from different vendors expose same interface
- Reduced integration: No custom mapping per vendor
- Best practices: Industry consensus on data organization
- Certification: Conformance testing ensures interoperability
To test companion specifications, open the diagram in Figure 103.1. Semantics Need Model Evidence supplies one named condition; Base OPC UA supplies the necessary comparison for companion specifications reduce custom semantics only when teams record model versions, tests, local extensions, and the client contract that.
Compare Semantics Need Model Evidence with Base OPC UA inside the visual at Figure 103.1. Next find node model, which completes the scope of companion specifications reduce custom semantics only when teams record model versions, tests, local extensions, and the client contract that. The decision in companion specifications must preserve that labelled boundary.
103.6 Implementation Considerations
103.6.1 Embedded vs. Server-Class
Embedded OPC-UA (PLCs, gateways):
- Limited resources (MB of RAM, MHz processors)
- Use nano or micro profiles
- Subset of features (no complex subscriptions)
- Focus on reliability over features
Server-class OPC-UA (historians, MES):
- Full feature support
- High-performance subscriptions
- Complex information models
- Integration with enterprise systems
103.6.2 Performance Tuning
Subscription parameters:
- Publishing interval: How often server checks for changes (100 ms-5s typical)
- Sampling interval: How often server reads underlying value (can be faster than publishing)
- Queue size: How many changes to buffer between publications
- Lifetime count: How many publishing intervals before subscription expires
Optimization strategies:
- Batch reads: Read multiple nodes in single request
- Indexed range: For arrays, read only needed elements
- Dead-band filtering: Only report changes exceeding threshold
- Aggregated subscriptions: Combine related nodes
103.6.3 OPC UA Subscription Performance
Use this interactive calculator to understand how subscription parameters affect bandwidth and data volume in your OPC-UA deployment.
Dead-band filtering eliminates noise by only reporting changes exceeding a threshold (e.g., temperature change). For process variables that fluctuate within tolerance, this can reduce notifications by 70-90% with no data loss.
Batching aggregates multiple variable updates into single messages, reducing per-message overhead. Instead of 24 bytes overhead per variable, batching 10 variables means bytes overhead each.
Typical use: Treat the calculator as a sizing aid, then validate the chosen dead-band and queue settings with actual process data so significant changes are not suppressed.
103.6.4 High Availability
Redundancy patterns:
- Server redundancy: Multiple servers with same address space
- Client failover: Automatic reconnection to backup server
- Network redundancy: Dual Ethernet paths
Session recovery:
- Transfer subscriptions: Move subscriptions to backup server
- Sequence numbers: Detect and recover from lost notifications
- Secure channel renewal: Automatic key rotation
103.7 OPC-UA in Practice
103.7.1 Typical Deployment Architecture
The next claim about typical deployment architecture depends on Figure 103.2. Its diagram makes ISA-95 Automation Pyramid with OPC-UA and Level 4: Enterprise explicit within opc-ua often sits between real-time ot systems and operations or enterprise consumers, so each isa-95 level needs an explicit interaction pattern and.
Locate ISA-95 Automation Pyramid with OPC-UA on Figure 103.2 before checking Level 4: Enterprise. The visual’s third anchor, ERP, Business Planning, completes opc-ua often sits between real-time ot systems and operations or enterprise consumers, so each isa-95 level needs an explicit interaction pattern and. Carry ISA-95 Automation Pyramid with OPC-UA into typical deployment architecture; use ERP, Business Planning as its limiting condition. A typical OPC-UA deployment spans five levels: field devices communicate via native industrial protocols, edge gateways aggregate data as OPC-UA servers, SCADA systems consume data as OPC-UA clients, cloud platforms receive pub-sub data over MQTT, and enterprise applications access analytics via REST APIs.
103.7.2 Common Integration Patterns
Pattern 1: PLC to Cloud
- PLC runs embedded OPC-UA server
- Edge gateway subscribes to PLC data
- Gateway publishes to MQTT broker
- Cloud platform consumes MQTT messages
Pattern 2: Multi-vendor Integration
- Each vendor’s equipment exposes OPC-UA server
- Central OPC-UA aggregator collects from all servers
- SCADA connects to single aggregator endpoint
- Unified namespace across all equipment
Pattern 3: Legacy Integration
- Protocol gateway converts Modbus/PROFIBUS to OPC-UA
- Gateway exposes standardized information model
- Modern applications connect via OPC-UA
- Legacy equipment remains unchanged
103.7.3 OPC-UA Deployment ROI Calculator
Explore an assumption-driven cost model for moving from custom point-to-point integration to an OPC-UA integration layer. The defaults are planning placeholders, not vendor quotes or guaranteed savings; replace them with site estimates before using the result.
The calculator shows how assumptions can change an OPC-UA business case:
Year 1: May have higher costs due to gateway/software purchases, but reduced integration labor often compensates.
Year 2-3: Lower annual maintenance can drive positive ROI if the model, gateway, and certificate lifecycle are actually easier to operate than the custom alternative.
Year 4-5: Savings may accelerate when standardized onboarding reduces the effort needed to add new equipment.
Real-world factors not modeled: outage windows, validation effort, vendor support, license terms, cybersecurity review, and the cost of maintaining namespace and certificate ownership over time.
103.7.4 OPC UA Bottling Plant Migration
Scenario: A beverage company operates a bottling line with native PROFINET PLCs, EtherCAT motion equipment, inspection cameras, and legacy Modbus RTU conveyor controllers. Management wants OEE dashboards and maintenance analytics without replacing functioning equipment.
Step 1: Inventory and protocol mapping
- Native OPC-UA sources: Identify controllers that already expose a supported OPC-UA server and document their endpoint policies, namespaces, and writable nodes.
- Gateway-required sources: Place legacy serial and vendor-specific Ethernet devices behind gateways that add asset names, units, quality codes, timestamps, and references.
- Consumer contracts: Separate SCADA/HMI operational clients from historian, MES, and cloud analytics consumers.
Step 2: Architecture design
- Direct OPC-UA: Let SCADA connect to native servers or an aggregator for browse, read, subscriptions, and approved writes.
- Protocol gateways: Bridge brownfield sources into a unified namespace without flattening everything into anonymous tags.
- Cloud connectivity: Publish selected read-only datasets through an edge or DMZ broker so cloud systems do not hold direct control-network sessions.
Step 3: Subscription tuning
Not all variables need the same update rate. Categorizing by purpose keeps significant changes visible without turning the historian into a packet sink:
- Safety and interlock evidence: Preserve every meaningful transition and test queue overflow behavior.
- Process control context: Use bounded sampling and queue settings that match the control cell’s diagnostic need.
- Quality metrics: Apply dead-band only where the process owner confirms small changes are noise.
- Dashboards and OEE: Publish slower aggregates when operators do not need every raw sample.
Result: The migration is ready for release only when reviewers can trace one value from source controller or gateway, through namespace and security policy, into the historian or dashboard, while preserving unit, quality, timestamp, owner, and allowed write behavior.
Checkpoint: Deployment Evidence
You now know:
- Subscription tuning starts with publishing interval, sampling interval, queue size, lifetime count, batching, and dead-band rules.
- The calculator’s defaults make the scale concrete: 2,000 variables at 100 ms can overwhelm a historian unless queueing and filtering are engineered.
- A brownfield release is not complete until one value can be traced from native OPC UA or gateway source through namespace, security policy, consumer, and decision.
- OPC-UA -> ISA-95 Levels 0-3: bridges the control layer (PLC) to the operations layer (MES/ERP).
- OPC-UA -> Industrial Protocols: replaces proprietary Modbus and PROFINET links with a vendor-neutral standard.
- Client-Server -> SCADA Systems: supports direct request-response access for HMI and configuration tools.
- Pub-Sub -> MQTT/AMQP: provides a decoupled pattern for cloud connectivity and analytics.
Cross-module connection: Real-Time Requirements and ISA-95 explains timing constraints that determine when to use OPC-UA client-server vs. pub-sub patterns.
Common Pitfalls
An OPC-UA endpoint that exposes thousands of PLC tags without units, quality, equipment hierarchy, or ownership is connected but not integrated. Model assets, variables, methods, and references so clients can understand the operational meaning of each value.
Trust lists, certificate renewal, user identity, role mapping, and endpoint policy need owners before release. If nobody owns certificate expiry or rejected-client handling, the first maintenance window can become an outage.
Cloud dashboards and analytics should receive selected read-only datasets through an edge or DMZ boundary. Keep operational write methods inside the approved OT path unless authorization, safety review, and recovery behavior are engineered for remote writes.
103.8 Summary
OPC-UA has emerged as the definitive standard for industrial interoperability. Here are the key takeaways from this chapter:
Key Takeaways:
-
Platform Independence: OPC-UA works across operating systems, hardware platforms, and programming languages, eliminating vendor lock-in. From embedded PLCs with megabytes of RAM to enterprise cloud servers, OPC-UA scales across the entire automation hierarchy.
-
Semantic Data Modeling: The self-describing, object-oriented information model (nodes, references, attributes) enables clients to discover and understand device capabilities with less vendor-specific mapping.
-
Built-in Security: Unlike legacy protocols (Modbus, PROFIBUS) that have no native security, OPC-UA provides layered defense: application certificates, message signing and encryption, multiple user authentication methods, and audit logging that supports controlled operations.
-
Dual Communication Patterns: Client-server mode supports traditional SCADA and HMI use cases requiring direct request-response interaction. Pub-sub mode (over MQTT/AMQP) enables scalable, firewall-friendly cloud connectivity for analytics and monitoring.
-
Companion Specifications: Industry-specific extensions such as PackML, EUROMAP, MTConnect, and ISA-95 provide standardized information models that reduce custom semantic mapping when the model version and local extensions are documented.
-
Legacy Integration: Protocol gateways bridge legacy Modbus, PROFIBUS, PROFINET, and vendor-driver devices into OPC-UA, allowing modernization without replacing functioning equipment.
When designing an OPC-UA deployment, always use client-server for control and direct device interaction (SCADA, HMI), and pub-sub over MQTT for cloud connectivity and analytics. Never use Security Policy “None” in production. Start with companion specifications for your industry before creating custom information models.
103.9 See Also
- Industrial Protocols — Comparison of Modbus, PROFINET, and EtherCAT to understand when OPC-UA bridges legacy systems
- Predictive Maintenance — OPC-UA data collection enables ML-based failure prediction in IIoT
- Real-Time Requirements — Timing constraints across ISA-95 levels determine client-server vs pub-sub choice
103.10 What’s Next
- Next: Real-Time Requirements and ISA-95 for timing constraints and automation hierarchy.
- Related: Predictive Maintenance for condition monitoring use cases.
- Related: Industrial Protocols for Modbus, PROFINET, and EtherCAT comparison.
- Index: Industry 4.0 Fundamentals for the full IIoT chapter sequence.