MTCONNECT

What Is MTConnect?

Those of us in the world of discrete and process automation think that everyone is part of the discrete world (individual parts) or the process world (continuous processes). The belief is that everyone uses PLCs and DCSs to control their systems and that their network architectures are composed of the technologies that are very familiar to us: Modbus, PROFIBUS, DeviceNet, EtherNet/IP and PROFINET IO.

That’s a very limited view. There’s a whole other world of automation devices – a pretty big one at that – that uses very sophisticated automation systems to generate product. That world is the machining or automated tooling domain. That’s a world with sophisticated cutting and machining tools, specialized processes and its own terminology and methodologies.

It’s similar to the traditional automation world that we’ve known for the last thirty years – a world before sophisticated information technologies like OPC UA. Like general automation, the automated tooling industry uses sophisticated controllers that don’t interoperate well, legacy machines that have limited or no ability to provide data and applications that can’t pull all the data they need without very cumbersome and complex interface equipment.

Just like the process and discrete automation domains, machine tooling facilities were faced with the prospect of creating or acquiring unique, sometimes custom adapters or interfaces for every machine tool on the network and every machining center software application. The lack of any common machining communication standard created a situation that Dave Edstrom, president of the MTConnect Institute, described as “adapter hell.” Shop floor integration was complex, challenging, laborious, inefficient and expensive.

MTConnect is the solution to that problem in the machine tool industry. It’s a pretty simple technology built on two very well-known standards: XML and HTTP. It’s an open, royalty-free standard designed to reduce the cost and complexity of integrating tooling devices and to enhance the interoperability of devices from different manufacturers. Very simply, it can be thought of as a well-defined standard for sending machine shop floor data as XML files. It uses simple HTTP Get instructions, the same instructions used for web servers to deliver web pages, to request machining data from a controller.

This works very well in the tooling industry as the industry is small enough to define a common vocabulary and information model semantics to serve most, if not all, information transfer requirements of the industry. Items like Power On/Off, Spindle Speed, Axis Position, Axis Speed, Feed, Block Number, Status, CNC Mode, Work Number, Alarm, Spindle Load, Axis Load, Spindle Override are common to most of the equipment in the industry.

MTConnect defines two devices that comprise the software functionality needed to transfer data from a machine controller to an application: adapters and agents. Adapters are software components that interact with the machine controller. They translate the machine controller data from their (often proprietary) values and format them into the common terminology of MTConnect. Software devices that interrogate adapters are known as agents. Agents respond to HTTP Get requests from applications with XML files. Those requests can include Probe requests, which are requests for the XML Schema for a machine controller, or Stream requests, which are data requests. The XPATH language is supported, which provides the capability to limit requests to some portion of the available data values.

Prior to MTConnect, tooling systems were largely proprietary with no standardized mechanisms for integration or data collection. It was extremely expensive to connect equipment from various vendors into a coherent system. Now, MTConnect users can achieve faster deployment and more meaningful data delivered from the automated tooling equipment.

MTConnect Architecture

Figure 1 – MTConnect system overview

MTConnect is unlike any of the typical industrial connectivity protocols such as Modbus TCP, EtherNet/IP or even BACnet. It’s not a protocol technology that simply offers communications. It’s a standard mechanism for presenting industrial data, generally from machine tools, from different systems using a common framework in a very structured, contextualized and non-proprietary way.

Let’s look at the different parts of the MTConnect system illustrated in figure 1.

Source Devices – These are devices that generate data. The source devices in this diagram are the two CNCs and two sensors. Any device (even non-automated tooling systems) can provide data and be included in an MTConnect system.

MTConnect Adapters – A device with software that connects the source device to the agent. An adapter can be located in a physical device with connections to the source device and an agent or it can be embedded in the source itself (device on right side of the diagram).

MTConnect Agents – These devices gather the data provided by one or more adapters and transmits it to a user application. An agent can also be embedded in a device and provide data for a single device. Agents are web servers that respond to standard HTTP Get requests with standardized XML files representing the data provided by the adapter in a very standardized way.

User Application – The software application receiving the data. It uses standard mechanisms to access the data from all source devices and is completely unaware of the original data, how the adapter obtained the data and any particular formatting that the original source device used for the data.

MTConnect Information Model

