OPC UA Companion Specifications for Robotics and Machinery: Interoperability in Practice

Connecting a machine to a plant network used to mean writing a custom driver for every vendor. OPC UA fixed the transport and security problem, but a bare OPC UA server still hands you a tree of nodes whose names, units and meaning are whatever the vendor chose. Two robots, both “speaking OPC UA”, can expose their joint positions under completely different browse paths. OPC UA companion specifications close that gap by standardising the information model itself: the object types, variables, states, methods and events that a given class of machine must expose.

This matters now because fleets are heterogeneous. A brownfield cell mixes CNC machines, robots, vision systems and injection moulding presses from a dozen suppliers, and the integration bill is dominated by semantics, not wires. This post explains how the companion spec stack is layered, what OPC 40001 Machinery, OPC 40010 Robotics, Machine Vision and the umati machine-tool model each define, and how to consume them with real tooling. You will leave with a mental model, a nodeset example, a conformance checklist and a list of failure modes to plan for.

What this covers: the layered model (OPC UA base, Device Integration, Machinery, domain specs), the main robotics and machinery specs, a worked nodeset and client walk-through, conformance and testing, and the trade-offs that bite in production.

Context and Background

OPC UA (IEC 62541) is a platform-independent service-oriented architecture with a built-in information modelling meta-model. Everything in the address space is a node belonging to a node class, and nodes are typed by reusable ObjectType and VariableType definitions. The base specification deliberately says nothing about what a robot or a lathe is. That is the job of companion specifications: domain-specific information models written jointly by the OPC Foundation and an industry body, then published as numbered documents such as OPC 40001 or OPC 40010.

The pattern emerged from the mechanical-engineering sector, where associations such as VDMA (the German mechanical engineering federation) and VDW (the German machine tool builders’ association) organised their members into joint working groups with the OPC Foundation. The OPC Foundation’s robotics page records that the first release of the robotics companion specification was published at the automatica trade show in Munich in June 2018, with Part 1 describing a motion device system focused on condition monitoring and later parts meant to extend it. That origin explains the character of the stack: it is vertical-integration oriented, built for reading state from machines into MES, SCADA, analytics and cloud systems rather than for real-time control loops.

For machine tools the equivalent effort is umati, the universal machine tool interface. According to the OPC Foundation, VDW and the Foundation set up a joint working group; the preliminary project group included 17 organisations, among them major machine tool builders and CNC control manufacturers. The group’s stated aim was standardising over 100 parameters across more than 20 use cases, covering production status, machine identification, job tracking, alerts, tool management and OEE analysis. At the AMB 2018 fair a proof of concept connected several machines through the draft model, with the OPC Foundation reporting 8 to 16 hours of configuration per implementation.

If you have not yet compared the semantic layers available for factory data, our analysis of AAS, DTDL and OPC UA information models sets out where companion specs sit next to the Asset Administration Shell and Digital Twins Definition Language. The short version: companion specs are the runtime, on-the-wire flavour of semantics, and they are the only one of the three that a machine controller can serve natively. The authoritative source for the framework is the OPC Foundation specification reference, which hosts browsable HTML for each companion spec and links the nodeset files.

Why transport standards alone were never enough

Consider what a protocol comparison tells you. In our write-up of DDS, MQTT and OPC UA for industrial messaging the point is that all three move bytes reliably. None of them tells a consumer that ns=2;s=Axis1.ActPos is a rotational joint angle in degrees. A consumer of an unmodelled server must be pre-programmed with a mapping per vendor, and the cost scales as vendors times consumers. A shared model turns the problem into vendors plus consumers: each vendor implements the model once, each consumer codes against it once.

The numbered-spec convention

Companion specs carry an OPC number. The ones relevant here, with the versions the OPC Foundation reference site showed when we checked this week:

