MQTT vs OPC UA with Kudzai Manditereza

David (00:00)
Hello, welcome you’re listening to the IT/OT insider podcast. I’m your host David subscribe to our blog or to our podcast on your favorite platform to learn more about our work or go to ITOT.Academy to discover our training now if you have been following our blog You’ve probably seen that recently we have published a new industrial data platform capability map where we you know We we talk about the ins and the outs of industrial data

And what we basically do in this article is we break down industrial data into, from a very high level, ingest and rich store expos. And then we convert that into core capabilities and supporting capabilities. Now, ⁓ as it happens to be, our guest today knows quite some ins and outs about the ingestion part, about the connectivity, about the data part. So I’m super happy to ⁓ welcome Kudzai.

Manditereza to talk about industrial connectivity. Welcome.

Kudzai (01:01)
Thank you so much, David, for inviting me onto the show. Really excited to be on here. Looking forward to unpacking more about all the connectivity stuff today. Thank you.

David (01:14)
Absolutely, yes. So, ⁓ Kudzai is the brains and face behind the popular YouTube channel, Industry4.0 TV. That’s also how I came across your work and how we started talking. And he’s also the Senior Industry Solutions Advocate at ⁓ HiveMQ. So, ⁓ before we dive into the connectivity and all the geeky stuff.

Kudzai (01:39)
Thank you.

David (01:39)
⁓

Why don’t you just start with a short introduction from yourself? Could I, where you started, about your steps in your career?

Kudzai (01:48)
Oh yeah, absolutely. Yeah, so I’m well trained as an electronic engineer. Early on in my career, I was into embedded systems design. So, you know, basically, you know, doing some microcontroller programming, peak microcontroller programming that was for a gas detection company. So basically, you know, designing these gas detection instruments that, know, my nice take with them underground when they, know,

going to the different sorts of mines. So that’s of like where I really started out my career. And then from there, I then moved to industrial automation. So I worked for industrial system integrator. So this is where I really started to experience a lot of ⁓ manufacturing technologies. So I was specifically doing PLC programming.

So my first experience with the PLC really was with, fortunately enough, because I was moving from the world of C programming, so it wasn’t easy for me to jump into LAD logic and things like that. So fortunately enough, I was working with Groove, Epic, back then they were still called Snaptex, so that’s from Opto 22, which is a PAC, kind of like a hybrid between a PLC and the computer, which allows you to…

David (02:50)
Yeah.

Kudzai (03:10)
know, write some scripting, you know, technologies. So that was a good segue for me to move from embedded systems into industrial automation. And yeah, I mean, this is where also it became evident for me again, all these inefficiencies as far as know, connectivity is concerned, you know, just know working through, you know, a manufacturing facility and seeing all of these

pen and paper, record keeping. And just the way everything was just siloed and kind of like this is where I started to look into this. ⁓ And back then it wasn’t really, I didn’t kind of think about it as IoT or IoT or IoT connectivity. It was just me wanting to see how best I could get access to data from these POCs.

And then turned out this was actually a thing out there. You know, there was a web that was going through. So this is kind of like where what led me to move more into the IOT space and kind of like start to investigate some more on that. long story short, I started to, you know, work with a lot of technologies, including OPC UA, MQTT.

which is what led me to ⁓ where I am today as far as high-vehicle is concerned, working for high-vehicle as their industry solutions advocate. So yeah, I mean, this is kind of like a nutshell, my background and sort of like, know, doubled down more on the media and education side of things. So kind of like become more of a technology communicator, which is not something that I kind of like thought I would have as a career, but it turned out that this is, know,

David (04:47)
Yeah.

Kudzai (04:57)
This was the path for me.

David (04:58)
Yeah, it was also not really on my bucket list a couple of years ago, all of a sudden it happens, I assume. Anyways, it’s really, really good to have ⁓ your insights also in the industrial community. ⁓ so the topic of today, I was thinking like, how should I introduce this? But I often…

Kudzai (05:09)
yes. Absolutely.

David (05:28)
like to use this term 101 course. Typically it’s a concept from the States, guess, I don’t know, but typically when you go for a 101 course, it’s the introductionary course. So let’s make this into this data connectivity 101 course. We have been in different articles, been talking about protocols and the most important ones are of course OPC.