You can find a lot of definitions for information models on the internet. For example: “An information model is a standardized mechanism to describe the data in a domain without constraining how that description is mapped to an actual implementation.”

There are two important points in that definition. First, an information model is a standardized description of data in a particular domain. It’s a common way for entities, human or computing, to standardize how to reference particular items in a domain. Second, the information model typically has no relationship to how that data exists in an actual implementation. It exists independently of the mechanism used to implement that model in an actual application.

Information models in MTConnect conform to the first half of this definition but, for simplicity’s sake, don’t conform to the second. The standard defines a highly specific and standardized information model that structures how to talk about tooling equipment. It defines the device names, data names and components and provides a structure for specifying these items in an application. XML is the vehicle that MTConnect uses to communicate its information model.

The XML schemas MTConnect defines are the files that are transferred from an agent to an application program. XML was chosen because, together with HTTP, there are open and standard mechanisms for moving XML files between a source and a destination. In MTConnect, an agent is an HTTP web server. It responds to standard HTTP Get requests from an application and delivers an XML file in response. The response is always a standard XML file containing very specific structure and terminology that details either the schema for the request, the current data values, buffered data values or error information. The format and structure of the XML files are defined by the standard.

There are four information models in MTConnect: Devices, Streams, Assets and Errors.

Devices Information Model – Provides the schema to the application. It contains the list of all the devices known to the agent. The agent collects this data from all adapters connected to it and structures that data in a Devices XML file. The Devices XML file contains these elements.

• A set of Device keywords that define all the devices known to it
• The components (all logical pieces of equipment) of each device
• The data items associated with each component and each device
• Meta data (the information and structure of the data, not the data itself)

The Devices XML file contains the schema for the system known to the agent. It contains no data. It simply defines all the pieces of the system that can be requested by an application program.

Streams Information Model – Provides data values (either current, sample, condition or event data) to the application program. Current data is the latest data values available to the agent. Sample data is one or more of the buffered data values that exist in the agent. Condition data is machine state data. Event data contains notifications of events available to the agent.

All Streams XML files are preceded by a timestamp specifying when that data was received and a sequence number organizing the data in numeric order.

Assets Information Model – Provides a list of key/value pairs that contains information on all the devices from all the adapters connected to the agent.

Errors Information Model – Provides information on protocol-related errors.

Detailed information on these information models and their specific contents is available in the MTConnect Specification.

A Deeper Dive into the MTConnect Adapter

Figure 2 – MTConnect adapter overview

The MTConnect adapter is the software component that “adapts” communication with some industrial device to the messages expected by an adapter.

Many automation devices, especially legacy automation equipment, use specialized, and sometimes obsolete, communication protocols and physical media. These devices may store data in non-standard ways and use highly specific, custom messaging to provide access to that data.

MTConnect takes the opposite approach. It uses a very structured vocabulary, well-defined and open information models and standard, open communication protocols. An adapter and an associated agent are the components that bridge this gap.

An adapter understands the data structure and messages of a device. Its mission is to use the communication mechanisms of the device to get the device data and repackage it to conform to the requirements of an agent. While the MTConnect Specification doesn’t specify how an adapter should operate, it does specify exactly how data is to be transmitted from the adapter to the agent.

Adapters are, by definition, non-standard. They are very specific to a particular device and, often, to a specific model of that device. Companies that build automation devices may include adapter software as part of their device (see CNC/Adapter in the diagram). Or they might create software running on some other platform that has the right media connections to access the device and the knowledge to access the non-standard data. When not built by the device vendors, adapters are built by third parties who understand how to adapt the communication media and data structure to MTConnect.

Understanding Adapters

1. All devices that connect to MTConnect require an adapter. An adapter is not part of the MTConnect Specification, it is simply the software required to move the data to someplace (an agent) where it can be handled and delivered to an application in the format specified by the standard.
2. Adapters can be built into a device or can exist in a separate piece of hardware. Only the original manufacturers of a device have the capability of including an adapter in their device.
3. Adapters that exist in a separate piece of hardware must have both the physical communications medium supported by the device and the knowledge of the internal data structure and messaging of the device.
4. An adapter has only one requirement: transform the data from the device into the data structure and messages expected by an agent.
5. Adapters must deliver messages to an agent in a way that conforms to the rigorous MTConnect Specification.
6. A single device can have multiple adapters.
7. An agent can get data from multiple adapters.
8. Agents can connect to adapters in various ways, though an Ethernet connection is typically used.
9. Every agent delivers data from a specific device to an application using the appropriate conversion. There is no generic adapter: they are particular to the device. (Devices that, for example, support a protocol like Modbus, could have an adapter that makes them look like a CNC machine or a robot.)

