OPC UA connects machines by giving each one a built-in server that clients browse like a folder tree: typed, named, structured data over one secure, vendor-neutral protocol (IEC 62541). For connectivity work, it means you discover what a machine offers instead of reverse-engineering a tag list.
If you already know what OPC UA is, this post is about using it: finding the server on a machine, browsing the address space, subscribing instead of polling, handling certificates without a week of pain, adding OPC UA to machines that predate it, and fitting it into an architecture next to MQTT. If you want the fundamentals first, start with what is OPC UA and come back; this post assumes the basics and goes to the practice.
Why use OPC UA for machine connectivity?
Because it removes the two worst chores in integration: guessing and translating. With flat protocols, connecting a machine means obtaining a register map or tag list from somewhere, hoping it matches the firmware, and hand-mapping every value with its units and scaling. An OPC UA server carries all of that in the machine itself. A client connects, browses, and sees named, typed nodes with engineering units and structure, so the machine documents its own interface. Multiply that across a floor of mixed vendors and the savings compound: one client stack, one security model, every compliant machine.
The second reason is durability. OPC UA is standardized as IEC 62541, maintained by the OPC Foundation, and implemented across thousands of products. A connectivity layer built on it does not die when a vendor changes hands or a proprietary driver stops shipping. For a plant, the protocol choice is a decade-scale decision, and OPC UA is one of the few options with decade-scale credentials.
How do you find and enable the OPC UA server on a machine?
Start in the controller configuration, not on the network. On many modern PLC platforms the OPC UA server ships in the firmware and just needs enabling in the engineering software, where you also choose which tags to expose. On packaged machines, the server often runs on the machine's HMI or IPC rather than the controller itself, and the OEM manual states the endpoint. The endpoint is a URL of the form opc.tcp://host:4840, with 4840 as the registered default port.
Three practical notes. First, expose deliberately: publish the tags that answer questions, not the whole program, both for clarity and to keep server load modest on smaller controllers. Second, check firmware versions early; older firmware may cap the number of sessions or monitored items, and those caps decide your architecture. Third, test with a generic OPC UA client before wiring anything downstream. Ten minutes of browsing tells you what the machine really offers, which beats any datasheet.
Should you poll or subscribe?
Subscribe, almost always. OPC UA's client-server mode includes subscriptions with monitored items: the client registers the nodes it cares about, sets a sampling interval and a deadband, and the server reports only changes. That is the OPC UA equivalent of report by exception, and it is dramatically lighter than read-polling every value on a cycle, both for the network and for the controller serving the data. Reserve plain reads for one-shot lookups like configuration values.
Set the sampling interval per signal, by the question it answers. Machine state wants tight sampling; a bearing temperature can report every few seconds with a deadband so noise does not become traffic. And mind the session limits on smaller controllers: one well-configured gateway session subscribing on behalf of everything downstream beats five applications each holding their own session, which is one of several reasons the gateway pattern in connecting PLC data to the cloud wins.
How do you handle OPC UA security without pain?
OPC UA security is built into the protocol: endpoints offer security policies for signing and encryption, and clients and servers authenticate each other with X.509 certificates. The pain people report is almost always process pain, not protocol pain, and it has a short fix list. Decide certificate handling before commissioning: either a simple internal issuing process or, at minimum, a documented exchange-and-trust step for each new client-server pair, instead of ad hoc clicking on trust prompts. Never leave endpoints on the None security policy after commissioning; it exists for testing. And treat user authentication (which user may write which node) as separate from application authentication (which certificates trust each other), because conflating the two is the most common configuration mistake. Handled this way, security setup is an hour per machine, not a week.
What about machines that do not speak OPC UA?
Wrap them. OPC UA gateways and server toolkits sit in front of older equipment, poll it over Modbus, serial, or a vendor driver, and republish the data as a proper OPC UA address space. The older machine then looks to every client like a modern one, and your consuming systems stay uniform. This is standard practice on mixed floors and pairs with the retrofit playbook: machines with no controller at all get external sensors, as covered in the machine connectivity guide, and those sensor signals can be served through the same gateway's address space.
Companion specifications push the uniformity further. Industry groups publish standard OPC UA information models per equipment class, among them Euromap 77 for injection molding machines and umati for machine tools, so that different vendors' machines expose the same structure with the same semantics. Where a companion specification exists for your equipment class, ask your OEM for it; it turns per-vendor mapping work into a solved problem.
How does OPC UA fit next to MQTT in one architecture?
Use both, at the layers they are best at. The pattern that dominates real deployments: OPC UA southbound, between machines and the edge gateway, where its browsing, typing, and machine-level security shine; MQTT northbound, from the gateway to the broker and everything above, where its decoupled publish-subscribe model lets any number of systems consume without touching machines. The gateway subscribes to machine servers on one side and publishes structured payloads into a unified namespace on the other. OPC UA also defines its own publish-subscribe option in Part 14 of the specification, and it has its place, but treating OPC UA and MQTT as rivals misreads how plants actually run them: as complements, one at the machine, one across the operation.
This split also keeps roles clean for the systems above. SCADA keeps its machine-close role, the historian subscribes for trends, and the operational layer subscribes for events it will join to orders and people. Nothing polls a machine twice, and adding the next consumer is a subscription, not a project.
What is the practical sequence for an OPC UA rollout?
- Inventory servers. For each machine: does a server exist, in the controller or the HMI, and what firmware and session limits apply?
- Enable and expose deliberately. Publish the tags that answer questions. Confirm with a generic client before going further.
- Wrap the non-speakers. Put OPC UA gateways in front of Modbus and serial equipment so the client side stays uniform.
- Stand up certificates properly. A documented trust process per pair, no None endpoints in production.
- Subscribe, do not poll. One gateway session per machine, monitored items with per-signal intervals and deadbands.
- Publish northbound into the namespace. Gateway to broker over MQTT, so every consumer plugs in once.
Where does Harmony AI fit?
Harmony AI consumes OPC UA the way this post describes: as the machine-side interface in a larger operational layer. Harmony AI's engineers connect your OPC UA machines, wrap your older equipment, and land it all, alongside digitized paperwork and your existing software, in one system where machine data carries operational context: which order, which crew, which quality checks. It works across mixed vintages with no rip-and-replace, and deployment happens in person on your floor, including the server inventory and certificate setup above. You can see the connected-systems module in context on the features overview, and what a full deployment looks like in the CLS case study.
What do the standards say?
- OPC UA is standardized as IEC 62541 and maintained by the OPC Foundation; the specification is public and implementations exist from embedded servers to cloud clients.
- Publish-subscribe communication is specified in Part 14 of the standard, extending the core client-server model for many-to-many use.
- Companion specifications, developed by the OPC Foundation with industry groups, standardize information models per equipment class, including Euromap 77 for injection molding and umati for machine tools.
- Northbound, MQTT (OASIS standard, ISO/IEC 20922) and Eclipse Sparkplug (ISO/IEC 20237, 2023) are the matching open standards for the broker layer above the machines.
Open at the machine, open at the broker: that combination is why a connectivity stack built this way outlives any single vendor on your floor.