Industrial Communication Protocols: A Field Guide

Industrial communication protocols are the languages machines use to talk to controllers, to each other, and to software. The ones you meet most are Modbus, PROFINET, EtherNet/IP, OPC UA, and MQTT. Older ones move raw device data at the machine; newer ones carry structured, secure data toward analytics. A plant almost always runs several at once.

That is the whole problem in one sentence: a plant runs several at once. One line speaks PROFINET, the next speaks EtherNet/IP, a legacy filler still speaks Modbus, and none of them agree on how to name a temperature. This guide is the field map, what each protocol is, where it sits, how they compare, and the case for translating the whole babel into one clean data layer instead of fighting it machine by machine.

Why do so many industrial protocols exist?

Because they were invented at different times for different jobs, and industrial equipment lasts long enough that all those generations still run side by side. Modbus arrived in 1979 to let a controller talk to simple devices over a serial wire. Fieldbuses followed. Then Ethernet came to the floor and each major vendor built an industrial version of it. Most recently, protocols aimed at data and the cloud appeared on top. Nothing retired, because the 1990s machine still works, so the floor accumulates languages the way a plant accumulates equipment.

What are the layers protocols live in?

It helps to sort them into three tiers by what they carry and how fast. The lower tiers move raw signals fast and deterministically; the upper tier moves structured data toward software. Knowing the tier tells you what a protocol is good at.

The tiers are why "which protocol is best?" is the wrong question. A control-tier protocol like PROFINET is superb at what OPC UA is not built for, moving I/O between a PLC and a drive in a few milliseconds, deterministically, and OPC UA is superb at what PROFINET is not built for: describing what a value means, securely, so software can use it. They are not competitors; they are different floors of the same building.

How do the main protocols compare?

Here are the five you are most likely to meet, side by side.

Two patterns worth noticing. First, the control-tier protocols cluster by vendor ecosystem, PROFINET where Siemens dominates, EtherNet/IP where Rockwell does, which is why mixed plants end up multilingual by accident of purchasing history, not design. Second, the newer protocols are deliberately vendor-neutral, because their job is precisely to get data out of those walled ecosystems. Modbus survives across both eras for one reason: it is dead simple and everyone implements it.

Which protocol should you choose for new equipment?

Match the protocol to the tier of the job, and lean open. For fast, deterministic control inside a cell, a controller commanding drives, I/O, and motion, you will usually inherit whatever your PLC vendor's ecosystem favors, PROFINET or EtherNet/IP, and that is fine. Fighting the ecosystem there buys little. The place to insist on open standards is the information and transport tiers: require that any new machine or controller can expose its data over OPC UA, and that your gateways can publish over MQTT. Those two choices are what keep your data portable no matter whose controller is under the hood.

A few honest rules of thumb. If a vendor offers only a proprietary protocol with no OPC UA path, treat that as a real cost, not a footnote, you are buying a machine whose data you may never fully own. If you already run a Rockwell-heavy floor, new EtherNet/IP equipment will integrate with the least friction; the same is true for PROFINET on a Siemens-heavy floor. And for anything that has to reach a platform or the cloud, resist the urge to invent a custom integration when MQTT already solves the moving-data problem cheaply. The goal is not protocol purity. The goal is that every machine you buy can hand its data to the layer above without a translation project attached to it.

What is the difference between fieldbus and industrial Ethernet?

Fieldbus is the older family of serial protocols built specifically for the floor; industrial Ethernet runs floor protocols over standard Ethernet hardware. The move from fieldbus to industrial Ethernet is the single biggest shift in the protocol story. Ethernet brought more bandwidth, standard cabling, and the ability to share one physical network, but plain Ethernet is not deterministic, so protocols like PROFINET and EtherNet/IP add real-time behavior on top. This is also where industrial networking and newer determinism standards like Time-Sensitive Networking enter the picture. For most plants, the practical upshot is simple: new equipment arrives Ethernet-based, old equipment is serial, and both have to coexist on a well-designed network. The mistake is assuming Ethernet on the floor behaves like Ethernet in the office. It does not, a control network carries traffic that cannot wait, so it needs managed switches, careful segmentation, and often deterministic scheduling that plain office gear never worries about. Treating the two as interchangeable is how a well-meaning IT project accidentally jitters a motion control loop.

How do you turn many protocols into one usable data layer?

You do not standardize the floor, you translate above it. Trying to force forty machines onto one protocol is a decade-long, rip-and-replace fantasy. The workable path is to leave each machine speaking its native tongue and translate at the edge, so everything above sees one consistent stream. That is exactly what edge IIoT gateways do.

A practical sequence for getting there:

1. Inventory what each machine speaks. Walk the floor and record the protocol, port, and controller for every asset. This list is the foundation of every later decision.
2. Prefer open protocols at every purchase. When buying new equipment, favor open standards over proprietary ones. Locked-in data is the most expensive kind of data you can own.
3. Translate at the edge, not in the platform. Put protocol translation on gateways next to the machines so the platform sees one clean stream, not forty dialects.
4. Normalize names and units. Two machines calling the same thing different names is a silent killer. Agree on one naming convention and enforce it in the translation layer.
5. Keep the path secure and read-mostly. Data flows up through a firewalled conduit per IEC 62443; the control layer is never exposed upward.
6. Model context once, above. In the data layer, tie each stream to a machine, order, product, and shift, so a reading becomes evidence instead of trivia.

What do the protocol stewards say?

• Modbus was introduced by Modicon in 1979 and remains an open, royalty-free protocol maintained by the Modbus Organization (Modbus Organization).
• EtherNet/IP is built on the Common Industrial Protocol (CIP) and is managed by ODVA; PROFINET is the open Industrial Ethernet standard governed by PROFIBUS & PROFINET International (ODVA).
• OPC UA is the vendor-neutral standard for secure industrial data exchange, standardized as IEC 62541 (OPC Foundation), and MQTT is an OASIS and ISO/IEC 20922 messaging standard (MQTT.org).

You do not need to master any of these protocols to run a connected plant, you need a strategy that stops treating their diversity as a wall. Every device that ends up on a network is one more dialect the data layer has to absorb, whether it is a controller, a sensor, or a collaborative robot. Harmony sits above the protocol layer: it reads from PLCs, sensors, and existing systems, normalizes the mess into one operational picture, and computes real OEE and alerts on top, no rip-and-replace of the control network below (see the connected systems module). For where this fits in the broader stack, see IIoT SCADA and how it dismantles manufacturing data silos.