Architecting a Unified Namespace for IIoT

Webinar Overview

Building a Unified Namespace (UNS) can help industrial companies digitally transform into data-driven businesses. Legacy architectures are full of point-to-point connections and modernization requires an interoperable framework for seamless data exchange across various platforms and applications. Building a UNS can accelerate Industry 4.0 outcomes from improved customer experiences, to operational efficiency, to digital twin use cases.

Watch this webinar to learn more about how the customers we work with at HiveMQ are architecting their Unified Namespace. We’ll share lessons learned and best practices to help viewers gain practical knowledge they can apply in their own deployments.

Learn how building a UNS can help your organization:

• Bridge the gap from OT to IT

• Create a framework for agility and scalability

• Prepare for complex use cases such as AI/ML and advanced analytics

Key Takeaways

• The Unified Namespace (UNS) is a way to integrate data from disparate industrial systems into a common data infrastructure using MQTT, allowing companies to rapidly innovate and address different use cases without having to set up new connectivity each time.

• Traditional industrial data integration involves point-to-point connections between systems, leading to a complex "spaghetti" architecture that is difficult to manage and scale as new use cases arise.

• The UNS follows an "Edge-driven" approach where data is published from its originating sources (Edge) into the common MQTT data infrastructure, creating a real-time snapshot of the current state and events across the business operations.

• The UNS promotes an open architecture, allowing companies to choose best-in-class tools for each use case rather than being locked into a vertically integrated solution.

• Companies can semantically structure the UNS hierarchy based on existing organizational or industry standards like ISA95, making data discovery and consumption intuitive across IT and OT domains.

• An IIoT platform or data operations layer contextualizes, normalizes, and models raw data from disparate sources before publishing it into consumable functional namespaces within the UNS.

• The UNS enables automatic discovery of new assets, lines, or areas as they are commissioned, providing real-time visibility across the enterprise without manual integration efforts.

• Security and access control are critical for maintaining data trust and integrity within the UNS, with HiveMQ extensions enabling authentication, authorization and role-based permissions management.

• Attendees may be interested in downloading our eBook on the same topic, Architecting a Unified Namespace for IIoT with MQTT.

Transcript

Introduction

Erin Musselman:  00:00:06.418 okay. I am going to start it so people can start coming in.

[silence]

Erin Musselman: 00:00:41.838 Hello. My name is Erin Musselman, and I'm on the marketing team here at HiveMQ. Welcome. Good morning, good afternoon, and good evening to everyone joining our webinar today. At the bottom of your screen, you should be able to see your Zoom toolbar. And there you can find your Zoom controls such as chat, Q&A, and all the other tools. If you have any questions during the session for the speakers, please use the Q&A box. That just helps us keep things organized a bit more. And then for discussion with either the host, the panelists, or any of your fellow audience members, you can use the chat box. If you have any issues that come up technically during the webinar or anything on your end isn't working, please send me a private message, and then I'll be able to help you directly. And now without further ado, I'm going to pass things over to the speakers, starting with Kudzai, so they can introduce themselves and kick things off. Thank you again for joining, and I hope you enjoy the session and the content. 

Kudzai Manditereza: 00:01:34.831 Thank you, Erin. And welcome, everyone, to our webinar today, where we'll be talking about how to architect a Unified Namespace for IIoT. So today, I'm joined by my colleague, Ryan, who's going to be supporting me on this webinar. My name is Kudzai Manditereza. I'm a developer advocate here at HiveMQ. I do all of the evangelism around smart manufacturing, and I also provide subject-matter expertise when it comes to the topic of the Unified Namespace and smart manufacturing in general. So I'll let Ryan introduce yourself.

Ryan Dussiaume: 00:02:14.721 Hi, everyone. My name is Ryan Dussiaume. I'm a solutions engineer here at HiveMQ, and I work with quite a few of our customers who are Industry 4.0 focused and using the Unified Namespace concept in their implementations. And so great to be here with you, Erin, and Kudzai, and looking forward to the discussion. Thanks.

Kudzai Manditereza: 00:02:41.109 Awesome. Okay. So as you all can see from the title of this webinar, really it's going to be about how to architect a Unified Namespace. I know we've put out a lot of content over the years about a Unified Namespace. So the purpose of this session really is to kind of show you what exactly it looks like. So we've got a demo simulation of a Unified Namespace. And the idea really here is to kind of take you through the phases of how to build out that data structure, how to model your data, and how to kind of really architect your Unified Namespace. And that we're going to do in the second half of this session. So please do make sure that you stick around for that. In the first half of this session, we're kind of like just going to start with the Unified Namespace principles. For some of you, who have never come across the idea of a Unified Namespace, this is kind of an opportunity for you to actually be on the same page as us. And for all of you who have an idea of what the Unified Namespace is, this is kind of a refresher to kind of really understand it in depth and also the value proposition of it. So we're also going to talk about a case study of one of our customers who are implementing the Unified Namespace, and then we're also going to open up for Q&A at the end of this session. So again, as I mentioned, Ryan is going to be supporting me throughout this session. So he's also going to be weighing in on all of the points that we're going to be bringing up as far as the Unified Namespace based on what he's seeing out there from our clients and all. So without further ado, let's get started. And to kick us off here, I'll give this over to Ryan to talk about HiveMQ and our product portfolio.

HiveMQ and Its Product Portfolio

