by Leslie Langnau, Managing Editor
The MTConnect communication protocol is one way to deliver shop floor data to the software applications used to run a business. Initially, this protocol establishes connectivity among machine devices. When fully implemented though, it will interconnect any equipment or device on the shop floor.
Despite the fact that there are a number of communication protocols available for use in the manufacturing world, (Devicenet, Ethernet, Modbus, Ethernet/IP, and so on), none are optimized to work well with the Internet. In any manufacturing facility, especially the shop floor, hundreds of machines and devices operate, needing to share data to ensure efficient and cost effective production of product. Each device tracks information on its operation. But transmitting that data efficiently to other devices is still a challenge.
The IT world has solved this issue with its model for efficient communication. The USB standard, for example, is just one available standard that allows a range of disparate devices to easily exchange data.
At the 2006 annual meeting of The Association for Manufacturing Technology (AMT), presentations from David Edstrom of
Sun Microsystems and Dr. David Patterson, Professor of Computer Science at the University of California, Berkeley described the need for an open communication standard that would allow manufacturing equipment to connect to the Internet and use it as a means of data exchange. The question asked was, how could manufacturing replicate the IT model of interconnectability? By 2008, joint efforts among academia and industry machine developers resulted in the MTConnect protocol, an open, royalty-free communication standard that uses Internet communications technology to link machines and systems together. The protocol is based on HTTP and XML.
Eliminate the communication “Tower of Babel”
According to AMT calculations, there are more than 1.2 million machine tools installed in the U.S, most of which have limited communication capability. Through MTConnect, this equipment could transmit such shop floor data as alerts, equipment availability, equipment usage, equipment effectiveness, energy use, security information, and other data for quality and statistical process control to various business optimization software to improve operations, track production, and analyze plant operations.
The goal of MTConnect is to enable a range of devices to speak in the same language. It differs from other manufacturing communication protocols in that it lets you develop a dictionary for manufacturing data, and it is a read-only protocol. MTConnect is set up to only extract data from devices, not write data to them.
The dictionary enables machine developers and users to label and categorize data through common definitions, names, units, values, and context. Thus, data need only be defined once, rather than anew for each application. Then, the data can be transmitted over networks using the Internet Protocol through HTTP and XML languages.
MTConnect compliant devices process information locally and then deliver it to any application, such as ERP, MES, and production management systems, spreadsheets, and other business management software. In addition, this protocol makes it easy for OEMs and users to add new data types that can be exchanged between machines and applications.
The MTConnect protocol is divided into three sections; one for information on the protocol itself and how to use XML, one for specifying the equipment, components, and data that will work with this protocol, and a section that specifies how the data will be organized from each connected device. A fourth section may be added later that will support mobile devices.
You implement MTConnect through these components:
The Device—a machine tool or other piece of equipment or data source.
An Adapter—an optional piece of software or hardware that translates data from its source to the data definition used in the MTConnect dictionary. Devices already compliant with MTConnect do not need this component.
An Agent—software that collects, arranges, and stores the data gathered from a device or the adapter.
A Network—the physical wiring between two or more shop floor devices. Usually, this is an Ethernet network; MTConnect is network neutral so it is compatible with other protocols, such as EtherCAT and Modbus. It can even be used with wireless technologies.
The Application—is the device or software requesting data from a machine, controller, or other shop floor device. A software function known as the Client initiates the request for data, and then translates them into a format compatible with the application.
Even though MTConnect works with HTTP formats, it is important to use other network security methods, such as a firewall or whatever else you or your customer uses.
The software for the Adapter and Agent functions can be located anywhere in the network architecture. Often, they are placed near the machine or device, but they do not need to be placed near each other. They can affect the amount of data flowing to different parts of your network.
Tips on connecting devices to an MTConnect network
The first step is to determine which existing devices can connect to this protocol. Some will have the communication capability built in; others will need it added. Machines are defined as either MTConnect Native, MTConnect Translation Dependant, or MTConnect Data Connection Dependant.
MTConnect Native Devices—are machines with the data dictionary and protocol functions. No other devices or MTConnect components are needed for communication. Data collection can begin immediately through a MTConnect compliant software application once you have an IP address for the machine or shop floor component.
MTConnect Translation Dependent Devices—are devices that require a component known as a Translation Unit to convert data from the device into a format compatible with this protocol. (Sometimes, the Adapter performs these needed functions.)
The Translation Unit is usually software and/or hardware. It can be installed within a machine controller, such as a PC, and can be placed in the machine or located external to it. The Translation Unit can isolate an application from any proprietary requirements of the devices; but it will need to know where data are stored within the controller.
MTConnect Data Connection Dependent Devices—are devices that do not normally publish or send data to other devices, or the amount of data they have is limited. Thus, a separate connection unit is needed to collect the data. For these circumstances, the Connection unit can function as a Translation Unit.
Once you’ve established what MTConnect connection equipment or software you need, the next steps are:
- Clearly define your problem. Are you looking to improve production capacity? Is there an issue with excessive or unpredictable downtime? If you could see information more clearly, how would that benefit your bottom line?
- Determine how you will measure success. Will a successful MTConnect implementation be evaluated by improvements in production capacity; by what percentage, for example? What measurements and parameters will be used to evaluate the benefit of using this protocol?
- Determine the equipment that will need to be connected. What controls, sensors, measurement devices, and so on will need to be involved? It is important to know the details of all controllers involved.
- Define the limitations or constraints you may encounter, such as budget, accessibility, security issues, must-have functions, legacy network systems, and so on?
- Determine who will be in charge of the implementation process. Also assess which departments will benefit from more and better data. Who or what could restrain or even derail the project?
- Define the resources you will need to implement the project. What equipment will be sending data, what software will be needed, and what legacy network systems will you be working with?
The MTConnect group also offers third party resources that can help with any parts of this process or with the installation. The website has a directory of these resources. Currently this protocol supports a variety of controllers, linear and rotary axes, various tooling, actuators, sensors, and hydraulic, pneumatic, and electric machine tool components.
Filed Under: Factory automation, CONNECTIVITY • fieldbuses • networks