OPC UA and MQTT today in the industrial connectivity ⁓ domain. ⁓ But we never really touched upon them. We never really explained what they do, what the differences are, where they come from. ⁓ I must say, I still come from the OPCDA and HDA times. I actually remember that back in 2000s,

I think 11, 12, I did some first tests in converting ⁓ some OPCDA connections into OPC UA just to come to the conclusion that almost zero vendors supported it at that point in time. ⁓ And that’s from my perspective, actually a bit the end of my journey because then I really moved to the platform side, the data, the AI side of things. So ⁓ where should we start? Should we start with?

OPC?

Kudzai (06:58)
Yeah, I guess let’s start with the OPC since obviously this is came first as far as the standardized connectivity protocols are concerned. So maybe I think we could start with just to bring some context here with a brief background of exactly where this is all originating from. So I think we.

We tend to think that obviously, the issues of standardizing data, collection or connectivity is something new, but this is something that the industry has been struggling with for a very long time. And so this is also part of what led to the creation of the OPC foundation or kind of like the first OPC, as you mentioned, or OPCDA or OPC Classic, as they would call it. And the problem was basically the same. We’ve got these many

different ⁓ devices and machines on the floor. And the only way to get this data from these devices was to have this each vendor having its own custom ⁓ drivers for a specific device. And then come back the natural thing, obviously there was to say, can we not standardize this, right? And have ⁓ a standardized way of getting data from the shop floor and.

Microsoft, who sort of like the custodians of OPC, turned out to have already done this with the printer drivers, right? So you could literally just use the printer drivers to literally talk to any printer. So the printer manufacturer, they kind of like build all of their drivers into that spec. And then the company took that same, literally that same technology that com, that existed in Windows and kind of like used it for the…

to create this OPC UA server whereby you’re exposing a standardized interface so that when you start to build your HMIs, your scatters and stuff like your historians, you’re connecting through that standardized interface. So that was a huge leap, right, as you would imagine in productivity.

David (09:07)
I

actually didn’t know it came from print. I didn’t know it came from print. That’s actually a cool sidestep.

Kudzai (09:15)
yes, absolutely. Yeah. And kind of like, so that was the OPC classic and for, you know, many years this, I mean, when it was created then, obviously they didn’t kind of like, you know, I mean, that was in 95, internet was just, you know, getting started. So no one even thought that devices would want to communicate over the internet. No one thought that you’d have actually Linux on the shop floor. So all of these things were really, you know, foreign at the time. that was everything.

David (09:39)
Yeah.

Kudzai (09:44)
it worked perfectly, but then sooner it became a constraint, right? Having that operate only on sort of like a Windows ⁓ environment. And it also didn’t have like a, know, a data model, like complex data model, as you will. ⁓ And so kind like that was led to then revising that, just to think about OPC UA, which is a unified architecture that then is more cross platform. And it’s also this ability to, you know, communicate.

over the internet. this was kind of like, you know, to align with more industry forward or technologies or the movement. So that was kind of like the journey for OPC UA. But I think for me, the interesting aspect of OPC UA, so I, unlike you, I started with OPC UA and then kind of like, you know, made my way back to investigate more the OPC classic, right?

David (10:38)
I can’t.

Kudzai (10:41)
But what is really interesting for me with OPC UA, when I came across OPC UA, it was just so astonishing to me how everyone was using it. Wrong is not the right word, but everyone was underutilizing OPC UA. Like 5 % of people were really not maybe using it correctly. And it was more around treating OPC UA

David (11:00)
Yeah.

Kudzai (11:10)
as ⁓ OPCDA but cross platform and kind of like just using it for data access, right? And I kind of like, as I discovered that this has got a very powerful information modeling capability behind it, for me that was really, know, astounding. Even to this day, I think OPC, there’s really no technology that can match the information modeling capabilities of OPCDA. This is kind of like what sets it apart.

David (11:14)
Yeah. Yeah.

Mm-hmm.

Kudzai (11:37)
And so this is what drove me to put together also some series of tutorials on my channel, because I thought this is the information that needed to be out there. A lot of people needed to know all this information more than the capabilities of OPC UA. So obviously, as you imagine, that opened up a whole can of worms, right?

