OPC-UA is not new. IEC 62541 has been around since 2008. But in our experience working directly with sortation control systems across fulfillment centers, the protocol only recently reached the adoption threshold where you can assume it on the shop floor without negotiating. This guide is for controls engineers doing real integration work, not for executives reading vendor brochures.
What OPC-UA Actually Is
OPC-UA (Unified Architecture) is a platform-independent, service-oriented protocol for industrial equipment communication, standardized under IEC 62541. Where OPC Classic relied on Microsoft's DCOM (Distributed Component Object Model), UA removed that dependency entirely. The result: a server running on a Siemens S7-1500 PLC can talk to a Linux-based analytics host without any Windows COM plumbing in between.
The architecture centers on three concepts worth internalizing before touching any integration code:
- Address Space: Every data item the server exposes lives in a hierarchical namespace called the address space. Nodes represent variables, objects, methods, and views. Each node has a NodeId, which is a tuple of namespace index and identifier (numeric, string, or GUID).
- Information Model: UA defines base types (FolderType, BaseObjectType, BaseVariableType) and lets vendors extend them. Siemens publishes a companion spec for S7 servers; Dematic and Honeywell Intelligrated each publish their own iQ namespace.
- Services: Browse, Read, Write, Subscribe, Call. That's it. The Browse service is how you discover nodes without prior schema knowledge. Read and Write are synchronous. Subscribe sets up monitored items with change notification, avoiding polling overhead.
Default transport is TCP on port 4840. Security is negotiated at the Session layer: None, Sign, or SignAndEncrypt. For any OT network touching production equipment, SignAndEncrypt with X.509 certificates is non-negotiable. More on that shortly.
Why It Replaced OPC Classic for Sorter PLCs
OPC Classic (DA, HDA, A&E) worked. It worked for years. The problem was operational, not conceptual: DCOM configuration was a nightmare to maintain across Windows version upgrades, firewall rules, and domain policy changes. We've seen integration engineers spend two days per quarter just keeping DCOM permissions intact after a Windows Update cycle.
UA eliminated the DCOM dependency in 2008. Platform independence meant the UA server could run on the PLC firmware itself rather than on a dedicated Windows PC acting as a DCOM broker. For a sortation environment running 50-plus PLCs across multiple sorter lines, collapsing that architecture matters. Fewer nodes, fewer failure surfaces.
The other driver: security. DCOM had no encryption layer worth mentioning in production deployments. UA's security model is baked into the transport, not bolted on. Certificates. Message signing. Endpoint filtering. These are first-class features, not add-ons.
OPC-UA vs. Modbus TCP: Where Each Protocol Lives in a Sortation System
Controls engineers sometimes ask whether to use Modbus TCP or OPC-UA for a given device. Short answer: both, in their appropriate layers.
| Protocol | Typical Use in Sortation | Strengths | Limitations |
|---|---|---|---|
| Modbus TCP | Photo-eye sensors, divert actuators, conveyor drives | Low latency, ubiquitous, deterministic register map | No self-describing data model, no security layer, coil/register paradigm only |
| OPC-UA | Sorter PLCs (Dematic iQ, Honeywell Intelligrated, Siemens S7), line controllers | Self-describing address space, security, bidirectional method calls, event subscriptions | Higher overhead, requires certificate management, more complex initial configuration |
In practice: Modbus TCP handles the sensor layer at 10ms scan rates. OPC-UA handles the sorter PLC layer where you need to read structured objects (induction station data, divert confirmation flags, sort plan tables) and write back updated parameters. Mixing them is normal. They're not competing; they occupy different tiers.
Common OPC-UA Server Implementations for Sortation Equipment
Four servers you'll encounter most often:
- Siemens S7 (TIA Portal + UA server): Enabled in TIA Portal project settings. Namespace URI follows the pattern
urn:hostname:Siemens.S7.UA. Node browsing reveals the DB block structure directly. Browse depth typically 4-6 levels for a sorter program. - Allen-Bradley ControlLogix (Kepware OPC-UA Server): AB doesn't ship a native UA server on ControlLogix; the standard path is Kepware KEPServerEX acting as a UA server fronting the EtherNet/IP connection. Namespace URI is Kepware-defined. Tag browser reflects the L5K tag structure.
- Dematic iQ: Dematic publishes an OPC-UA companion specification for iQ. The namespace exposes sorter objects by line and divert position. Sort plan writes go through a Method node, not a plain variable write.
- Honeywell Intelligrated: UA server embedded in the Intelligrated Supervisory Control layer. Namespace structure mirrors the Intelligrated zone model. Variable nodes for per-zone throughput, jam counts, and induction rate targets are browsable without prior schema import.
Discovering Nodes in an OPC-UA Address Space
Most integration failures we've tracked trace back to hard-coding NodeIds without first doing a proper Browse traversal. Don't do that. NodeIds can change across firmware versions. Browse programmatically.
The Browse service takes a starting NodeId (typically i=84 — the Objects folder), a browse direction (Forward), and a reference type filter. Walk the hierarchy recursively. Log every NodeId, DisplayName, DataType, and AccessLevel. This is your integration manifest. Keep it in version control.
Once you have the manifest, identify the variables you need:
- Induction rate (items/hour) — typically a Float or Int32 variable
- Active sort plan identifier — typically a String variable
- Divert confirmation counters — typically UInt32 arrays indexed by chute position
- Fault status words — typically UInt16 bitmask variables
Set up Subscriptions on the high-frequency variables. Use Read/Write for parameter updates. Never poll variables at 100ms intervals when a Subscription with a 500ms publishing interval will do the same job with one-tenth the network traffic. Fact: a 50-variable subscription at 500ms publishing generates roughly 6 KB/s. Polling the same 50 variables at 100ms generates over 200 KB/s. On a congested OT network, that difference matters.
Bidirectional Writes: How Sortwyre Pushes Parameters Back Every 90 Seconds
Reading data is the easy half. Writing back is where most integrations stop short, and it's exactly where optimization value lives.
Sortwyre reads sorter throughput, induction gap data, and divert error rates continuously via OPC-UA subscriptions. Our optimization engine runs on that data and recalculates induction rate targets. Every 90 seconds, we push updated induction rate parameters back to the sorter PLC via OPC-UA Write calls. Not a SCADA override. Not a human in the loop. Automated, deterministic, bounded.
The 90-second write cycle was chosen deliberately. It's fast enough to track induction variability during peak hours (parcel mix changes on 5-10 minute cycles), but slow enough to avoid write-induced PLC scan jitter. Short-burst writes to PLC output variables at 10-second intervals have measurable scan time impact on S7-1500 firmware below v2.8. We've seen it. 90 seconds avoids that regime entirely.
On the server side, the Write service requires AccessLevel = ReadWrite on the target variable node. Check AccessLevel during your Browse phase. If the vendor has locked a node as ReadOnly, you're going to need a firmware configuration change before you can write to it. Find this out in staging, not in production.
OT Network Security: SignAndEncrypt, Certificates, and Edge Architecture
The SignAndEncrypt security policy (formally: Basic256Sha256) provides message signing plus AES-256 encryption on the channel. Both the client and server present X.509 certificates during the SecureChannel handshake. The server maintains a trust list; any client cert not in that list gets rejected.
Certificate management is the operational burden people underestimate. A few hard rules we apply:
- Use a dedicated CA for OT device certificates, separate from your IT PKI. OT certificate lifetimes are typically 5 years; IT systems will want 1-year renewal cycles. Mixing them creates expiration conflicts.
- Automate certificate distribution to UA server trust lists. Manual trust list updates across 50 PLCs is a support ticket waiting to happen.
- Keep the UA client on the same OT network segment as the UA server. Routing OPC-UA traffic across IT/OT boundaries through a firewall pinhole is technically possible but operationally fragile. Edge-local architecture, where the analytics agent lives on the OT segment and forwards aggregated data upstream, is more defensible.
Port 4840 should never be reachable from the corporate LAN directly. If your network diagram shows a direct path from an enterprise analytics server to port 4840 on a sorter PLC, that's a finding, not a configuration.
The Integration Pattern That Actually Works
Here's the pattern we've found reliable across multiple sorter installations:
- Deploy an edge agent on a hardened Linux host on the OT network segment.
- Edge agent browses the UA address space on first connection, caches the node manifest locally.
- Subscriptions handle data ingestion; no polling except for low-frequency status variables.
- Optimization logic runs edge-local to minimize round-trip latency on write cycles.
- Aggregated metrics (not raw PLC data) forward to cloud analytics over a unidirectional data diode or a tightly scoped firewall rule.
- Write commands originate from edge-local logic only. Cloud never writes directly to PLCs.
This keeps the PLC network air-gap-adjacent. It keeps write authority close to the hardware. And it means a cloud connectivity failure doesn't affect sortation control. The edge agent runs independently. Simple as that.
OPC-UA is mature enough that the protocol itself is rarely the problem. Certificate management, node discovery discipline, and write cycle timing are where real integration projects succeed or fail. Get those three right, and the rest follows.