OPC UA (Open Platform Communications Unified Architecture)

What is OPC UA?

OPC UA (Open Platform Communications Unified Architecture) is a platform-independent, service-oriented communication protocol and information modelling framework for industrial automation. It is standardised as IEC 62541 and maintained by the OPC Foundation. OPC UA is the successor to OPC Classic, which relied on Microsoft COM/DCOM and was therefore limited to Windows environments.

Unlike OPC Classic, OPC UA runs on any operating system – Windows, Linux, embedded RTOS, and even microcontrollers – and communicates over standard TCP/IP networks. This made it the de facto standard for machine-to-machine communication in smart manufacturing and the backbone of most Industry 4.0 and IIoT architectures.

OPC UA is not simply a messaging protocol: it defines a rich information model that describes what data means, how it relates to other data, and how it should be accessed. This semantic layer is what distinguishes OPC UA from lower-level protocols such as MQTT or Modbus, and is the reason it is well suited to integrating RFID readers into manufacturing execution systems (MES) and SCADA environments.

How OPC UA works

Information modelling and address space

The foundation of OPC UA is its address space: a hierarchical, graph-structured namespace of nodes connected by references. Every piece of data, method, event, or object exposed by an OPC UA server lives as a node in the address space. Nodes have attributes (NodeId, BrowseName, DisplayName, DataType, Value) and are linked to other nodes via typed references such as HasComponent, HasProperty, or Organizes.

Clients discover the server's address space by browsing: starting from the root node and following references to find objects and their variables. This self-describing structure means a client does not need prior knowledge of a server's layout – it can interrogate the server at runtime, which is critical for integrating RFID readers from different manufacturers into a single factory system.

Client-server and publish/subscribe

OPC UA supports two fundamental communication patterns:

• Client-server: The classic OPC UA pattern. A client connects to a server, browses the address space, and reads, writes, or subscribes to nodes. The server sends MonitoredItem notifications when values change. Used for direct integration between a SCADA system and an RFID reader's OPC UA server.
• Publish/subscribe (OPC UA PubSub): Introduced in OPC UA Part 14, PubSub decouples publishers from subscribers using a message broker (typically MQTT or AMQP ) or UDP multicast. Publishers encode OPC UA data in JSON or binary and push it to a broker topic; subscribers consume it without a direct connection to the publisher. Well suited to large-scale IIoT deployments where hundreds of readers publish tag reads to a central platform.

Encoding: binary and XML

OPC UA messages can be encoded in two ways. Binary encoding (UA Binary) is compact and fast, used over raw TCP (port 4840) for low-latency machine-to-machine links. XML encoding (UA XML) is used over HTTPS (port 443) for web-service-style integration and firewall traversal. In PubSub mode, UA JSON encoding is also supported, making OPC UA data consumable by standard web and cloud tooling.

Security model

OPC UA has a built-in, mandatory security architecture based on X.509 certificates. Every OPC UA application (client or server) has a certificate that identifies it. Security is configured per Endpoint and is described by a SecurityPolicy (e.g., Basic256Sha256) and a MessageSecurityMode (None, Sign, or SignAndEncrypt). Connections use TLS, and each session requires authentication (anonymous, username/password, or certificate). This makes OPC UA significantly more secure by default than legacy industrial protocols such as Modbus or older OPC Classic deployments, which had no built-in authentication or encryption.

OPC UA in RFID and IoT

OPC UA's role in RFID is to provide a standardised interface between RFID readers (which speak low-level protocols such as LLRP ) and higher-level factory systems (MES, ERP, SCADA, WMS). Without a standard like OPC UA, each RFID reader vendor requires bespoke integration code. With OPC UA, a reader that exposes an OPC UA server can be integrated into any OPC UA-capable MES using the same client code regardless of the underlying reader hardware.

The typical integration pattern in a smart factory:

• UHF RFID readers are deployed at production line conveyor points and assembly stations.
• Each reader runs (or connects to) an OPC UA server that exposes tag reads, antenna status, and reader configuration as OPC UA nodes.
• A PLC or edge gateway subscribes to the readers' OPC UA servers and aggregates tag read events.
• The PLC or edge device publishes aggregated data up to the MES or SCADA layer, either via OPC UA client-server or via OPC UA PubSub over MQTT.
• The MES records tag reads against work orders, enabling real-time work-in-progress tracking, quality traceability, and serialisation for regulatory compliance.

OPC UA is also used in automotive production lines to track vehicle bodies through paint and assembly stages, in pharmaceutical plants for EPCIS -compatible serialisation, and in logistics sortation systems.

AutoID Companion Specification

The OPC UA AutoID Companion Specification (published by the OPC Foundation in partnership with AIM Global) is an OPC UA information model specifically designed for automatic identification devices: RFID readers, barcode scanners, and RTLS systems.

The specification defines a standard OPC UA address space structure for AutoID devices, including:

