umati vs MTConnect vs OPC UA for Machine Tools (2026)

Ask five shop-floor integrators how they get spindle load out of a CNC and you will get five answers: a vendor DLL, a polled PLC tag, an MTConnect agent, a bespoke OPC UA server, and a screenshot-scraping script nobody admits to. The machine is the same; the interface is different every time, and every difference is a week of integration work that does not survive the next controller upgrade. This is the problem that umati machine tools interfaces were created to remove.

The confusion in 2026 is that umati is not a protocol competing with OPC UA, and it is not a rival to MTConnect in the way most comparison posts imply. It is a community and a set of profiles built on OPC UA, with a machine tool information model at the centre. This post separates the three layers people keep conflating: transport, information model, and adoption programme. You will leave with a precise picture of what each option models, who can write to the machine, how the pieces bridge, and a decision path for greenfield and brownfield fleets.

What this covers: the umati initiative and the Machine Tools companion specification, how MTConnect differs at the semantic and architectural level, proprietary interfaces, the object model in detail, a working bridge and client in Python, security and write semantics, failure modes, and a selection matrix.

Context and Background

Machine tools are an unusual corner of industrial automation. A single plant may run controllers from Siemens, Fanuc, Heidenhain, Mitsubishi and Mazak, each exposing data through its own API, each with a different vocabulary for the same physical thing. “Spindle override”, “feed rate override” and “program state” mean broadly the same across vendors, but the node names, data types, units and update semantics rarely match. Historically the integrator absorbed that cost, one vendor at a time.

Two open efforts attacked this. MTConnect, an open standard maintained by the MTConnect Institute, began as a read-only semantic vocabulary for machine data delivered over HTTP. Version 2.0, released in June 2022, moved the standard to a model-based form (a SysML model in an XMI file), added discrete-manufacturing semantics such as parts and processes, and shipped a rewritten reference agent with TLS support (American Machinist coverage of MTConnect 2.0). The standard has continued to advance since; the Institute’s documentation site hosts parts of release 2.5.0, though I did not verify whether a later release is current as you read this.

The second effort is umati, short for universal machine tool interface. It is a global connectivity initiative led by VDW (the German Machine Tool Builders’ Association) together with VDMA, and it is built on OPC UA. In its 2025 EMO Hannover communication, VDW described a community of more than 400 partners, roughly 25 published companion specifications for mechanical engineering and about 30 more in development (VDW: umati at EMO Hannover 2025). Those are the initiative’s own figures and are marketing-adjacent, so treat them as indicators of momentum rather than audited adoption.

The technical anchor is OPC 40501-1, “Machine Tools – Monitoring and Job Management”. The OPC Foundation reference site lists the current release as 1.02.0, dated 2024-09-14 (OPC 40501-1 reference). Its object model is organised around a MachineToolType with identification, monitoring, production and equipment parts, which we unpack below.

If you want the head-to-head on the two data standards without the umati lens, we already compared them in MTConnect vs OPC UA for machine tool data. This post takes a different cut: it centres umati and asks what changes when OPC UA arrives with a machine-tool-specific, vendor-agreed information model rather than as a blank toolkit. For the transport side of OPC UA, see our write-up on OPC UA PubSub over MQTT vs UADP, which matters once you scale beyond a handful of client sessions.

One framing carries through the rest of the article. There are three independent questions: how do bytes move (transport), what do the bytes mean (information model), and who is committed to implementing it (ecosystem). OPC UA answers the first and gives tools for the second. MTConnect answers the second and defines its own answer to the first. umati answers the third and curates the second on top of OPC UA. Comparing them as if they were peers on one axis is the root of most bad advice.

What umati Actually Is: Layers, Profiles and the Machine Tools Model

In short: umati is a VDW and VDMA initiative that standardises how machine tools expose data through OPC UA. It does this by agreeing a companion specification (OPC 40501-1 for machine tools), providing sample servers and clients, and running interoperability demonstrations, so a buyer can expect the same node structure from different vendors.

Figure 1: Where umati machine tools sit between the CNC controller and the consumers. Proprietary APIs, MTConnect agents and umati OPC UA servers all read the same control but expose it differently.

Figure 1 shows why the landscape is messy. The same controller can sit behind three interfaces simultaneously. A proprietary API such as Fanuc’s FOCAS library gives deep, vendor-specific access. An MTConnect adapter and agent give a read-only, vocabulary-driven HTTP view. An OPC UA server implementing the umati profile gives a typed, browsable, subscribable address space that also supports methods. Consumers on the right (MES, historians, digital twins) have to pick which of these they bind to, and that decision determines how much per-vendor code survives.

A companion specification is a contract, not a library

OPC UA itself is deliberately generic. It defines a service set (browse, read, write, subscribe, call), a security model, and a type system, but says nothing about what a spindle is. A companion specification adds that meaning: object types, variable types, references, and conformance units. An OPC UA client that knows the Machine Tools specification can browse any compliant server and find the same Monitoring and Production structures without a vendor manual. That is the practical meaning of “semantic interoperability” here.

OPC 40501-1 does not stand alone. It builds on the base OPC UA specification series and on the generic machinery companion work, which is why a machine tool server typically presents identification information in a form that other machinery companion specifications share. I could not confirm the exact normative reference list from the portions of the spec page that are publicly rendered, so check the Normative references section of OPC 40501-1 before you design an address space around assumptions.

What umati adds beyond the specification

A specification alone does not give you interoperability; implementations drift. umati’s contribution is the programme around the specification: a sample server so client developers have something to connect to, test tooling, and public demonstrations in which machines from several builders feed one shared dashboard. VDW’s EMO 2025 account describes a live demonstrator where machines and software from different partners fed the umati.app, with QR codes on equipment letting visitors view live data. That demonstration discipline is what separates a working ecosystem from a PDF.

It also builds bridges rather than demanding a clean slate. The same VDW account names umatiConnect, an open-source connector developed at IFW Leibniz University Hannover with Mazak and DMG Mori, which links MTConnect systems to OPC UA for Machine Tools. That detail matters for our later argument: in practice umati and MTConnect are being joined at the edge, not fought over.

The scope, honestly stated

The scope of OPC 40501-1 is monitoring and job overview. Its title says “Monitoring and Job Management”, and the public scope text frames it as the basics of such an interface. It is not a full remote-control or programming interface. It does not stream every axis servo signal at kilohertz rates, and it does not replace a CNC’s native diagnostics. Anyone who expects to replace a machine builder’s full API with the first release of a companion specification will be disappointed; anyone who wants a consistent, vendor-neutral view of machine state, active job and basic utilisation will not.

The Machine Tools Information Model in Detail

The reference site’s table of contents for the specification names the pieces precisely: MachineToolType (clause 8.1), Identification (8.2), Monitoring (8.3), Production (8.4) and Equipment (8.5), with ProductionJobType and ProductionJobListType appearing under Production. There is also a “MachineTool Job Management Server Facet” among the conformance profiles, which is how a server declares that it supports the job functions.

Figure 2: Simplified object model of the OPC UA Machine Tools companion specification. Names are abbreviated from the specification’s structure and are illustrative of its shape, not a complete type listing.

Figure 2 sketches the hierarchy. The diagram is deliberately simplified. Treat the leaf names as a reading aid and consult the reference site for the authoritative type definitions, since I have not reproduced every optional component.

Identification: who is this machine

The Identification branch holds the facts that never change on the shop floor day to day: manufacturer, model, serial number, location and software identification. The reference lists both MachineToolIdentificationType and SoftwareIdentificationType. For a digital twin this is the join key. If two servers expose the same serial number under the same type, a twin platform can create one asset with confidence instead of fuzzy-matching names. This is also where umati overlaps with the broader OPC UA machinery work, so identification code written once tends to be reusable across machine families.

