Hive MQ Exhibitor Demo: Comprehensive Data Management Solution with MQTT, Sparkplug and UNS

In today’s data-driven world, effective data management is crucial for manufacturers seeking to harness the full potential of their production assets. As industrial environments become increasingly connected, the need for a comprehensive data management solution that ensures real-time, reliable, and scalable communication is more critical than ever. HiveMQ with its enterprise MQTT platform that is highly reliable, scalable and secure provides that ideal platform working with the Ignition ecosystem. We will showcase some of our new product offerings like our Sparkplug module for DataHub enabling metrics fan out and other offerings that will complement the Ignition Edge platform, building the UNS framework to streamline data collection, integration, and dissemination, ultimately driving smarter decisions, greater operational efficiency, and supporting advanced use cases like AI.

Transcript:

00:00
Ravi Subramanyan: Good morning, everyone. Hi. So day one of ICC, and here we are, first session. I have the enviable task, or unenviable task, as one might say, of getting the day started. Hopefully I'll do a good job with that as people trickle in. I just wanted to introduce the topic. I know the topic is very relevant to what this conference is all about. It's all about open communication with MQTT, how that plays into the Inductive Automation ecosystem, along with Sparkplug, and of course, the new kid on the block, which is not new anymore. It's the Unified Namespace. Everybody's talking about it. Everybody wants to know about it, and everybody seems to have a solution for it. So understanding and unraveling that. That's kind of like what we are gonna take you on the journey in the next half an hour or so. I'm Ravi Subramanian. I work for HiveMQ, and I'll introduce HiveMQ when we get to our slide, but HiveMQ has... Wow, I like that.

01:02
Ravi Subramanyan: Seems like a rock concert here. HiveMQ has an enterprise-grade MQTT solution that is highly scalable, highly reliable, highly secure, flexible solution that plays well in the Ignition ecosystem, along with the Cirrus Link modules. We have a few customers that are using us, and we can talk about that case study as well. So for HiveMQ, I'm the Industry Solutions Manager for Manufacturing, so I focus on this particular area. I have seven-plus years of manufacturing experience, and I try to evangelize on behalf of HiveMQ on how our solution works well with manufacturing and vice versa. Do I help our salespeople make sure that they understand the manufacturing talk? When they talk to manufacturing or energy, or industrial customers, there is a specific language, there's a specific need, or specific use cases that we want to talk about, so that's what I do.

02:00
Ravi Subramanyan: So this is the agenda. I'm gonna jump right into it because we have only a half hour. Okay, so let's just look at, quickly look at some of the trends. I know some of these things are very, you guys are very, very familiar, but things like material shortage in manufacturing is rampant because, obviously, there is more need to manufacture goods, and the supply chain, as we thought, is ironclad; it's not quite ironclad, so there is, like, where is the material coming from? So what if the next pandemic hits? What are your backup plans? So those things continue to happen to be big issues. Carbon footprint reduction, that's something that every manufacturer is going through, not only for being like good Samaritans, reducing the CO2 footprint, but also for themselves to be more efficient in manufacturing and, of course, reducing the energy cost. Security vulnerability comes with the name of the game because, obviously, you're getting the data out of your ecosystem, so naturally, what you thought was like an air gap is not an air gap, so there is things that you need to worry about. And other things like supply chain, we talked about demographic changes, which is real. So the employees that can just hear a machine and then figure out what the issue is are long gone or on the way out.

03:14
Ravi Subramanyan: So new employees are coming in. How do you incentivize them? How do you make sure that they're able to perform to that optimal level? Last but not least, regulations and bureaucracy continue to be issues. So, Smart Manufacturing, what is that? So, again, we make a distinction between digitalization and digitization. So digitalization simply means just take the paper form that is used in manufacturing and convert it to digital; just scan it in into a digital format. That's the simplest thing, but 80% of the customers or 80% of manufacturing is still on paper, which is shocking, so going beyond paper. But then, beyond paper, you also need to combine that information coming in with other pieces of information in real time from equipments and combine that with information coming in from IT systems so that you can drive those insights.

