As companies continue to prepare for digital transformation, the debate around which data protocol is better for smart manufacturing systems rages on. The need to capture data from HAAS machines and other manufacturing equipment is a critical component because much of the data required for smart manufacturing originates in your company’s machines, robots, processing equipment, and inspection equipment. In some cases, the data resides in a computer on board the equipment; in many cases, the data sits in a proprietary controller. These data sources use a wide variety of protocols. Many standards organizations have attempted to consolidate communication protocols. A few leaders have emerged, but that perhaps has made decisions about how to capture machine data for smart manufacturing even more complex.
Smart manufacturing technologies offer massive competitive advantages to companies that implement them. Manufacturers use these systems to reduce waste, achieve operational efficiency, improve product quality, deliver on customer commitments, conduct closed-loop design for manufacturing, carry out predictable machine maintenance, and so much more. What do these solutions and benefits all have in common? Every single one requires data – complete, timely, accurate, valid, consistent data. Unfortunately, most smart manufacturing systems oblige you to make tough decisions about data protocols at the outset. This approach could potentially cost your company tens or hundreds of thousands of dollars in equipment, data translation software, devices, hard-wiring, programming, and labor. While our team will address those concerns in future articles, it’s helpful to compare and contrast two common protocols manufacturers use today to capture data from equipment.
In 1995, a collaboration of leading automation suppliers developed a set of standards for communication between control systems – object linking and embedding for process control was born (OLE for process control, or simply OPC). The mission was to establish a uniform interface that could be used by any organization or with any custom software package. OPC is based on Microsoft’s OLE-COM and DCOM technologies and is a protocol widely used today. Many software vendors have developed applications that translate data from hundreds of proprietary machine control protocols to the OPC standard.
It's helpful to be aware that there are multiple OPC protocols in use today. The most common is OPC data access (OPC DA), while OPC historical data access (OPC HAD) and OPC alarms and events (OPC AE) are less common.
OPC Unified Architecture (OPC UA) is a machine-to-machine communication protocol for industrial automation developed by the OPC Foundation. It allows users to embed a full information model into the protocol so that standards organizations and companies can include more context around manufacturing data. OPC UA provides for tremendously rich data such as information about the machine, the manufacturing process, the order, quality specifications, and many more parameters. However, with this richness of data comes tremendous complexity. This complexity may be one reason why many smart manufacturing software vendors have not eagerly or entirely embraced OPC UA.
MTConnect – short for machine tool connect – is a manufacturing technical standard to retrieve process information from numerically controlled machine tools. This data exchange standard uses a defined XML file to exchange data. Like OPC UA, it includes raw data plus context around that data. Unlike OPC UA, context is determined by the standard and open for the end-user company to define. Some machine tool manufacturers like Mazak and Okuma and some smart manufacturing software vendors have adopted MTConnect.
Armed with a high-level understanding of the OPC, OPC UA, and MTConnect protocols, it’s a little easier to engage in at least a preliminary debate about which protocol is best for smart manufacturing systems. The unfortunate reality is that most smart manufacturing software vendors support either OPC UA or MTConnect, and very few support both. The result is that (until now) manufacturing companies have had no choice but to carefully map out their data infrastructure before they even make the investment to collect data from machines.
Let’s consider the most common scenario. Today’s manufacturing company doesn’t have just one kind of machine or controller. Typically, manufacturers have many types of equipment, from many OEMs; some with built-in same-maker controllers, some with same-maker external controllers, and some with third-party controllers. Today’s shop is a patchwork of equipment that spans many types of uses, many decades, many OEMs, and no one-size-fits-all method to connect or capture the data.
For either scenario, older machines (legacy machines, legacy equipment) that require hard-wiring present similar challenges. There's a different set of hardware necessary to support OPC UA than MTConnect, so again, the protocol path dictates which vendors you're able to work with.
"Why can't we just connect a machine once and do it in a way that’s software-agnostic?” Until recently, manufacturing companies have been practically begging for a way to capture machine data quickly, easily, and in a way that they don’t have to make software choices or sacrifices down the road.
Today, there’s a new breed of edge device that offers freedom and flexibility to:
This new breed of “any protocol” edge device eliminates the question, “Which protocol is better for smart manufacturing systems,” and lets you instead focus on the operational improvements your company can achieve with smart manufacturing.