Monitoring: what is it doing right now

Monitoring carries live state: operation mode, power-on and run durations, channel and spindle state, overrides, messages and signal-tower (stack light) state. The point is not that any single value is novel. A CNC has always known whether it is in automatic mode. The point is that the value lives at a predictable path with a predictable type and engineering unit, so a utilisation dashboard written against machine A works unchanged against machine B.

A useful mental test is the OEE question. Overall equipment effectiveness needs three machine-sourced facts: is the machine running a program, is it in a fault or stop state, and how many good parts did it make. Monitoring answers the first two uniformly; Production answers the third. If a vendor’s server cannot answer those, the umati label is not delivering on its purpose.

Production: what job is it running

Production is where the specification goes beyond a pure telemetry vocabulary. A job list holds jobs; each job carries a state, run counts and a reference to the program and part being produced. This is the part MTConnect historically handled less directly because MTConnect was framed around observation, though MTConnect 2.0 added parts and processes semantics. In OPC UA the job objects can also expose methods, so a scheduler can, subject to the server implementing the job management facet, push a job to the machine rather than wait for an operator.

That last sentence deserves caution. Whether a particular controller lets an external client create or start a job depends on the builder’s implementation and on the machine’s own safety and permission design. The specification enables the capability; it does not guarantee that a given machine grants it. Always confirm which facets a server declares before you plan a workflow around them.

Equipment: what is installed

Equipment holds the tool and spindle resources the machine currently has: tools in the magazine, their identifiers and wear-related data where the control provides it. In practice this is the branch with the largest gap between specification ambition and field implementation, because tool management data inside controls is often locked behind proprietary structures. Plan on testing this branch separately for each vendor rather than assuming parity.

Why a typed address space changes integration cost

A flat tag list from a historian forces the consumer to know that ns=2;s=Ch1.SpindleLoad means spindle load. A typed address space lets the consumer discover that a node is an instance of a spindle-related type and read its engineering unit from the node’s properties. Discovery by type is what removes per-vendor mapping tables. It also costs something: the address space is larger and subscription management must be thought through, which we return to in the trade-offs section.

Deeper Analysis: MTConnect, Proprietary APIs and the Bridge Between Them

How MTConnect actually works

MTConnect separates three roles. An adapter talks to the machine in whatever way the control allows and emits observations. An agent buffers those observations and serves them over HTTP as XML (and, since the 2.0 line, JSON options exist in the reference tooling). A client polls or streams from the agent. The agent exposes a small set of requests: probe returns the device model, current returns the latest value of every data item, sample returns a sequence range from the buffer, and asset returns documents such as tool or part definitions.

The semantic heart is the device model. Components (axes, controller, path, spindle) contain data items classified as samples (continuous numeric values), events (discrete state such as EXECUTION or CONTROLLER_MODE) and conditions (fault, warning, normal). Because the vocabulary is fixed and open, two agents from different machines return the same names for the same concepts. A circular buffer with monotonically increasing sequence numbers gives the client a cheap way to resume after a disconnect: ask for sample from the last sequence you saw. This pull-and-resume design is one of MTConnect’s quiet strengths and is why it works well on constrained networks.

The design is read-oriented by intent. The standard defines no general mechanism for a client to command the machine through the agent. That is a feature for plant security teams, since a compromised dashboard cannot start a spindle through MTConnect. It is a limitation if your use case is job dispatch.

Where OPC UA via umati differs structurally

OPC UA is session-oriented and push-capable. A client opens a secure channel, creates a session, then creates subscriptions with monitored items; the server sends data-change notifications only when values change beyond a deadband, at a sampling interval the client requests. The server can also expose methods, accept writes where authorised, publish events and alarms, and describe history. The information model is typed and extensible, and the security model includes certificate-based application authentication and message signing and encryption by policy.

