Robot Software
OPC UA for Robotics: What the Companion Specification Defines
OPC UA gives robots a vendor-neutral information model for condition monitoring and identification. What it standardises, what it deliberately does not, and where it belongs in a cell.
The robotics companion specification defines a vendor-neutral information model, not a control protocol. It standardises how a robot describes itself and reports condition data, so a monitoring system can read motion device identity, axis state, temperatures and operating hours from any compliant robot without a per-vendor driver. It does not replace the fieldbus, and it is not how you command motion.
What it standardises
OPC UA provides a general framework for describing machines: an address space of typed objects with properties, methods and events, plus transport, security and discovery. A companion specification narrows that generality for a domain by defining the specific object types the domain uses.
For robotics, the model is built around the motion device system: a controller, one or more motion devices, their axes, and the drive units powering them. Typical content includes:
- Identification. Manufacturer, model, serial number, firmware version, production date.
- Structure. How many motion devices, how many axes each has, and how they relate.
- Axis state. Actual position, velocity, torque or load, and motion state per axis.
- Condition data. Motor temperature, drive temperature, operating hours, power-on hours.
- Operational mode and state. Whether the robot is running, stopped or in an error condition.
- Safety-related status as read-only information, reported rather than commanded.
What it deliberately does not do
| Task | Right layer | Rate | Why not OPC UA |
|---|---|---|---|
| Joint control | Controller internal bus | 1 to 20 kHz | Orders of magnitude too slow |
| Cell handshake with the PLC | PROFINET, EtherNet/IP | 1 to 8 ms | Determinism not guaranteed |
| Safety signals | Safety protocol on the fieldbus | 4 to 20 ms | No safety integrity claim |
| Program selection and start | Fieldbus, or OPC UA methods where latency allows | 10 to 100 ms | Acceptable only for slow supervisory actions |
| Condition monitoring | OPC UA | 100 ms to seconds | This is what it is for |
| Production data to MES | OPC UA | seconds | This is what it is for |
Some vendors do expose methods that start a program or select a job over OPC UA, and using them for supervisory actions at 10 ms to 100 ms is reasonable. Using them inside a takt-critical handshake is not, because OPC UA offers no timing guarantee.
Security is a real advantage
Unlike most fieldbus protocols, OPC UA has authentication, authorisation and encryption built into the specification rather than bolted on. Certificate-based trust between client and server, signed and encrypted messages, and role-based access control are part of the standard. In a plant where machine data leaves the cell and reaches an analytics platform or a cloud service, that is the difference between a defensible architecture and an open port.
The practical cost is certificate management: issuing, distributing, renewing and revoking. Plants that skip it end up running in a no-security mode, which discards the main reason to prefer OPC UA at that layer.
What to ask a robot vendor
- Is an OPC UA server built into the controller, or does it require a gateway device?
- Which companion specification version is implemented, and which optional parts are included?
- Which condition data is exposed, specifically temperatures, operating hours and load per axis?
- What update rate is supported, and how many concurrent clients?
- Are write operations supported, and if so which ones, with what access control?
- Is the security mode configurable, and what certificate handling is provided?
Question three matters more than it sounds. A server that publishes identification and nothing else is compliant and useless for condition monitoring, which is the main reason to want it.
Frequently asked questions
What does the OPC UA robotics companion specification define?
A vendor-neutral information model for motion device systems: identification, structure, axis state, condition data such as temperatures and operating hours, and operational state. It defines how a robot describes itself, not how it is commanded.
Can I control a robot over OPC UA?
Not for motion. There is no timing guarantee, so joint control and takt-critical handshakes belong on the fieldbus. Supervisory actions such as program selection at 10 ms to 100 ms are acceptable where a vendor exposes them.
Does OPC UA replace PROFINET or EtherNet/IP?
No. They serve different layers. The fieldbus carries deterministic cell signalling at 1 ms to 8 ms; OPC UA carries descriptive and condition data at 100 ms to seconds and travels beyond the cell.
Is OPC UA secure by default?
It has authentication, encryption and role-based access control in the specification, but they must be configured. Plants that avoid certificate management end up running without security, which removes the main advantage over a plain fieldbus gateway.
Do all robot brands support it?
Support is broad but uneven. Some controllers include a server natively, others need a gateway, and the set of exposed data varies. A server that publishes only identification is compliant yet useless for condition monitoring, so ask for the specific data list.
Sources
- OPC UA for roboticsOPC Foundation, scope of the companion specification
- IEC 62541, OPC unified architectureInternational Electrotechnical Commission, the underlying standard
- ISO 10218-1:2025, Robotics, Safety requirements, Part 1International Organization for Standardization, why safety signals stay on a safety protocol