OPC UA Robotics Companion Specification (OPC 40010): Robot Information Model, Skills and Integration

A factory with five robot brands has five ways to ask the same question: is the arm in automatic mode, what is the motor temperature on axis three, and which program is loaded? Each vendor answers through its own proprietary protocol, its own tag names and its own idea of what “running” means. Every integration project then repeats the same translation work, and the translation rots the moment a controller firmware changes.

The OPC UA robotics companion specification, published as OPC 40010-1 “Robotics – Vertical Integration”, removes that translation layer by standardising what a robot looks like to an OPC UA client. It names the objects (motion device, axis, power train, controller, safety state), fixes their properties, and defines two small state machines for remote operation. The current release is 1.02, dated 2025-09-09.

This article gives you a verified, practitioner-level reading of the specification: what it models, what it deliberately leaves out, how the state machines behave, how conformance profiles work, and how to place it in a plant architecture. It also takes a clear position on “skills”, a word the title of this article promises and the specification itself does not use.

What this covers: history and ownership, the information model, the remote-operation state machines, safety and operating modes, profiles and conformance, the integration architecture, a browsing example, failure modes, and a pragmatic adoption checklist.

Context and Background

OPC UA companion specifications are the mechanism by which the OPC Foundation lets an industry define a shared information model on top of the generic OPC UA address space. The base standard provides the meta-model (objects, variables, methods, references, events). A companion specification says what a “robot” or an “injection moulding machine” is in that meta-model. Without that layer OPC UA is a transport with a type system, and every server author invents their own structure.

The robotics work began in Germany. According to the OPC Foundation’s press release, the VDMA (the German mechanical engineering association) and the OPC Foundation announced the OPC UA companion specifications for robotics and machine vision on June 19, 2018, at a press conference at automatica 2018. The robotics document was VDMA Specification 40010, and Part 1 was released as a draft. The stated goal was to present “all robot related data regardless of manufacturer or location in a uniform manner”, with asset management, condition monitoring, preventive maintenance and vertical integration as the headline uses. KUKA and Afag were quoted at the launch, and several robot manufacturers showed a condition-monitoring demonstrator.

The specification then moved into the OPC Foundation’s own numbering as OPC 40010-1. The Foundation’s specification page lists version 1.00 (dated 2019-05-13) as deprecated and version 1.02 as the current release (2025-09-09). The page describes the specification as “split up into several parts from part 1 to part n”, but at the time of writing I could find only Part 1 on the Foundation’s pages and reference site. Treat any claim about a published Part 2 as unverified until you see it on the OPC Foundation site. The editor named on the specification page is Bernd Fiebiger, the working group is Robotics, and the document is distributed under the OPC specifications licence; downloads require a Foundation login, while the browsable reference at reference.opcfoundation.org is open.

OPC 40010-1 is built on three layers you should know by name. Underneath is the OPC UA base specification (the OPC 10000 series). Above that is OPC UA for Devices (DI, OPC 10000-100), whose ComponentType is the parent of most robotics types, so every robotics object inherits identification and parameter-set conventions. Beside it is OPC 40001-1, the OPC UA companion specification for Machinery, with which the robotics model is designed to be used; its Annex C shows the combination. The 1.02 release also added a profile for “Robotics and Machinery Identification” according to the Foundation’s change list.

If you are new to how companion specifications compose, our survey of OPC UA companion specifications for robotics and machinery gives the landscape view. This article is the deep dive on the robotics document itself. For sensor-level integration beneath the robot, see how IO-Link and IO-Link Wireless connect to OPC UA through IODD-based architectures.

What it is not

Two clarifications prevent most misunderstandings. First, OPC 40010-1 is a vertical integration model: it exposes robot state and a limited set of remote-operation methods to supervisory systems, MES (manufacturing execution systems) and analytics. It is not a real-time motion interface. It does not define trajectories, joint-level command streaming or force control. Those belong to the controller’s own real-time network, to ROS 2 and DDS in research and service robotics, or to OPC UA FX in the controller-to-controller domain.

Second, the word “skills” does not appear in the content of Part 1 that I reviewed. The use cases in the specification are supervision, condition monitoring, asset management and remote operation. I return to the skills question in its own section, because it is where most marketing language and most real engineering decisions collide.

The Robot Information Model: MotionDeviceSystem, Controllers and Safety