Spec	Title (short)	Version seen	Notes
OPC 40001-1	Machinery, Part 1: Basic building blocks	1.04.1	Listed as published 2026-01-01; namespace http://opcfoundation.org/UA/Machinery/
OPC 40010-1	Robotics, Part 1: Vertical integration	1.02	Listed as published 2025-09-08; namespace http://opcfoundation.org/UA/Robotics/
OPC 40100-1	Machine Vision, Part 1: Control, configuration, recipe, result management	1.0	Listed as published 2019-08-01
OPC 40501-1	Machine Tools, Part 1: Machine monitoring and job management	1.02.0	The umati model; 16 main sections plus three annexes
OPC 40083	Plastics and rubber machinery, general type definitions	1.03	Reused by OPC 40077 for injection moulding MES integration

Treat the version column as a snapshot, not a pin. Versions move, and a given controller may implement an older minor release than the one on the website. Always read NamespaceVersion and NamespacePublicationDate from the server you are talking to rather than assuming.

The Layered Reference Architecture for OPC UA Companion Specifications

Companion specifications form a layered inheritance tree. At the bottom is the OPC UA base namespace (ns 0). Above it sits Device Integration (OPC 10000-100, “DI”), which defines DeviceType, ComponentType, identification and software-revision variables. Above that sits Machinery (OPC 40001-1), which generalises the notion of a machine and provides a single discovery point. Domain specs such as Robotics, Machine Tools and Machine Vision sit on top and subtype or reuse those building blocks.

Figure 1: The OPC UA companion specifications stack. Each layer subtypes or references the layer below, so a generic client that understands Machinery can already find and identify any machine.

The diagram shows why a generic tool can work at all: a client that only knows DI and Machinery can enumerate the machines on a server and read their identification, even if it has never heard of the robotics spec. Domain-specific consumers then descend into the specialised subtrees.

Layer 1: Information model meta-model and DI

The first design decision is reuse by subtyping. A companion spec defines ObjectTypes; a vendor server instantiates them and may add vendor-specific extensions. Because OPC UA supports subtyping with HasSubtype references, a vendor can derive MyRobotType from the spec’s MotionDeviceType and add proprietary children without breaking a client that browses for the base type. This is the mechanism that lets standard and proprietary data coexist, and the reason the spec can say “mandatory” for a handful of nodes while vendors still differentiate.

The DI layer matters because it provides the identification vocabulary: manufacturer, model, serial number, hardware and software revision. Machinery builds its identification aspect on the same ideas, so asset registries can harvest basic inventory from any compliant machine in one pass.

Layer 2: Machinery as the common entry point

OPC 40001-1 is, in the framing of the OPC Foundation, a set of basic building blocks used by other machinery-sector specs. From our reading of earlier releases of the spec, its main contributions are: an entry point object (conventionally called Machines) under the server’s Objects folder where every machine instance is registered; an identification object type for per-machine inventory data; a way to list components in a machine; and two small state machines, one for the item state (such as executing, not executing, out of service, not available) and one for the operation mode (such as processing, setup, maintenance). We did not re-verify these object names against the 1.04.1 text for this post, because the reference site pages we could fetch exposed only the landing page; check names against the nodeset before coding against them.

The entry point idea is simple but powerful. A discovery tool connects, browses Objects/Machines, and finds every machine without knowing vendor paths. This is the generic hook that makes fleet-level dashboards possible.

Layer 3: Domain specifications

Domain specs define what is special about their machine class. Robotics (OPC 40010-1) covers, according to the reference page, the motion device system, motion devices, controllers, axes, power trains and safety state, plus task control. Machine Vision (OPC 40100-1) addresses four operational areas: system control, configuration management, recipe management and result management. Machine Tools (OPC 40501-1) provides monitoring and job overview, and enables exchange between machine tools and enterprise systems such as MES, SCADA, ERP and analytics platforms.

An important structural point: these domain specs are not competing. A robot-tended machine tool cell may legitimately expose an OPC 40501 machine tool, an OPC 40010 motion device system and an OPC 40100 vision system on one server or across three. Each registers under Machinery’s entry point so a generic client sees one coherent list.

Layer 4: Profiles, conformance units and nodesets