04:06
Ravi Subramanyan: That's kind of what Smart Manufacturing is all about. And why is it important? You can see the growth projection over the next five years now or so. So let's talk about the power of Smart Manufacturing. Again, why Smart Manufacturing is important. I'm not saying it, McKinsey is saying it. Within one year of implementation of a Smart Manufacturing solution, this is what you can expect. These are the gains you can expect to get in using Industry 4.0, which we'll talk about in the next slide, and the technologies that come with Industry 4.0. So, again, what is Industry 4.0? It's all about all of these technologies that come together, which includes industrial IoT, which includes robotics, AR, VR, smart sensors, cloud computing, all of these things coming together to ensure that you have real-time information, you can power predictions, you can make your factory autonomous, you can create new revenue streams. How? Because you have the data that gives you some insights which you didn't have in the past, and then you can radically transform your operations with that.

05:10
Ravi Subramanyan: So, again, it's not just a revolution; it's an evolution. Why is it an evolution? Because when you get on the journey, it's not that you're done. So you have to be there for the long haul because things always change. So you have to be on this journey, and that's why it's an evolution. And these are some of the steps, so connecting, collecting, which we'll talk about. So getting the data together, collecting, assembling, and consolidating the data, driving insights, then that power, your AI and ML and predictive maintenance and other cool use cases, which can drive some of the KPIs that you have. So this is the typical, I'm not gonna spend too much time with this; this is how the architecture is and how the data flows.

05:54
Ravi Subramanyan: So, again, having some kind of a data management for the data flowing through all of these systems is paramount. Both at the machine-to-machine level and the machine-to-enterprise or the cloud level. So let's talk about that data management. So, again, so this is kind of like some insights from IoT analytics. They put out that AI being the next big thing; everybody's talking about AI, and AI is actually like powering the need for data management. So the data management market has significantly grown over the last few years, and it's projected to grow to $13.3 billion by 2020. And why? Because AI heavily relies on data management and the different aspects of it, which includes analytics, governance, orchestration, ingestion, and things like that. So if you want to do the modeling, you better have a proper data model available that you can trust, and that's why data management solutions are absolutely important, and that's why solutions like Inductive Automation, along with HiveMQ, along with Cirrus Link, and along with other players in this space are paramount to ensuring that you have the right experience when it comes to AI and predictive maintenance and things like that.

07:12
Ravi Subramanyan: So, again, what does it do? Again, it enables real-time decision-making, and obviously you're having a lot of data sources. So there's this huge variety of data coming from different locations. There is heavy velocity of data, the speed at which data is coming, and then the volume, how much volume of data. I think manufacturing is, it's overtook, I think, the World Wide Web as the biggest producer of data. You have all the data, but do you have the insights is the question. And then how you can drive that is by integrating all the data and transforming the data, and then you're ensuring that the data is trustworthy because at the end of the day, you can build your best models and you can build your best solution, but the moment you cannot trust that data, you're gonna lose your belief in that. That's what we are trying to do.

08:00
Ravi Subramanyan: We are trying to make sure that the data is ready, it's trustworthy, and ready to go. Yeah, this is kind of like the traditional ISA-95 model with all these different levels, and some of the issues here is that each layer is its own silo. It's its own snowflake, if you will, in some ways. And if you want to communicate, so you have to create a custom code that helps you interact between all of these different layers. If you want to go from shop floor to top floor, that's a lot of customizations that you need to do, and it's not replicable. And for you to be able to communicate between different systems, typically these things are point-to-point communication, which if your implementation is small, it's fine, but as it grows, this is where I think you get the spaghetti architecture, and it hogs the bandwidth. It's not efficient at all. That's where I think a solution like an MQTT comes in, and I'm sure a lot of you already know MQTT is that publish-subscribe technology, which makes it really easy for clients to publish data to a centralized broker when connectivity is available. The use cases are, for example, in a remote oil and gas upstream use case, or maybe in a factory where connectivity and bandwidth are limited.

09:18
Ravi Subramanyan: This is where I think it really helps you out, and the broker can then share that information with other clients on particular topics. Now, one of the things about MQTT is it's open. That's the advantage, but the disadvantage is also it's open. It's like you can create a topic structure however you want or the content however you want, which normally is fine, but in the case of manufacturing and industrial use cases, it may not quite work. There is a need for a particular structure around it. That's like the topic namespace as well as the payload content. You need to know the state of your machines. This is where Sparkplug comes in. Sparkplug adds that additional framework on top of MQTT that adds this information, and that's why Sparkplug, along with MQTT in the industrial use cases, is gaining popularity as well. And again, just a lightweight, bi-directional design for stateful context. These things are all reasons why MQTT and Sparkplug are gaining a lot of traction within the industrial use cases.