• AutoIdDevice object type: The base type for all AutoID devices. Exposes properties such as DeviceInfo, ProtocolVersion, and RuntimeParameters.
• RfidReaderDevice object type: Extends AutoIdDevice with RFID-specific nodes for antenna configuration, read cycle parameters, RF power settings, and tag population events.
• Scan method: A standardised method that triggers a read cycle and returns an array of ScanResult objects. Each ScanResult contains the tag identifier, RSSI, antenna number, timestamp, and protocol-specific data (EPC, TID, user memory for UHF; UID for HF).
• ScanEventType: An OPC UA event fired when a tag is detected. Allows a MES to subscribe to continuous tag presence notifications without polling.
• BarcodeReaderDevice and RtlsDevice: Parallel type hierarchies for 1D/2D barcode scanners and real-time location systems, using the same Scan method and ScanResult pattern for consistency across AutoID technologies.

By implementing the AutoID Companion Specification, an RFID reader from any manufacturer exposes exactly the same OPC UA interface. A MES vendor can write a single OPC UA AutoID client that works with readers from Zebra, Impinj, Feig, Pepperl+Fuchs, and others without any vendor-specific code.

Advantages

• Rich information model: Data is self-describing with types, units, and semantic relationships. A MES receives not just a raw tag EPC but a structured ScanResult with context – antenna, timestamp, signal strength – without requiring custom parsing.
• Built-in security: Certificate-based authentication and TLS encryption are mandatory parts of the specification, not optional add-ons. OPC UA connections are encrypted and mutually authenticated by default.
• Platform independent: Runs on Windows, Linux, VxWorks, and bare-metal microcontrollers. No dependency on Microsoft COM/DCOM or any specific OS.
• Industry 4.0 standard: OPC UA is mandated or recommended in the German Platform Industrie 4.0 reference architecture (RAMI 4.0) and the Industrial Internet Consortium IIoT reference architecture. Adoption is effectively required for integration into modern European manufacturing systems.
• Broad vendor support: Siemens, Rockwell Automation, ABB, Beckhoff, B&R, and virtually all major PLC and SCADA vendors support OPC UA natively. RFID reader vendors including Zebra, Feig, and Pepperl+Fuchs publish OPC UA AutoID-compliant servers.
• Scalable communication patterns: Client-server for direct integration, PubSub over MQTT/AMQP for large-scale cloud or edge architectures. One protocol spans from PLC to cloud.
• Companion specifications ecosystem: Beyond AutoID, companion specs exist for packaging machines, CNC, robotics, weighing, and many other domains – meaning OPC UA RFID data integrates naturally with OPC UA data from other factory equipment.

Limitations

• Complex specification: The OPC UA specification runs to 14 parts and thousands of pages. Implementing a full OPC UA stack from scratch is a significant engineering effort. Most deployments rely on commercial or open-source SDKs (open62541, Eclipse Milo, Unified Automation).
• Heavyweight for constrained devices: A full OPC UA stack requires significant RAM and CPU. Nano and Micro profiles exist to reduce footprint, but even these are challenging on Class 0/1 IoT microcontrollers with under 64 KB of RAM. Simple sensors and readers often use MQTT or HTTP instead.
• Steep learning curve: The address space model, node types, references, and security configuration are not intuitive for developers accustomed to REST APIs or MQTT. Onboarding time for OPC UA development teams is substantially longer than for web protocols.
• Slower adoption outside industrial IoT: OPC UA is dominant in factory automation but rarely seen in consumer IoT, retail, or logistics where MQTT and HTTP are preferred. RFID deployments outside manufacturing are unlikely to encounter or need OPC UA.
• Certificate management overhead: The security model requires managing X.509 certificates for every client and server. In large deployments with hundreds of devices, certificate provisioning, rotation, and revocation adds operational complexity.
• Firewall and NAT traversal: OPC UA binary transport uses port 4840, which is not as widely permitted through enterprise firewalls as port 443. PubSub over MQTT mitigates this, but the native transport requires network configuration.

Common applications

• Manufacturing RFID integration: RFID readers at production line stations expose tag reads via OPC UA AutoID to a PLC or MES. Work-in-progress tracking, tooling identification, and pallet routing all use this pattern in automotive, electronics, and general manufacturing.
• Automotive production lines: Vehicle body carriers (skids) carry UHF RFID tags read at every station. OPC UA connects readers to the line PLC and MES, enabling per-unit traceability from stamping through final assembly.
• Pharmaceutical serialisation: Track-and-trace for individual medicine packs uses RFID readers integrated via OPC UA into MES systems that generate EPCIS events for regulatory compliance (EU FMD, DSCSA).
• Smart factory / Industry 4.0: OPC UA is the standard connectivity layer in Industry 4.0 architectures. RFID, vision systems, PLCs, and robots all publish data to an OPC UA aggregation layer, enabling digital twin and analytics applications.
• Warehouse and logistics automation: Conveyor sortation systems use RFID and barcode readers connected via OPC UA AutoID to WMS systems, with PubSub over MQTT for cloud-based fleet management.
• Tool and fixture tracking: Machine tools, jigs, and fixtures carry RFID tags read at machining centres. OPC UA connects the reader data to the CNC OPC UA companion spec, associating tool data with machining parameters for quality records.

OPC UA vs MQTT vs HTTP

Related