MTConnect Architecture Explained: Agents, Adapters, and Data Streams
Modern manufacturing machines generate an enormous amount of operational data like spindle speeds, feed rates, tool positions, machine states, alarms, and much more. But collecting and using this data effectively has traditionally been difficult because machines from different vendors expose information in different formats and interfaces.
This is where MTConnect becomes useful. MTConnect standardizes how machine data is described and accessed so that software systems can read it in a consistent way.
At its core, MTConnect uses a simple but powerful architecture built around two main components: Adapters and Agents. Together, these components collect machine signals, translate them into a standard format, and make them accessible to applications.
Understanding the MTConnect Data Pipeline
Before diving into individual components, it helps to look at the overall data flow. In a typical setup, machine data travels through a small pipeline before reaching applications.
Machines produce raw operational signals. Adapters connect to those machines and translate the signals into MTConnect vocabulary. The Agent then organizes and serves this information through APIs that applications can access.
This layered design separates machine communication, data standardization, and application access, making it much easier to build software around manufacturing equipment.
What is an Adapter?
An Adapter acts as the bridge between a machine and the MTConnect system. Manufacturing equipment typically exposes information through proprietary interfaces like controller APIs, serial communication, network protocols, or vendor-specific software. These interfaces are rarely consistent across vendors.
The adapter connects to the machine and translates those raw signals into standardized MTConnect data items.
For example, a machine controller might report spindle speed using a proprietary variable name. The adapter reads that value and maps it to the MTConnect concept of Spindle Speed, ensuring that applications receive a standardized representation regardless of the machine vendor.
In practice, adapters are responsible for three core tasks:
Connecting to machine controllers or sensors
Reading raw operational signals
Translating the data into MTConnect-compatible format
Once the data is translated, the adapter continuously sends updates to the MTConnect Agent. Importantly, adapters themselves do not serve APIs or store long-term data. Their job is simply collecting and translating machine signals.
One of the strengths of MTConnect is that adapters can be built for almost any device. They can connect to CNC controllers, PLC systems, robots, inspection machines, or even embedded devices such as Raspberry Pi boards collecting sensor readings. This flexibility allows manufacturers to integrate both modern and legacy equipment into the same data ecosystem.
What is an Agent?
If adapters collect machine data, the Agent is responsible for organizing and publishing that data for applications.
The MTConnect Agent acts as a lightweight server. It receives data streams from one or more adapters and makes that information available through a set of standardized HTTP endpoints. These endpoints allow software applications to query machine data using simple web requests.
Internally, the agent maintains a buffer of time-series data received from adapters. It also keeps track of the machine’s structure including its components, axes, spindles, tools, and other devices. This contextual information allows the agent to provide structured responses to client applications.
From a developer’s perspective, interacting with an MTConnect agent is straightforward. Applications simply send HTTP requests to retrieve machine information. The responses are typically returned in XML or JSON format, which makes them easy to integrate into dashboards, analytics platforms, or monitoring tools.
Another important responsibility of the agent is configuration and context management. Configuration files define which adapters the agent connects to, how machine devices are structured, and how the service is exposed on the network. This allows the agent to interpret incoming machine signals correctly and present them in a meaningful structure.
How Devices Communicate in MTConnect
When deployed in a manufacturing environment, the communication process follows a predictable sequence.
A machine generates operational signals through its controller. The adapter connects to that controller and reads those signals. It then converts the information into MTConnect data items and streams them to the agent. The agent receives these updates, organizes them into its internal buffer, and exposes them through its API endpoints.
Applications can then request this information from the agent whenever needed.
The communication between adapters and agents typically happens over a network connection using a simple structured protocol known as SHDR (Simple Hierarchical Data Representation). SHDR messages contain timestamps, data item identifiers, and values representing machine state or measurements.
Because the agent centralizes machine data, multiple applications can read the same information simultaneously without connecting directly to the machine controller. This reduces integration complexity and prevents software systems from interfering with machine operations.
Push vs Pull: How Data Moves Through the System
One interesting aspect of MTConnect architecture is that it combines two different communication patterns.
The first stage uses a push model. Adapters continuously push machine updates to the agent as new data becomes available. This ensures the agent always has the latest machine state.
The second stage uses a pull model. Applications request information from the agent using HTTP calls. Instead of machines sending data directly to every application, applications simply query the agent when they need information.
Adapter → (Push) → Agent
Application ← (Pull) ← Agent
This hybrid push–pull architecture works well in manufacturing environments. Machines can stream updates efficiently to a single service, while many applications like dashboards, analytics engines, maintenance tools, etc can access the same data source without adding load to machine controllers.
Sample Data Walkthrough
When an adapter reads machine signals, it sends structured messages that include a timestamp and one or more data values. A simplified message might look like this:
2025-11-04T10:15:22 | Zabs | 657.125 | Zload | -2
This message indicates the machine’s Z-axis position and load at a specific moment in time. Once the agent receives this information, it stores the data in its internal buffer and makes it available to applications.
Typically, an application interacts with an MTConnect Agent in the following sequence:
Probe request – retrieves the machine’s device structure and available data items
Current request – retrieves the latest values for each data item
Sample request – retrieves time-series data from the agent’s buffer
This workflow allows applications to continuously read machine data and build dashboards, analytics tools, or monitoring systems without needing direct access to the machine controllers.
Conclusion
The architecture behind MTConnect is intentionally simple but highly effective. By separating responsibilities across Adapters, Agents, and Applications, the system creates a clean pipeline for machine data.
Machines generate operational signals. Adapters translate those signals into standardized MTConnect data. Agents organize and publish the information through APIs. Applications then turn that data into dashboards, analytics, and automation workflows.
For manufacturing developers and software engineers, understanding this architecture is the key to building scalable machine connectivity solutions. Once machines are connected through adapters and agents, it becomes much easier to create monitoring systems, production analytics tools, predictive maintenance platforms, and other smart manufacturing applications.
Want to explore MTConnect in practice?
You can start by exploring the official MTConnect Agent implementation on GitHub:
https://github.com/mtconnect/cppagent
And if you'd like to see the architecture explained in more detail, watch the recording of the MTConnect Bootcamp session: