During IMTS, over two-dozen companies participated in a demonstration in which MTConnect data were transferred to the ETC and displayed using an application written by Georgia Tech. Show participants tapped a company icon on a touch screen and immediately connected with a machine to see real-time data about feeds, speeds, and alarms.

Typical manufacturing facilities have hundreds or thousands of machines and independent systems operating in consortia to ensure a product is manufactured quickly and cost effectively, and with quality. Each machine and system accumulates operation information and, often, is unable to communicate it to anyone or anything else. Thus, coordination, data tracking to insure the machine, factory or system is operating at an acceptable level (think machine efficiency, process flow, energy usage, tool-path validation, and so on) is difficult.

There is a need to standardize interfaces for machine tools and other manufacturing equipment, bringing tight integration and interoperability. This stability provides two benefits. First, the improvements from the technology “islands” can be fully realized, and secondly, communication among machine tools and between machine tools and applications can use a common language.

In 2006, in recognition of this need, The Association For Manufacturing Technology (AMT) formed a project team with representatives from industry, academia, and government to develop a standard method for communication among machine tools and factory applications. The team developed MTConnect, produced a set of supporting software tools, and conducted workshops across the country to assist with implementation.

During the 2008 International Machine Tool Show (IMTS) that was held in Chicago, MTConnect was the centerpiece of the IMTS Emerging Technology Center (ETC).  During the show, over two-dozen companies participated in a demonstration in which MTConnect data were transferred across the network to the ETC and displayed using an application written by Georgia Tech. Show participants could tap a company icon on a touch screen and immediately connect with a machine communicating through this standard. As the machine ran in the booth, real-time data about feeds, speeds, and alarms were displayed on the touch screen.

This schematic details the integration of a manufacturing system using MTConnect for both intra- and inter-system interoperability.

MTConnect is a data exchange standard that allows disparate entities in a manufacturing system and their associated embedded devices to share data seamlessly and in a common format. The standard aims to provide a common means for communication between these varied devices. It does not create hardware or special purpose software to link machines and systems together.

It is an open communication protocol based on XML (Extensible Markup Language), which offers a widely recognized and accepted flexible representation for exchanging semi-structured machine-readable data.

The standard is free to insure the widest possible acceptance and utility. This approach ensures communication and connection from the lowest end of the manufacturing chain, nearest the work piece or shop floor, to the highest design or process-planning tool. Additionally, the interoperability enables a host of third party system providers to develop software and hardware to make the entire manufacturing enterprise more productive.

Given the importance of interoperability standards in the manufacturing industry, several have been proposed and are in development. The most significant of these are IPC-CAMX, OPC, and STEP/STEP-NC. These standards take a more comprehensive view of the problem of enabling communication between “smart machines.”

MTConnect does not aim to replace them, and instead serves two important roles relative to them. It facilitates basic communication between the entities of a manufacturing system by standardizing a simple communication protocol, and acts as an enabler for the higher-level standards. Secondly, it provides a lightweight alternative for simple deployments when a more comprehensive standard is not required.

MTConnect is quick to deploy and easy to retrofit to existing equipment. The “business logic” of the manufacturing system is also not coded into it, and hence it can be flexibly deployed in a variety of situations.

The inner workings
MTConnect is based on an open protocol for data integration, not data transmission or data use. It strives to enhance the data acquisition capabilities of devices and applications and move toward a plug-and-play environment to reduce the cost of integration.

It is built upon the most prevalent standards in the software industry, which maximizes the number of tools available for implementation and provides a high level of interoperability with other standards and tools. Unlike proprietary data communication technologies, implementation does not require third party software. Rather, you can develop your own software (unencumbered by run-time licensing), make use of the software development kit (SDK) available at no cost from mtconnect.org, or purchase functions from software suppliers.

Since MTConnect only defines a method for exchanging information, no special hardware is required to implement the standard. Ethernet ports already present on machine tools and the network infrastructure in most factories can be used without modification.

The choice of operating system (OS) or programming language is also not dictated by the standard. You are free to use any programming language or operating system that meets your technical, business, and financial requirements. This flexibility to build a communication architecture in a variety of ways should foster adoption and acceptance, which is crucial for a standard to gain the momentum needed to propel it into wide-scale acceptance. As an example, within weeks of IMTS, Sun Microsystems and GEFanuc announced their support for MTConnect.

With the vast number of devices and information that may come into play, MTConnect provides a common high-level vocabulary and structure. The first version focuses on producing measurement, calibration, and design data in near real-time to have an immediate impact on operation efficiency. Future versions will expand the data structures to include a wider array of manufacturing equipment, such as tool pre-setters and robots, define a method to communicate bi-directionally, and extend the software development kit.