Every companion spec ships with a nodeset (an XML file in the UANodeSet schema) and a list of profiles made of conformance units. The nodeset is the machine-readable model; the profile list tells a vendor which behaviours a server must implement to claim a facet such as “Machinery Basic Server”. The OPC Foundation maintains the nodesets in the public OPCFoundation/UA-Nodeset GitHub repository, which contains folders for Machinery, Robotics, MachineTool, DI and roughly eighty other domains. This repository is where you get the files you feed to code generators and test tools.

Remember the architecture implication: the nodeset is the contract. Documentation prose can be ambiguous; the XML is not. If a vendor’s server and the published nodeset disagree, the nodeset is the arbiter for interoperability and conformance.

Deeper Analysis: Walking Through Robotics, Machine Tools, Vision and Moulding

The best way to understand a companion spec is to follow data from a machine to a consumer. This section walks through the Robotics model structurally, contrasts it with the machine tool model, then shows a nodeset fragment and a client read.

Inside OPC 40010: the motion device system

The Robotics specification models a robot as a MotionDeviceSystem. This top-level object aggregates the pieces that make up a robot installation: one or more motion devices (the manipulators), one or more controllers, and, where relevant, safety state information. According to the OPC Foundation reference page, the specification covers motion device systems, motion devices, controllers, axes, power trains and safety state, with task control as an additional functional area.

The hierarchy answers a practical question that raw vendor models do not: which axis belongs to which arm, and which controller drives it? A six-axis arm is a MotionDevice that organises six Axis objects. The model also carries power train objects (motor, gear) next to the axes, so that condition-monitoring tools can correlate a rising motor temperature with the correct gearbox. Exact reference types between axes and power trains should be checked in the nodeset. Structure like this is what turns a flat list of tags into a model that analytics can reason over.

Part 1 is explicitly about vertical integration: it exposes the state of the robot to higher-level systems. It does not define how to command trajectories. If you came looking for a standard way to stream joint setpoints at 1 kHz, this is the wrong layer. Real-time motion control belongs to fieldbus and fast-cycle mechanisms; OPC UA’s PubSub extension and Time-Sensitive Networking address cyclic traffic, but the Robotics Part 1 information model is a status and configuration contract. We flag that distinction because it is the single most common misunderstanding in robotics procurement conversations.

For a deployment that embodies the problem, consider the fleet-scale operating models we examined in Agility Robotics Digit and robots-as-a-service deployment. A RaaS operator wants uniform uptime, fault and utilisation signals across robot makes. Industrial arm vendors can give them that through OPC 40010; humanoid and mobile platforms mostly cannot yet, because those domains have no equivalent companion spec in the set we verified. That asymmetry is a real adoption gap, and we say so plainly rather than imply a standard exists.

Machine tools and umati

The machine tool model is richer in the job dimension. OPC 40501-1 is titled “Machine Monitoring and Job Management”. Its scope statement says it aims to create a common interface among machine tools of different technologies, manufacturers and model series, covering monitoring and a job overview. Per the reference page the document has 16 main sections and three annexes, covering object types, event types, data types, conformance profiles, implementation guidance and KPI calculation frameworks.

umati is the community and brand around that model. It is not a different protocol: it is OPC UA with the machine tool companion spec, a sample-server ecosystem and a joint push by VDW and the OPC Foundation to get controller vendors to ship it. The OPC Foundation lists major CNC control manufacturers among the participants, and the Control Engineering coverage from 2019 names B&R, Mitsubishi Electric, Beckhoff, Bosch Rexroth, Fanuc, Heidenhain and Siemens. Whether any particular controller or machine you buy ships it today is a procurement question you must check per model and per option package; do not assume.

What does the model give you operationally? Production status in a normalised form, machine identification, the active and queued jobs, alerts and error reporting, and counters useful for resource consumption and OEE. The OEE point deserves care. The spec supplies the inputs and a calculation framework; whether your plant’s OEE number matches the vendor’s depends on how planned downtime, setup and micro-stops are categorised. Agree the definitions before you compare machines.

Machine vision and plastics machinery