The OPC UA robot information model describes a complete robot installation as one MotionDeviceSystemType object holding three folders: MotionDevices (the manipulators or mobile robots), Controllers (the control units, with software and task controls) and SafetyStates (informational safety status). References tie the three together so a client can navigate from a controller to the devices it controls.

Figure 1: The OPC 40010-1 object model. MotionDeviceSystemType is the entry point; the dashed Controls reference links a controller to the motion devices it drives.

Figure 1 shows the containment structure. The scope text says the information model represents a complete motion device system so that higher-level control and evaluation systems can interact with it, and that a system may contain one or more motion devices such as industrial or mobile robots, kinematic chains or manipulators, together with their control units and peripheral components. That wording matters: the model is deliberately broader than “six-axis arm”.

MotionDeviceSystemType: the entry point

MotionDeviceSystemType is a non-abstract subtype of DI’s ComponentType. At least one instance must exist in the server’s DeviceSet, which is the standard DI location where a client looks first. It has three mandatory component folders: MotionDevices (instances of MotionDeviceType), Controllers (instances of ControllerType) and SafetyStates (instances of SafetyStateType). It has one optional property, ComponentName, a localised text that a vendor, integrator or user may set.

The design choice worth noticing is that safety, control and mechanics are separate subtrees joined by references rather than nested inside one another. Robot installations rarely map one controller to one arm. A single controller may drive a robot plus a positioner and a linear track; a dual-arm cell may have two controllers; a safety PLC may be independent of both. Reference types let the model express those topologies without forcing a hierarchy that real hardware does not follow.

MotionDeviceType, AxisType and the power train

A MotionDeviceType carries mandatory identification properties: SerialNumber, Manufacturer, Model and ProductCode, plus a mandatory MotionDeviceCategory. Optional properties are AssetId, DeviceManual and ComponentName. The category enumeration is based on ISO 8373 and has seven values: OTHER (0), ARTICULATED_ROBOT (1), SCARA_ROBOT (2), CARTESIAN_ROBOT (3), SPHERICAL_ROBOT (4), PARALLEL_ROBOT (5) and CYLINDRICAL_ROBOT (6).

Structurally, a motion device must have at least one axis and at least one power train, held in the mandatory Axes and PowerTrains folders. It may also expose a FlangeLoad (type LoadType), an AdditionalComponents folder, and a TaskControlReference. Its ParameterSet has one mandatory variable, SpeedOverride (a Double), and two optional Booleans, OnPath and InControl.

AxisType is a subtype of DI ComponentType with a mandatory MotionProfile property (an AxisMotionProfileEnumeration) and an optional AssetId. Its ParameterSet has a mandatory ActualPosition and optional ActualSpeed and ActualAcceleration, all Doubles using AnalogUnitType. Limits are not separate variables: position, speed and acceleration limits are expressed through the EURange property of the analog unit type, and the specification requires EURange on ActualPosition when the axis has physical limits. That is a good example of the model reusing OPC UA primitives instead of inventing new ones.

The PowerTrainType ties an axis to what actually drives it. An axis can reference the power trains that must be actively driven when only that axis moves; virtual axes have no such reference. Underneath, MotorType and GearType describe the electromechanical components. The Foundation’s change list for 1.02 records that IsConnectedTo references for MotorType and GearType were removed, which is the kind of detail that bites when you generate code from an older nodeset.

Why model the power train at all? Because condition monitoring needs it. Motor temperature, load and operating hours are named in the specification’s condition-monitoring use case, and asset management needs part numbers and serial numbers of the main electrical and mechanical parts so technicians can plan replacements. A model that stopped at “joint angle” would serve a dashboard but not a maintenance planner.

ControllerType: software, task controls and drive context

ControllerType represents the control unit. Mandatory properties are SerialNumber, Manufacturer, Model and ProductCode. Mandatory components are CurrentUser (a UserType), Software (a folder that must hold at least one SoftwareType instance) and TaskControls (a folder that must hold one or more TaskControlType instances). Optional elements include AssetId, DeviceManual, ComponentName, a Components folder, a ParameterSet, a Programs folder of type FileDirectoryType, and a SystemOperation add-in of type SystemOperationType.