David (11:47)
Mm-hmm.

Yeah,

of course. Can you give an example of such a basic information model? What would be something you typically find?

Kudzai (12:11)
Yeah, so I mean, if you are reading data from your traditional ⁓ protocols like your mod bus and all these other protocols, the data model is kind of like your tag, right? You’ve got that register and that value. So again, obviously, you can pretty much use it in a spare bonus like that. We’re using it to access a specific data point. But when you’re talking about a data model, we’re talking about

the ability to represent an object. because a shop floor is full of objects, you’ve got a pump, you’ve got a compressor, you’ve got this and that. So instead of having these data points being represented as just discrete data points that you just collect, and then if it gets into a database or the IT side, you have to start to rebuild that and say, okay, this one is this temperature, this is the current. Rather,

Data modeling on the standard itself with OPC UA is to kind of like be able to describe objects using the language of OPC UA because it has got this strongly typed language that allows you to then say, this is a variable, this is a type, this is a pump, this is in so on and so forth. And then you’re able to use some references to then link to say this pump actually belongs to this machine. This machine actually belongs to this line.

This one, so you can actually build this complex representation of information.

David (13:44)
So that means that if I am a machine builder and I make a unit, I could actually ship my units with a pre-built data model, which then the user who is installing it, the end user who is installing it at their facility could then without effort ingest that data model in their historians, data, DCS, whatever.

Kudzai (14:12)
yeah, absolutely. And actually, know, the OPC sort of like standard takes it a bit further, but kind of like just to go back to what you said, where, you know, as a company, could say sort of like, you know, talk to your machine builders and say, this is the standard or this is the model that you, we want you to back into whatever machines you supply to us so that it becomes a plug and play scenario within that company where, you know, if it’s a compressor, it follows this certain information model for OPC UA.

David (14:31)
Mm-hmm.

Kudzai (14:42)
then all of our applications are able to automatically pick that up. And we don’t need to custom build interfaces all the time. It’s reusable. But the foundation also took it a step further and said, instead of you being able to do that, let’s also ⁓ create what are called companion specifications, where you’re using the same best information model to then define standardized specifications for each industry vertical. We are able to even reuse it among

many different companies, not within just one company, right?

David (15:14)
And that spec gets maintained by the OPC foundation themselves.

Kudzai (15:19)
Yes, so there’s a working

groups, different kind of working groups. with mechanical engineering, electronic engineering, so robotics. So there’s many different working groups that sort of like take care of these different companion specifications.

David (15:35)
That’s interesting. I have a couple of questions, maybe before we do a deep ⁓ dive in those questions, maybe we should put MQTT next to that because typically many people, use OPC and MQTT in the same sentence. They go like, yeah, we do this or that. So where does MQTT then come from?

Kudzai (15:54)
Yeah, absolutely. And I think that ⁓ DbEd, I mean, that’s an age old DbEd, right? Where OPC UA versus MQTT. And to some extent, I think it’s more misinformed DbEd, right? Because these are kind of like two different tools for two different ⁓ problems, right? So maybe just kind of like give a quick background of MQTT. So MQTT also started in the…

David (16:01)
you

Kudzai (16:21)
all pipeline for monitoring all pipelines, right? So kind of like really for remote monitoring and the challenge there was obviously you have got limited bandwidth on your audio devices. And that was pre, you you know, that was like 99. So like, that was kind of like a huge challenge as far as bandwidth is concerned. they, you know, you know, they wanted to be able to build a protocol that allows them to be able, that is really light on the wire and very, you know, bandwidth efficient.

David (16:24)
Okay.

Yeah.

Kudzai (16:49)
And on top of that, they wanted to have like to move away from this idea of having to pull because if you’re using the client server, you know, approach of, you know, collecting data where you’ve got like a client that pulls the server, again, you’re consuming, you know, bandwidth. So they wanted something that is more, you know, changes that whole paradigm. So that’s why they adopted the publish, subscribe mechanism of communication.

David (17:06)
Yeah.

