The Unified Namespace (UNS): How-To Guide for Success

00:00
Speaker 1
I’m done. No. All right, back to this graphic. But now it is relabeled the how to guide for success. Now we’ve talked about all the problems and all the struggles, and now I’m going to magically make them all go away. But all right, that’s me. Surprise. All right, so today we’re going to talk about architecture tips. We’re going to talk about ignition, UDTs and MqTT and how those can be leveraged to build a uns. And we’ll do some q a as well. All right, we’re back to isa, right? In my mind I was thinking there was going to be separation between these two sessions. So I was like, let’s recap here. You don’t need a recap. It’s all fresh in your mind. See, remember this? Yeah. That’s a unified namespace. All right, so what are the actual tips that we’re talking about here?

00:45
Speaker 1
So first you need to model your architecture on your environment, your facility, your process. We talked about that in the last session as well. Right. It has to be reflective of your process. And then I guess I talked about this earlier too. Right. But it has to be focused on what operations wants to see. We’ve seen people that do this just from an it perspective. And also it breaks down and doesn’t get relevant data. And then the last one based naming conventions on your hierarchy. Great, let’s get into udts. So ignition. Ignition goes and it has different drivers to talk to different devices. And we do have edge solutions to pull data from other devices and can bring it into a centralized system, all that kind of stuff.

01:28
Speaker 1
But when you create tags inside ignition, you could just define whatever structure you wanted for your tags. You could put them all flat in one folder and you could have thousands and thousands, hundreds of thousands of tags flat there. Or you could just create a folder structure that’d better, right? Where I can create folders for my tags so that when I want to go look at line one blank, right, there’s a line one folder and I can go see these things. And you could actually just do a folder structure that matched this. Right. I could have an enterprise folder, I could have a site folder, an MES folder, oee folder and so on. And I could start breaking up tags that way. You should absolutely do that. Is that enough just to have folders of individual data points?

02:18
Speaker 1
We would argue no, it’s not enough to just do folders of tags. But instead, in order for a uns to be really valuable, we need a concept of a user defined data type, a UDT. And what this is saying, instead of just folders of tags, we actually want objects, which is a subtle difference. But you want the system to be aware that everything in here represents some real world object. And why is that beneficial? Well, it can be that when you define a UDT, it could be multiple folders inside it. It could have child udts inside it. So I have a line, one UDT, and inside of that I’ve got this other piece of equipment, and inside that I’ve got this other piece of equipment. But also by making it a UDT, you can enforce a specific structure.

03:26
Speaker 1
And so I’ve got a motor, and a motor has got HOA and it’s got amps and it’s got run control and status and whatever else, right? But when I do that motor, I don’t want one motor to have one set of tags in my motor, one folder to have one set of tags in there and one structure. And then my motor two has a different set of tags and a different structure and motor three, so on. Right. Even though I’ve defined that structure now, if the actual data isn’t consistent, I’m also missing out on some of the functionality of the UNS, right. Even though I had a bucket to put it in, my data is still cluttered in the garbage. And so my UDT comes in where I define this user defined type, I define a structure for this.

04:15
Speaker 1
And so every motor is going to have these exact things and I’m going to store history on these data points and I’m going to have alarms configured on those and they’re going to go up at this rate to this thing, all that kind of stuff, right? And so what that allows you to do is that now you’re enforcing some structure on new projects and new implementations and things like that. So there’s consistent structure, and if you make a change to the definition of this, every instance is automatically going to get those updates.

04:45
Speaker 1
And that’s the biggest thing here, is that it’s great if when you initially release something and you created your uns, they’re like, sure, all the motors match then, but a year from now when another project starts, are they going to just randomly make all the tags in those new folders the same? Maybe not, but if they have to use the same UDT definition, you got a better shot. All right. And so kind of to illustrate that point here, before, maybe I just got all these tags kind of flat inside my folder structure here, and they’re named things like average type AV GTYP. I don’t really know what that is. Or Cal WGT. That’s calculated weight, maybe, but I’d have to start guessing here of what these different things mean. But maybe that’s how they appear in the PLC. Well, that’s okay. Still in ignition.

05:43
Speaker 1
I could bring them in, I could alias things. I could create this structure so that I now see, I’ve got this meter config, and down in here I’ve got all these structures and they’re all named better. And maybe I’ve got some values in here that are just really like a numerical representation of a status. But I wanted to actually enumerate that out to be what the actual status is, so that when it goes up and some other business application is seeing this later, they’re not going to know what the difference between a two and a three is, or between seven and 96. Right. And so your UDTs can add all that kind of structure so you can have more meaningful tags over here. So that’s what UDTs do, is they say, all right, it’s still a folder structure. Right.