Ryan Dussiaume: 00:04:34.499 Okay. Thanks, Kudzai. So yeah. Just a high-level summary of what is the HiveMQ Platform, what do we do, how does it relate to the Unified Namespace. And so at its core, we're an MQTT broker, and that's what you see there in the center. But that broker has lots of features in it that are in support of enterprise scale and reliability. And this is an essential component of the Unified Namespace because when you have a single source of truth and you need to rely on being able to get that data and get that data at scale. And while it's moving through your organization in real time and at different levels of your network topology, these features of the broker are what bring that capability to the Unified Namespace. And those are namely the ability to cluster for high availability and reliable message delivery, having observability of everything that's going on in the platform with things like our control center and our metrics, being able to format that data in a way that's expected by all the parties that are tapping into the Unified Namespace to get that information. And then our extension system enabling these additional capabilities on top of that architecture for things like integrating with streaming platforms, databases, different security services, and custom applications. 

Ryan Dussiaume: 00:06:19.368 And one of the main extensions that applies really well to the Unified Namespace concept is our Bridge Extension, which enables the Unified Namespace to span different sections of your network topology by bridging broker clusters together. And so I'd also mention here our HiveMQ Edge platform, which is all about being able to tap into those industrial protocols and convert that into MQTT and have that data come into our HiveMQ Platform. So we've worked in quite a few industries. It's a really interesting job to have, personally, because we're always talking to all kinds of different customers in different verticals. We grew up in the connected car space. We have quite a few connected car customers and lots of device companies like commercial device companies. Let's say you have a smart fridge, for example. And I consider all these things to be kind of like that Internet of Things world, where we also have an industrial internet of things world where HiveMQ works with companies that are doing things like manufacturing or energy production and transportation, smart warehousing, and all those kinds of industrial use cases. And those are primarily the types of use cases that we'll be talking about today. And so I'll pass it back over to Kudzai, who's going to start us off by talking about the motivation for why you'd use MQTT in those types of use cases.

Computer Integrated Manufacturing Pyramid (CIM)

Kudzai Manditereza: 00:08:05.756 Awesome. Thanks. Thanks, Ryan. Okay, so to kind of start here, I'm sure a lot of you on this call have come across this automation pyramid, which is kind of like the way that currently all assets or production systems are arranged in many industrial settings. This is kind of like what you call the [inaudible] model where you've got different levels from level 0 up to level 5. So this is kind of like the situation or the setup that is there in the manufacturing world today. So what I want to talk about here is why do you really need to adopt the Unified Namespace? Because this is something that I believe a lot of manufacturers or a lot of companies still don't quite get or still understand what the value proposition is there. So based on the automation pyramid that I just showed in the previous example, the convention for traditional companies is to kind of just continue building on top of that tiered approach of integrating systems. So what that means is that whenever you bring in a new predictive analytics app or energy efficiency app or whatever it is, the application that you are bringing into the system — you simply kind of like just include it into that tiered approach. And for you to get data from the shop floor into all those systems, this is the kind of picture that is involved as far as getting the data out through all these different layers.

Traditional Industrial Data Integration

Kudzai Manditereza: 00:09:41.791 As you can see, these systems have got some point-to-point integrations. And in some cases, you've got some MES systems that are not connected into a SCADA system. There's still paper-based kind of information exchange there. But the point is that for you to address a data use case currently with this kind of setup, what that involves is many different stakeholders. You need PLC experts who know how to get data out of your PLCs. You need some SCADA experts that know how to get data from SCADA, MES experts, and also from ERP experts. So each time you need to address a simple use case, you need to go through that process. So this is a very long process. For some of you who work in industrial companies, it would take months just to kind of really set this connectivity infrastructure just for you to get data out into a platform where you want to kind of get value out of that data. And even if you do go through that process of setting up that connectivity infrastructure for one data use case, tomorrow you come up with a different use case, and you need to go through the step of replicating the connectivity infrastructure, which is a costly exercise, and it takes a lot of time. So the time-to-value for a lot of companies that go down that digital transformation path can end up really leading up to years and expensive. And that's the reason why we've seen a lot of companies not really realizing value out of their digital transformation efforts because it's costly and it takes time just to kind of really prototype and be able to prove some concepts.

Kudzai Manditereza: 00:11:27.258 Because in many cases, data use cases or innovation within a company starts with an idea. It starts with a hypothesis to say, "What if we could better run this line or how else could we better manage these assets?" Right? So for you to prove a hypothesis, you want to be able to simply plug in some system and be able to kind of do that within a matter of days. You don't want that to be like a five-month-long process for you to be able to prove that. And with this kind of approach, this is basically what we're seeing out there. A lot of companies that are not getting their value in time. And even if you do create all these data use cases and connect all these different applications together using your point-to-point data integration, what that does is it ends up creating this spaghetti architecture where you've got everything being directly connected to every other application. Your application is directly connected to devices, and they actually tightly coupled to that specific API implementation or SDK implementation. So this is a very difficult architecture to manage. This is a very difficult architecture to scale. As you can see, because you've got this whole complex setup. And if you need to bring in a different data use case or a different application, now you need to connect to more than one service just to get value out of your data. So — 

Ryan Dussiaume: 00:13:06.057 Yeah. Just to add to that Kudzai, if I could, on the previous two slides, one of those big things that you were referring to — I mean, you made many good points about kind of the friction of having that agile way of developing on top of that data. A big piece of friction there is from a security standpoint when you're making these point-to-point connections, especially when you're connecting down from the IT networks into the OT networks. What we've seen quite a bit with customers is they're bringing in their security teams or security experts to look at how they can become more agile from a security standpoint and not having to provision, let's say, every user or every application or every piece of infrastructure that needs to then access the OT data. And so that's a big hurdle we see that can be addressed with this approach as well.

UNS Principles

Foundations of Unified Namespace

