The Future of MQTT?

I have an interesting history with MQTT. In the very early days, I disliked it and thought it had no place in the automation hierarchy. I had what I thought were good reasons at the time but came to realize that I was wrong. More importantly, everyone else knew I was wrong.

A year later I wrote a couple of articles essentially saying that I was wrong for dismissing the technology. I finally saw that it had a place on the factory floor. I think that place is for automation professionals who need to solve a data transfer problem. It is easy to implement. It works well in limited domains. It’s fast and somewhat secure. But data modeling has always been its Achilles heel.

A lot of manufacturers don’t care too much about data modeling, but it is a weakness, one that I think will become more important as time passes. And it could lead to the diminished importance for MQTT unless the technology people behind it solve this problem.

Here’s what I mean. Data modeling is the future. We may never fully get there, but the clear direction is to have a “printer driver” kind of asset for every device on the factory floor. This “driver” would embed a standard data model such that any subscriber that wanted to use that device could. The data model could be interrogated and a subscriber could get just about anything it wanted from that device by consulting the data model. There would be no need for manuals, tag lists or anything of that sort.

OPC UA is on its way there. UA was built with data modeling already in place. It also allows devices to interrogate that data model so requesters can find the data values they want, get the data type and any of the meta data associated with it. These data models also determine how often that value is updated and what the resolution is as well as whatever additional information is available for understanding that data value. As I said, data modeling is the future.

CESMII, an organization with close ties to OPC UA, NAMUR, VDMA and other organizations working on factory floor standards, recently released the first implementation of its cloud server. This server will provide data models to controllers and devices that want to understand other devices. The people behind MQTT must develop similar solutions if they want to remain relevant.

Now, to be fair, MQTT has its own kind of modeling in Sparkplug B. Sparkplug predefines topic names and makes it easier to work with MQTT in a standard way. It’s fine for now but it’s light years away from the kind of data modeling envisioned for the future of the factory floor. If MQTT is unable to evolve and develop tools to support the kind of models that are becoming standardized, I’m not sure what its future will be.

RTA doesn’t have a dog in this fight. We just want to help manufacturers move data around the factory floor quickly and easily. When data models become an important part of your job, we’ll be there to help you. We support MQTT in our gateway product line but not Sparkplug…at least not yet. If you think Sparkplug is important to support (I’m actually not sure) let me know why you think so. In the meantime, check out some of our most popular MQTT products.

460BMQT

Publish BACnet MS/TP data from up to 32 BACnet MS/TP devices to an MQTT broker

460AQT

Publish ASCII data to an MQTT broker

460ETCQT

Publish AB PLC (Logix, PLC5, SLC, MicroLogix) data to an MQTT broker

Again, let me know what you think about MQTT. You can reach me by using the contact form on the RTA’s website or you can find me on LinkedIn.