Machine Vision (OPC 40100-1) is a good illustration of a domain where the model is about workflow rather than hardware. Its four areas are system control, configuration management, recipe management and result management. A vision system exposes methods to select and prepare a recipe, trigger or run it, and return results with metadata that identifies the part and the evaluation, so a PLC or MES can orchestrate cameras from different suppliers the same way. The 2018 launch reporting from the Vision Systems trade press ties the machine vision and robotics specifications together as joint VDMA-OPC Foundation efforts introduced at automatica.

For injection moulding, the plastics and rubber machinery general type definitions (OPC 40083, version 1.03 as listed) provide reusable types such as temperature zones and moulds, and the OPC Foundation page notes that these are leveraged by OPC 40077 for MES integration with injection moulding machines. The reference page adds an honest caveat that matters for every domain: not all machines support every type. A machine without a mould temperature zone simply will not instantiate that type, so a consumer must treat optional types as optional.

A short nodeset example

A nodeset is plain XML. The fragment below is a deliberately simplified illustration of how a vendor-specific robot type extends a companion spec type. The namespace URIs for the vendor model and the node ids are invented for the example, and the base type reference is written symbolically rather than as a real numeric id (look up the real i= value in the published Opc.Ua.Robotics.NodeSet2.xml).

<UANodeSet xmlns="http://opcfoundation.org/UA/2011/03/UANodeSet.xsd">
  <NamespaceUris>
    <Uri>http://example.com/UA/AcmeRobot/</Uri>
    <Uri>http://opcfoundation.org/UA/Robotics/</Uri>
  </NamespaceUris>
  <Aliases>
    <Alias Alias="HasSubtype">i=45</Alias>
    <Alias Alias="HasComponent">i=47</Alias>
    <Alias Alias="String">i=12</Alias>
  </Aliases>
  <!-- Vendor type derived from the spec's MotionDeviceType.
       2:MotionDeviceType_ID is a placeholder, not a real node id. -->
  <UAObjectType NodeId="ns=1;i=1001" BrowseName="1:AcmeSixAxisType">
    <DisplayName>AcmeSixAxisType</DisplayName>
    <References>
      <Reference ReferenceType="HasSubtype" IsForward="false">ns=2;i=MotionDeviceType_ID</Reference>
    </References>
  </UAObjectType>
  <UAVariable NodeId="ns=1;i=6001" BrowseName="1:ToolCalibrationDate"
              ParentNodeId="ns=1;i=1001" DataType="String">
    <DisplayName>ToolCalibrationDate</DisplayName>
    <References>
      <Reference ReferenceType="HasComponent" IsForward="false">ns=1;i=1001</Reference>
    </References>
  </UAVariable>
</UANodeSet>

Three details in that fragment generalise. First, the namespace table lists the spec’s URI so the importer can resolve ns=2; indices are local to each file and remapped at load time. Second, the vendor type points back at the spec type with an inverse HasSubtype, which is how a generic client recognises it as a motion device. Third, the vendor adds its own variable under its own namespace, so extensions never collide with spec-defined browse names.

Turning a nodeset into a running server

Open-source stacks make this practical. The open62541 C library includes a nodeset compiler that reads one or more NodeSet2.xml files and generates C code that instantiates the address space; the project documents importing companion specs by loading dependency nodesets (DI first, then Machinery, then the domain spec) before your own file. We attempted to fetch the 1.4 documentation page this run and got a 404, so we cannot quote exact flags; follow the nodeset compiler section of the version of the manual that matches your checkout. Eclipse Milo is the Java counterpart for client and server SDKs, and Python’s asyncua can load a nodeset at runtime for quick prototyping and tests.

The order matters because of dependency resolution. A domain nodeset refers to nodes in DI and Machinery by namespace URI; if you load them out of order, the compiler or loader reports unresolved references. A robust build script treats the dependency chain as data: an ordered list of nodeset files pinned to commits from the UA-Nodeset repository.

Consuming the model from a client