Kudzai (17:17)
So basically the idea was to say, instead of having a client and the server communicating directly, let’s put an intermediary or man in the middle that kind of like angles, you know, communication between the client and the server. which in this case is the publisher and subscriber, and you can kind of like achieve a bidirectional communication because each client that connects to that central MQTT broker, that server, that mediator can actually become a publisher and a subscriber so they can exchange information.

without having to know anything about each other. So that would come like a huge benefit as far as, know, servings, more specifically on the bandwidth, you know, side of things.

David (17:46)
Yeah.

That’s actually a bit, we compare, we talked about printers going into, I would say OPC. In this case, we can also compare that to early news groups in IT systems, where again, in the 80s, I assume, ⁓ also on the IT side, bandwidth super limited. So this idea of publishing news to a news group and then subscribing to that is actually more than the same, I guess.

Kudzai (18:27)
Oh yeah, absolutely. mean, and it’s a, it’s really interesting because, know, MQTT was like, as I say, founded in 1999 for industrial use cases, but for like 10 years, for like a decade, I would imagine up until, you know, early 2010s, think this is where MQTT started to regain popularity more in the industrial space. between

During that gap, was mostly used in kind of like the IT side of things with companies like Facebook, of course, that are implementing it in this messenger platform. And then it kind of like could gain its popularity into the industrial space in kind of like the 2010s. because more in the IT, this is more where this idea of a published subscribe mechanism was sort of like making sense, I would imagine. I mean, even to this day, there’s still engineers or kind of like people in the industrial space.

who for them it still doesn’t make sense this idea of public subscribe. So traditional was still used to things being directly connected to each other, directly coupled to each other, right?

David (19:35)
Yeah.

And ⁓ the objects, the way you depict objects in OPC, ⁓ from an MQTT perspective, that is not entirely the same. There we talk about topic structures, if I’m correct.

Kudzai (19:56)
Yeah, so absolutely. MQTT is a transportation protocol. So it doesn’t detect what payload structure you should follow. So it of transports your data. And opposed to obviously, which kind of like has got an opinion on how you should model the information. But it’s something that I found.

David (20:04)
Mm-hmm.

Yeah.

Kudzai (20:24)
interesting that still, know, kind of like a lot of people still maybe not may not be, you know, familiar with is a lot more capabilities within the MQTT, you know, protocol that makes it more than just an M2M because, you know, for a long time MQTT was used as a sort of like this M2M, of like you send this data to that. So in a way it was, you know, you’re using it as a

David (20:47)
Yeah.

Kudzai (20:53)
for direct connection from one device to the next. But the MQTT topic, which is a way of addressing information within an MQTT broker, we have using like a hierarchical structure to be able to say, this information belongs to this ⁓ specific root folder, and then you of like create those data access. That is a huge, a very simple ⁓ concept, but kind of like the huge implications to how you structure information.

David (21:06)
Mm-hmm.

Kudzai (21:21)
And it is the reason why it has even led to concepts like the unified namespace being easily associated with MQTT because it kind of just maps nicely to that hierarchical topic structure. Because now you’re moving from this idea of just point to point or this kind of like to ⁓ communication, but just kind of like using that topic structure to share the information as your folder structure, just like how you’d use

David (21:27)
Yeah.

Kudzai (21:50)
a Google Drive, for example, you can just put information in relevant folders so that whenever someone wants to look for information, they can just simply go through those folders and discover all of this information. So that’s of like a huge ⁓ thing about MQTT that I think maybe a lot of people still take for granted to this day.

David (22:11)
From your personal perspective, are there reasons to use one or the other, OPC or MQTT? Because I think in most cases, bandwidth won’t be the big issue anymore. I can imagine that Publish Subscribe is very interesting in certain cases, for example, especially for IoT devices where you…

one communication not towards the IoT device, but from the IoT device towards a broker. But from your experience, would there be reasons why one would choose for one or the other, or is it more about what you already have, what your legacy is, what you’re, I don’t know.

Kudzai (22:54)
Yeah, and I think this is kind of like a good point to address. I think maybe I didn’t quite address your question before to really, again, if anyone can kind of like take something away from this discussion, it’s kind of like this clear ⁓ separation of ⁓ conflict concerns as far as OPC UA and MQG is concerned. So as I mentioned, OPC UA is all about providing a standardized interface for all your

