MTConnect, OPC UA and Modbus compared

MTConnect, OPC UA and Modbus are three standards for reading data from a machine’s control, and each one does a different job. MTConnect gives machine tools a shared, read-only vocabulary; OPC UA models, reads, writes and secures data from almost any industrial device; Modbus moves bare 16-bit registers whose meaning lives in the device’s manual. You need one only when the data you want lives inside the control.

This guide is for engineers and plant managers deciding how to get data off a mixed fleet. It explains how each protocol works, where machine connections stall, and how to choose.

What a machine protocol defines#

A protocol for machine data answers three questions: how bytes move between two devices, what each value means, and who may read or change it. The three standards in this guide answer them differently, which is why one can’t stand in for another.

For example, a spindle turning at 1,200 rpm reaches your software as the number 1200 in all three. Modbus sends only the number. MTConnect and OPC UA send the number with its name and unit, so the software knows what it is looking at.

Each protocol talks to the machine’s controller: the PLC or CNC control that runs it. That makes it the right tool for data only the control holds, and more than you need for data a sensor can see from outside.

How MTConnect works#

The specification describes MTConnect as a data and information exchange standard built on a dictionary of terms for manufacturing operations, open and royalty-free for anyone to implement.^[1] The dictionary is the point.

A measured spindle speed is a RotaryVelocity sample with the subtype ACTUAL, in REVOLUTION/MINUTE.^[2] Software written against the standard reads that item the same way on any builder’s control that implements it.

Adapter, agent and client#

Three pieces of software sit between the machine and your dashboard:

• An adapter is optional hardware or software that turns what the equipment provides into a form the agent can receive.^[1] A control that doesn’t speak MTConnect natively needs one.
• An agent collects data from one or more machines, organizes it, and answers requests from client software.^[1]
• A client is your monitoring or analytics software, which asks the agent for data.

An agent must answer four requests: probe for the machine’s structure, current for the latest value of every data item, sample for buffered history, and asset for the assets the agent tracks.^[1] The Institute’s reference agent also takes input over MQTT and can publish to an MQTT broker.^[3]

Read-only by design#

The MTConnect REST API is read-only and produces no side effects on the agent or the equipment.^[1] A client can’t start a program, change an offset or clear an alarm through MTConnect. If you need to write back to a machine tool, MTConnect isn’t the path.

Security in MTConnect#

MTConnect defines what the data means and how to request it. Protecting the connection falls to the transport and the network. The reference agent supports TLS, so it can serve its data over HTTPS with certificates.^[3]

The OPC UA companion specification for MTConnect, released in September 2019, expresses the MTConnect model in OPC UA and brings OPC UA’s end-to-end security to it.^[4] The two standards cooperate rather than compete.

How OPC UA works#

OPC UA runs on anything from a microcontroller to a cloud server, PLCs included.^[5] A device or gateway runs an OPC UA server. Your software connects as a client, browses what the server offers, and reads, writes or subscribes to values based on the permissions it holds.^[5]

Information models#

Where Modbus has registers, OPC UA has a typed model that a client can browse. For example, a press might expose a node for its main motor, a variable for motor current with a data type and an engineering unit, and a method that resets a counter.

The modeling framework is extensible, so industry groups publish companion specifications that fix the model for one kind of machine.^[5] The MTConnect companion specification is one of them.^[4]

Transports#

OPC UA is often described as an HTTP or MQTT protocol, but that isn’t accurate. Its main client and server transport is OPC UA TCP, which runs directly on TCP/IP and whose endpoints use the opc.tcp URL scheme.^[6] IANA registers port 4840 for it, and port 4843 for OPC UA over TLS.^[8]

HTTPS, WebSockets and SOAP over HTTP are alternative mappings in the same specification.^[6] The separate publish-subscribe model, PubSub, defines mappings for UDP, raw Ethernet and MQTT.^[7]

PubSub is built for many-to-many traffic.^[5] Choose it when one device feeds many consumers, and choose client and server when your software asks for data on demand.

Security in OPC UA#

Security is part of the OPC UA protocol. Each client and server is identified by an X.509 certificate, messages can be signed and encrypted, users authenticate, and activity is logged as an audit trail.^[5]