10:25
Ravi Subramanyan: So let's talk about HiveMQ. So HiveMQ, again, started in 2012, right after MQTT became open source in 2010. And so we built our solution on top of that. And what we did that is different from others is that we made it highly scalable, highly reliable, and highly secure. What does that mean? So from a scalability perspective. So you might have many, many, many different connections across your different factory locations or subsystems that need to be connected, and all of it need to be publishing and subscribing data at the same time. So concurrent connections with data going through, new connections coming in, and that needs to be enabled. So that is where scalability comes in. So one of the things that we do from our perspective is we have this clustering technology where we can add more nodes as needed. So it's like you can pad up or pad down the nodes so that you can scale up or scale down depending on your use case. Maybe you're a cyclical business; you don't need that scale all the time, but maybe sometimes you need that scale.

11:30
Ravi Subramanyan: That's what our solution is able to do by providing that high scalability. Reliability, as you know, MQTT already has a quality of service built into it: zero, one, and two. We are taking that to the next level by building additional reliability, like high availability, for example, using the same clustering technology, having multiple nodes within a cluster, replicate the data across all of these nodes, having a masterless cluster which can ensure that when one node goes down, the second node can automatically take over because guess what? The node is already capturing all of the information that the primary node is capturing, so it can automatically take over so that from a manufacturing perspective, there is no downtime, because every minute of downtime might cost dollars.

12:14
Ravi Subramanyan: It could be thousands or sometimes even millions of dollars, depending on where your production is. That's the level of reliability we provide. Security, the normal security, like X5.9 certificate authentication, like encryption data, TLS encryption, is all there, but we also take that beyond that to ensure that whatever other methods you might have from your security perspective is also enforceable on the broker itself. The other key feature that we have is what we call the data hub. We talked about data quality. We truly believe in the fact that data is obviously garbage in, garbage out. We all know that. So for you to make sure that for whatever use cases you are using that solution, it makes sense; you want to have the right data. For example, you might want the temperature to be in a certain format, degree Celsius, Kelvin; that's simple. We do that transformation to make sure that all the temperature values and the pressure values are in a certain format.

13:18
Ravi Subramanyan: You might want only the data to be in a certain range, for example. You don't want all of the data. Because A, it is not useful for you, B, it's like that's the only thing that you're concerned about. You want to enforce certain rules on which clients publish, can publish, and which clients can subscribe. Those are the kinds of things that the data hub can ensure. It's basically a software module sitting in our broker where you can create policies, and you can enforce those policies. You can also do transformations. For example, in some scenarios, Sparkplug may not be the most ideal because while it can talk to your industrial, the OT side of the world, no problem. Everybody can interpret that. But on the IT side of the world, people or systems don't understand that. So how can you make sure that the IT world is able to interpret that data? So you take the core aspects of Sparkplug, and then you can also convert the data to like a straight MQTT.

14:17
Ravi Subramanyan: And you can fan out all of the variables, all of the metrics that are part of Sparkplug so that, like an IT application, for example, like an ERP or a MES system, can understand that and then can take that and make a decision based on that or maybe a database or like some other cloud-based application. That's what we do. We ensure that we provide the best of both worlds through these transformations or through improving the data quality that will make sure that when you try to do your operations, when you try to go out and start off your AI projects or ML projects, you're ready to go and you don't have any bottlenecks and you don't have to have a separate project that you have to do. Like in a lot of cases, we heard that I'm starting off on a data project or I'm starting off on AI. I see the data; it's sitting in like this data lake, or some people call it a data swamp because you just like dump the data there.

15:15
Ravi Subramanyan: And then I have to spend six months cleansing the data, and I have to spend a lot of time figuring out like how the data can get into the format that I need it. So what we help you with is preemptively getting that in the format that you need so that you can then take and run with it and do your projects. One of the side benefits that people have said is that cloud is costly. So moving the data or ingress cost on AWS, Azure, and Google is costly. So why just take the data and just dump it all on the data lake if you don't even care about all of the data? Just selectively bringing the right data ensures that you also keep the cost down, you're focused only on the data that you need, and the data is in the right format. It is cleansed; it is what we call normalized because you might have this data sitting in so many different systems that need to be all normalized. Hey, I have this pressure point here, but I also have a pressure point data there in a different system.