you know, ⁓ shop low objects. you know, it exposes this server, right? That kind of like abstracts all of the implementation of the different PLCs, different, you know, pounds and things like that. And then kind of like it exposes that server that then allows, you know, things like scatter systems to connect into that and then maybe display the data and also kind of like provide that back and forth. And then that works fine.

in sort of like maybe a cell or a line where you’re kind of like this closed loop, know, control process that is, you know, happening, right. But as you then want to sort of like integrate your data across an entire enterprise. Now, if you kind of think about a situation where you have got like thousands and tens of thousands of machines that you want to have a ⁓ unique identity within your entire ecosystem.

and you want to integrate those and connect them into an enterprise or IT system. This is where that tight coupling really just falls apart. So my approach to it is to say you use OPC UA from level 0 up to level 2.

And maybe at level three, this is where typically you want to put your broker, or rather in the demilitarized zone. This way you have got an MQTT that kind of takes over from there and then does the integration with your IT system. So you’ll never control a pump using MQTT, or you never try to open some critical. ⁓

David (24:43)
Yep. Yep.

Kudzai (25:05)
assets or control some critical assets using mktd because it just doesn’t have that feedback.

David (25:10)
it doesn’t have that type

of connectivity you need to do real time control. That’s very interesting one. Because I think that’s also, if I may say so, probably one of the common source of ⁓ misinformation or at least people not really understanding the difference as well enough is that in this…

Kudzai (25:16)
Exactly.

David (25:40)
closed loop control ⁓ situations. You don’t want to build something where you have to publish something into the broker and then the divide itself needs to keep on pulling for the request. The request, the result, I’m sorry, the result of course.

Kudzai (25:57)
yes, absolutely.

yeah, yeah, mean, exactly. this is where, you know, for example, it would make sense if you wanna, you know, adjust some, some settings. So maybe you’ve got a setting that is coming from your MES system or whatever system, maybe it’s going to the DCS system. So maybe that’s not really a critical set point. No Solrack system is pulling and waiting for it that you could have that information coming down from your MQTT, you know, broker down into the…

David (26:23)
Yep.

Yep.

Kudzai (26:30)
sort of like, know, control environment as it were, but not interfacing directly to, you know, opening your critical equipment.

David (26:36)
No,

because for example, if you take that example, the DCS system, it knows, it can get at certain points in time, it can get a new set point or a request to produce a recipe or whatever. So in that case, you’re implementing the logic to wait for that message in the DCS or the SCADA system, but then…

Kudzai (26:59)
Yes.

David (27:05)
If you’re then cascading that down, then indeed you come into the real time part. But that’s a very important one. I think that’s misunderstood by many people.

Kudzai (27:09)
Yes, absolutely, 100%.

Oh yeah, absolutely. And also, the huge misunderstanding, and also one of things that I kind of like tried to, you know, paint, you know, I do a kind of like a whole lot of, you know, evangelism and thought leadership around unified namespace. And one of the things that I kind of like tried to point is that MQTT is, you know, or the unified namespace by, whatever. I mean, I think maybe let’s stick to MQTT because unified namespace, you know, I feel it is, it’s a…

It’s been contested a lot, right? There’s different, you know, versions of what a unified namespace is, right? So, rather this ability to be able to exchange events, right? This ability to exchange events in an event, something that has been done in IT for a long time where if, for example, you mentioned the idea of a, know, a recipe set point, and then maybe the DCS system has finished, you know, making whatever it is making, and then it kind of like, you know, raises that as an event.

It’s not really waiting to know if someone receives it or acknowledges, but it can share that information as an event to the MQTT broker. And then that’s very important information. if a machine breaks down, that is an event. That information is shared into the MQTT broker. So at the end of the day, you end up having that current state of your business. You know the state of every machine.

You know the state of every application, but you don’t necessarily need to control how it performs this operation. So your unified namespace is kind of like that snapshot that gives you that snapshot of your current state of your information. And MQTT is very good at doing that, holding that real time events of your business.

David (29:07)
And actually just the fact that you mentioned events makes me also, I look to most implementations I see where a SCADA or a DCS ⁓ is getting information from a ⁓ third party source, we gave Recipe as an example, but for example, quality data.