Kudzai Manditereza: 00:14:11.514 Awesome. Thanks, Ryan. So yeah, the idea really of a Unified Namespace is to say, instead of having all these point-to-point integrations, instead of having to set up infrastructure, the connectivity infrastructure, each time you need to address a different use case. The idea of a Unified Namespace is to do that one-time setup where you connect all of your production assets into a common data infrastructure, which then allows you to reuse that data as you address the different data use cases that arise. This allows you as a company to be really — to rapidly innovate all the different use cases that you come up with and also be very competitive whether you're addressing energy efficiency use case or whether it's OEE, predictive analytics. Once you have all of your data in one common repository, you're then able to tap into that data or information and then be able to address all the different use cases as they arise. And the idea of the Unified Namespace also is that data is being published from the source, from all the originating sources into the common data infrastructure from the Edge, which is otherwise known as an Edge-driven idea. And what that does is that if data is actually being published from originating sources, from all ends into a common data infrastructure, it then creates that snapshot, a real-time snapshot of the current state and events of your entire business. 

Kudzai Manditereza: 00:15:42.848 And this is very important because then it allows you to build your business models around that data infrastructure — because what you're looking at is the current state of your entire business operations or entire operations in your shop floor. And then the idea that it is based on an open architecture, having MQTT as the center or as that technology that holds your Unified Namespace, promotes this idea of an open architecture. And what that means is that as you go through your digital transformation and you start to address different use cases, you're then able to kind of pick the best-in-class tools for whatever problem it is that you want to solve. So if you were doing this in a conventional approach, say using a vertical integrated state, you could only deal with the tools that are at your — or that integrate with that specific vertical solution. You're not at liberty to choose whatever tool it is that you believe will help you really solve that problem to the best of its abilities. And also, the idea that it's Report by Exception and lightweight means that this really is a scalable and is also very light on the wire. Now, this is kind of a high-level, somewhat oversimplified view of the Unified Namespace where you've got your MQTT broker sitting in the middle there. And then you've got your system from the IT and your system from the OT all plugging into that common data infrastructure and pushing data there. So you're kind of really creating a shared repository of information for OT and IT. 

Kudzai Manditereza: 00:17:23.948 Now, the IT side of things doesn't really need to know the implementation details of exactly what systems are providing that data on the shop floor side of things. They don't need to know any OPC UA server addresses, any Modbus registers. They are simply communicating through that data abstraction, which kind of really creates that decoupled approach to building your architecture as you will see shortly when I show you the example of a Unified Namespace. Now, I mentioned on the previous slide that this is oversimplified architecture because there's a lot more to it. So as you push data from all the different PLCs or systems, in many cases, a lot of PLCs don't natively support MQTT already. So what that means is that you are probably going to need some gateway or some converter that converts from one protocol and then do some contextualization and then publish that information into the MQTT broker. So essentially, there are two key components that make up a Unified Namespace. It is the broker itself, and then it is, what you would call, an information gateway or an IIoT platform that collects data, contextualizes it, because if data is moving from one platform into the next, it definitely needs to be contextualized so that it can be interpreted in the same way across your entire enterprise. So this could be with a standalone information gateway or IIoT platform.

The Core of UNS and Data Historization in UNS

Kudzai Manditereza: 00:19:00.181 Or for example, with HiveMQ Data Hub, we've kind of started to build in some of those IIoT capabilities within Data Hub itself that allows you to, for example, normalize the data or transform the data or simply do a validation of the data to see if all these producers of information are actually conforming to the predefined structure, which then kind of really avoids technical debt for downstream applications that want to consume that information. So as you can see, we are tapping into all the different systems from PLCs, Fiat Files, SQL, or OSI PI, or ERAP, MES, whatever system it is that you want to get data from and bring into the Unified Namespace. You're going to need that intermediary platform that does the conversion, and then you're going to then end up with a Unified Namespace. So again, a lot of questions that come up when you talk about the idea of a Unified Namespace is the idea of historical access. So from a conceptual standpoint, the Unified Namespace itself doesn't give you history, right? The Unified Namespace gives you real-time data, real-time events, right? And current state, and also consumer-aligned data. So what then you need to do is to kind of connect a historian or time series database to then tap into the Unified Namespace and then persist that information. Now, the big difference of having to tap into the Unified Namespace for historical data is that we are now consuming contextualized, normalized data, and unified data, which really makes it easy for applications that need to visualize that. Or if you want to train some machine learning models using that, you already have that information. This is different from a conventional approach where information is just collected from PLCs, and it's pumped into the cloud to some data lake or data warehouse where it doesn't have any context whatsoever. And then kind of shifting that problem for OT into IT. And it makes it worse because the IT folks, in most cases, they don't really know what PLC tag needs to be at what position or it's coming from what machine.

Transaction Data to Events in UNS

Kudzai Manditereza: 00:21:13.139 So it's very important to have that abstraction that does the contextualization and persist information into the database. And then again, you are going to have some transactional information that you need to get out of some external systems and bring into the Unified Namespace. So this could be, for example, you want to go into a historian and then get information like what was the rate of production in the last five days. And that information is important for real-time operations. So what you do is you kind of perform that transaction and then publish that information as an event into the Unified Namespace. So Unified Namespace holds all of that current state of your information, as you will see shortly when we go into the demo.

Reference Architecture Model