Set side by side the difference is not “which one is better” but a different set of defaults:

Dimension	umati / OPC UA for Machine Tools	MTConnect	Proprietary API (for example FOCAS)
Stewardship	OPC Foundation spec with VDW and VDMA umati programme	MTConnect Institute	Single vendor
Transport	OPC UA binary over TCP, or HTTPS; PubSub also possible	HTTP request and response, XML or JSON	Vendor library or protocol
Interaction	Session, subscriptions, methods, events	Stateless polling or streaming of the buffer	Library calls
Write or command	Supported by the protocol, as exposed by the server	Not part of the design	Often yes, vendor-specific
Semantics	Typed object model from the companion spec	Fixed open vocabulary and device model	Vendor-defined
Security	Certificates, signing, encryption, user auth	TLS in modern agents, deployment-dependent	Vendor-defined, often network-perimeter
Retrofit on old machines	Needs a gateway for controls without a native server	Adapters exist for many controls, strong brownfield story	Only that vendor
Best at	Typed, cross-vendor integration with job and control paths	Fast, read-only fleet visibility	Deep access to one control

Two rows deserve emphasis. First, the retrofit row: MTConnect’s long head start means a large catalogue of adapters, and an OPC UA server for a twenty-year-old control often does not exist. Second, the write row: the choice between “read-only by design” and “write-capable by protocol” is a security and architecture decision, not a feature checkbox.

Proprietary interfaces are not the enemy

It is fashionable to treat vendor APIs as the thing both standards exist to defeat. In practice they remain the deepest source of data. Servo diagnostics, high-rate trace, PLC ladder access and controller parameters are generally reachable only through the builder’s own interface. A realistic architecture keeps the proprietary path for engineering and diagnostics and presents a standard view for everything operational. Standards win breadth; vendor APIs win depth.

Bridging: MTConnect into OPC UA, and the umatiConnect pattern

Two official routes exist for joining the worlds. In 2019 the OPC Foundation and the MTConnect Institute released the OPC UA Companion Specification for MTConnect, Part 1, which expresses the MTConnect device and stream information models in the OPC UA modelling language. The announcement lists benefits including data type enforcement, separation of model definition from implementation, and OPC UA end-to-end security (OPC Foundation press release). Note what that does and does not do. It exposes MTConnect’s own vocabulary as OPC UA nodes. It does not translate MTConnect into the umati Machine Tools model.

The second route is a mapping gateway that reads from an MTConnect agent and populates a umati-shaped address space. That is the umatiConnect idea reported by VDW, an open-source connector from IFW Hannover with Mazak and DMG Mori. The two routes serve different goals. Mirror MTConnect semantics in OPC UA if you want MTConnect-aware tools to keep working over OPC UA. Map into the Machine Tools model if you want OPC UA clients written for umati to work against legacy MTConnect-instrumented machines.

Figure 3: Bridge flow for brownfield machines. The gateway polls the MTConnect agent, maps data items to Machine Tools nodes, and the OPC UA side alone accepts subscriptions and method calls.

Figure 3 shows the control flow. Note the asymmetry in the note: because the agent is read-only, any write or method call terminates at the OPC UA server and never reaches the control. A bridged machine therefore gains umati’s shape but not umati’s authority. If a method such as job start must reach the control, you need a real control-side integration, not just a translation layer.

A concrete mapping table

The following mapping is a reasonable starting point, and it is illustrative: it is my working convention, not an official crosswalk, and you must verify each target against the specification’s node IDs before use.

MTConnect data item	Meaning	Machine Tools target concept
`AVAILABILITY`	Device reachable	Monitoring state, server health
`EXECUTION` (`ACTIVE`, `READY`, `INTERRUPTED`, `STOPPED`)	Program execution state	Channel or job state
`CONTROLLER_MODE`	Automatic, manual, MDI	Operation mode
`PROGRAM`	Active program name	Production program reference
`PART_COUNT`	Parts produced	Production job run count
`Sspeed`/`SpindleSpeed`	Spindle RPM	Spindle monitoring value
`Load` condition or sample	Spindle or axis load	Spindle monitoring value
`EMERGENCY_STOP`	E-stop state	Messages or stack light state