06:27
Speaker 1
I still am creating the same uns paradigm, but I’m able to do it with much more context now and much more consistency. Does that all make sense? Any questions about that? Yeah, go ahead.

06:42
Speaker 2
I guess in my experience, there’s not.

06:44
Speaker 1
A lot of experience, but sure, real.

06:48
Speaker 2
World situations where we have things, a power pack or a motor, where they’re very different. What I’ve done, we started out like, cool, we want to do udCs, that’s how we’re going to do it. And then there’s just so many differences between the machines that it almost becomes better to just copy and paste and delete.

07:15
Speaker 1
Sure.

07:16
Speaker 2
You kind of have to fit into the system that’s already there. It can be hard to leverage the power of UDP because, I don’t know, you see them, it’s like, this is incredible, and it’ll make everything so much better. But then you try put the pieces together and they’re so very different.

07:34
Speaker 1
Agreed. And that’s part of the challenge of the UNS. Right. But if you do define UDTs and those are based on your uns and you have new plcs being deployed or things like that, they can at least follow a standard. And so I think it’s always better to have a standard, and it may be that you have multiple versions of a motor, for example, or a meter. Right. I’ve got v one, v two, v three. I’ve got line with three cells line with four cells, whatever. You name all these things, right? And so you’re right, it’s not always perfect and easy, especially in a brownfield situation. But I would argue it’s still worth defining it and setting that as a structure for everything going forward, even if some of the other stuff can’t comply to it right away, if that makes sense.

08:21
Speaker 1
But, yeah, I don’t have a magic solution that’s like, oh, yeah, we’ll just go reprogram all your plcs and go get rid of your equipment and buy all new equipment. That’s not practical. Right. And so you have to meet in the middle somewhere.

08:38
Speaker 2
If your people change or your system integrators change or whatever, but your software stays the same, there’s that structure that you can follow, which is cool.

08:46
Speaker 1
Agreed.

08:48
Speaker 2
Yeah. Sometimes you get caught up, like, I’m going to champion this project for the rest of my life.

08:52
Speaker 1
Yeah, I know exactly how it works. Cool. Any other comments or questions or thoughts here? Great. So one thing I wanted to highlight here is the reference tags and derived tags. So this is another nice form of transformation. So something you can do. This doesn’t solve all the problems that we just talked about of, like, what if I have brownfield that’s in a different format and different structure, right. But in some cases, you can just inside ignition, connect to the stuff as it exists in its space, but then retransform that into the format that you need. Right. And that doesn’t mean I can magically make data appear that didn’t exist or magically remove things that exist. But in ignition, you can create a whole new structure that just maps to a different structure that you have in a different system.

09:57
Speaker 1
And so tread carefully with that, because you don’t want your whole system just become like spaghetti, right, where everything just points to something else, and it’s hard to know where the actual original data is. It’s much better if it’s just a clean structure, where it’s actually the same structure as it’s shown in every place. But this still can be helpful in certain use cases. Do you have a comment? Think about the uns that we implemented.

10:24
Speaker 2
By necessity, and that’s very quickly realized that, as you say, by record studying the real data.

10:45
Speaker 1
It’s a great comment. Go talk to him about how to do it. No. So what he’s talking about is what we’re going to get to here in a second, which is actually now when ignition starts publishing data up over MQTT, which we’ll just jump to that, right? So now we go to mqtt here. And so what is MqtT? MqtT is a protocol that was originally created 20 something years ago for oil and gas because people had data out in the field and they had VSAT systems. So satellite systems where they could only send up very little data, had very little bandwidth. And so they needed a very efficient way to have smart sensors publish data up on change, because they were doing this round robin polling before, and they’d only get data once an hour maybe, and they’d have these oil pipelines.

11:42
Speaker 1
And imagine a valve opens when it’s not supposed to, and oil is dumping out somewhere and you don’t find out for an hour, right? That’s not acceptable, that’s bad. Or you see, like, oh, pressure just dropped suddenly, oh, maybe we have a leak somewhere in our pipeline. Would have been nice to know that 30 minutes ago, right? All that kind of stuff. And so people needed higher resolution of data, but less bandwidth requirements for that. That’s how MQTT was born. It was meant to be this lightweight version of data transfer over TCP. And it’s funny because it was built by IBM at the time with a consultant, and they were like, oh, this is cool. We’re going to make this open source.