Kudzai Manditereza: 00:22:03.622 Now, this is kind of also a reference architecture model of Unified Namespace to show you exactly what potentially different components you could put together for you to build that Unified Namespace. So the Unified Namespace is more of a distributed architecture, as you can see here. And what that means is that in many cases — actually, this is what we see from a lot of our companies. And I'm sure Ryan will be happy to weigh in on this, where what they're doing is they're having an MQTT broker on each specific site that holds that local Unified Namespace and then have an enterprise broker that is where all of these different sites are pushing data or bridging that information into an enterprise to kind of give that real-time data access at an enterprise level. So whenever there's sort of a disruption of that connection between the edge and the cloud, this still doesn't affect the Unified Namespace — is actually on-site. So you still operate as normal. And then data is then aggregated into the enterprise. And this is mainly for purposes whereby it's not always the case that you've got some enterprise information that needs to end down in a PLC. So that might not be of interest to an automation engineer or to a PLC to get that information. So you've got this distributed architecture where you've got different Unified Namespaces that are aggregating information into an enterprise-wide Unified Namespace. And then you have — 

Ryan Dussiaume: 00:23:38.465 [inaudible].

Kudzai Manditereza: 00:23:39.452 Yeah, sure. You want to jump in?

Ryan Dussiaume: 00:23:41.641 Oh, yeah. Yeah. Sure. I would just say, yeah. I mean, this is how you create that Unified Namespace that really spans the different levels of your network topology. What Kudzai is showing here is typically using our Bridge Extension to connect to different HiveMQ clusters that are not co-located. They're at different locations, typically. And why is that? Why is MQTT used for that? Well, if you think about the Internet of Things, where you typically have little devices, and sometimes you have mobile applications on your phones. And that's what people normally think of when they think of the Internet of Things, they think of those small devices. But what we see quite a bit in terms of the use of MQTT is not only to connect those small devices but to connect distributed systems. And this is really what we're doing here. We have that central MQTT broker, and then we have a lot of other brokers that are distributed at different sites. And the MQTT protocol is used to connect them so that there's reliable real-time data. It's like a reliable real-time data backbone for your organization. And in that case, the things are all of these different sites, right, as opposed to a device. And so this is why MQTT is so effective in this kind of architecture. 

Kudzai Manditereza: 00:25:16.301 Awesome. And then, to bring in that data into that local Unified Namespace, again, as I mentioned, you might have an IIoT platform or, what you'd call, a DataOps layer that connects to all these different systems and then publishes that information into the Unified Namespace. And you might also have connectivity software like HiveMQ that allows you to connect to different protocols, pull data out from Modbus, OPC UA, and also some sensors — that may talk MQTT natively — are able to kind of push that data to that line level as it were. And then that information is then breached into that Site UNS. And then you could have some systems like KepserverEX that may have MQTT connectivity. But they don't give you access. You don't have control over the payload that is transmitted. So simply, information is being put into the broker. We then want to be able to subscribe to the broker and then re-contextualize that information and publish it back or use Data Hub that is built into the broker to then kind of rename the topics or rename the payload and all things like that. And also, if you happen to have Kepserver installed, still HiveMQ is able to tap into it also through OPC UA interface that Kepserver exposes. And the benefit, really, here of having HiveMQ do that is then you have got Data Hub also installed in HiveMQ that then allows you to filter through this data, validate the data, contextualize it at the Edge before it even leaves the Edge going into the broker. So in your local Unified Namespace or site Unified Namespace, you've got all your clean data there.

Semantically Structuring UNS Hierarchy

Kudzai Manditereza: 00:27:05.354 So again, I'm just going to go quickly through this one. This is the picture also that shows you that in a Unified Namespace, again, this is also a common misconception where a lot of companies think that going the MQTT route or the Unified Namespace route means that they need to rip out whatever they've got and replace it with MQTT. This is basically not the case. So you're still going to have your point-to-point connections, right? You're still going to have — Unified Namespace is a non-destructive approach to data integration. You're simply tapping into your existing infrastructure and then publishing that data into your Unified Namespace. So you're still going to have some point-to-point connections on the Edge. And then for integration with your IT side, this is where that data is converted into MQTT. And then, as you can see, it is then placed strategically within the MQTT broker using the topic namespace to kind of really organize it in the way that it is intuitively understood by anyone who understands the organizational structure, because that's basically how you typically structure your Unified Namespace. And then there are no really hard and fast rules as how you could actually name or use the MQTT topic structure to create the hierarchical levels, but these are recommendations around adopting already existing standards, like the ISA95, where you're using the enterprise, site, area, line, and cell convention to kind of create buckets of information based on where your assets reside within that asset model.

Kudzai Manditereza: 00:28:44.922 And then again, this is also a picture that shows you exactly how it looks like using an example company that has got different areas here and then showing you all these different events that are being published into that specific hierarchical level. And then, again, this gives you a picture of what that semantic hierarchy looks like. So you could have an enterprise level with different areas here. And then you've got different namespaces within different levels of the hierarchy. And then these are the different examples that you could see here. So maybe I think this is also a good point to then jump into the demo to show you exactly what that looks like in practice. So before we do that, I'll simply kind of just talk through one of our customers who are implementing the Unified Namespace. So it's Anglian Water, which is the largest water and water recycling company in the UK. So if you want to read more about this case study here, we'll provide a link where you can then go and find out and read more about how exactly they're doing it, and also a video of them talking about why they find MQTT or Unified Namespace to be really transformational as to how they are improving their operations.

Case Study of Customer Implementing UNS