The mismatches teach the most. MTConnect’s EXECUTION has no one-to-one counterpart in a job-oriented model, because “the control is executing” differs from “the job is running”. A job can span several program executions, a restart after tool breakage, and idle gaps. A naive mapping that copies execution state into job state will report a job as finished every time a program ends mid-job.

Working Code: Read an MTConnect Agent, Publish a Typed OPC UA View, Read It Back

The code below is a compact, runnable pattern. It uses the requests and asyncua Python packages. It is a teaching sketch: the namespace and node names are my own, not the OPC 40501-1 identifiers, and it shows the mechanics of bridging rather than a conformant umati server. A conformant server should import the official NodeSet2 XML from the OPC Foundation and populate those types.

Step 1: poll an MTConnect agent

# mtc_poll.py
import requests
import xml.etree.ElementTree as ET

AGENT = "http://localhost:5000"   # an MTConnect agent, e.g. the open-source cppagent


def current(device: str = "") -> dict:
    """Return {dataItemId: value} from an MTConnect /current response."""
    url = f"{AGENT}/{device}/current" if device else f"{AGENT}/current"
    r = requests.get(url, timeout=5)
    r.raise_for_status()
    root = ET.fromstring(r.content)
    values = {}
    # Namespaces vary with the MTConnect version, so match on local names.
    for el in root.iter():
        tag = el.tag.split("}")[-1]
        di = el.attrib.get("dataItemId")
        if di and tag not in ("DeviceStream", "ComponentStream"):
            values[di] = (tag, (el.text or "").strip())
    return values


if __name__ == "__main__":
    for k, (tag, v) in sorted(current().items()):
        print(f"{k:24s} {tag:20s} {v}")

Step 2: expose a typed OPC UA address space

# umati_bridge.py
import asyncio
from asyncua import Server, ua
from mtc_poll import current

URI = "https://iotdigitaltwinplm.com/demo/machine-tool"

# illustrative mapping: MTConnect dataItemId -> (browse name, OPC UA type, default)
MAP = {
    "execution": ("ExecutionState", ua.VariantType.String, "UNAVAILABLE"),
    "mode":      ("OperationMode",  ua.VariantType.String, "UNAVAILABLE"),
    "program":   ("ProgramName",    ua.VariantType.String, ""),
    "pcount":    ("PartCount",      ua.VariantType.UInt32, 0),
    "Sspeed":    ("SpindleSpeed",   ua.VariantType.Double, 0.0),
}


async def main():
    server = Server()
    await server.init()
    server.set_endpoint("opc.tcp://0.0.0.0:4840/machinetool")
    server.set_security_policy([ua.SecurityPolicyType.NoSecurity])  # demo only
    idx = await server.register_namespace(URI)

    machine = await server.nodes.objects.add_object(idx, "MachineTool")
    ident = await machine.add_object(idx, "Identification")
    await ident.add_variable(idx, "Manufacturer", "DemoWorks")
    await ident.add_variable(idx, "SerialNumber", "DEMO-0001")
    mon = await machine.add_object(idx, "Monitoring")
    prod = await machine.add_object(idx, "Production")

    nodes = {}
    for di, (name, vtype, default) in MAP.items():
        parent = prod if name in ("ProgramName", "PartCount") else mon
        nodes[di] = await parent.add_variable(
            idx, name, ua.Variant(default, vtype))

    async with server:
        while True:
            try:
                data = current()
                for di, node in nodes.items():
                    if di in data:
                        _, raw = data[di]
                        vtype = MAP[di][1]
                        if raw in ("", "UNAVAILABLE"):
                            val = ua.Variant(MAP[di][2], vtype)
                        elif vtype == ua.VariantType.Double:
                            val = ua.Variant(float(raw), vtype)
                        elif vtype == ua.VariantType.UInt32:
                            val = ua.Variant(int(float(raw)), vtype)
                        else:
                            val = ua.Variant(raw, vtype)
                        await node.write_value(val)
            except Exception as exc:       # agent down: keep serving last values
                print("poll failed:", exc)
            await asyncio.sleep(1.0)


