Latest / Internet of Things with Fexingo: Connected Devices, Sensors, and Industrial IoT / The Hidden Protocol Wars Behind Industrial IoT
Transcript
- Lucas: When people talk about industrial IoT, the conversation usually lands on sensors, cloud dashboards, or maybe edge gateways. But there is a quieter war happening inside every connected factory — and it is not about hardware at all. Luna: Let me guess — protocols. The alphabet soup of how devices actually talk to each other. Lucas: Exactly. And the reason it matters is that most factories are not greenfield. They are brownfield — machines from the 1990s, maybe older, running on fieldbus protocols that predate the internet as we know it. You cannot just swap them out for shiny new Ethernet-enabled equivalents. Luna: So you are stuck with Modbus, PROFIBUS, CANopen — and then trying to make those talk to MQTT or OPC UA on the cloud side. Lucas: Right. And every protocol has its own assumptions about timing, data structure, error checking. The moment you insert a protocol translation gateway, you add latency. I spoke with an automation engineer at a mid-sized German firm — let's call them Mittelstand Automation — who was retrofitting a factory floor from 1994. They had two million dollars' worth of Siemens PLCs running PROFIBUS. Replacing them was off the table. Luna: Two million is a lot of capital tied up in controllers that still work. So what did they do? Lucas: They added a gateway that translates PROFIBUS frames into OPC UA packets for the new monitoring layer. But here is the kicker — the translation added 15 to 30 milliseconds of latency per transaction. For most data collection, that is fine. But for a synchronized robotic cell where two arms need to coordinate within 5 milliseconds, that latency is a showstopper. Luna: So you cannot just blindly gateway everything. You have to decide what data can tolerate delay and what cannot. Lucas: Precisely. That plant ended up running a hybrid network: the legacy PROFIBUS loop for time-critical motion control, and a parallel Ethernet-based network with MQTT for vibration and temperature sensors feeding a predictive maintenance model. The gateway only handles the slower, less urgent data. Luna: I have read that MQTT is lightweight, but it is publish-subscribe — so you lose the deterministic timing that PROFIBUS gives you. That is a fundamental design difference. Lucas: Exactly the point. PROFIBUS is a master-slave protocol with a fixed cycle time. Every device knows exactly when it will be polled. MQTT is event-driven — you publish when you have data, and the broker distributes it. Great for cloud, terrible for a robotic arm that needs a new position command every 1 millisecond. Luna: And yet, so much of the hype around Industry 4.0 assumes every device can just be ip enabled. The reality is more like protocol coexistence. Lucas: Yes. And the industry has been trying to standardise for decades. The IEC 62541 standard — known as OPC UA — is the closest we have to a universal protocol for industrial communication. It is platform-independent, it supports encryption, and it can wrap legacy protocols. But adoption is slow because it requires significant engineering effort to retrofit. Luna: Plus, there is the installed base argument. Why switch if the old system works? Especially when the cost of downtime for a protocol migration can be hundreds of thousands of dollars per hour in a continuous process plant. Lucas: That is the real friction. A chemical plant running a batch process cannot afford a 48-hour shutdown to rewire controllers. So they keep Modbus RTU over RS-485 serial cables — which, by the way, is incredibly robust in electrically noisy environments. Ethernet can be finicky around high-voltage motors; RS-485 is differential signalling and handles interference much better. Luna: Interesting — so the 'old' protocol might actually be technically superior for certain physical conditions. Lucas: Absolutely. There is a reason RS-485 is still widely used in oil and gas, mining, and heavy manufacturing. It is simple, it is proven, and it can run over long distances — up to 1,200 meters without a repeater. Standard Ethernet is limited to 100 meters. So when you see a 'modern' IoT retrofit, it is often adding an Ethernet gateway at the edge, not replacing the serial backbone. Luna: So the protocol war is not really about winner takes all. It is about choosing the right tool for each layer — serial for the noisy shop floor, Ethernet for the aggregation point, MQTT or OPC UA for the cloud. Lucas: And that is the pragmatic message. But there is a structural challenge underneath: the skills shortage. Most electrical engineers trained on PLCs know PROFIBUS and CANopen inside out. Younger engineers come out of school with Python and MQTT. Bridging those two worlds is hard. I have seen projects fail because the controls team and the IT team literally could not agree on a data format. Luna: Right. The OT versus IT divide. The operations technology people want deterministic, locked-down systems. The IT people want open standards and cloud connectivity. Those cultures clash at the protocol gateway. Lucas: And the vendor ecosystem does not help. Siemens pushes PROFINET, Rockwell pushes EtherNet/IP, Beckhoff pushes EtherCAT. Each has slightly different real-time capabilities and toolchains. If you standardise on one, you are locked into that vendor's ecosystem. That is why OPC UA is attractive — it is vendor-neutral. But it is also more complex to configure. Luna: Let me ask a practical question: if I am a plant manager today, what is the single most important thing I should know about protocols before starting an IoT project? Lucas: Audit your latency requirements first. Not all data is equal. A temperature sensor can tolerate 100 milliseconds of delay. A servo motor cannot tolerate 5. Classify every data point by its timing criticality, then pick the protocol that fits each class. Do not try to force everything into one protocol — that is where projects fail. Luna: That is good, concrete advice. And it avoids the trap of believing the marketing that says 'one protocol to rule them all'. Lucas: Exactly. And if today's episode was useful to you and you want to keep it ad-free, buy me a coffee dot com slash fexingo helps. It is a small thing that genuinely keeps this show independent. Luna: Yeah, we do not run ads, and listener contributions are what make that sustainable. So if you find value in these deep dives, that link is there. Lucas: Back to protocols for a second — I want to give you one more concrete example. There is a standard called io link that is gaining traction in sensors. It is a point to point communication protocol that runs over standard 3-wire cables. It lets you send configuration data and diagnostics alongside the sensor value. Think of it as giving a simple proximity sensor a digital voice. Luna: So instead of just a binary signal — object detected or not — you get distance reading, temperature, maybe even the sensor's health status. Lucas: Right. And io link is designed to coexist with existing fieldbuses. You plug an io link master into your PROFIBUS or EtherNet/IP network, and suddenly your dumb sensors become smart — without changing the backbone. That is the kind of pragmatic evolution the industry actually adopts, not the revolution that analysts predict. Luna: It reminds me of the early days of Ethernet in the office — we had Token Ring and ArcNet and all these competing standards, and eventually Ethernet won because it was good enough and cheap. But industrial protocols are stickier because downtime costs so much. Lucas: Exactly. The switching cost is enormous. So we will live in a multi-protocol world for at least another decade, probably longer. The skill for engineers is not picking one protocol — it is designing systems that bridge multiple protocols effectively. Luna: And for the rest of us watching from the outside, it is a reminder that the internet of things is not just about Wi-Fi and cloud APIs. It is about RS-485, PROFIBUS, and a lot of bit-banging in C on microcontrollers. Lucas: Exactly. The invisible plumbing. That is what makes industrial IoT work — or not. Luna: Alright, I think we have given listeners a good mental model for thinking about protocols. Next episode maybe we dive into security implications of these gateways? Lucas: That is a great idea. Because once you connect a PROFIBUS network to the internet via an OPC UA gateway, you have created a new attack surface. We will cover that next time.