MQTT is being used a lot more in recent years inside of factories for sharing data between machines. Historically it's been used in Oil & Gas for SCADA (getting data from remote well sites).
10+ years ago we added it to Kepware (OPC server) and streamed tag values to "the cloud". I was at a conference giving a presentation on it when Arlen Nipper, one of the creators of MQTT, came up after the presentation and said I did a "decent job". It was humbling :). Fast forward to today, and we have a new company (HighByte) modeling factory data at the edge and sending it via MQTT, SparkplugB (protocol over MQTT), direct to S3, Azure Blob, etc, etc.
All that to say, MQTT is a big driver in Industry 4.0, and it's cool to see it so heavily used all these years later.
We are currently using the Kepware IoT plugin to stream around 800k tags per second via MQTT ultimately into a Victoria metrics DB. It's a little clunky and requires more processing steps than I would like. I am currently moving away from this solution (since Kepware charges a reoccurring license fee every year for the IoT plugin), and toward using telegraf to read the OPC-UA data directly from kepware without the IoT plugin.
I also work in that industry and am quite puzzled by the technological inferiority, scope creep and NIH syndrome of the OPC foundation’s standards. I wish they just used sparkplug b and implemented their specs on top of that for semantics.
Then again the async stuff they’re doing now is so over-engineered and terrible as well.. I took part in their teams meetings some time, only to find they had never read the mqtt spec (less than 50 easy to read pages) and didn’t understand what the headers are for for example (they wanted to put stuff in there that actually belongs in the payload). Some microsoft guy also took offense at my suggestion to first look at what competitors are doing with mqtt, because he wanted to create something new rather than copy. My company will just treat opc ua at the very edge and isolate it from our tech as much as possible on my suggestion.
> MQTT is being used a lot more in recent years inside of factories for sharing data between machines. Historically it's been used in Oil & Gas for SCADA (getting data from remote well sites).
This is where I first encountered it too -- chemical production. Also saw a lot of it in aviation and railroad control systems.
That said, seeing a lot more Kafka and RabbitMQ crowding into MQTT's marketspace.
There is also MQTT integrating bus-hardware- you basically plug in as bus-hardware replacement which allows to send data directly from the bus to the broker. The PLC never know what hit it.
In some cases yes, controllers are adding in MQTT support directly or SparkplugB.
It works in simple cases, but the lack of transactions & ability to control what and how often you're reading from the client side, can create challenges.
10+ years ago we added it to Kepware (OPC server) and streamed tag values to "the cloud". I was at a conference giving a presentation on it when Arlen Nipper, one of the creators of MQTT, came up after the presentation and said I did a "decent job". It was humbling :). Fast forward to today, and we have a new company (HighByte) modeling factory data at the edge and sending it via MQTT, SparkplugB (protocol over MQTT), direct to S3, Azure Blob, etc, etc.
All that to say, MQTT is a big driver in Industry 4.0, and it's cool to see it so heavily used all these years later.