asyncio.run(main())

# mes_client.py
import asyncio
from asyncua import Client


class Handler:
    def datachange_notification(self, node, val, data):
        print("change", node, val)


async def main():
    async with Client("opc.tcp://localhost:4840/machinetool") as c:
        root = c.nodes.objects
        machine = (await root.get_children())[-1]
        mon = await machine.get_child(["2:Monitoring"])
        sub = await c.create_subscription(500, Handler())   # 500 ms publish
        await sub.subscribe_data_change(await mon.get_children())
        await asyncio.sleep(60)

asyncio.run(main())

The pattern exposes the key mechanical difference. In step 1 the client does the work of asking; in step 3 the server does the work of telling, and only when something changes. For a fleet of fifty machines, fifty polling loops at one second each generate three thousand HTTP requests a minute whether anything happens or not, while a subscription with a deadband generates traffic proportional to change. That saving is real but depends on how noisy the signals are; a spindle-speed value that jitters will defeat a naive deadband.

Security and Write Semantics: The Question That Decides Architecture

Most comparisons treat security as a footnote. For machine tools it is the main design axis, because the interface sits next to equipment that can injure people and destroy workpieces worth more than the controller.

Read-only is a security property

MTConnect’s read-oriented design means the worst a compromised consumer can do through the agent is read production data, which is itself sensitive (cycle times and part counts reveal customer volumes). Modern agents support TLS, but the standard does not mandate a particular authentication regime, so protection depends heavily on deployment: network segmentation, reverse proxies and agent configuration. In many plants the agent sits on a flat network with no authentication at all, which is a well-known weakness of casually deployed instances.

OPC UA security is richer and easier to misconfigure

OPC UA provides application-instance certificates, signed and encrypted messages through security policies, and user authentication by identity token, with authorisation decided by the server. Done well, this is stronger than anything in the MTConnect stack. Done badly, which usually means a demo server left on NoSecurity with anonymous login, it is worse, because the same server may expose methods. The demo bridge above uses no security purely to stay short. Production deployments need trusted certificate stores, a rotation process, and role-based permissions that distinguish a read-only analytics client from a scheduler allowed to call job methods.

Where the line should sit

A pragmatic rule is to separate the observation plane from the command plane. Put monitoring and production-state subscriptions on one endpoint with read-only roles. Put any method that changes machine behaviour behind a distinct role, ideally on a distinct server instance reachable only from the scheduling system. The umati job management facet makes it possible for a server to advertise job functions; your architecture decides whether anyone is allowed to use them. This ties into the wider integration question of where machine data lands, covered in our comparison of Unified Namespace, data mesh and data fabric for industrial data.

Selection Guidance: Greenfield, Brownfield and Mixed Fleets

Figure 4: Decision flow for machine tool data interfaces. The deciding questions are native umati support, fleet age and mix, and whether writes or job management are required.

Figure 4 compresses the choice into three questions. The flow is a heuristic, not a law, but it matches the situations that actually arise.

Greenfield purchase

If you are buying new machines, put the interface in the request for quotation. Ask for an OPC UA server conforming to OPC 40501-1, state the version, and ask which facets are implemented. Ask the builder to demonstrate it against a neutral client, not their own. VDW’s materials describe a sample server for exactly this kind of testing, and the OPC Foundation lists a umati sample server on its marketplace. A vendor who answers “we support OPC UA” without naming the companion specification has told you almost nothing, since a bare OPC UA server can expose any structure it likes.