Two reference types connect the controller to the rest. HasSafetyStates (inverse SafetyStatesOf) links it to SafetyStateType instances, and Controls (inverse IsControlledBy) links it to the MotionDeviceType instances it drives. The optional controller ParameterSet covers cabinet-level health data: TotalPowerOnTime, StartUpTime, UpsState, TotalEnergyConsumption, CabinetFanSpeed, CPUFanSpeed, InputVoltage and Temperature. These are exactly the variables a maintenance analytics team wants and a proprietary protocol rarely exposes consistently.

One subtle recommendation in the specification: the Components folder inside ControllerType can hold AuxiliaryComponentType and DriveType instances, but the specification recommends using the Components folder from OPC 40001-1 (Machinery) instead. This is the first sign that Robotics and Machinery are meant to be used together, with Machinery owning generic composition and Robotics owning robot-specific types.

SafetyStateType: informational by design

SafetyStateType describes the safety state of motion devices and controllers. It has optional folders EmergencyStopFunctions and ProtectiveStopFunctions (holding vendor-specific EmergencyStopFunctionType and ProtectiveStopFunctionType instances that list each function’s name and state) and a mandatory ParameterSet with three mandatory variables:

OperationalMode, an OperationalModeEnumeration.
EmergencyStop, a Boolean that is TRUE when one or more emergency stop functions are active (reflecting only the listed functions when the folder is present).
ProtectiveStop, a Boolean that is TRUE when one or more enabled protective stop functions are active.

The specification states plainly that this type is not intended for functional safety applications and is not for IEC 61508. Read that as a hard architectural rule: an OPC UA client may observe that an emergency stop is active, but must never be a link in the chain that performs or verifies a safety function. The model exists so supervisory systems can log stops, correlate them with production data and report them, not so they can replace a safety controller. It was placed inside the motion device system model because vendors implement safety in different places, in hardware or in software, and a single safety state may serve several devices.

The OperationalModeEnumeration follows ISO 10218-1:2011 clause 5.7. Its values are OTHER (0, no valid mode, for example during boot, when the system is uncalibrated, or when the safety system has failed), MANUAL_REDUCED_SPEED (1), MANUAL_HIGH_SPEED (2), AUTOMATIC (3) and AUTOMATIC_EXTERNAL (4, automatic but under external control such as a PLC). That last value is practically important: it is the difference between “the robot is in automatic” and “the robot is in automatic and will accept start commands from the cell controller”.

Remote Operation: SystemOperation and TaskControl State Machines

Remote operation in OPC 40010-1 uses two small state machines built from the same three states: Idle, Ready and Executing. SystemOperation governs the controller as a whole (power-up preparation and run), while TaskControl governs one program context (load, start, stop, unload). Clients drive both through standard OPC UA methods, and both emit transition events.

Figure 2: A typical remote-operation sequence. The client prepares the system, loads a program on a task control, starts execution and later stops it.

The fourth use case in the specification, remote operation, was extended in release 1.02 through add-ins and state machines, according to the Foundation’s change list. This is the part of the model closest to what people mean when they ask for robot “skills”: a way to tell the robot to do something. It is worth understanding exactly how much it does and how little.

SystemOperationStateMachineType

SystemOperationStateMachineType is a subtype of OperationStateMachineType and models the controller’s behaviour at system level. It has three states: Idle (state number 1, available but needing preparation), Ready (2, ready to start execution) and Executing (3, running, typically with at least one task control executing).

The transitions are explicit:

Transition	From to	Trigger
IdleToReady	1 to 2	GetReady method, or internal event when preparations succeed
IdleToIdle	1 to 1	StandDown, internal events, or failed preparation
ReadyToExecuting	2 to 3	Start method, or internal event
ReadyToIdle	2 to 1	StandDown, or internal event
ExecutingToReady	3 to 2	Stop method, or internal event once stopped
ExecutingToIdle	3 to 1	Internal event, typically an error

Four methods drive it: GetReady, StandDown, Start and Stop. GetReady requests the Idle-to-Ready transition and implies internal preparation such as switching on an intermediate circuit (the drive power stage). Start takes the system from Ready to Executing and can return status codes including OK, E_SystemState, E_UnexpectedError, E_ActiveAlarm and E_AcknowledgeRequired. Stop takes a StopMode argument that must be 0 or one of the values in PossibleStopModes; anything else yields Bad_InvalidArgument. StandDown returns Ready to Idle or cancels an ongoing preparation.

