MQTT in manufacturing

MQTT shows up in almost every industrial IoT conversation. It is lightweight, it handles unreliable networks better than many alternatives, and it lets many systems subscribe to the same stream of events. For manufacturing, those qualities matter.

They are also not enough.

I have seen MQTT used well, and I have seen it used as a substitute for thinking. A broker in the middle of the plant does not, by itself, produce better production decisions. It only moves messages. The value appears later, when those messages correspond to something an operator, a planner or a maintenance engineer can act on.

Why MQTT fits the shop floor

Factories are full of devices that need to speak without assuming a permanent, clean connection. Machines start and stop. Networks are shared. A PC on the line may be turned off at the end of a shift. Publish and subscribe is a better fit for that world than a chain of tightly coupled request-response calls.

MQTT also allows the same machine event to be useful to more than one consumer. A cycle-complete signal can update OEE, notify a supervisor, and feed a historian without each of those systems polling the machine on its own schedule. That is a real architectural advantage.

The protocol is simple enough that teams can implement it without turning the plant network into a research project. That simplicity is one of its strengths. It should stay that way.

What MQTT does not decide for you

MQTT does not tell you which tags matter. It does not tell you how to name topics. It does not decide whether a message should be retained, how long it can be late, or what happens when the same stoppage is reported twice.

Those are manufacturing and data-design questions. If you skip them, you will get a busy broker and a noisy dashboard. The plant will still not know why the line stopped.

Before choosing MQTT — or any protocol — I want to know:

• What decision will this data change?
• Who needs it, and how fresh does it have to be?
• Which machines can actually provide it, and in what form?
• What is the source of truth when the machine, the MES and the operator disagree?

If those answers are unclear, the protocol discussion is premature.

Topics are a model of the plant

Topic design is not a naming exercise. It is a model of how the factory is organized. A topic structure that follows the vendor's example will usually fail the first time someone wants data by line, by product or by shift.

A useful structure tends to follow the way people already talk about the plant: site, area, line, machine, then the kind of event. It should be stable enough that adding a machine does not require renaming everything that already exists.

Payloads need the same discipline. A timestamp, a stable machine identity, and a value that means one thing are more valuable than a large JSON object that tries to describe the entire state of the world in every message.

Reliability is an operations problem

Quality of service settings, retained messages and last-will messages are not just broker features. They change what the plant believes is true.

If a machine goes offline, someone needs to know whether the last reported state is still valid. If a message arrives late, OEE and sequencing can be wrong in different ways. If two gateways publish the same tag, you will spend weeks arguing about which number is real.

These are the details that separate a demonstration from a system a plant can run for years. They are also the details that get postponed because the first dashboard already looks impressive.

Use MQTT where it earns its place

MQTT is a good choice when many consumers need the same events, when connectivity is imperfect, and when the plant wants to add subscribers without revisiting every machine interface.

It is a weaker choice when a single system already owns the conversation with the machine, when the data is better pulled on a known cycle, or when the organization does not yet know what it wants to ask. In those cases, adding a broker creates a new moving part without reducing any existing confusion.

I have spent a lot of time around MQTT, industrial software and connected systems. The lesson I keep returning to is ordinary: the protocol is the easy part. Understanding the process and the data is the work.