Kudzai Manditereza: 00:30:04.231 So the main challenge that Anglian Water really wanted to address when they were investigating the Unified Namespace was they wanted to really improve their customer service and also operational efficiency and also kind of just really the environmental performance. And this meant that they needed to bring all this data from all these disparate sources into a single source of truth, into that one common repository of information where then they could be able to tap into that information and be able to address all these different use cases or objectives that they want to do. So the solution, again, was to kind of use IBMQ as that platform, that data infrastructure to which they collect MQTT information and publish it and build that Unified Namespace or that single source of truth of data that allows them to then tap into that information, whether it's IT or OT side of things, they're then able to share that information and then be able to rapidly innovate to address all these different use cases that they want to address. And the result that they got out of that really was that they now are getting a better insight into the performance of their assets. And then also, as I mentioned, that integration between IT and OT environments, that friction has been eliminated. Now we've got this seamless kind of interaction through this abstraction. And then also, as Ryan alluded to, this really helps them maintain a high level of security. Okay. So now let's quickly jump into the demo.

[silence]

Demo: Live Unified Namespace

Kudzai Manditereza: 00:32:07.979 Okay. Ryan, just give me a thumbs up if you can see my screen. Awesome. Okay. So what I'm going to show you right now is a live Unified Namespace. So this data is simulated. And then this kind of really is meant to kind of give you an idea or a guidance as to exactly how you could architect your Unified Namespace. And then this will also really connect the dots if you're still struggling to understand what the Unified Namespace is concretely, right? So what you see here is an MQTT Explorer. So I'm connected to a HiveMQ Broker using MQTT Explorer. And then here, I've got a namespace that is being published into that specific broker. So as you can see, I've got a fictional company here called Global Industries. And this company could have many sites, but here we're actually showing one site, which is Munich. So it could have many different sites across the world. So now if we go into Munich, so this is a simulation of a batch plant. So typically, in a batch plant, you've got different areas of production. You've got your blending area. You've got your storage area. You've got your filling area, and you've got your packaging area. And you could have many more areas. Now, this is also a very important part to mention one of the compelling aspects of the Unified Namespace — this idea of automatic data discovery or automatic discovery of information. 

Kudzai Manditereza: 00:33:40.390 So as you can see here, I've got a Munich site and under Munich site, I've got four areas. Now, suppose we've just commissioned a new area within that specific site. So as soon as you plug in information from that site, it will automatically show up here. So what that means is that across your entire enterprise, whoever is connected to that one broker endpoint can immediately be notified or discover that a new area has actually been commissioned into line. Now, think of the savings in both time and cost if this had to be done manually to kind of really discover all of this information from different areas of enterprise, whether it's OT or IT. Now, by subscribing to that MQTT broker, that Unified Namespace, we're able to automatically discover all lines, all PLCs, everything that is plugged in, it will immediately show up here, and you can immediately consume information. So that's the first big compelling thing about the Unified Namespace. Now, again, there are no really hard and fast rules around the Unified Namespace or exactly how you need to structure it. So this could be different areas that you are mentioning here. So if I go into the blending area here, you could see I've got Line1. So I could have many lines again. So I could have Line1 up to Line5 — so depending on what is the current reality within your shop floor. So if I go into Line1 — so now as you may already see, I'm actually following that ISA95 Enterprise, Site, Area, Line. 

Kudzai Manditereza: 00:35:25.407 So once you get into your line, again, you want to have, first of all, a namespace where you're getting all of your raw data. So as I mentioned previously, you're not always in control of the MQTT data that is incident on your broker. So you want to have a namespace. So if we go into Edge here, I've got a namespace that is coming, say, from HiveMQ Edge. So suppose I've got a HiveMQ Edge installation in my factory, and I've got MQTT messages that are being converted, say, from OPC UA, and then they're being converted by HiveMQ Edge, and they're being published into the MQTT broker. I may not already know what I want to use that information for. That's the whole idea of the Unified Namespace — it’s that you don't make assumptions about what you're going to do with that data. You collect the data, arrange it in a semantically understood namespace. And then as you discover the problems, as you kind of conceptualize your data use cases, you're then able to find information that you need in a matter of minutes or seconds, literally, just to get that information and then be able to address all the different use cases. So if I go into HiveMQ Edge, for example, here you could see I'm connected directly to PLC tags. So this could be coming from OPC UA, Modbus, but now I have them under the HiveMQ Edge namespace. So I've abstracted all of those industrial protocols. All of this information is actually coming through as information that is coming through from HiveMQ Edge.

Kudzai Manditereza: 00:37:02.239 But as you can see, these are all still just discrete data points, right, even though they've now been abstracted. So same applies. If I go into Kepserver, I've got data that is also coming through from my Kepserver instance. And again, these are all discrete components. But again, here, you'll notice that I might have, for example, here in my simulation of a batch plant, I've got level transmitters for my silos. I've got four silos, and then they've got level transmitters. As you'll see here, I've got LT_01 up to 4. As you know, some of you work in the automation space. This is typically how an automation engineer would name things inside the PLC. So this might be coming from a system where you've got no control over how that information lands in your broker. So you want to first put that information in that namespace where you know this is data that is coming from a Kepserver. This is the naming convention. But now, once you've got all of your information here that is coming from all these different systems, you now want to create some consumable information. You now want to create some namespaces as it was some functional namespaces that allow this information to be readily consumed by many different applications. So the first example here that I have is to say, now in your line, perhaps you've got a mixer, right? I've got a mixer in that specific line. Now I've created a Mixer1 namespace. So I could have many mixers there. So if I could go into mixers, I can then find out all of the information about this specific mixer. So I could go and find out the process parameters. What are the process parameters that are currently going on in the mixer? So I need to find out what is the agitator speed for my mixer. I need to find out what is the current weight. 