Because OPC UA can write as well as read, the permissions a client receives are a decision for the plant. Connecting software to a controller is a security concern for many plants, and IT usually reviews it first.

How Modbus works#

The specification calls it an application layer messaging protocol for client and server communication across different buses and networks, run over TCP/IP on Ethernet or over serial links such as EIA/TIA-485.^[9] Older documents call the client a master and the server a slave.

Four tables of numbers#

Modbus organizes a device’s data in four primary tables.^[9]

Each table addresses up to 65,536 items, and function code 03 reads 1 to 125 holding registers in one request.^[9] Nothing in Modbus says what register 108 holds. The device maker’s register map does, so every new device model means a new map to load and check.

Read a temperature and a counter#

The specification defines only 16-bit registers, so how two registers combine into a 32-bit value is the device maker’s choice. Read the same counter with the words swapped and you get 34,464 × 65,536 + 1 = 2,258,632,705 cycles. The register map, not the protocol, tells you which word comes first.

Security and current use#

Plain Modbus TCP, on port 502, has no authentication or encryption.^[10] The Modbus/TCP Security protocol carries the same messages inside TLS on port 802, adding encryption, integrity checks, certificate-based authentication and roles for authorization.^[10] Where a device supports only plain Modbus, protect it with the network: keep it on a segment that only the systems that need it can reach.

Modbus is old, but it isn’t retired. HMS Networks’ 2026 analysis of newly installed nodes in factory automation puts Modbus TCP at 5% and Modbus RTU at 3%.^[11]

The Modbus Organization describes Modbus/TCP as widely deployed in industrial control systems.^[10] Meters, drives, temperature controllers and older PLCs are where you meet it most.

Compare MTConnect, OPC UA and Modbus#

The biggest practical difference is direction. MTConnect only reads, while OPC UA and Modbus clients can also write to the device.

Why machine connections stall#

A protocol on the spec sheet doesn’t mean the data reaches your dashboard. Connection projects stall at five points, and each one has a fix you can plan for.

• A mixed fleet. A 2005 lathe, a 2019 machining center and a hydraulic press can speak three different protocols, or none. Each protocol is a separate connector to build, test and keep running, so list every machine’s protocol before you budget the project.
• No data path. A control with no network port, or with no MTConnect support, needs an adapter before an agent can read it. Budget the adapter per machine, not per plant.
• No meaning. Modbus values arrive without names. For example, 40 meters and drives across six models means six register maps to load and verify against a hand reading.
• The security review. A controller connection puts a new device on the machine and on the plant network. That is a security concern for many plants, so IT usually reviews it first. Bring IT in before the project starts, not after the hardware arrives.
• More data than you need. Reading 30 values a second from each of 20 machines is 600 values a second, or 51.8 million a day. Decide which values answer a question before you poll them all, and use a data collection plan to rank them.

Get machine data with or without a protocol#

IoTFlows reads machines both ways. SenseAi mounts on the outside of any machine and reads vibration and sound, so it reports running, stopped, part counts and cycle times with no connection to the control. The sensors never connect to your PLC.

On Enterprise, the IoTFlows edge device reads PLCs and controls over MTConnect, OPC UA, Modbus TCP, EtherNet/IP, Profinet and MQTT, and it reads only the controls you choose to connect. Its signals feed the same dashboards and alerts as the sensors, so a controller alarm can open a Maintain work order.

IoTFlows engineers scope, build and validate each custom integration, and it goes live in one week to a month, depending on the machines. Stanley Black & Decker used the edge device to pull every welding data point from the robotic welding machines on a major automotive customer’s production lines.

Which protocol do you need?#

Start from the data you need, not from the protocol. The first two rows need no connection to the control at all.

Use that table with these rules:

• Choose MTConnect when your machines are CNC machine tools whose controls support it and you only need to read. It gives every builder’s control the same names, which suits CNC machine monitoring across brands.
• Choose OPC UA when you connect PLCs, robots or mixed equipment, need a typed model, need security in the protocol, or need to write back.
• Use Modbus when a device offers nothing else. Load and verify its register map, and keep it on a protected network segment.
• You don’t need any of them if your questions are about run time, stops and counts. A sensor answers those from outside the machine, and the sensor vs PLC comparison sets out what each path sees. For a whole line, see production line monitoring without PLCs.