> connecting things
I have spent enough time around factory floors to realize that industrial automation is not just about logic. There is history to it. And the history is messy. If you have ever tried to get a 20 year old PLC to talk to a modern websocket or API, you know exactly what I am talking about. You are not just fighting code. You are fighting decades of competing business interests and product first mentalities.
The world of industrial connectors is a graveyard of good intentions and walled gardens. To understand why we are stuck with a dozen different ways to move a single integer, you have to look at where it all started.
The Grandfather
Modbus was born in the late 70s. It was simple, rugged, and designed for the hardware of the time. It does not care about data models or metadata. It just reads bits and registers. Because it is so primitive, it became the universal language of the plant floor. It is the paper and pencil of automation. It is not efficient, but it works.
As we moved into the 90s, we needed more. We needed Windows to talk to machines. That gave us OPC Classic. It worked, but it was tethered to Microsoft. If you wanted to talk to a machine, you needed a Windows server sitting in the middle like a gatekeeper.
The Great Cleanup
By the 2010s, the industry tried to fix the mess. We got OPC UA, which finally gave us structure and security that did not depend on a specific operating system. It turned raw numbers into actual information. Then came MQTT, a Publish Subscribe model originally built for oil pipelines. It is lightweight, it handles spotty connections, and it has become the darling of the Industrial IoT.
So, if we have these modern standards, why is the average factory floor still a chaotic mix of five different protocols?
The Product First Trap
The reality is that both the makers and the users of these machines have priorities that compete with standardization. Equipment makers prioritize speed to market. They want to ship their hardware and move on. For them, interoperability is often a secondary goal or even a threat to their business model. Historically, if you bought a certain brand of PLC, that company wanted you to buy their drives and their software. They did not want their machines talking to the competition.
On the other side, factory owners are focused on their own output. They need to make their product first. In the heat of a production cycle, building a clean data architecture is almost always a P2 when compared to keeping the line moving. When the goal is simply to get widgets out the door, how the data is moved feels like a problem for another day.
Changing Perspective
We can complain about the lack of standards, or we can change our perspective. The most successful engineers I know have stopped looking for a silver bullet protocol. It is just not going to happen for brownfield applications. They have accepted that the mess is intentional.
Instead of trying to force the entire factory to speak one language, they focus on abstraction. Modern solutions like RabbitMQ are a core part of that shift. RabbitMQ acts as the Post Office of the factory. Instead of Point A talking to Point B, machines drop off their data at the broker. The broker handles the queue and delivers it to the destination, whether that is a database, an AI model, or an analytics dashboard, in the format it needs.
Flexibility is a competitive advantage. When you stop fighting the history of the equipment and start building abstraction layers, you gain the freedom to innovate. You are not limited by what the manufacturer intended. You are only limited by what you can do with the data once it is out of the box.
I see a lot of similarities with where developer tools and agentic workflows are headed today. Hello MCP servers! The Model Context Protocol is doing for AI agents what abstraction layers are trying to do for the factory. It is about creating a standard way for a brain to reach into a tool without needing to know the plumbing.
The mess is not going away. Our job is to build the translators that make it irrelevant and focus on how the data can impact our bottom line.