Stop Guessing Your Network: A Field Guide to Protocol Layering

Who This Is For

If you're an automation engineer or a control systems tech who's been woken up at 3 AM because a line is down, this is for you. You know your PLCs and your HMIs, but when the network starts acting up, you're not always sure where to point the finger. That's not your fault. The industrial networking world is a mess of acronyms and proprietary tech, and vendors love to keep it that way.

But here's the truth: most of your network problems aren't protocol problems. They're layer problems. You're trying to carry a conversation that belongs on one layer over a pipe that's meant for another. And until you get your layers straight, you'll keep chasing ghosts.

Step 1: Map Your Layers

First, you need a clear picture of what's in your plant. Grab a whiteboard and draw every device that talks to anything. That's your starting point. The protocols you're using on the plant floor—Modbus, PROFINET, EtherNet/IP—they're all field-level. Modbus is the old workhorse, developed in the late 1970s, using a master-slave register model. PROFINET is Siemens' real-time Ethernet. EtherNet/IP runs CIP over TCP/UDP, and it's huge in North America on Rockwell gear. These protocols connect your sensors, drives, and PLCs. They are the hands and feet of your operation.

Then you have the higher-level stuff: OPC UA and MQTT. These are the messengers that carry data from the field up to your SCADA, MES, or cloud. OPC UA is vendor-neutral and has built-in encryption. MQTT is a lightweight publish/subscribe protocol, standardized as ISO/IEC 20922, that's great for constrained devices. The key insight—and this is the part that solves half your headaches—is that these layers are meant to work together, not compete. You don't replace Modbus with OPC UA. You put OPC UA on top of Modbus that's still talking to your legacy sensors.

Step 2: Diagnose with a Layered Eye

When something goes wrong, don't start by blaming the protocol. Start by asking: which layer is actually failing? Here's a quick checklist I've used on more floors than I can count.

• Is the physical link up? Check link lights, cable continuity, and switch ports. That's layer zero, and it's where half the problems live.
• Is the fieldbus communicating? Watch for error counters on your scanner or master. If you're seeing CRC errors on Modbus RTU, you might have a wiring or grounding issue, not a protocol bug.
• Is the data getting to the higher level? If your OPC UA server shows no updates but the PLC is running fine, you've got a gateway or configuration issue, not an OPC UA problem.

I've seen engineers swap out a perfectly good PROFINET controller because they thought the IRT class wasn't working, when the real issue was a bad patch cable. The protocol wasn't the problem. The physical layer was. Check the easy stuff first.

Step 3: Implement the Layered Fix

Once you've mapped your layers and you know where the data is getting stuck, it's time to implement the fix. My recommendation is simple: standardize on a layered architecture. Use Modbus, PROFINET, or EtherNet/IP for the field devices—they're proven, they do their job, and they're not going away. Then use OPC UA or MQTT to bridge to the upper layers. OPC UA can securely connect to your SCADA or MES, and MQTT can push data to the cloud. This isn't just my opinion; the OPC Foundation describes these protocols as layered in exactly this way, and the ISA/IEC 62443 standard, which sets cybersecurity benchmarks for industrial automation, expects you to have a clear architecture.

Here's a concrete example from a plant I worked with. They had a bunch of old Modbus RTU temperature sensors, a newer PROFINET-based PLC, and a cloud dashboard they wanted to feed. The old approach was to try to get Modbus data directly into the cloud, which meant custom gateways and a security nightmare. The fix was to put the Modbus sensors on a simple serial-to-Ethernet gateway that spoke Modbus TCP, then have the PLC poll those registers via Modbus TCP. The PLC already had PROFINET, so it was the natural aggregator. Then we used an OPC UA server on the PLC to expose the data to the SCADA, and an MQTT bridge to publish to the cloud. It sounds like a lot, but it's actually simpler because each layer does what it's good at.

What Can Go Wrong

Here's the warning: if you ignore layering and just try to bolt everything together, you'll end up with a security hole. CISA's guidance on OT security warns that threat actors exploit weak authentication and outdated protocols. If you're exposing a raw Modbus TCP port to your IT network, you're asking for trouble. The ISA/IEC 62443 standard exists to help you avoid that. It defines security requirements for asset owners, suppliers, and integrators. If you don't have a layered view, you can't segment your network properly, and you'll have no defense in depth.

Quick tip: When you're shopping for new equipment, ask for products that support open standards like OPC UA and MQTT, and that have secure configurations out of the box. CISA's Secure by Demand guidance specifically recommends this.

Takeaway

Stop thinking of your network as a single protocol. It's a stack of layers, each with a job to do. Fieldbus protocols like Modbus, PROFINET, and EtherNet/IP handle the real-time control. OPC UA and MQTT handle the data movement to higher systems. Map your layers, diagnose with that map in mind, and implement a layered architecture. You'll cut your troubleshooting time in half and make your network far more secure.

Sources

• OPC Foundation - https://opcfoundation.org/
• ISO/IEC 20922 MQTT Standard - https://www.iso.org/standard/69466.html
• ISA/IEC 62443 - https://www.isa.org/standards-and-publications/isa-standards/isa-iec-62443-series-of-standards
• CISA Industrial Control Systems - https://www.cisa.gov/topics/industrial-control-systems