12:30
Speaker 1
We’re not going to make this a proprietary protocol, but they didn’t advertise it, and so nobody really knew about it for years. Facebook picked it up for Facebook messenger for a while of how they sent Facebook messenger posts. Other people have used it for other things, but within the last ten years, maybe really the last five years, people realized like, oh, we have the IoT push and the IIoT push, and we need protocols for sending data that are lightweight and report by exception, all that kind of stuff. And they’re like, oh, there’s this great one that already exists. We should leverage that. And that’s kind of how MQTt was formed. But the great thing about MQTT is you can publish any payload of data to any topic, any namespace, whatever you want. You can define whatever structure you want.

13:19
Speaker 1
The bad thing about MQTT is you can send any payload to any namespace, any point, right? It’s this two edged sword where it’s like MQTT is very flexible in what you publish, but because there’s no standardization, it’s easy for it to feel like you’re just inventing your own protocol when you’re trying to use it. And so because of that, Spark Plug came along. And so one of the consultants that worked for IBM, when MQTT was originally formed, was a guy named Arlin Nipper. And Arlin Nipper was very familiar with creating payload formats and stuff like that. And he was aware of the limitations here for the industrial space of people creating their own protocols on top of this. And so he defined Spark plug, which is a payload specification for how you send data via MQTT. So is spark plug separate from MqTT?

14:15
Speaker 1
No, Spark Plug sits on top of MQTT and helps you encapsulate your data in a meaningful way. And it is important because it makes it statefully aware. So, you know, if things are connected and provides a whole slew of other benefits. Is it perfect? No, I would say it’s not perfect in that it was still kind of designed with the expectation that I’m taking data from my devices and I’m publishing that up to a centralized system, and it’s all device specific, which leads to your problem, right. Where I’m publishing data up, it’s based on a device id. If my structure changes or whatever else. And now I have data coming from a different device, I move my tags to a different system or whatever. It’s brittle in that sense, right.

15:04
Speaker 1
It breaks down, and so you can alias it by doing reference tags and abstract away some of the things that Spark plug was originally designed for. And like you said, that works beautifully, but you’re adding some complexity and stuff like that. So we have been talking about how do we solve that? We’ve talked about new versions of Spark plug being more based on this UNS concept rather than the original concept of device state. And is my device publishing data and all that kind of stuff? Because devices are mostly abstracted in the UNS, right? And so how are we going to fix it? How are we going to make it easier for you? Do we change spark plug? Maybe? Do we just make it so that ignition magically changes some stuff for you?

15:52
Speaker 1
We could do that, but we’re trying to decouple ignition, like decouple infrastructure from applications, right. We want your uns to be infrastructure. And so, absolutely, we can go and roll some stuff out in ignition to make it the best. And make sure you always use ignition for your uns, which would be great for us, but it kind of misses the message that we’re really trying to send here, right? That it’s not just about ignition. This is about how do I create a great structure, right? And how do I make sure that other applications end up seeing that perfectly? So it’s a complex thing to solve, but you’re absolutely right that there are some limitations. All right, any questions about MQTT and spark plug? Does this make sense, what I’m talking about?

16:39
Speaker 1
One time I was teaching a session in Reno, Nevada, which is like a mini Las Vegas, and were in this big casino hotel. But I was talking about the difference between OPC and MQtt. And we talked about like, all right, so if I’m here and we’ve got Clarice there in the back taking pictures, but every time she takes a picture, say she had, like, a Polaroid camera that prints off the picture right away, and she is running it up to me to give me the latest picture. And then I’m looking at that. Is that efficient for her to be, like, running back and forth or me saying, like, send somebody, hey, go get the latest picture, bring it back to me. Send a picture, get it back to me. Right? That’s polling.

17:25
Speaker 1
We used to do polling where we say, we’re going to go request the latest value from the device, bring it back to me. When I get it, I look at it, I go request the next one. Right? And we said instead we should do report by exception, meaning every time she takes a picture, what if she just texted it to me and then I receive it, right? That’s the equivalent of MQtT here. And now OPC also does a subscription thing, right? OPC says, yeah, send me the picture as well. So why would I use OPC versus Mqtt? OPC is interesting in that, unlike MQTT, where MQtT was like, you can do anything you want. We don’t define the namespaces. We don’t define all of this stuff.

18:07
Speaker 1
They’re like, we are going to look at every industrial process and every piece of equipment, and we’re going to find a structure that fits everybody, and there’s going to be all of this structure defined, and then we’re going to make sure we send you data that’s highly contextualized and just able to be used right away, which is great, but it also means that it’s a little bit bloated as a protocol and so on premise. OPC works great because I can subscribe to data, I can bring it in. I can already understand. Everything’s got a timestamp and everything’s got a quality code and all that kind of stuff, right? That’s awesome. But if I’m trying to do that now over a VSAT system or something like that, all of that extra metadata that comes with it starts to make your protocol a little slower.