Kudzai Manditereza: 00:38:50.032 So this is information that would be coming through a large cell or whatever measurement mechanism you're using to measure the current product that is within the mixer. I need to find out the temperature of the product, the pressure of the product. So these are the process parameters. Now, this is information that could be coming from that raw data that I'm collecting using HiveMQ Edge or Kepserver, or it could be data that is coming from an IIoT platform that has been contextualized. Now, you could see here, now I'm giving it names where it's now agitator speed or weight. It no longer has that PLC kind of like convention about it. And this data is now being published for the sole purpose of consumption. So this could be the data that is of interest to a process engineer. So a process engineer wants to get these parameters, then they know that if I need to know about process parameters of Mixer1, this is where I go to get that information. Now, think about the power of that information to say: "If I'm a process engineer, I don't need to know anything about the source of the data. All I need to know is how our organization is organized semantically. I know I need to go into Munich. I know I need to go into the blending area. I know I need to go into Line1. I know I need to go into Mixer1, and then I'll find the data that I need to then do whatever it is that I want to perform. Whether I just want to historize this information or I want to trend it. And then I want to correlate this information with data that's coming from another mixer in the same plant or in a different plant. I've got all of this information already in a functional namespace that allows me to use that information straight away without having to rely on anything else." 

Kudzai Manditereza: 00:40:36.808 And again, here, I've got machine parameters. Here, I've got data about a specific machine. So this could be of interest to a maintenance engineer who wants to get information about this specific mixer. What is the current state? What is the vibration of this mixer? What is the speed of this mixer? So as you can see, this maybe might not be information that is of interest to a process engineer, but now it has been created for the sole purpose of consumption by a maintenance engineer, or whoever is interested in this information about the machine itself and not the process. So as you can see, now we are reusing your data to create different functional namespaces for different consumption use cases. So again, you could have batch events. You could have alarms, whoever is interested in consuming alarms. And you could also have information about this specific machine. So you want to know about the serial number, or maybe you want to put some calibration information, when was it last calibrated, who calibrated it. So I mean, as you start to think about this whole thing, you are finding all of this information that you care about, irrespective of who you are, OT or IT. You find all of that information in a semantically understood arrangement and in a way that it has already been contextualized and normalized. And if it so happens that you have got a predictive analytics application, so you want to perform some predictions on your mixer or the component of a mixer. You want to know when a specific motor is going to, or when a specific mixer is going to fail, or you want to kind of monitor that. You're then able to create a predictive analytics namespace within the mixer itself, so that a predictive analytics application that wants to monitor the condition of all motors or all mixers knows exactly where to go to find the information it needs to perform that.

Kudzai Manditereza: 00:42:30.139 And then here, again, you can see that this data model has been created for the sole purpose of being consumed by a predictive analytics application. So I'm calculating the average current, the vibration, and then I'm also specifying what is the current material that is being produced. So maybe this information is important. Maybe the viscosity of the product is what's causing the mixer to fail. I don't know. So the power of the unified analysis is that it allows you to arrange information based on how you want to use it. Now, bear in mind, this is information where you've defined the structure. You've defined these events. You've defined these models once and only once. And now we are reusing this information and creating for many different data use cases. You can already imagine the speed at which this really allows you to move from one use case to the next, from one use case to the next. By simply just connecting to one endpoint, you are discovering all of this information. So again, here, we've got a visualization namespace. So again, we're in this specific mixer or a specific line. So maybe you want to visualize information consistently across your line. The automation engineers don't need to connect directly to the PLCs and kind of like build dashboards, how they imagine they need to be built. You could standardize on how information needs to be visualized for each specific line, for each specific site, for each specific mixer. All they need to do is to kind of go into that visualization namespace and then pull the data that has already been pre-packaged for them, and then they're simply just displaying it there. And if you happen to actually be working on a SCADA system that supports MQTT, say Ignition, this literally boils down to drag and drop. 

Kudzai Manditereza: 00:44:20.892 So an engineer is simply just dragging these visualization tags and dropping them onto a canvas, and then just choosing what visualization widgets they want to be able to do that. So this kind of shows you the power of the Unified Namespace, again, at being able to create all of these different namespaces. So also, if you could monitor the Q&A there for me, Ryan, because I want this to be interactive. I want to find out if there's anyone who's asking questions about what we are currently showing right now so that we could address it while we are here. So again, here, if I go out of the mixer here, so within this Edge namespace here, I've also got waste. I can monitor exactly the amount of waste that is being produced in this specific Edge namespace. And then —

Q&A Time

Ryan Dussiaume: 00:45:17.857 Yeah. Because I'd say a lot of people are asking about what you mean by an IIoT platform. What qualifies something as being an IIoT platform? And maybe you could give some examples as well. 

Kudzai Manditereza: 00:45:35.538 Yeah. That's actually a good question. So IIoT platform is kind of, really, a broad term. But what I would say is, basically, it is a platform that allows you to connect to legacy systems and also some modern systems, bring that data into that specific platform, and then add context to the data, rename the data, normalize the data, and unify the data, and perform all kinds of transformations on the data or data messaging that you'll be able to imagine. And also, to some extent, be able to buffer the data in case there's some kind of loss in connectivity with the MQTT broker. So it is those capabilities that an IIoT platform will be able to provide. So an example would be, for example, Ignition could be considered an IIoT platform because it allows you to connect to all the different systems and perform these transformations, create data models. Because, also, the other thing that you want to be able to do within a platform is to say data that is coming out of all these different PLCs exists as discrete data points. And you want to be able — before you actually publish your data to persist in a database or whatever you want to do with that data, you want to be able to kind of unify the data to say, "This is the data that is coming out for Mixer1." So you want to be able to define to say, "How does a mixer look like?" So a big part of it is that as an organization, you're going to sit down and say, "How best could we represent a mixer? How best can we represent a pump?" And then you're going to create a definition of that standard to say, "This is what we expect of a pump. We expect these certain properties from a pump." 