As mentioned earlier, the standard does not presuppose how the information will be used. Rather, it provides the raw data from the device and allows the application or other devices to use them to satisfy specific business requirements. The primary goal is to avoid a protocol that would limit the types of devices or uses of the data. Therefore, there are no predefined states of the device and all information can be sourced from the device without further interpretation beyond units conversion. The designers of MTConnect expect future, higher-level standards to add more vertical approaches for determining function, such as operational efficiency or machine tool performance.

Here is an example hierarchy for a machine tool represented in the MTConnect schema.

Protocol
MTConnect uses XML to structure the data exchanged between data producers and consumers. A machine-readable XML schema defines the format of MTConnect data and since the items are self-describing and the XML instances carry a protocol version number, extensions can be added or custom data messages can be created for a specific scenario without jeopardizing backwards compatibility.

An added benefit of XML is that it is a hierarchical representation, and this is exploited by setting up the hierarchy of the MTConnect schema to resemble that of a conventional machine tool. Thus the schema itself functions as a metaphor for the machine tool and makes the parsing and encoding of messages intuitive. The hierarchical representation also allows related data items to be grouped together. For example, a spindle will have associated with it load and rotational velocity. All relevant data items for that spindle can be retrieved by a single command, rather than specifying each data item separately.

The standard also makes use of Hyper Text Transfer Protocol (HTTP), the same protocol used by web browsers and servers to exchange XML data between entities. MTConnect agents (data producers) act as HTTP servers and data consumers act as HTTP clients. As with web servers, agents can service multiple requests for information from a variety of requesters so the one-to-one communication function that limits many automation protocols is absent from this standard. HTTP runs on top of TCP/IP, so commodity Ethernet components can be used to build a factory network.

The protocol is based on open web standards, like TCP. The overall network performance is mainly governed by the underlying physical infrastructure (network, switch, network adapters) than the protocol itself. Since it is XML based, a single message will be longer than a raw data packet. We have decided to trade network efficiency for the flexibility and extensibility of XML.

XML compression techniques greatly alleviate its overhead. MTConnect only records and sends data when it changes, which removes the duplicate values and reduces the amount of information processed by the application. It has been tested collecting data from a device with a sample rate of 10 ms. The protocol was able to easily keep up with this sample frequency even when the data stream was uncompressed.

In the near future we will be doing performance testing to measure the maximum data rates from an MTConnect agent. As well, we are working on a reference Agent using high performance components to reduce the memory and CPU requirements.

Information types
MTConnect models manufacturing devices as a collection of components that are organized hierarchically and associated by their function in the device. For example, the axes are all associated under a component called Axes. This logical organization allows an application to collect only the information needed without specifying every low-level data item. Since the vocabulary is standard, the application can use the information it understands and be assured that regardless of the source of the data, it will have the same meaning and units.

The current specification version has modeled the data for cutting machines, which did not limit the types of devices it was applied to. During IMTS, MTConnect was implemented on everything from optical gauging to bar feeders to gear test equipment. The generality of the structure allowed devices to present the information they contained. For example the optical gauging device provided the position of the camera and the axis. The bar feeder provided the feed axis and the power status.

The standard makes few assumptions about what is available from a device. It only assumes the device can provide the current power status, any additional information is at the discretion of the implementation. It is also designed to be easily extended to provide domain specific data, such as a quality metric from a gauge or bar-stock from a bar feeder. These extensions can be added by a consortium of vendors or as an extension to the existing specification. Once the domain specific extensions are added, they will become part of the standard.

Components can be identified with a universal unique ID (UUID). The ID will be associated with the component for its lifetime. In this way sensors moved from device to device can be tracked. The UUID is optional.

In the near future, MTConnect will address the class of transitory components and tools that are temporarily associated with a given device. A tool can move from a crib to a pre-setter and then to a machine. Any information the device collects regarding the tool must be retrievable from other applications or devices using the tools unique identification. This issue is being addressed for the entire class of objects including tools, gauges, and work-holders.

Topography
MTConnect does not require any communication topography. The protocol is completely peer-to-peer with the requests origination from the application requesting the data. Because it does not know how the data will be used, it is the responsibility of the requester to specify the specific pieces of information they are interested in as well as the update frequency if a periodic push of changes is desired.

The standard can be deployed with a single device supplying data to other devices or applications or both. For example, a given shop can have each device supplying data to a central application, a historical database collection, all alarms and notifications, and all the other devices in the cell. By allowing N-way communication, MTConnect provides the maximum level of flexibility.

For additional information about MTConnect, please contact the authors or visit www.mtconnect.org.

Georgia Institute of Technology, Artisanal Software, LLC, University of California.