Two details deserve attention. First, a method-triggered transition may be delayed until internal conditions are met, so a successful method return does not always mean the state has already changed; clients should subscribe to the state variable or the TransitionEventType event rather than assume. Second, conditions in SystemOperationType may require acknowledgement before the system can be activated, for example after an operational mode change. That is how the model carries the real-world rule that you cannot silently re-enable motion after a mode switch.

Optional IdleSubstateMachine and ExecutingSubstateMachine objects expose progress during slow transitions, such as a slow preparation for Ready or a slow stop for certain stop modes. Vendors may substitute their own substate machines. LastTransition and LastTransitionReason record the most recent change, which is valuable for post-mortem analysis.

TaskControlStateMachineType

TaskControlType represents a program context inside the controller (a robot controller may have several, for example a main program and a background task). The remote-operation add-in, TaskControlOperationType, contains a mandatory TaskControlStateMachine and an optional MotionDevicesUnderControl property listing the motion devices controlled by that task control together with the loaded program. The specification says task controls may be started manually or in a system context through SystemOperation.

The task control state machine reuses the three-state vocabulary with different meanings. Idle means no program is loaded. Ready means a program is loaded but not executing. Executing means the program is loaded and running; if the program restarts automatically at the beginning, the task control stays in Executing.

Its methods are LoadByNodeId and LoadByName (load a program or module that exists in the address space, such as one in the controller’s Programs folder), UnloadProgram, UnloadByNodeId and UnloadByName, Start, and Stop. Start only works in Ready and starts from the beginning or resumes depending on the program pointer. Stop takes a StopMode, and if the optional ReadySubstateMachine is present the task control must be in its Suspended substate. The ReadySubstateMachine also offers a ResetToProgramStart method. A failed load keeps the machine in Idle (IdleToIdle). An internal error that stops and unloads the program moves it from Executing straight to Idle.

Figure 3: SystemOperation and TaskControl share the Idle, Ready, Executing vocabulary but are driven by different methods. Transition names follow the specification; layout is simplified.

One documentation inconsistency is worth knowing before you implement: a transition table in the specification refers to LoadProgram(), while the methods actually defined are LoadByNodeId and LoadByName. Implement the defined methods and treat the stray name as an editorial slip.

What remote operation does not give you

Notice what is absent. There is no method to move a joint, no way to pass a target pose, no tool-centre-point interface, no gripper command. The model lets a client select a program that already exists in the controller and run it. It carries state, identification, health and a program lifecycle. For many integrations that is exactly right: an MES says “load recipe 47 and start”, and the robot’s own programming environment owns everything about how recipe 47 executes. But if your requirement is parameterised, device-independent action commands, you are asking for something more than Part 1.

Skills, Profiles and the Conformance Reality

OPC 40010-1 does not define a skill model. It defines state, identity, health and a program-lifecycle state machine. “Skills” in the OPC UA world refers to a separate, higher-level pattern in which a device exposes an abstract, parameterised capability such as “pick” or “screw” with its own state machine; research groups have published skill models for robot manipulators, but those are layered on top of, not part of, the Robotics Part 1 information model.

The distinction matters because purchasing language blurs it. A vendor saying “OPC UA robotics support” may mean any of three very different things: a proprietary information model that happens to run over OPC UA, a subset of OPC 40010-1 (read-only monitoring), or a skill-style capability layer of their own design. Only the second is the standard. Ask which.

Why skills are a different layer

A skill abstraction answers a question OPC 40010-1 does not: how does an orchestrator ask a device to perform a capability without knowing the device’s programming language? Academic work exists on this. Examples that surfaced in my research include a TUM publication on a hardware-agnostic OPC UA skill model for robot manipulators and an Aalto University thesis on implementing the OPC UA skills concept on an assembly-process laboratory model. I have not verified the detailed content of these works against the primary papers, so treat them as pointers to the research direction and not as endorsements of a specific design.

What can be said from first principles is how a skill layer would relate to Part 1. A skill needs a lifecycle (idle, running, completed, error), parameters, and a result. The TaskControl state machine is a lifecycle for a program; a skill lifecycle is a lifecycle for a capability invocation. You can implement skills on a Robotics-compliant server by mapping each skill to a program loaded through LoadByName plus a parameter set that the program reads, but that mapping is your design, not the standard’s. Making it explicit in architecture documents avoids the trap of assuming interoperability that does not exist.