Kudzai Manditereza: 00:47:30.564 And then an IIoT platform then allows you to define those models and then create instances of those models and then map those to the actual data points that are coming out of the PLC and then plug these or push these into the namespace in a level where it makes sense for that data to live. So as you can see, the IIoT platform is responsible for creating two types of data products. First of all, data products that reflect the current operational state, the current state of your operational systems. So this could be a pump. These are the properties of a pump, and these are the values of a pump at any given moment. So that data could be persisted on a database, and then it could be aggregated at a later point for value, or it could be used to train machine learning models. And then the other aspect is that you're creating some consumer-aligned data products. That is data that is created not necessarily to reflect the current state of your business, but for the sole purpose of being consumed by another application. So this really removes that friction where data needs to end into a data warehouse first. And then you need a data science team to perform some ETL transactions, which could take three weeks. And then they get that data product, and then they share it with you and then you say, "Oh, this is the data product that I need to train my model." Now you've got a platform that allows you to create all these different data products. So that's basically what an IIoT platform could be. Examples include — HighByte also is another data platform.

Kudzai Manditereza: 00:49:08.705 And then also, as I mentioned, that line is now starting to kind of become sort of like a gray line where a lot of these IIoT platform capabilities are now starting to be built into the broker itself. For example, Data Hub is now starting to build those IIoT platform capabilities. So I don't have a clear answer of exactly what [crosstalk] does. 

Ryan Dussiaume: 00:49:32.415 Edge as well, I guess, right? Like HiveMQ Edge as well would be part of the picture that might be considered something that's sort of having IIoT platform features kind of coming into a broker-type architecture?

Kudzai Manditereza: 00:49:46.943 Exactly. So HiveMQ Edge also because it's got the connectivity to all the different PLCs. And then it's also got this IIoT platform capabilities with Data Hub allows you to perform all of this normalization and contextualization of data. So that's basically what really makes up an IIoT platform. So it's a broad set of capabilities that it needs to support. 

Ryan Dussiaume: 00:50:14.933 So thanks for that, Kudzai. So what we're looking at here with MQTT Explorer, someone was just asking: How does this data arrive in MQTT Explorer? What's the mechanism by which you are kind of connecting and pulling in this data? 

Kudzai Manditereza: 00:50:36.255 So again, that's the beauty of MQTT. So all you need to do is to really — so I'll quickly show you the connection here. So as you could see, what I did — I simply specified the broker URL address, code number, username, and admin, and then it will bring that namespace. But then now, obviously, the application itself needs to have the capability of then kind of rendering that hierarchical view of the Unified Namespace. So there's other tools also like MQTT.fx that allow you to connect to an MQTT broker and then do the same thing. Ignition also allows you to connect to an MQTT broker, bring that namespace just for the sole purpose of you being — to be able to visualize that. But that hierarchy exists. Whether you visualize it or not, it exists within the broker itself. So if you know what topics you want to subscribe to, so if I've got a predictive analytics application that wants to subscribe to say, here again, to this mixer, it then needs to kind of specify this specific topic path. So not every application needs to get the entire namespace like MQTT Explorer and view it. Of course, for diagnostics purposes or for visualization purposes, as you build your Unified Namespace, it really helps for you to visualize what your structure looks like.

Kudzai Manditereza: 00:52:09.641 But as you start to consume, you're going to be consuming it at different points of the namespace. So you're simply specifying that specific topic path, whether you're using also wildcard to subscribe to multiple levels or everything under a level. This is kind of the power that MQTT gives you to be able to perform that kind of subscription.

Ryan Dussiaume: 00:52:30.978 Because I do know if BACnet is supported in HiveMQ Edge, I think we were adding it. We've either added it already, or we're adding it very, very soon. 

Kudzai Manditereza: 00:52:43.319 So it's not yet supported, but it's actually the next one in line to be released. So that's coming up very soon. 

Ryan Dussiaume: 00:52:51.386 Okay. Great. We had another person asking where does Sparkplug come into this whole picture? Is all of this that you're showing? Is it Sparkplug compatible?

Kudzai Manditereza: 00:53:08.131 Yes, it is. So what I've just done right now is that I've activated Ignition to publish a Sparkplug namespace into that broker, which I've pulled here. So as you could see, Sparkplug now exists within the broker with its own namespace. So because, obviously, the Sparkplug has got a Protobuf encoding as far as the payload is concerned. And then also, it's got a consistent way of representing the topic structure. So how we think about Sparkplug currently is that you use Sparkplug from level 0 up to 2, like sort of a SCADA network because it's got all this goodness as far as device management capabilities are concerned, automatic discovery of tags. So you would have a namespace within the broker for the sole purpose of really maintaining those SCADA functionalities or whether you're using Ignition or whatever SCADA platform that supports Sparkplug, you're able to have isolated SCADA layer that uses Sparkplug. And then, as soon as you want that data to be available in your global Unified Namespace or a flat MQTT Unified Namespace, you're then able to use, again, an IIoT platform to subscribe to that Sparkplug namespace and then unpack it so that it's actually a flat MQTT namespace and then republish it into the Unified Namespace. So for example, as you can see, I've got a refrigerator that is in the packaging line that is publishing Sparkplug payload. 