On the consumer side, the interoperability dividend appears in the following pseudocode-level Python using the asyncua library. It resolves namespaces by URI (never by index), finds the Machines entry point, and reads identification from every machine it finds.

import asyncio
from asyncua import Client

MACHINERY = "http://opcfoundation.org/UA/Machinery/"
ROBOTICS = "http://opcfoundation.org/UA/Robotics/"

async def main():
    async with Client("opc.tcp://cell-07.example:4840") as c:
        ns_m = await c.get_namespace_index(MACHINERY)
        machines = await c.nodes.objects.get_child([f"{ns_m}:Machines"])
        for m in await machines.get_children():
            name = (await m.read_browse_name()).Name
            print("machine:", name)
        # Robotics types are resolved by URI, not by a hard-coded index.
        ns_r = await c.get_namespace_index(ROBOTICS)
        print("robotics namespace index on this server:", ns_r)

asyncio.run(main())

The code is illustrative and untested against a specific vendor; the browse path Machines is assumed from our reading of the Machinery spec and should be validated against the nodeset. The pattern, however, is the point: look up namespace indices at runtime by URI because every server assigns its own indices, and discover machines through a standard entry point instead of vendor paths.

A worked cost illustration

Here is an illustrative, clearly hypothetical calculation of why the model changes economics. Suppose a plant has 6 machine families from different suppliers and 4 consuming systems (MES, historian, maintenance, energy dashboard). Without a shared model you maintain 6 x 4 = 24 point-to-point mappings. With a companion spec for each family, you maintain 6 vendor implementations (done once, by the vendors) plus 4 consumer integrations: 10 artefacts, and adding a seventh machine family from a compliant vendor adds zero consumer work. If each mapping costs a nominal two engineer-weeks, the difference is 48 weeks versus roughly eight, before maintenance. The numbers are invented for illustration; the shape of the saving, multiplicative versus additive, is the real result.

Figure 2: The OPC 40010 Robotics model at a glance. The motion device system aggregates motion devices, controllers and safety state; axes and power trains support condition monitoring.

The Figure 2 diagram makes the containment structure explicit. Notice that the controller sits beside the motion device rather than under it; this reflects real installations where one controller can drive several manipulators, and it is a modelling choice that consumers must respect when joining data.

Conformance, Testing and Deployment Topology

Publishing a model is not the same as implementing it correctly. The gap between “we support the companion spec” and “our server passes the spec’s conformance units” is where integration projects lose weeks, so this section covers how to measure it.

Profiles, conformance units and the CTT

Each companion spec lists profiles, which bundle conformance units. A conformance unit is a testable statement, such as “the server exposes the Machines object and registers each machine in it”. Vendors claim facets (a server profile, for instance) and buyers can request them in tenders.

The OPC Foundation’s Compliance Test Tool (CTT) automates much of the testing. According to the Foundation’s page, the CTT can test OPC UA client and server products for compliance with the specification, runs in client and server modes and has a command-line interface for automation. The page lists separate test script packages for certain companion specs (it names weighing technology, MDIS, process automation devices and PLCopen IEC 61131-3 among them). We could not confirm from the page whether the Machinery, Robotics or Machine Tools specs have dedicated CTT script packages today, so verify that with the Foundation before writing it into a contract.

Two constraints are worth stating. The CTT is available exclusively to active OPC Foundation corporate members, and the license says the Foundation is the sole entity that may perform certification testing. In practice that means an integrator without membership cannot run the official tool; they can still validate a server with their own client scripts against the nodeset, but they cannot claim certification on that basis.

A pragmatic acceptance test you can run without the CTT

A lightweight acceptance suite covers most of the interoperability risk. Write it once and run it against every new machine at factory acceptance test.

1. Namespace check: read the namespace array and confirm the expected companion URIs are present, with the publication date and version you contracted.
2. Entry point: browse the Machinery entry point and confirm each machine instance is listed once.
3. Identification: read manufacturer, model and serial number; compare with nameplate data.
4. Type conformance: for each domain object, confirm it subtypes the expected spec type, and that mandatory children exist.
5. Data quality: check engineering units and ranges (a joint angle that changes unit between firmware versions will break analytics).
6. Events and states: force a state change (operation mode, alarm) and confirm the event or state variable changes within a stated latency.
7. Security: confirm SignAndEncrypt with application-instance certificates is enforced and anonymous access is off.