Profiles: what a server can claim

Part 1 defines four profiles, each a server facet:

Profile	Purpose
Robotics Base Server Facet	Minimum model: motion device system, motion devices, controllers
Robotics MDS Operation Server Facet	Adds remote operation of the motion device system
Robotics AM Extended Server Facet	Asset management extensions (identification of axes, power trains, parts)
Robotics CM Extended Server Facet	Condition monitoring extensions (health parameters)

Behind the profiles sit 31 conformance units, all in the Server category, with names such as Rob MotionDeviceSystem Base, Rob Axis AM Extended, Rob Controller CM Extended, Rob Task Control Modules, Rob Emergency Stop Function and Rob Protective Stop Function. Profiles aggregate conformance units; certification and procurement language should reference profiles, not just “supports OPC 40010”.

I also noticed a small defect in the published tables: the CM Extended facet lists a conformance unit called Rob PowerTrain CM Extended, while the conformance unit table defines only Rob PowerTrain AM Extended. If you are generating test cases from the spec text, expect to reconcile that against the nodeset or ask the working group. It is a good reminder that specification documents have bugs and that a nodeset-driven test suite is more reliable than reading prose.

What conformance does not guarantee

A server can claim the Base profile and still expose very little. Many optional elements (OnPath, InControl, ActualSpeed, controller ParameterSet values) are optional precisely because not every controller can supply them. Two compliant servers can therefore differ in how useful they are for condition monitoring. Evaluate the AM and CM facets and then inspect the actual populated nodes on a real controller, not on a datasheet.

Reading the four use cases as a requirements checklist

The specification’s four use cases are a practical way to decide which profile you need. Supervision means access to operational, safety and process data during production; it needs the Base facet and the safety states. Condition monitoring means assessing machinery while it runs to catch early signs of faults, with motor temperature, load and operating hours named explicitly; it needs the CM Extended facet. Asset management means tracking identifying details of the main electrical and mechanical parts (part number, brand, serial number) so replacements can be planned; it needs the AM Extended facet. Remote operation means controlling robot programs through the controller and task-control state machines, including upload, download, loading, unloading, starting and stopping; it needs the MDS Operation facet.

Write your RFP per use case and require the matching profile. “Supports OPC UA” without a profile name tells you nothing; “claims the Robotics Base Server Facet and the CM Extended Server Facet, with a nodeset and a populated-node report” is testable.

Integration Architecture: From Robot Controller to Digital Twin

The practical architecture places an OPC UA server (embedded in the robot controller or in a gateway) exposing the Robotics and Machinery models, aggregated by a plant-level server that fans data out to MES, condition monitoring, asset management and digital twin services under a single certificate and role policy.

Figure 4: Reference integration. The robot-side server exposes the model; a plant aggregation layer shields consumers from controller diversity and enforces security policy.

Embedded server versus gateway

Where the OPC UA server lives is the first decision. An embedded server in the robot controller exposes native state with the least latency and the least translation, but you inherit the vendor’s server quality, update cadence and licensing. A gateway server (on an industrial PC or edge device) reads the vendor’s proprietary interface and maps it to the OPC 40010-1 model. The gateway gives you control over the mapping, and it lets you cover older robots that will never get a firmware update. It adds a component to maintain, and the mapping is only as good as the information the legacy interface exposes.

The specification’s own optional elements hint at what a gateway struggles with. Controller cabinet variables such as CabinetFanSpeed, CPUFanSpeed and InputVoltage exist only if the vendor interface reveals them. A gateway may fill the mandatory nodes truthfully and leave the optional health data empty, which is acceptable under the model but disappointing for analytics.

Aggregation, namespaces and the Machinery companion

At plant level, an aggregation server (or an OPC UA client library with a unified browse layer) presents many robot servers as one address space. The model helps: because every compliant robot starts at MotionDeviceSystemType under DeviceSet, a consumer can find robots by type rather than by site-specific path. Combine this with the Machinery companion specification (OPC 40001-1) for machine identification and generic components, using the Robotics types for robot-specific detail. The 1.02 release’s “Robotics and Machinery Identification” profile exists to make that composition certifiable.