Kudzai Manditereza: 00:54:53.931 So I could subscribe to this refrigerator here from Sparkplug namespace. And then, I could then go into my Unified Namespace. And then here, I'll be then able to publish this data in flat MQTT here. So I'm taking from this namespace and putting it into a Unified Namespace. So now you've created that bridge between your OT and IT. You're getting the goodness of Sparkplug for your OT SCADA capabilities, and you're also getting the advantages of being able to then integrate that directly with your MQTT platform. So again, as I mentioned, that functionality is also built into HiveMQ Data Hub that allows you to unpack Sparkplug from Protobuf into JSON. And then, you republish it into a flat or vanilla MQTT topic namespace within your Unified Namespace. So those are also the capabilities that an IIoT platform would do, or a platform such as HiveMQ Edge, which is Data Hub, would allow you to unpack those Sparkplug metrics into the Unified Namespace.

Ryan Dussiaume: 00:56:05.290 Thanks. Thanks for that. So we have had a lot of questions about security and securing the namespace, let's say, in terms of who can publish to which topic, who can subscribe to which topic. Obviously, this is a very, very important subject when it comes to the Unified Namespace because a big part of being able to trust that data is that you know that the client that's published it has been authenticated and that that client has the right role within the system to be able to modify that data so that you know it's coming from a reliable source. The way that the HiveMQ platform supports this is through our Enterprise Security Extension. So it has capabilities to enable clients to authenticate using different third-party sources, like you may have LDAP or OAuth or other mutual TLS, so client-side certificates. Lots of different ways of authenticating clients. And what's nice about the way that this extension works as well is that you can even extract properties from that authentication method and use it in your authorization or your permissions for that device. So if that device has a particular name and that name is part of the certificate that's been given to that device in order to operate, you can extract that name and use it within the topic structure that the device is allowed to publish into. 

Ryan Dussiaume: 00:57:47.826 So you can even keep devices within their own kind of sandbox within that Unified Namespace and just creating that kind of reliable trust chain from authentication to authorization to consumers of the data with that method. I had another question here for you, Kudzai. So somebody said: What are the best practices for architecting a UNS? In terms of the path structure, I think they're meaning the topic structure here. And how do you keep it flexible and adaptable and make it easy to use, let's say? 

Kudzai Manditereza: 00:58:31.501 Yeah. So as I mentioned, the whole idea is to say you structure it according to how your organization is already organized. So in most cases, for a lot of companies, your organizational structure already exists within your ERP system. So whatever hierarchical structure or asset sort of modeling structure you've got within your ERP system is what you need to replicate for your Unified Namespace. Because the whole idea is to say you want it to be kind of semantically discovered intuitively for any application that's interacting within your enterprise. It needs to kind of really understand how that information is structured. So there's no standard way of doing that. The whole idea is to kind of structure it according to how it makes sense for your business. That's the whole idea to kind of really create that. So obviously, if your business is following ISA95, then naturally, this is what you want to follow. Or if you don't have a structure already, ISA95 is a good place to start.

Ryan Dussiaume: 00:59:39.084 Okay. Great. And so, when it comes to an MES system and information coming from there, I assume your answer would be very similar in that regard. It depends on what the answer is essentially, it depends, and it's based off of your organization's structure, let's say.

Kudzai Manditereza: 00:59:57.522 Exactly. So again, you could see on Lline1, I've got an MES system. This could be area level, but here I've got it on the line level. And then because this is where I'm actually kind of monitoring my production efficiency within this namespace. And then also you could see on ERP, I'm actually publishing data from the ERP system into this ERP namespace at line level. This could be at site level if it makes sense for your business for that information to leave a site level. But the whole point is that now the MES and ERP, which typically communicate to each other using direct SDK or API — now they're just communicating through this abstraction. You could change your ERP system and the MES wouldn't know or doesn't really care because this information is available through the namespace.

Ryan Dussiaume: 01:00:47.106 Thanks. How are we doing on time, Erin?

Erin Musselman:  01:00:51.354 No. We are at time. I think we could just do one more question and then wrap things up.

Ryan Dussiaume: 01:00:57.755 Okay. Sure. I have one here, which is just: Is there any specific infrastructure that's required to manage the enterprise UNS? Well, typically, we're dealing with customers that are looking to put their UNS on MQTT and HiveMQ. And so I'll just answer that question from the perspective of where you can deploy and operate the HiveMQ Platform, which is really pretty much anywhere. You can deploy it on Linux, you can deploy it on Windows, you can use Docker containers, you can use Kubernetes. And Kubernetes is becoming, well, already has become a very popular choice. And one of the reasons for that is based off of our availability of a Kubernetes operator, which takes care of common operational tasks to make it easy to manage HiveMQ — to have very low overhead in doing so. Things like being able to recover from a failure in terms of restoring a node in a cluster or doing an upgrade without any downtime, which is normally called a rolling upgrade, where one node is upgraded at a time. So lots of great deployment options. And we also have managed offerings as well where we run the platform for you in your cloud of choice. So lots of different options there. 

Kudzai Manditereza: 01:02:34.175 Awesome. So many questions. If we don't get through to your question, I will definitely reach out to you and answer all those questions. And if you need to contact us directly for more information, also please feel free to do so.

Erin Musselman:  01:02:47.832 Yes, exactly. Thank you all for joining today. This was a fantastic webinar. Great content, great questions all around. So thank you again for joining. You'll receive an email later this week with the recording of the webinar in case you'd like to watch it again or share it with any of your colleagues. And you'll also receive a copy of our new e-book. Thanks again, and we hope to see you at a future HiveMQ webinar. Have a great week. 

Ryan Dussiaume: 01:03:12.549 Thanks, everyone.