16:11 
Ravi Subramanyan: How does this relate to that? So to kind of make sure that all of that makes sense and it's cleansed and it's brought together in a conceptualized fashion. That's kind of like what a Unified Namespace is, where you're able to bring all the data together into a single namespace, a Unified Namespace that you can then take and use it for any business decisions that you're trying to make. And so that's what we are able to enable. The one other thing that we also do is we recognize that there are a lot of systems that are non-MQTT; they don't talk MQTT. So for those systems, we're able to create these, what we call, extensions, which are application plugins. For example, streaming analytics platforms or databases, or other systems.

16:56
Ravi Subramanyan: We're able to take the data from our broker and then translate that into whatever formats they need through extensions that we have created. We also have SDKs that help you create new extensions based on what you need as well. So the other thing that we also do is we understand that the deployment of this system, this piece of software, needs to be flexible. So you can either take it and then put it into your virtual machine and manage it to yourself or you can put it into your version of the cloud. Maybe you already have AWS or Azure; you can do that. Or we also have a fully managed solution on our end which is available on AWS or Azure, or other cloud-based platforms. So that is completely managed by HiveMQ on behalf of our customers. So the initial tier, which we call the serverless, is free of charge for people to use. And then there are obviously additional features built in as needed to get to that enterprise grade as well.

17:56
Ravi Subramanyan: So people are free to try it out, and maybe for your use case, the serverless version works for you. So again, providing that flexibility to be able to interact with any application and not kind of like pigeonhole yourself into saying I can only work with the Azure or AWS ecosystem. So we believe in democratizing the data, which means that you should be able to work with any application in any particular system that you prefer. That's kind of like what we're trying to drive at. And on the left side, again, talking to devices, we have a client, which is MQTT, basically like a MQTT client library that can be installed in any device that can bring the data in the MQTT format. Or we can work with any popular gateways that are available, like Ignition Edge gateway, for example, that is able to publish the data in the MQTT format through the Cirrus link modules, which we can intercept, we can bring in, we are able to expose the tags, we're able to support the UDTs, and then bring the data in a highly scalable and reliable fashion.

19:01
Ravi Subramanyan: So that's the HiveMQ platform. Now let's quickly talk about Unified Namespace, and I want to leave some time for questions as well. So again, I already alluded to it. So basically, it's kind of like the single source of truth for all of the business data. Let's put it that way. Because you cannot say only OT data, because these days, your business data is a combination of your operations technology data sitting on your manufacturing floor, but you also want to bring in information from your ERP system or databases or CMMS or other applications that are not necessarily on the OT side of things, because the combination of all of this is that single source of truth for all of your data. That's what a Unified Namespace is all about. It has the ability, and it borrows a lot of the benefits of MQTT that I had talked about and the ability to conceptualize the data and bring it all together into one location. So when you look at your data, so it's able to catalog all of the business data in one location. Hey, what are my alarms? What are my events? What are things that are red? What are things that are green? So you're able to bring it all together visually so that if you see some issues, you can react to it.

20:16
Ravi Subramanyan: And these things can be sent as, maybe you can have a mobile app tied to it that can give you alerts and alarms and things like that. So it's just a quick way for people to understand the status of their business. That's what a Unified Namespace is. And just going back to that other architecture diagram, juxtaposed with Unified Namespace and how it enables the ISA-95 architecture to perform more efficiently. That's what we're able to do. And then there's something called federation of data, because you have certain data on the shop floor, you have certain data on your MES layer, some on the cloud, some on ERP. So you need to have various different levels of namespaces. Let's put it that way. Where you want to consolidate the data, and then ultimately you want to bring it onto your enterprise Unified Namespace. So imagine each of these are separate brokers. You have many different brokers talking to different subsystems on your factory, consolidating that onto your plant broker, for example, and then that is consolidating on your enterprise broker. And all of these are talking to each other through what we call a HiveMQ bridge, which is another extension. And the concept is called a federation of these brokers.

