Established in 2006, MTConnect has become the universal interface that connects machine tools to the rest of the digital world. Prior to MTConnect, monitoring the disparate tools and machines on the shop floor from different vendors was impractical for all but the largest, most profitable and most technologically adept machine shops. It democratizes the machine shop floor and brings the ability to provide sophisticated analysis in the machining realm – live monitoring, fault notification, fault prediction and trending, efficiency reporting and so on – to even the smallest machine shops.
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.
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.
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.
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.
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.
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.
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.
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.