You have added OPC UA to your device. The datasheet says so. And your customer’s integrator is still emailing to ask what DB12_INT3 means. That gap is where most integrations stall, and it is rarely the protocol’s fault.
OPC UA promised one language for the whole factory floor. In practice most integrations get stuck in the space between “we support OPC UA” and “the SCADA system can actually use this”. What follows is what tends to go wrong when you are putting OPC UA onto your own hardware, roughly in the order it bites.
Server, client, or both? Decide before you scope
It sounds trivial. It gets skipped often, and it quietly sets the budget for the whole project.
If your device is a sensor, a controller or a machine that others need to read from or command, you are building a server. If it aggregates, supervises, logs or passes data upward to MES or IT systems, you need a client. Plenty of devices need both.
Your address space is your product
If you take one thing from this article, take this.
An OPC UA server is not a list of tags. It is a typed, browsable model of your machine. Expose two hundred variables called DB12_INT3 and you have ticked the compliance box while delivering none of the value, because the integrator still needs a spreadsheet from you to make sense of any of it. You have reinvented Modbus with more overhead.
Done properly, somebody can point a client at your device, browse it, and understand what it is without ringing you. Objects map to real things. Types get reused. Units and ranges are declared. Methods do what their names say.
Certificates: it works, until one day it does not
OPC UA security is certificate-based, and certificates are where deployments quietly rot. Three questions decide how much pain you have signed up for.
How does a certificate reach the device in the first place: factory, commissioning, or the customer’s own PKI? How is trust established, and is that a documented procedure or tribal knowledge? And what happens when a certificate expires on a device that has sat in a cabinet for eight years?
That last one catches people. Industrial hardware routinely outlives its certificates. With no renewal path designed in, the answer is an engineer in a van, per device, and nobody costed for that.
Settle your supported security policies early too. Anonymous, unencrypted access is convenient on the bench and unacceptable in production. Discovering which policies you need after the hardware is frozen is not a good week.
Your customers still have Modbus
Very few plants are all-OPC-UA and they will not be for years. Any realistic integration means bridging to something older: Modbus RTU and TCP, EtherNet/IP, a serial protocol with a datasheet from 1998 and a typo in the register map.
The interesting question is not whether to bridge but where the bridge lives. Embedded in your device, on a separate gateway, or up at the supervisory layer. Each answer moves cost, latency and, more importantly, who gets called when it breaks. Make that choice deliberately rather than inheriting it.
Stop polling everything
A lot of first integrations poll every variable on a timer, watch the load climb, and conclude OPC UA is slow. It is not.
OPC UA is built around subscriptions. The client states what it cares about and how often, and the server reports changes. Sampling intervals, publishing intervals, queue sizes and deadbands all exist so you can tune responsiveness against load. Getting them right is usually the difference between something that scales across a plant and something that struggles with a single cell. Where data rates are genuinely high, or one-to-many distribution matters, look at OPC UA PubSub over MQTT or UDP rather than forcing everything through client-server sessions.
What to settle before you commit
- Server, client or both, written down rather than assumed.
- Does a companion specification already cover your equipment?
- Could a stranger browse your model and understand the machine?
- How do certificates arrive, get trusted and get renewed across the service life?
- Which security policies are supported, and which are refused?
- Which legacy protocols need bridging, and where does that run?
- What are the real update rates, and how many clients connect at once?
- How will conformance be demonstrated, to yourself and to your customer?
- How does the stack receive security updates once it is in the field?
Answer those and the implementation is tractable. Leave them open and no amount of stack-shopping will rescue the project.
Integrating OPC UA into your own hardware?
Book a free OPC UA assessment
DevSpark Ltd builds working OPC UA architectures: server and client development, information-model and address-space design, certificate and security configuration done properly, and bridges from legacy protocols so older equipment joins the same conversation. Over a decade integrating industrial equipment across production lines, from robot controllers to national infrastructure. Fixed scope, working data in weeks.
DevSpark Ltd is a UK-based deep-tech engineering consultancy in embedded systems, photonics and video-infrastructure engineering. Registered in England & Wales, company number 15572238.