The downstream consumers map directly to the four use cases. MES and supervision use state and operational mode. Condition monitoring subscribes to axis, motor and cabinet variables. Asset management reads identification properties on devices, axes, power trains and parts. A digital twin service consumes the same structure as its physical-asset binding; because the model gives stable object identity and typed relationships (Controls, HasSafetyStates), the twin’s graph can be generated from the address space instead of hand-built. For historical analytics on top of that stream, see our reference on ingesting OPC UA time series from historians into digital twins.

Security is not optional

A model that can start and stop robots is a safety-adjacent attack surface even though the safety state itself is informational. Use signed and encrypted sessions, a trust list managed by a Global Discovery Server where available, and role-based permissions that separate read-only analytics clients from the rare client allowed to call Start. Our guide to OPC UA certificates, security policies and GDS trust lists covers the mechanics. In the Robotics model the method-level permission is the critical one: the Resource unavailable result (Bad_ResourceUnavailable, used when a method is locked by another client) and Bad_UserAccessDenied appear among the documented result codes precisely because multi-client control needs arbitration.

Where ROS 2 and robotics middleware fit

Researchers and service-robotics teams often ask whether OPC 40010-1 replaces ROS 2. It does not. ROS 2 handles perception, planning and control inside the robot or fleet, over DDS with tuned quality-of-service. OPC 40010-1 is the northbound interface for plant IT. A reasonable pattern is a ROS 2 node that publishes state to an OPC UA server implementing the Robotics model, so that the same robot looks conventional to the MES. Our post on Isaac Sim 6.2 and the ROS 2 migration checklist is relevant if your digital twin is simulation-based and you need the simulated robot to expose the same OPC UA surface as the real one, which is a powerful way to test supervisory logic before commissioning.

Walk-Through: Browsing and Operating a Robotics Server

The following Python sketch uses the open-source asyncua library. It is illustrative, not validated against any specific vendor server. Namespace indexes vary per server, so the code resolves nodes by browse name and never hard-codes indexes. If you want the server-side basics first, our asyncua production tutorial covers building one.

import asyncio
from asyncua import Client

async def child_by_name(node, name):
    for c in await node.get_children():
        bn = await c.read_browse_name()
        if bn.Name == name:
            return c
    return None

async def main():
    async with Client("opc.tcp://robot-gw.example:4840") as client:
        objects = client.nodes.objects
        device_set = await child_by_name(objects, "DeviceSet")

        # Find every MotionDeviceSystem by type name, not by path
        for sys_node in await device_set.get_children():
            type_def = await sys_node.read_type_definition()
            td = await client.get_node(type_def).read_browse_name()
            if td.Name != "MotionDeviceSystemType":
                continue

            motion_devices = await child_by_name(sys_node, "MotionDevices")
            controllers = await child_by_name(sys_node, "Controllers")
            safety = await child_by_name(sys_node, "SafetyStates")

            for md in await motion_devices.get_children():
                cat = await child_by_name(md, "MotionDeviceCategory")
                print("device", (await md.read_browse_name()).Name,
                      "category", await cat.read_value())

            for ss in await safety.get_children():
                params = await child_by_name(ss, "ParameterSet")
                mode = await child_by_name(params, "OperationalMode")
                estop = await child_by_name(params, "EmergencyStop")
                print("mode", await mode.read_value(),
                      "estop", await estop.read_value())

asyncio.run(main())

Three practical notes on this code. It reads the safety state only to log it, consistent with the informational status of SafetyStateType. It finds systems by type definition, which is robust against vendors who name the instance differently. And it handles an optional-element reality: child_by_name returns None for absent nodes, so production code must treat everything not marked mandatory as possibly missing.

Calling methods safely

Driving SystemOperation from a client follows the sequence in Figure 2. In asyncua you obtain the method node by browse name and call it on its parent object, for example calling GetReady and then waiting for the state variable to read Ready rather than assuming the call’s return implies the transition. A robust client does the following in order:

Subscribe to the SystemOperation state machine’s current state and to TransitionEventType events.
Check the operational mode. If it is not AUTOMATIC_EXTERNAL (4), a remote start is probably not meant to succeed; do not retry in a loop.
Call GetReady; wait for Ready, with a timeout derived from the vendor’s documented preparation time.
Load the program with LoadByName on the relevant task control; wait for Ready on that task control.
Call Start on the SystemOperation (or on the task control, depending on your cell design) and handle E_ActiveAlarm and E_AcknowledgeRequired as business outcomes, not as exceptions.
On shutdown, use Stop with a StopMode taken from PossibleStopModes, never a hard-coded number.