Step 7 is not optional. A companion spec describes data, not access control, so a perfectly modelled machine can still be reachable without authentication if the vendor ships a permissive default configuration.

Deployment topologies

There are three common topologies. In the first, the machine controller runs the OPC UA server itself, which is the simplest and the most faithful to the spec. In the second, an edge gateway reads a proprietary protocol and re-exposes it through the companion model. The gateway is a pragmatic bridge for legacy machines, but it moves conformance risk from the vendor to you: you now own the mapping, the units and the update cadence. In the third, a plant-level aggregation server collects several machine servers and exposes one namespace to enterprise systems, trading extra latency and a single point of failure for simpler consumer configuration.

Figure 3: Three ways to expose a companion model: native server on the controller, gateway for legacy equipment, and a plant aggregation layer feeding MES, historian and cloud.

For wide-area or cloud delivery, OPC UA PubSub over MQTT is a typical choice, and the information model travels with the data: the publisher’s DataSetMetaData describes fields so a subscriber can interpret them. Our industrial messaging comparison covers when to prefer brokered transport over client-server sessions. A condition-monitoring pipeline built on top of these models is described in our machinery health architecture piece, where the standard model is what makes cross-vendor feature extraction reusable.

Session flow for a model-aware client

The sequence below shows how a generic client establishes trust, resolves the model and subscribes, which is the minimum set of steps every consumer repeats.

Figure 4: Client discovery sequence. The client resolves namespaces by URI, finds machines via the Machinery entry point, reads identification, then subscribes to domain nodes.

The key design point in Figure 4 is the order of operations. Namespace resolution comes first because every subsequent NodeId depends on indices that are valid only for that session. Subscribing before resolution would hard-code indices, which breaks the moment a vendor reorders its namespace table in a firmware update.

Trade-offs, Gotchas, and What Goes Wrong

Companion specifications reduce integration cost but are not a free lunch. The failures below are the ones we would plan for.

Optional is the default. Most nodes in a companion model are optional, and the spec says as much for entire types in the plastics model. A server can be compliant while omitting the variable you need. Consumers must treat missing nodes as normal, and tenders must name the specific optional items required rather than say “compliant with OPC 40010”.

Version skew. The specs evolve (the Machinery page we read showed 1.04.1, while robotics Part 1 showed 1.02). A controller may implement an older minor version; a consumer written against a newer nodeset may rely on nodes that do not exist. Pin nodesets, read NamespaceVersion at connect time and keep a compatibility matrix in the repository.

Semantics are only as good as the vendor mapping. Having the right browse name does not guarantee the right value. Vendors map internal variables onto the standard model, and mistakes in units, sign conventions or coordinate frames happen. This is why the acceptance test above checks values against a known physical state, not only structure.

Scope mismatch. Robotics Part 1 is vertical integration. Teams that expect it to carry real-time motion control, or to cover mobile robots and humanoids, will be disappointed. For gaps, you may need a vendor-specific extension or a separate standard, and extension work should follow the subtyping pattern shown earlier so you do not fork the model.

Performance. A nested model with thousands of nodes per machine, polled by many clients, can overload a controller’s embedded server. Use subscriptions with sensible sampling and publishing intervals, set deadbands, and limit browse depth. Budgets are controller-specific and we have no vendor-neutral number to quote, so measure on the target hardware.

Governance and licensing. Specification documents and nodesets are subject to OPC Foundation licence terms, and CTT access depends on membership. Budget for membership if you intend to certify products.

Anti-pattern: the mirrored proprietary tree. Some gateways expose the vendor’s proprietary tree and add a thin companion-spec “veneer” with a few nodes. Consumers then still need vendor knowledge for anything beyond identification. Judge a model by how much of your use case it covers without side channels.

Practical Recommendations