A Deeper Dive into the MTConnect Agent

Figure 3 – MTConnect agent overview

The agent is the software component that provides data to some user application. The agent gets data from one or more adapters and makes that data available to one or more user applications.

The agent is the visible component of MTConnect. It’s the component that connects to user applications and provides formatted data. It buffers some amount of data so that the user application can request data for multiple samples. When the user application issues a Get command, it can ask for data from one device, from several devices, from all devices, from a certain set of sequence numbers and so on. The agent stores that data and responds to the user application with the requested data in a standard format.

An agent has a limited ability to archive data for a short time. If the connection between the user application and the agent is lost, the agent stores the data until the connection is restored. The resources available to store data vary with the specific agent implementation. Data is stored in a FIFO buffer. New data replaces the oldest data in the buffer.

There are four basic requests that user applications can use to retrieve data.

Probe – The probe command returns the devices document. It is the device model for all the devices connected to it. This can be called a schema or information model: it provides the “picture” of what devices are in the system and what data the user application can request.
Sample – A sample request returns some number of entries from the data in the agent. Parameters on the command can limit the data returned to a specific device or a specific set of sequence numbers. There is even the capability to do some streaming of data.
Current – A current request provides a snapshot of device data at the current time. Parameters can be used to specify some subset of the data, such as restrict the data provided to just some devices, just some variables or only values for some interval. By default, all data is returned.
Asset – The asset request provides detailed data on the equipment connected to an agent. Parameters on the asset request can filter the data delivered by specific device or asset.

Agents are software components running on the same platform as user applications or on standalone platforms. They use the data supplied by adapters to deliver the data specified by the requests listed above. Agents have two primary functions. One, collect data from one or more adapters. And two, provide that data to applications. Agents communicate with adapters in whatever communication mechanism is supported by that adapter. This is a very important point. The MTConnect Specification does not define how data moves from adapter to agent.

Designers are free to build adapters in any manner they choose and expose data using whatever mechanism makes sense to the application. There is no standard way to move data between an adapter and an agent. The communication between the user application and agents is what is specified in the standard. The standard specifies the HTTP Get requests that applications use to get data from an agent. The standard also specifies the format of the XML files that an agent delivers to a user application. All agents are required to support the XPATH language, which is how requests are limited to specific values.

MTConnect Summary

Many compare MTConnect to OPC UA. While they have the same objectives, if all you want to do is to deliver operating data from a tooling system to an application, there is nothing better than MTConnect.

MTConnect Advantages

• Users can analyze patterns of downtime, add or remove machines from the production line, upgrade or replace machines, adjust maintenance schedules and reorganize workflow.
• Fast integration with applications using standard HTTP JSON.
• Extensive data filtering by equipment, collection date or sequence number.
• A standardized dictionary that provides a common vocabulary for devices, components and the data values in those components.
• Device and equipment designers can create devices that provide valuable data instead of just executing tooling operations.

MTConnect Disadvantages

• It’s a one-domain technology. It is designed and built to provide tooling data from specific types of tools to applications collecting that data. Extending it to other domains, while possible, is unlikely given the dominance of OPC UA and other protocols in most other domains.
• IMTConnect adapters are not available for all types of machine tools and CNCs. Users can have difficulty finding adapters for everything in their plant. This is an even greater challenge for older plants with a significant number of pieces of legacy equipment.

Prior to MTConnect, shop floor monitoring of the disparate tools from different vendors was impractical for all but the largest, most profitable and most technologically adept machine shops. Now, operations staff can quickly react to disabled or underperforming tools, easily upgrade or replace machines and analyze patterns of downtime when your machines are connected with MTConnect.

Like other technologies, MTConnect is a means, not an end. Although it is easy to use and standardized for the tooling industry, its real value lies in the productivity gains that its applications deliver. That’s where automated tooling systems with MTConnect can really benefit.