18:57
Speaker 1
And so MQTT has been favorable in those type of applications because it’s lighter weight. But I think this is most evidenced by Siemens PlCs. If you just pull a Siemens Plc, great performance. If you try to talk to their OPC server now, it’s browsable, it’s cool, it’s great. How’s performance? I see some people shaking their heads. They know you get to try to get subscribed to 10,000 tags on a single Siemens Plc over OPC, whole thing crashes. OPC is awesome for what it does, but it’s not going to solve all your problems at scale and across networks.

19:42
Speaker 1
And that’s why OPC foundation released a new version which is OPC over MQTT, where they said we’re going to take the best of both worlds and we’re going to bring it into one protocol, which is it’s been cool to see that there’s less of like you have to pick OPC or MQTT, but there’s starting to be more collaboration there, which I think is really positive for the industry overall. And also ignition as a built in OPC server because inside ignition itself we’re not as worried about the performance. Right. And we manage all of our tags for that. So I’m not trying to say OPC is bad, we use it internally. We don’t have an MQTT broker internally to manage all of our tags. Because you use it in the right context, they’re not equivalent, if that makes sense.

20:26
Speaker 1
All right, so why are MQTT and spark plug ideal for uns? Well, because they’re lightweight, like I’ve talked about. It’s an open architecture, it’s open source reports by exception. So she can just text me the images when she takes them instead of somebody running back and forth carrying me these images that we’re printing. Right. It’s not efficient and also it’s edge driven. What does that mean? When you go and you define your tag structure, you define your udts. Do you want to do that centrally or do you want to do that at the edge? And generally you want to do that as close to the equipment as possible so that once your data is flowing through your data pipeline, it’s doing it in the right format from the beginning.

21:07
Speaker 1
You don’t want to have the data all be published up in some crazy format and then have to do the translation centrally because that’s getting away from the UNS where you’re doing these hops, where you’re doing translation and then something changes down here. I got to go figure out where the transformation is, having the translation is happening and go apply it. No, no, we want it just to be right at the edge. And so MQTT, you can define that structure. That structure is going to carry up, and that’s tied into our UDT structure. With an ignition, your UDT definitions and instances can flow up over MQTT as well. So you define that once at the edge and it just goes up. And of people doing uns’s, it’s actually the most popular right now.

21:50
Speaker 1
Does that mean that there aren’t other solutions that people are doing today? No, there’s lots that people are doing today and there’s lots of products out there for it, but this one’s the most prevalent right now. All right, so yeah, we talked about that. It decouples devices from applications, and MQTT helps all components in the system communicate. And also that spark plug provides that missing context and data modeling, all that kind of stuff. We’ll try to get through stuff a little bit here. So just another graphic to kind of show, right, that you have all these different systems that are all tying into that unified namespace. You’ve got edge publishing data up, you’ve got smart sensors publishing data up, edge controllers, Lim systems, WiM systems, you’ve got MEs ERP, right.

22:37
Speaker 1
But some of these are publishing and some are consuming and some are doing both, right? Some are consuming and then they’re augmenting or collecting other data and publishing it back up. And so that still all fits into that uns. And so a UNS is nice because different things can use it for different purposes, but it’s still all tied in the same single source of truth. So back to this diagram that we talked about earlier. Right? So we’ve got data, and we talked about now that we can be pulling that data, we can be doing all these things. We can define our structures down here. We can use MQTT to publish that data up in a very efficient way. And now we’ve got an MQtT server or broker here. This could be an ignition. We have a broker that you can use called MQtT distributor.

23:32
Speaker 1
You can also use chariot, but you could also use third party brokers as well. Once again, I’d love to just sell you ignition all day, but that’s not the point here, right? The point is that you’re leveraging open standards here, so that’s interchangeable. Right. But then now on the other side, what this is showing is that we can take that data and push it into all different sorts of applications. And so starting at the top, Canary could just consume that data, log it automatically. Right. Flow can also tie into this in that they’re consuming the data, but they’re also able to add all of those metrics that were talking about earlier today. And then he can take those templates and he can publish them right back to MQTT. In fact, I think we’re going to see some of that later.

24:23
Speaker 1
So make sure you stay and watch Lenny’s presentation as he kind of shows how flow fits into this. But also we can take the data and we can push it directly into other applications as well. So AWS has something called sitewise, which is an asset model framework that can exist in the cloud, and we can just take your structure that you’ve defined with your udts and everything, and it’ll just automatically turn all of those into like, your UDT definitions become models, your instances become assets, and your tags become measurements. And it just does this one to one mapping. That’s really simple. And now you’re inside AWS and they have a few tools automatically built into that can tie into that. And it’s still a relatively new product from AWS.

