Robotics
| Document | OPC 40010-1 |
|---|---|
| Version | 1.02 |
| Published | 2025-09-08 |
| Namespace | http://opcfoundation.org/UA/Robotics/ |
| Sector | Robotics |
OPC UA for Robotics models an industrial robot as a motion device system: controllers, motion devices, axes, power trains with motors and gears, load, safety states and task control. Version 1.02 (September 2025) is layered over the IA industrial-automation layer, which is itself layered over DI.
Where it sits in the stack
Robotics is the clearest example of the three-tier companion-spec stack: DI provides device identification and structure, IA provides the shared industrial-automation layer, and Robotics adds the motion domain on top. It is a vertical model, describing what a robot is and what it is doing, rather than a production model, so pairing it with the Machinery base layer is what makes a robot cell measurable alongside the other machines in the plant.
The types that matter
| Type | What it carries |
|---|---|
MotionDeviceSystemType | The root object type for the whole robot system: its controllers, its motion devices and its safety states. This is the object to match with HasTypeDefinition. |
MotionDeviceType | One motion device, meaning the manipulator itself, with its axes, power trains and the identification inherited from the DI pattern. |
ControllerType | The robot controller, including its software and its diagnostic information. On many installations this is where the useful state actually lives. |
AxisType | One axis of the motion device, with its motion profile and its current values. Axis data is the raw material for condition monitoring, not for OEE. |
PowerTrainType | The drive chain behind an axis, grouping the motor and gear that move it. |
MotorType | The motor in a power train, with the identification and operating data needed for wear and health tracking. |
GearType | The gear in a power train, including the ratio, which matters when interpreting axis and motor speeds together. |
DriveType | The drive electronics associated with a power train, where the vendor exposes them as a modelled component. |
SafetyStateType | The robot's safety condition, covering emergency stop and protective stop and the operational mode the safety system permits. Safety stops are a large share of real robot downtime. |
TaskControlType | Task and program execution on the controller: what the robot is running and in what state. This is the closest thing to a production state in the model. |
LoadType | The payload and load configuration of the motion device, which is what makes cycle-time comparisons across products meaningful. |
Using it on a real machine
- Check the whole stack is loadedRead NamespaceArray and expect three entries, not one: the DI URI, the IA URI and http://opcfoundation.org/UA/Robotics/. A client that loads only the Robotics nodeset cannot decode the inherited types.
- Find the motion device systemBrowse for objects typed on MotionDeviceSystemType, then walk down to controllers, motion devices and axes. Read the identification properties at the system level before descending.
- Subscribe to task control and safety stateFor anything production-facing, the useful signals are what the controller is executing and whether the safety system has stopped it. Axis positions are high-rate data you almost never want in an OEE pipeline.
- Rate-limit axis data deliberatelyAxis values change continuously. Use deadbands and a publishing interval matched to your purpose, and keep axis monitoring in a separate subscription from your production signals so one cannot starve the other.
- Add Machinery on top for production contextWhere the cell also exposes Machinery, take availability from MachineryItemState and MachineryOperationMode and counts from the cell PLC. Use Robotics for the robot's own condition, not as the production counter.
What it gives you for OEE
Robotics is a device and motion model, not a production model, and treating it as an OEE source is the standard mistake. What you can get: robot availability inferred from TaskControlType execution state plus SafetyStateType, which is genuinely useful because emergency and protective stops are a large, under-attributed share of robot-cell downtime, and axis and motor data as condition-monitoring input for predicted stoppages. What is absent: there is no ProductionStatisticsType equivalent, no standardised part counter, no good and scrap split, and no condition-class reason-code taxonomy comparable to MachineTool. In practice, part counts for a robot cell come from the cell PLC or from a downstream station, and the OEE model is built on the cell rather than on the robot. Layer Machinery on top and the robot becomes measurable the same way the rest of the plant is.
Gotchas
- Three nodesets, not one. Robotics depends on IA and DI, and a partial load produces undecodable inherited types rather than a clean error.
- Version 1.02 dates from September 2025, one year after 1.01. Installed controllers will be on the earlier version, where optional nodes differ.
- Vendor coverage is uneven and often licensed as an option on the controller. Confirm the robot maker actually exposes the model before designing against it, and confirm which optional branches.
- Axis and motor data is high-rate. Put it in its own subscription with deadbands, or it will crowd out the production signals you actually needed.
Once the machine speaks a companion spec, the OEE mapping is portable across vendors, which is the point at which analytics stops being a per-machine project.
See Jemba →Last verified 7 September 2026 against OPC UA 1.05.07. Version and publication date read from the released nodeset. OPC UA Connect is an educational resource and is not affiliated with the OPC Foundation.