What is the Difference Between MTConnect and OPC UA?

The need for technical standards that harmonize the process of data transfer across manufacturing shop floors has been the topic of discussion for quite some time now. This is because of the diverse equipment types in today’s shop floors, the number of legacy equipment still being used, and the need to facilitate data transfer within an interconnected environment. Industry 4.0 business models also rely on data exchange and, to achieve this, shop floor equipment must be able to transfer and receive data from software applications.

The above reasons became the foundation for the founding of diverse technical standards and their accompanying protocols to regulate data transfer within manufacturing facilities. Today, MTConnect and the Open Connectivity Foundation have become the standout organizations at the forefront of harmonizing data exchange across shop floors.

The Differences Between MTConnect and OPC UA

Although MTConnect and OPC UA are standards developed by different organizations, some similarities between both offerings exist. These similarities exist due to what they intend to accomplish- which is enabling data exchange. To that end, both options are HTTP-based protocols which makes them usable on internet-enabled networks.

Now to the differences. The question of “why MTConnect exists if the unified architecture OPC was developed to accomplish actually works” has been asked multiple times across different forums, and this is what this post intends to answer. The short answer to this question is that MTConnect is a standard that makes data actionable while OPC UA is a standard that makes that data available. And for the long answer, you have to read a little bit further…

Differences in Definition – Starting with the definition of both standards, OPC UA is a machine to machine and machine to enterprise communication protocol for industrial automation. Thus, it ensures diverse automation systems are compatible with one another within a unified architecture that facilitates interoperability. On the other hand, MTConnect provides a machine to machine or machine to enterprise communication vocabulary that ensures equipment with similar standardized functions can communicate.

What this means is that OPC UA creates an enabling environment consisting of diverse equipment with varying network and communication technologies to com6municate while MTConnect is basically the standardized language these equipment use in communicating. Thus, MTConnect is extensible and can be integrated into OPC UA.

Data Exchange Protocols – Another important difference between both standards can be seen in their ability to provide, read, and/or write protocols. While OPC UA offers standards to read and write data based on the specified access permissions, MTConnect is read-only which means machine data cannot be modified and written back to a machine.

These differences provide interesting application scenarios for both options. For example, if machines need to be monitored at a high level, MTConnect provides the vocabulary needed to read the data they produce regardless of the machine type. Thus, making it easy for machine monitoring software to visualize the condition of machines running on a network. While in a situation where the machine being monitored needs specific feedback to automate its functions, OPC UA will be the better option to use.

Accessibility and Ease of Use – The standardized vocabulary of MTConnect makes it an easier option to use when reading data from machines via software applications. In contrast, OPC UA’s lack of a standard dictionary means the addresses within its programmable logic controllers (PLC) where specific data is stored must be known. Thus, this address must be known by the end-user and transferred to a monitoring software in order to access the required information at that location. This mode of accessing data makes OPC UA a more difficult proposition for machine monitoring software to navigate.

Hardware and Software Availability – For both standards to retrieve data from machines, a retrieval process or interface must first be established. For OPC UA, a driver is needed to facilitate the retrieval of data from the PLC. The driver generally contains the software needed to retrieve data from devices, and these drivers can be purchased from a variety of vendors.

For MTConnect, an MTConnect adapter is required to facilitate data capture from a piece of equipment and format it for the MTConnect agent which then allows monitoring software to access the data. Many new machines come equipped with MTConnect adapters but for older machines, a vendor may be required to develop the adapter.

Looking Ahead

In machines where MTConnect adapters are available, it is generally the best option to use in monitoring equipment due to its standardized vocabulary. OPC UA can also be used to capture data across shop floors and accessed by an MTConnect adapter for standardization. This is why MTConnect and OPC UA have developed specifications to unify interoperability across both standards.

Looking ahead, while more and more machines are adopting these standards, the simple fact is there are too many distinct types of equipment — Lathes, Mills, Plastic Injection Molding, Stamping, Laser Cutters, Robotics, etc — and too many different standardization protocols to expect one to win out above the rest as the one true standard. That’s not even including legacy equipment that won’t speak any of these new languages without complex translation capabilities installed on them.

Thus, MachineMetrics took a slightly different approach to this problem. The solution is not to have all machines (new and/or legacy) speak the same language. In the end, all that matters is that the data points from each machine is transformed into one standard protocol.

This was not a simple task to solve: we first simplified IoT connectivity with an inexpensive edge device that enables secure ethernet, wifi, and cellular communication while connecting directly to machine tool PLCs and controls. This device is programmed with dozens of custom software adaptors developed to automatically unlock, map out, collect, and standardize the available data points (Status, Modes, Alarms, Overrides, Load, Speeds, Feeds, and more). We then add the ability to connect additional sensors or collect data from legacy equipment with digital and analog I/O that is configured and managed remotely through a web interface. This task, to enable the connection, collection, and standardization of every piece of discrete manufacturing equipment, is paramount as every manufacturer has a wide variety of equipment types and ages that require data to be collected from to drive analytics.

Our data collection infrastructure is the foundation of the MachineMetrics IIoT Platform. Once collected and transformed, data can immediately be made actionable through vertically focused applications delivered either by MachineMetrics, through 3rd parties, or with custom applications built by our customers using the available APIs.

Download our newest Case Study with SilencerCo