Also ask what the machine does not expose. Equipment and tool data is the usual gap. If tool life management is central to your process, make tool data a contractual acceptance test rather than an aspiration.

Brownfield fleet

For machines built before native servers existed, the MTConnect adapter ecosystem is typically the faster route to consistent visibility, and the practical path is MTConnect first, then bridge. Deploy an agent per machine or per cell, validate the data item coverage per controller, and expose a normalised view upward. Whether that view is MTConnect itself, a mirrored OPC UA model, or a mapped Machine Tools model depends on what your consumers need.

This is where a unified namespace often earns its place. Rather than point every consumer at every machine, publish normalised values and state into a broker topic hierarchy and let the interface choice become an implementation detail behind it. Time-series storage then becomes the next decision; our comparison of InfluxDB, TimescaleDB and ClickHouse for IoT time series covers how machine state and sample data behave at scale.

Mixed fleets

Most real shops are mixed. The workable approach is to define your canonical model once, typically the umati Machine Tools model if you expect OPC UA clients, and treat each machine’s native interface as a source. New machines map trivially. Older machines pass through a gateway. The canonical model then outlives the control upgrades that would otherwise force rewrites, which is the economic argument for adopting the umati vocabulary even where the wire protocol underneath is something else.

A decision matrix by use case

Use case	Best fit	Reasoning
Fleet utilisation and OEE dashboards	MTConnect agents, or umati monitoring	Read-only state is enough; adapters cover old controls
Automated job dispatch from a scheduler	umati OPC UA with job facet	Needs methods and authenticated writes
Digital twin with identity and state	umati OPC UA	Typed identification and monitoring simplify asset binding
Servo tuning and high-rate diagnostics	Proprietary API or controller trace	Standards do not target kilohertz signal capture
Cross-vendor tool management	Verify per machine, then decide	Equipment data is the least uniform area
Lightweight retrofit on a small shop	MTConnect adapter plus agent	Lowest cost for read-only visibility
Data space or Manufacturing-X participation	umati OPC UA, possibly via Asset Administration Shell	Aligns with the ecosystem VDW describes

Trade-offs, Gotchas, and What Goes Wrong

Conformance is not binary. A server can implement a subset of the companion specification and still use its name. Facets, optional components and version differences mean two “umati” machines may expose different node sets. Always capture the declared conformance units during commissioning and write acceptance tests against them rather than trusting a datasheet.

Companion specification versions move. OPC 40501-1 is at release 1.02.0 on the reference site as of this writing, but a deployed machine may implement an earlier version. A client written against one version’s node IDs may break against another if types changed. Browse by type and browse name rather than hard-coding numeric node IDs, and keep the NodeSet files you tested against in version control.

Address space size surprises. A full object model with typed children can contain thousands of nodes. Subscribing to everything on fifty machines creates a large monitored-item population, and servers on embedded controls have finite limits on sessions, subscriptions and monitored items. Subscribe selectively, and test the limits of the actual controller rather than a PC-based demo server.

Semantic collisions in bridges. As shown in the mapping table, execution state is not job state. Bridges that flatten distinctions produce plausible but wrong KPIs, the worst kind of data defect because dashboards still look healthy. Document each mapping decision and test it against recorded machine behaviour, including restarts and feed holds.

Clock and sequence handling. MTConnect agents number observations with sequence values and buffers wrap; a client that stays disconnected longer than the buffer holds will lose data and must detect the gap. OPC UA subscriptions have their own keep-alive and lifetime rules and can drop after a network interruption, requiring recreation. Both need explicit reconnection logic; neither is solved by the standard.

Treating the standard as the whole stack. Neither interface is a historian, a contextualisation layer, or an analytics platform. Teams that adopt umati expecting dashboards to appear find themselves still owning storage, retention, unit normalisation and alarming.