A mapping example: legacy controller to the model

Suppose a legacy controller exposes joint angles over a proprietary TCP protocol and a handful of status bits. The mapping is straightforward in principle. Each joint becomes an AxisType instance with ActualPosition (and EURange set from the machine’s joint limits). The robot becomes one MotionDeviceType with MotionDeviceCategory set to ARTICULATED_ROBOT (1). The controller becomes one ControllerType with the identification properties filled from the vendor’s data sheet. A status bit meaning “program running” maps to the task-control Executing state. The emergency stop input maps to EmergencyStop in a SafetyStateType. This illustrative mapping shows why the mandatory set is deliberately small: most controllers can fill it, while the optional elements are where the quality differences live.

Worked example: sizing the subscription load

Consider an illustrative cell with 12 robots, each exposing 6 axes with ActualPosition, ActualSpeed and one motor temperature per axis, plus 8 controller variables. That is 12 x (6 x 3 + 8) = 312 monitored items. At a 1 second sampling interval and an assumed payload of roughly 40 bytes per change including overhead (an assumption, not a measurement), worst case is about 12 KB per second of notification traffic before encryption overhead. That is trivial for a modern network. The real cost is not bandwidth but meaning: position at 1 Hz is useless for control and marginal for analytics. Decide per variable which ones are condition-monitoring candidates (temperature, energy, power-on time, which change slowly and sample cheaply) and which belong to a high-rate edge pipeline. The model does not make that decision for you.

Trade-offs, Gotchas, and What Goes Wrong

The biggest risk with OPC 40010-1 is expecting more than it promises. It standardises how a robot is described and how its program lifecycle is observed and driven. It does not standardise motion commands, tool interfaces or safety functions. Projects fail when the requirement document says “OPC UA robot interface” and the architect assumes this specification delivers a vendor-neutral motion API.

Optional means optional. Mandatory nodes are few by design. A server can be compliant and still omit axis speed, acceleration, OnPath, InControl and the cabinet health parameters. Compare servers by the populated nodes, and put the expected optional variables into the acceptance test.

Version drift. Version 1.00 is deprecated; 1.02 corrected figures and inheritance, removed IsConnectedTo references for MotorType and GearType, added a profile for Robotics and Machinery Identification, and added remote-operation capabilities through add-ins and state machines. A server built against 1.00 and a client built against 1.02 can disagree on references and on whether remote operation exists. Check the namespace publication date and the nodeset version in the server’s NamespaceArray and model metadata.

Asynchronous transitions. Because a method-triggered transition can be delayed until internal conditions hold, naive clients that call Start and immediately read the state will see Ready and conclude failure. Equally, assuming that GetReady completes within a fixed time is a bug waiting for a cold-start day. Design for events and timeouts.

Multi-client arbitration. The result code Bad_ResourceUnavailable indicates a method locked by another client. If both an MES and a maintenance tool can call Stop, you need an operational policy about who may, and a security role design that enforces it. The protocol will tell you a conflict occurred; it will not resolve it.

Safety misuse. Never use EmergencyStop or ProtectiveStop values as inputs to a safety interlock. The specification states the type is not for functional safety (IEC 61508). A network read has no guaranteed latency, no diagnostic coverage and no integrity level. Use it for logging, alarms and analytics only.

Documentation errors. The specification text contains small inconsistencies that I found while reviewing it: a LoadProgram() reference where the defined methods are LoadByName and LoadByNodeId, a SafetyStatesType name in prose where the type table says SafetyStateType, and a CM Extended conformance unit name that is absent from the conformance unit table. None is fatal, but they argue for driving tests from the machine-readable nodeset.

Performance and scale. An address space with hundreds of axes, parameters and add-ins can make initial browse slow on a constrained embedded server. Prefer targeted reads and subscription sets over recursive browse, cache the node structure after first discovery, and avoid polling slow-changing identification data.

Vendor reality. Even with a published standard, vendors implement as little as marketing requires. Several large robot vendors support OPC UA in some form; I have not verified which of them implement which profile of OPC 40010-1 in current products, so do not infer vendor support from the existence of the specification. Request the vendor’s conformance statement for the exact controller and firmware you will buy.