25:13
Speaker 1
We’re excited that they’re going to be tying it into more and more of their services in the cloud. But this is just a much better way to get data into AWS than say, like just going through kinesis streams, which is very expensive for how it streams data in. And then you have to do python scripting to actually map where that data is going to go, usually. And so sitewise already brings it up with the context of your uns. Same thing. IoT bridge for Azure goes directly into Azure digital twin. So rather than going up through ADX or through, I don’t know, they have like three different event hubs and something else. Pick event hubs. If you go the other way, don’t pick ADX, it’s so expensive. But you can go into Azure digital twin.

25:58
Speaker 1
You got people who know what I’m talking about that are laughing over here. Maybe they agree, maybe they don’t. But ADT, Azure Digital twin is a way to once again bring that up where it’s a model asset framework. The objects that you create inside your uns directly get mapped there and then down to the bottom. Same thing, Snowflake. We can publish it directly into Snowflake and it’ll create separate views for all of your objects and all that kind of stuff. So it’s all structured in a meaningful way that you can then query. But we know UnS is something that, are we saying that you buy our products and then tomorrow you’ll have a uns? No, that’s not the message I’m trying to say here. Right.

26:36
Speaker 1
But I’m trying to say that if you can work within your organization, work with your customers, all that kind of stuff, and you can help define this structure, then once you have that structure, we have tools that will help it be successful to actually get that data accessible to other tools and things like that. And so I really hope that you give this a shot. I hope I’m not scaring you away by saying like, oh, it’s a lot of work. I hope that you recognize that there is a lot of value to this and organizations really can benefit and ignition certainly can help you succeed. And if you have questions about this, you can go talk to element eight, and they’d be happy to talk to you about how they’re working with customers on this today. They can point you to some other resources.

27:19
Speaker 1
We’ve got other integrators who have published books and other things all about this kind of data. There are lots of personalities out there that are making videos about these kind of things too, that you can go and watch and all that kind of stuff. Right. And so this is certainly not an inductive automation concept. Right. This is an industry concept, but it’s a concept that’s not going away. And so hope you take the dive with that. We’ve got a few minutes left. Questions. What do you got for me? Oh, I wanted to say we have lots of training and there’s cool videos if you want to learn MQTT about all those connectors and stuff like that. On Seriouslink’s website we have a series that is called what is MQTT? But it’s a series of like 17 videos.

28:05
Speaker 1
I want to say maybe it’s 19 videos that step by step walks you through from a base installed ignition to configuring MQTT, setting up, storing forward, all this kind of stuff. It’s a great thing if you want to get a crash course. I highly recommend it. But yes, questions going once I’m looking at my timer and I still have to talk for another minute and 12 seconds. So I need a question or else I’m going to get kicked out. Nothing. Well, then what I want to finish with is I think that if you need help with the technology side. Right. We want to talk to you about that.

28:52
Speaker 1
But if you need help figuring out how to approach this within your organization, or you want to figure out how to talk to your integration partners or the integration partners, you want to figure out how to talk to your end users about this. We’re happy to get in those conversations as well to help facilitate those discussions. Right. To help get buy in across the board. We don’t want to then become the permanent middleman that owns this and stuff like that. Right. We’ve already established the enterprise has to own this, but we do want to help facilitate those conversations. So please feel free to reach out. We can talk to you about approaches of how to sell this internally, all that kind of stuff. Oh, there’s a question. Yeah, can you go back to that one? Go for it.

29:39
Speaker 2
My actual question is now, which is going to be the UNS ignition Canary flow?

29:44
Speaker 1
The UNS is really going to be the MQtT server?

29:48
Speaker 2
Yes. But now then, do you push your data through the server to Canaries, and then when you display again, it goes through the UNS back down to scale it up on display?

30:00
Speaker 1
I would say that this middle part here is your MQTT broker. Canary and flow and ignition are all tied into that same one. And so it’s not like there’s multiple instances of it.

30:11
Speaker 2
It’s also consuming.

30:14
Speaker 1
Yep. Yeah. So for like, historical. Right. So, yeah, you’re right that this represents the real time status, and you’ll find that Lenny is going to talk about this because there’s additional things you can put on top of that. So I’ll wait for him. I’ll stop. But yes, there’s a difference between real time data and historical data. How do we handle that? And for all of that, thank you, everybody. I’m done.