That’s also something I often see where, you know, you have, example, have a lab system, a lab technician makes, ⁓ does something, measures something, and then you wanna feed back that quality information into the DCS to then use that for an advanced control algorithm or an optimizer or just change a set point or whatever. Most of those interfaces today are just file-based.

It’s like a file on FTP server, which you keep on pulling, or it’s an XML. ⁓ But just, I think, having a better understanding of event-driven architectures, which IT is really good at. If the IT world wouldn’t have an event-driven architecture, the entire internet would collapse, basically. But in OT, we seem to miss that boat, or at least many of us seem to have missed that boat.

I that’s, yeah, I don’t know if you have something else to say, but it’s just like a personal rant here at this point.

Kudzai (30:39)
yes, absolutely.

know, absolutely. it’s a, like I said, it is something that is difficult to wrap your head around, you know, maybe if you’re kind of like thinking about it for the first time, because you are thinking about this mentality where applications need to actively reach down to the shop floor and ask for information and get information rather. Rather this idea of event-driven architecture to say, you don’t need to think that way. Rather you need to kind like just

push those events to that event broker that kind of holds all of that information and then that can be reused for many different purposes. And this is where also one big ⁓ misconception about the unified namespace where a lot of people still don’t understand this idea that you reuse data, right? Because we have not…

We have not thought about data as an asset, obviously, in the industrial space. But the ability to reuse data is a huge factor. So you don’t need to always do some heavy lifting whenever you want to address a data use case. You always need to set up the connectivity infrastructure. You can actually do that definition of your events, definition of your enterprise, and then start to reuse that data for many different purposes. And then Carpath gives you that

David (31:58)
Yeah.

Kudzai (32:08)
agility or that speed to be able to ⁓ address all the use cases.

David (32:12)
It’s this platform product type of thinking. Again, something super common in the IT world where you, okay, maybe not the best example, but let’s take OpenAI and ChatGPT as an example. They have something, they have a backbone and they just say to everybody who wants to build some application on top of it, you know, just do, here is the definition, here are the APIs, here is the cost, of course as well. And just build on top of that. And I think…

If you have that availability, suppose that I need to ⁓ build my own LLM first or install LLM software or whatever, then probably I won’t start. But if I can just link to the Chatch GPT API, then I can start building whatever I want very easily. And I think the same is true. And I like the fact that you say that, and I just want to emphasize that as well, is that this scaling approach.

is so important in the industry as well. And I think that’s also one of the major reasons why real transformation, real digital transformation is going slow. ⁓ If you came across examples where, yeah, good or bad or something to share in that aspect as well.

Kudzai (33:31)
Yeah, I mean, well, I think this is a common issue, kind of like the lake, the sort of like the… So we have spoken to some companies here who had initially, you know, had a projection. So the company had a list of use cases that they want to address. And then their projection, I might be wrong about the numbers, but the contract gives you a clear, you know, ballpark where they you know, projected about 10 years to take them to address those use cases.

But as soon as they started to think differently about data reuse, that dramatically went down to like three years, like when they address those use cases. So it could be wrong about the numbers, but that gives you kind of like that of exactly how that shift sort of like allows that scale and speed for you to be able to implement.

David (34:13)
It’s, yeah.

Scaling and thinking in terms of scale is so important. And I think this is also a perfect ending of this episode. Before we close, ⁓ we did a podcast a while ago with the authors of the book, ⁓ Unbundling the Enterprise. And that podcast was ⁓ all about scale and a concept they call happy accidents. What they mean with a happy accident is if you have a platform, ⁓ then

accidentally finding something which makes sense suddenly becomes really easy. So for those listeners who haven’t listened to Unbundling the Enterprise, ⁓ make sure to do so. ⁓ That’s a wrap for this episode of the ITOT Insider podcast. ⁓ Yeah, Kudzai, thank you so much for ⁓ sharing your insights.

Kudzai (35:10)
Absolutely. Thank you so much for the invitation. Really enjoyed the conversation.

David (35:15)
And course also to our listeners, thank you for tuning in. If you enjoyed the conversation, don’t forget to subscribe. ⁓ You can find all links to all platforms on itotinsider.com and see you next time for more insights in bridging IT and OT and until then take care, bye bye.