21:29
Ravi Subramanyan: So information can be easily sent back and forth efficiently. And this is kind of like an example of a typical Unified Namespace for a bottling plant, where you have data from different locations coming in, and you can see how the data is organized in a logical way. Again, there is no specific way to organize the data. We're not saying that it has to be the explorer model. It has to be based on the location and then all of the systems in the location. Sometimes you want to do, like I want to look at all of the alarms and I want to bring in all of the pressure data, for example, in one namespace, or I want to bring in all of the other information on one namespace. So again, it is completely dependent on customers and how they want to organize the data in a way that makes sense for them. So that's the beauty of a Unified Namespace. It provides a framework. Implementation is completely up to how you want to do it. Well, that makes it efficient. Yeah, this is kind of like just showing how it all comes together, and going back to the ISA-95 model, area, line, cell, and then you have enterprise. So again, bringing the data all the way from the line to the area, all the way to the enterprise, and how that all works and comes together to create that enterprise Unified Namespace.

22:46
Ravi Subramanyan: Yeah, that's just the final slide I have. So I know we have about five, six minutes. Maybe open it up to any questions you folks might have. Yeah. Yeah, yeah, that's a great question. And one of the advantages of the Unified Namespace and the way we are envisioning, ultimately building out that full finalized product, is you bring in the model the way it works for you. Some people prefer the ISA-95 model, but others prefer other models. Maybe Sparkplug, that kind of provides a model as well, but there's no kind of one-size-fits-all.

23:23
Ravi Subramanyan: So the tool itself will be able to take any model that you already have and just build it out based on that so that you can easily interpret the data. Yes, yes. So Data Hub is a relatively new software that we've added, both on the edge. So it can basically be deployed on the edge or on the cloud because it's all about going to the source of the data and transforming the data before it's brought to the higher layers. So there are scripts; there are modules that are already available. For example, if you want to move Sparkplug data and convert that to straight JSON or Google Protobuf to JSON, or you want to do a metrics fan-out from Sparkplug to just straight MQTT with all the metrics listed out. So those are things that we've already built out, but you can also use your own scripts, XML scripts, and bring it in to do whatever you want to do, and that will allow you to do those transformations.

24:31
Ravi Subramanyan: Oh, good.

24:32
Audience Member 4: And So is that module somehow available in the HiveMQ...

24:38
Ravi Subramanyan: Yeah, on the cloud, we are looking to add the module. We don't have that yet on the cloud. We have it on our on-premise solution, but we are looking to do that. That will, something that we're looking to do in this year.

24:49
Audience Member 4: Okay, thank you.

24:50
Ravi Subramanyan: Thank you. There's a question there.

24:55
Audience Member 5: Yeah, I have actually two questions. One, we heavily use brokering, and so we have situations where within Ignitions and all of our Ignition nodes, we use the Sparkplug, but a lot of our external applications we wanna use JSON. So if I understand what you're saying, you have a built-in extension that if I publish a topic in Sparkplug, you can republish that topic in JSON?

25:24
Ravi Subramanyan: Yes, yes, that's right.

25:26
Audience Member 5: And then second thing, one of the things we're seeing is if an example would be, you have a node that publishes a topic to a broker, and you have another node that is gonna subscribe to that topic. And then about 10 minutes later, another node comes along, and it needs to subscribe to the same topic. What happens is now the publisher has to refresh its data because the data is stateless. And everybody, so the new guy needs to know it, but that causes the publisher to be involved, and every time a new node comes onto the network and needs to subscribe to data, the publisher is involved in that transaction. Which means if a million subscribers come on at once, the publisher has to be set up to be able to perform well enough to publish for a million consumers. Can you, does your system make that work any better?

26:25
Ravi Subramanyan: Yeah, yeah. So again, this is a very, very specific question. We can certainly have our technical folks give a better answer, but my perspective is that we can; our solution ensures that there is some buffering that can happen in that scenario. And make sure that any new publishing or new subscribing clients get that information. There are ways, even within MQTT, to be able to do that, but we are able to also do additional things to make sure that that happens more seamlessly.

26:55
Audience Member 5: Okay, thank you.

26:57
Ravi Subramanyan: Yeah, Thank you. Couple of more questions. So we do have a booth upstairs. So please do stop by; we are happy to do a demo. I was trying to figure out if I can do the demo here, but I thought it would be better for us to have this Q&A session rather than the demo. But do stop by upstairs so we can obviously talk about your specific use case, and then we can give demo of that module that we talked about, as well as anything else you would like to know about HiveMQ. There's no other questions. I think we are good. Thank you so much. I think session one is in the books. Thank you. I will talk to you guys later.