Treat companion specifications as a procurement and architecture lever, not only a developer feature. Start by defining the use cases you need (for example monitoring, job tracking, condition data) and map each to the spec parts that cover it. Then write those requirements into purchase specifications by naming the spec, the minimum version and the exact optional items, and ask for a nodeset export from the actual machine.

On the engineering side, standardise on one client library and one nodeset-management practice, and build the acceptance suite once. For legacy equipment, prefer a gateway you control and test it like a product. For new machines, ask suppliers for their roadmap on Machinery, Robotics, Machine Tools or Vision and treat “supported on request” differently from “shipping on current firmware”.

A short checklist:

• Pin nodesets to commits from the UA-Nodeset repository and record the version per machine.
• Resolve namespaces by URI at runtime; never hard-code indices.
• Name required optional nodes in the contract.
• Run the seven-step acceptance test at factory acceptance.
• Enforce encrypted, authenticated sessions; disable anonymous access.
• Measure controller load under realistic subscription counts.
• Keep vendor extensions in subtypes with their own namespace.
• Confirm certification status with the OPC Foundation, not from marketing material.

Frequently Asked Questions

What are OPC UA companion specifications?

They are domain-specific information models built on the OPC UA meta-model, published jointly by the OPC Foundation and an industry body. Each defines standard object types, variables, methods, events and a nodeset XML file, so machines of one class (robots, machine tools, vision systems) expose the same structure and meaning regardless of vendor. They add semantics on top of OPC UA’s transport and security, and they are published under numbers such as OPC 40001 or OPC 40010.

What is OPC 40010 and what does it cover?

OPC 40010 is the OPC UA for Robotics specification. Part 1, titled Vertical Integration, was listed at version 1.02 (published 8 September 2025) on the Foundation’s reference site. It models motion device systems, motion devices, controllers, axes, power trains and safety state, plus task control. It targets status and configuration exchange with higher-level systems, not real-time trajectory control.

What is the difference between umati and OPC UA Machinery?

OPC 40001 Machinery provides generic building blocks, such as machine identification and a common entry point, that many machinery-sector specs reuse. umati is the initiative, started by VDW and the OPC Foundation, around the machine tool companion specification OPC 40501-1, which focuses on monitoring and job management for machine tools. In practice umati machines build on Machinery concepts, adding machine-tool-specific content.

Do I need the OPC Compliance Test Tool to use a companion specification?

No. You can implement and consume a companion spec with open-source stacks such as open62541, Eclipse Milo or asyncua, and validate against the published nodeset with your own scripts. The Compliance Test Tool is restricted to OPC Foundation corporate members, and only the Foundation can perform official certification, so you need membership and certification if you want to claim formal compliance.

Can a legacy machine support these specs without replacing the controller?

Often yes, through an edge gateway that reads the machine’s existing protocol and exposes the companion model. The trade-off is that you own the mapping and its correctness, including units and update rates, and the gateway becomes part of your support surface. Test it with the same acceptance suite you would apply to a native server, and document which optional nodes it implements.

Do companion specs replace MQTT or the Asset Administration Shell?

No. Companion specs define machine-side semantics served by OPC UA. MQTT is a transport that can carry OPC UA PubSub messages, and the Asset Administration Shell is a digital-twin metamodel that can reference or map to OPC UA data. Many architectures combine them: a companion model at the machine, PubSub or MQTT for distribution, and an AAS at the enterprise layer.

Further Reading

• AAS vs DTDL vs OPC UA information models: how the main semantic layers compare.
• DDS vs MQTT vs OPC UA for industrial messaging: choosing transports for companion-model data.
• Condition monitoring and machinery health architecture: using standard models in analytics pipelines.
• Agility Robotics Digit RaaS deployment analysis: fleet operations where uniform robot data matters.
• OPC Foundation specification reference: browsable companion specs and nodesets.
• OPCFoundation/UA-Nodeset on GitHub: the published nodeset XML files.
• umati at the OPC Foundation: background on the universal machine tool interface.

By Riju — about