Vendor reality. Native umati support varies by builder and control, and public adoption figures from the initiative itself are promotional. Run your own proof of connection on the exact machine and control firmware you intend to buy. If you cannot find independent evidence for a vendor’s claim, ask for a supervised demonstration.

Practical Recommendations

Start from the decisions that are expensive to reverse. Choose a canonical data model first, then choose how each machine feeds it. For most organisations in 2026 that means adopting the Machine Tools vocabulary as the canonical shape for monitoring and production data, while accepting that MTConnect agents and proprietary APIs will remain valid sources for years.

Treat acquisition contracts as the lever. A line in the purchase specification that names OPC 40501-1, a required version, the facets, and a neutral-client acceptance test costs nothing and prevents years of integration work. Treat brownfield modernisation as incremental: start with read-only visibility, prove the data is trustworthy, and only then consider write paths, which should be a separate, reviewed project with its own risk assessment.

Keep the security posture explicit. Separate read and command roles, never ship NoSecurity beyond a lab, and treat certificates as operational assets with owners and expiry dates.

A short checklist:

Name the companion specification and version in every RFQ; require a neutral-client demonstration.
Record declared conformance units and node-set versions per machine at commissioning.
Browse by type and browse name; avoid hard-coded numeric node IDs.
For old controls, deploy MTConnect adapters and agents first, and validate data item coverage per controller.
Document every semantic mapping, especially execution state versus job state.
Separate observation endpoints from command endpoints; apply least-privilege roles.
Test subscription and session limits on the real controller, not a PC simulator.
Put a unified namespace or equivalent between machines and consumers so the interface can change without rewriting consumers.
Keep a proprietary diagnostic path for engineering use.
Re-verify spec versions annually; both OPC and MTConnect keep evolving.

Frequently Asked Questions

What is umati in machine tools?

umati, the universal machine tool interface, is a global connectivity initiative led by VDW and VDMA. It standardises how machine tools expose data using OPC UA, centred on the OPC 40501-1 Machine Tools companion specification for monitoring and job management. It is not a new protocol. It is a shared information model plus the testing and demonstration programme that makes vendors implement it consistently.

Is umati a replacement for MTConnect?

Not directly. They overlap in goal but differ in design. MTConnect is a read-oriented HTTP and XML standard with a fixed vocabulary and a large adapter catalogue, while umati profiles OPC UA, adding typed models, subscriptions and methods. In practice they coexist, and open-source connectors such as umatiConnect, reported by VDW, bridge MTConnect systems into OPC UA for Machine Tools. Many fleets will run both for years.

Which is better for brownfield machines, MTConnect or umati?

For older controls, MTConnect is usually quicker, because adapters already exist for many controllers and the interface is read-only and simple to retrofit. A native umati OPC UA server rarely exists on legacy hardware, so you would need a gateway anyway. A common pattern is MTConnect at the edge, then mapping into a canonical OPC UA or unified namespace model.

Can OPC UA write to a CNC through umati?

The protocol supports writes and method calls, and the Machine Tools specification includes a job management facet. Whether a specific machine allows an external client to create or start jobs depends on the builder’s implementation, permissions and safety design. Never assume write capability from the specification alone; confirm declared facets, and restrict command methods to authenticated, authorised roles on a separate endpoint.

What is the difference between OPC UA and a companion specification?

OPC UA is the generic framework: services, security and a type system. A companion specification, such as OPC 40501-1 for machine tools, defines domain-specific object types, variables and conformance profiles on top of it. Without one, two OPC UA servers can expose the same machine with completely different structures. The companion specification is what makes browsing a second vendor’s machine feel like the first.

Do I need both MTConnect and OPC UA?

Not always, but often in practice. If your fleet is homogeneous and new, native umati OPC UA may cover everything. If you have mixed vintages, MTConnect adapters give coverage for older machines while OPC UA serves newer ones and any write or job workflow. What matters is a canonical data model downstream, so the underlying source protocol becomes an implementation detail rather than a dependency.