Digital twin overreach. Because the model gives you structure, it is tempting to build a full physics twin from it. The model has no kinematic parameters, no inertia data, no link geometry (a LoadType describes mass payload on a flange or axis, not a robot model). For simulation you still need URDF, SDF or OpenUSD descriptions; see our comparison of robot description formats. Use OPC 40010-1 for the operational binding between the twin and the real asset, and a physics description for behaviour.

Practical Recommendations

Start from the use case. If you need supervision and asset visibility across mixed vendors, the Base and AM Extended facets are enough, and you can get value quickly with read-only access. If you need condition monitoring, require the CM Extended facet and confirm the specific health variables you need. If you need remote operation, require the MDS Operation facet and test the state machine behaviour on the real controller, including failure paths.

Treat the nodeset as the contract. Download the machine-readable model for the exact version, generate your client types from it, and write acceptance tests against it. Use the open reference at reference.opcfoundation.org for human-readable lookups of types and conformance units, and keep your own record of the discrepancies you find.

Separate the layers explicitly in your architecture: OPC 40010-1 for vertical integration, Machinery for generic identification and composition, a safety system for functional safety, and a skill layer (if you build one) as your own documented extension. Do not call the combination “standard skills”.

A short adoption checklist:

Name the target version (1.02 at the time of writing) and the profiles required, per use case.
Ask each vendor for a conformance statement and a sample nodeset export from the exact firmware.
Decide embedded server versus gateway per robot family, and budget gateway mapping effort for legacy units.
Put authentication, signed and encrypted sessions, and role separation in place before enabling any method calls.
Subscribe to state and transition events; never poll for state after a method call.
Keep safety states read-only and out of any interlock path.
Define sampling intervals by variable class, with slow health data on subscription and fast data on an edge pipeline.
Test failure paths: failed load, active alarm, acknowledgement required, locked method, server restart.
Pair the model with a separate geometry and kinematics description if you build a simulation twin.

Frequently Asked Questions

What is the OPC UA robotics companion specification?

It is OPC 40010-1, “Robotics – Vertical Integration”, a companion specification developed with the VDMA that defines a vendor-neutral OPC UA information model for robot systems. It models motion devices, axes, power trains, controllers, task controls and safety states, plus state machines for remote operation. The current release is 1.02, dated 2025-09-09. Its aim is to present robot data uniformly regardless of manufacturer for supervision, condition monitoring, asset management and remote operation.

Is OPC 40010 the same as VDMA 40010?

They are the same lineage. The VDMA and the OPC Foundation announced the robotics companion specification at automatica in June 2018 as VDMA Specification 40010, and it is now published by the OPC Foundation as OPC 40010-1. Version 1.00 (2019-05-13) is deprecated; 1.02 is current. When a vendor says “VDMA robotics OPC UA”, ask which version and which profiles they implement, because the content changed between releases.

Does OPC UA for robotics define robot skills or motion commands?

Not in Part 1 as I reviewed it. The specification covers state, identification, condition and a program lifecycle: you can load, start and stop programs through the task control state machine and operate the controller through SystemOperation. It has no joint-move, pose or tool commands. Skill-style capability models exist in research and in vendor designs, but they are separate layers built on top, so interoperability for skills is not guaranteed by OPC 40010-1.

Can I use the SafetyState information for functional safety?

No. The specification states that SafetyStateType is not intended for functional safety applications or IEC 61508. It exposes the operational mode, emergency stop status and protective stop status for monitoring, logging and analytics. A network read has no guaranteed latency or integrity level. Safety functions must be implemented in a certified safety system, with OPC UA used only to observe their state.

How does OPC 40010-1 relate to OPC UA Machinery and DI?

It builds on DI (OPC 10000-100): most robotics types are subtypes of DI’s ComponentType, and the entry object sits in the server’s DeviceSet. It is designed to be used with OPC 40001-1, the Machinery companion specification, which supplies generic machine identification and composition; the specification even recommends the Machinery Components folder over the controller’s own. Release 1.02 added a profile for Robotics and Machinery Identification to support this combination.

Does OPC UA replace ROS 2 for robot integration?

No. They operate at different layers. ROS 2 and DDS handle perception, planning and control with tuned real-time quality of service inside a robot or fleet. OPC 40010-1 is a northbound plant-integration interface for MES, analytics and asset management. A common pattern is to run ROS 2 inside the robot and expose a Robotics-model OPC UA server at the boundary so enterprise systems see a standardised view.