The Unified Namespace (UNS): What is it, and why should you care?

00:02
Speaker 1
All right. Hey, everybody, welcome to the better track. Not that, you know, not that I’m biased or anything. No, but welcome to track one. We’re going to be talking about all kinds of stuff today, and starting off for all of this, we’re going to be talking about the unified namespace, what it is and why you should care. So, yeah, we’re going to jump into this, but to start off, how many of you had heard of this term before today? Most people. How many are experts on this great trade? No, but, yeah. Unified namespace is not a new conversation. Right. It’s not a new thing that’s happening, but it’s still something that there’s a lot of confusion about. People are trying to figure out how to make this work and all that kind of stuff. And so the first half of this.

01:02
Speaker 1
So for the next 30 minutes, we’re going to be talking about this at kind of a high level, and then the second 30 minutes, we’re going to do a deeper dive and talk about how ignition in this stack can really help you accomplish uns in a meaningful way. So that’s me. You’ve already talked to me today. All right, so what is the problem that we’re trying to solve here? Right. Because we talked about that earlier, that you don’t start just by talking about technology or something. You talk about what’s the problem you’re trying to solve. And we have data silos, meaning the data isolated and people don’t have access, they don’t have visibility, they don’t know what’s happening in other divisions, other departments, all that kind of stuff.

01:47
Speaker 1
And then also there’s just difficulty sharing that data with others, and that’s something that is not new. Right. We’ve had this going on for a long time. People have had data that they buy equipment from one manufacturer that comes and gets deployed, and the only way to see that data is to go and look at the HMI for that specific piece of equipment. Or now they’ve got two integration partners working on the same project, and those two integration partners develop completely different standards. Or they’ve got a PLC team that builds this weird standard, they bring in another set, and their next PLC standard is completely different. Right. And so you just end up with, even when you have access to data, the data is not compatible or that it’s created for one site. And now I’ve got a new site that comes online.

02:40
Speaker 1
I try to marry those together, and nothing looks the same. Right. All that kind of stuff. Right. So there’s just all these problems about these data silos, but also just difficulty sharing the data. And so what do things really look like today? What are we dealing with all the time? Part of it is we’re dealing with a lot of manual data entry still. People are walking around with clipboards and checking that things are working, and then they write that down, and then they go and they move that onto a whiteboard. And then somebody looks at that whiteboard and they enter something into excel, and then that’s their reporting, right? And it’s just based on so much human error potential, right, that you can go and accidentally mistype something or something like that.

03:27
Speaker 1
And so we have also seen this point to point data integration, and we’ve showed a lot of diagrams today of everything being connected to everything else directly. And so I want to put in my SCaDA system, and that’s pulling my plcs. And now I put in an MES system that’s also pulling my plcs. And now I want to put in this new tool that’s also going to pull my plcs. And now I go and want to make a change to something. I’ve got to go change it in a bunch of different places. My PlC is overloaded because all these systems are competing to be able to get things efficiently, all that kind of stuff. And so this point to point data integration is complicated and it also just makes it difficult to scale.

04:11
Speaker 1
And so, yeah, I got a diagram for you that looks like that, right? You’ve got your plcs, you’ve got SCADA systems connected to stuff. You got mes erp. And these applications are tied to everything. And especially when partner comes in, implements this, or multiple partners come in, and then the end user is left with this as their architecture to maintain. And then each individual partner may have implemented a solution that was fine for the scope that they were given, but it’s like, how does that all get maintained long term, right? And this just doesn’t work for that. And so the solution is what? How can we, instead of having everything all connected to everything else, how do we make it so that everything kind of ties into one system? What is that? Well, that’s a UNS. That’s a unified namespace.

05:02
Speaker 1
And as Lenny talked about earlier today, that doesn’t mean like there’s one vendor that’s giving you one thing that fits in the middle here, and now everything’s happy, right? This data still is going to come in from all these different places and be used by all these different places. But by having some standard in the middle that all of these things can connect with, that can tie everything together, is going to make it so that it’s much easier to maintain long term. So this unified namespace, it’s this proposed solution. It’s a standardized method of organizing and naming data so that all of your data is consistent. And we talked about, once again, it’s not a product. And what I wanted to say is that a unified namespace is really a collective understanding between you and the organization of how you’re going to structure things.

06:09
Speaker 1
And it’s this one communication interface. And this doesn’t work. To say, we’re going to start at the bottom and we’re going to define something for my unified namespace and then expect that to go up through the organization, which is how a lot of these projects work. An engineer gets a good idea, and an engineer goes and implements something, we see the value, and then people start to replicate that value in small ways. Until you have an organization that’s tackled things, and that’s how inductive automation grew. We were software that could come in, solve a problem, and then it would grow from there. Right? Unified namespace is more difficult than that. Generally, you’ve got to come and look at this at a more holistic picture. You need to make sure you’ve defined your structure at the beginning.

06:58
Speaker 1
And so when we talk about unified namespaces, they are awesome, but they are not easy, if that makes sense. And it’s not because the technology is hard, it’s because people are hard, and your system is hard, and you have to come to some understandings there. So what is this structure? I have that slide twice. Is that. Yeah. Okay, here we go. So I need to represent my data in a meaningful way, and I need to make sure that when I am setting up my structure, my naming scheme for all this stuff, that I leave room for all of my equipment in my naming structure. So how do I make sure I define that appropriately? Well, one convenient way is with ISA 95, and ISA 95 is an older specification. It’s been around for a long time, and it has some staying power.

08:04
Speaker 1
Is it as relevant today as it was the day it was released? No, it’s not perfect. This is not a perfect standard. Certain parts of it are kind of outdated, but I think that it’s a useful starting point. And we have some people who come in and they’re like, ISA 95 is the standard that I have to follow. Everything has to be exactly as it’s outlined in that standard. And I would actually discourage you from that because I think that it’s more valuable to use this as a reference, but to come up with something that it accurately reflects your organization. And so ISA 95, still relevant, still useful, but it’s not the one source of truth, right? Go and figure out exactly what you want to represent. But I like this concept, right, of you start, you define the enterprise, that’s your parent level.

08:55
Speaker 1
And then within that you have sites and you say, I only have one site. Well, still add a site layer to your naming scheme here so that if you do in the future add sites, it’s going to fit into this, right? And then within sites, areas, production lines, work cells, you say that all seems like manufacturing, but I do x or whatever, right? Once again, this is just a framework to get you inside the right mindset. But then go and figure out what are the tiers that make sense within your organization, within your business and start defining your structure. And so how do we take it and actually start creating a unified namespace? A unified namespace says, all right, now I need to start relating this to individual data points.

09:40
Speaker 1
So I need data points to be able to fit into this unified namespace concept, which means my names need to show those layers like we saw in that ISA 95 standard. And so you end up with these long names, but it’s because I’ve got this set point here. Make sure I hit the right button, right, of running or set point or process value. And I can’t just have those at the root level because what if I’ve got another set point or another process value? I need to know where that came from, right? And so people go and they start their tag structure or their naming for their points with whatever their enterprise name is, the site name, the area name, the line number, so on. Once again, you figure out what the right hierarchy is for you.

10:27
Speaker 1
But if you start too small and you say, I’m just starting at per machine, and I go down from there. Then once again, from a scaling standpoint, as soon as you start adding things outside of that scope, now your naming is broken, right? So the key to this is starting big, right? A unified namespace starts at an organizational level and then it grows from there, right? So now I add oee, data, great, that fits in nicely here, right? So still enterprise site. I add mes or ERP or whatever else. And so I can start fitting in different kinds of data into this unified namespace because it wasn’t defined with just one thing in mind, right? It’s looking at my whole enterprise. And so this is interesting.

11:14
Speaker 1
Because now you say, all right, ignition is publishing some data into this, and some other system is publishing some data into this or whatever else. And that’s how we get to this, right, is that data can be coming in from a variety of sources, but fitting into one hierarchy, one naming scheme, and that’s the goal, because then it’s easy to start bringing that into flow and start looking at different metrics and start to get all your KPIs, or you can bring it into ignition and visualize in easier, interesting ways, or store all this data in a similar format in canary and have axiom to go and query the data. Right, there’s all these tools, but if the data all looks different, then it’s harder to leverage those tools efficiently. All right, so I went all the way back, forgot that.

12:06
Speaker 1
I was like, oh, yeah, I’m going to want to go back to that. And I just added another slide. So good job, Kent. All right, so what are the benefits of this? Right, well, it makes the data more accessible, because there’s one source of truth for where all your data goes, and it can be more affordable to get to that data, because you’re not having data in all these different silos and having multiple systems all connect to those different silos to query that data out. And so you’re not getting all this duplicate data flowing around your network. It can all be pulled from a single source. You get better ability to predict when things go wrong, because now your data, once again, is not isolated. Your data is in one spot.

12:46
Speaker 1
So it’s easier to tell when things are good or when things are bad, and then also more traceability into that data for the same reasons it’s in one spot, and easier scalability, because now that you’ve already defined the structure, when you have new data that gets created from within your enterprise, now it can fit into that hierarchical structure that you’ve already defined. All right, also, I mentioned a single sort of truth. If an organization can define this, then it actually makes it much easier for partners to come in, because now partners can operate within an existing model and can add things there. There’s already a standard. Instead of creating their own models, their own structures like that, trying to figure out how to convey that information to the customer, all that kind of stuff.

13:33
Speaker 1
So less manpower and engineering, uses the supply chain better, because now you can once again tie into all the other things and greater efficiency, better decision making, all that kind of stuff. So why are people talking about this? Where did this come from? We keep talking about contextualizing data today. And a big thing is, it’s a point that’s already been hit on today, right? But this concept of, I want to do artificial intelligence. Like, I have a bunch of data that’s out there, and I don’t know what to do with it, I don’t know what it means. And so I want to bring it up and I want AI to solve it for me, or I’ve got all this data, but I need to get more efficient. And so I want to do machine learning or predictive maintenance.

14:27
Speaker 1
I want to know when to swap stuff out, all that kind of stuff, and to leverage these tools. If the data is uncontextualized and is all over the organization, it’s really hard to implement those. And so then you come and you pay a bunch of money for people to come and scrub that data. But who are the people that really should be adding context to data? It should be the people that know what that data means, which means it’s not a third party consultant that’s coming in. It’s going to be your operations team that’s there, that understands what’s going on from the day to day, right? They should go and add context, know what things mean.

15:05
Speaker 1
But if you have a bunch of different systems all talking to those plCs, pulling it all individually, now, am I expecting operations to go and add context to all these different systems and maintain that and stuff? No, but if it’s embedded in their SCADA system, for example, and they go and add context in their data, in their SCADA system, and then that magically flows throughout the rest of the enterprise. Now we’re cooking with gas. Now we got something, right? Because you’re allowing people to define things one time, and then things just augment that as we go. The MES system takes in that data, adds some context, pushes it back into the UNS flow, brings in that data, adds some context to it, adds it back to the UNS, right?

15:47
Speaker 1
And so, once again, you get that single source of truth, but now it’s in a format that we can actually leverage these different tools and actually have success because they have the necessary data to get you going. And so I want to talk about this slide for a few minutes here. So this is what we’re talking about. So I’ve got all this data over here coming in from all these different pieces of equipment, maybe going into different databases, going into canary, going wherever it’s going to go. And then we can take this data and we can publish it out into a centralized system. And so now we have products here in the middle. Right. And we’ll talk about this in more detail later. But is the value just in the products? And we would say no.

16:39
Speaker 1
So we’re going to talk about a proposed uns that you can leverage today. But that’s not what makes it a UNS. It’s not the product that we deliver from inductive automation that you’re getting through all these solutions via LMN eight. No, UNS is you have to go and do all that homework to define that hierarchical structure. Right. And then you can leverage these open standards and products and stuff like that to push the data into all these different places. And so I’m going to actually not just wait till the end for questions. We’ve been talking about a lot of stuff here. I wanted to open it up to all of you. What do you think so far? When we talk about a UNS, there’s a ton of data out there. Does this mean uns to you?

17:27
Speaker 1
What do you think about when you think of a UNS? Any thoughts? Because you could easily look at this and just be like, actually, that’s just a load of text. That’s really confusing. Right? How is that driving value? How is that innovative? Why did that become a buzword and a trend that everybody’s talking about? That’s nonsense, right? Does anybody feel that way? No. You’re like, no, we’re way smarter than you. We got this. Good. But if were to take an example here, right? So you’ve got the Acme company, right? And so they put Acme right here. And then their site name, they’ve got their Cape Town site or whatever, right? So Acme’s got Cape Town here, and then within that they’ve got different types of data, mes, ERp, all that kind of stuff. Does that match exactly with what this said? Well, not exactly.

18:34
Speaker 1
Right. Once again, I said Isa 95 is useful. And I said enterprise site area. You could count Mes and ERP as areas, but this is usually more of a physical representation. But in ours we showed maybe it’s not so much a physical representation, maybe it’s more of a logical separation between some of these ideas, right. And that can be just as useful. So once again, figuring out for your organization how to break these things down. And then this goes to production line. But maybe it’s not exactly a production line for you. I went the wrong way. Right. So I was in this one. So now it goes in under mes, went to oee, and then availability. Right? And so it’s not a production line. Right?

19:22
Speaker 1
So some people see Isa 95 and they’re like, immediately, oh, wait, none of this applies to me because I’m not manufacturing. I don’t have lines of this stuff. That’s not true. There’s a lot of value there. But you need to figure out what your structures would be, what your organization levels would be, and make sure you add enough tiers in there, if that makes sense, that you give yourself room to grow. Whose responsibility is it to define your uns? Is it the end user that needs to do this? Is it the integration partner is element eight, the one who comes in and tells you this. Do you have to hire some contractor to come in and define this for you? Who do you think is ultimately responsible? The plant? Yeah. Why?

20:15
Speaker 2
Because they know how the enterprise is structured, how all the sites are structured in that. So how the unit is implemented, the software used or the method might be the system integrated, but that structure must be defined by the enterprise.

20:37
Speaker 1
Yeah. For anybody who couldn’t hear him, he said it’s the enterprise that needs to do that, because they’re the ones who know what’s going on the sites. They know what their structure is. And I think that is usually true. Sometimes end users are oblivious to what’s going on, and sometimes the integrator has to help fill in the gaps. Right. But the integrator is coming in to help, but they don’t own it. Right. Because sometimes I think integrators, systems, integrators come in and because they have some knowledge of what they implemented, people expect them to define this, but they’re not going to own it and maintain it forever. Right. They don’t see what’s beyond the scope of their project. And so it has to come back to the enterprise. And the enterprise can consult with all the people who are involved in their projects.

21:22
Speaker 1
But still, the enterprise has to be the one who owns it. Right. They need to be the ones, at the end of the day, who make it happen. Yeah.

21:28
Speaker 2
Would you still promote a kind of standard document?

21:38
Speaker 1
Yes. It kind of depends where you’re at, right. So if you’ve already implemented a bunch of stuff and then you’re creating this, it’s a collaborative process from the beginning where you’re trying to talk to people to figure out what exists today. If it’s Greenfield, then absolutely, you can go and define what the structure should look like, and then you can share that with your integration partners to say, like, all right, now this is the standard. We need you to go build everything in a way that’s going to be compatible with this. But just because you’ve already started and you’ve already done a site or two or you’ve got half your thing built, does that mean you should just give up on this and stop?

22:14
Speaker 1
No, it’s not too late to go and start building to this structure, even if it’s just all new stuff goes into the uns and eventually you can come back and update the old stuff to tie into it. But definitely not advocating that. It’s like it has to be greenfield or nothing. Right. Because that’s just not practical for most people. So we talked about the enterprises responsible for this. So my next question is ot or it responsible for this? I heard OT. Did I also hear it? No, I agree that it’s both. I think that it sometimes has a tendency to come in and try to define structures, right. And they want to impose their will on all the plants and things like that, but sometimes, only sometimes. Sure.

23:14
Speaker 1
But I’ve also seen it though, where ot rejects everything that it is trying to do and they just create a structure that makes sense for their plant with their vision of it. But then sometimes that doesn’t scale out. Right. And so it has to be this ot it convergence so that there’s a balance because we’ve got other tools in here that are coming in too. Right. And maybe your OT team isn’t really familiar with everything that’s going on in the ERP system, but you still want to make that in here. And other applications want to be able to push data back into here. Right. And so it has to be this collaboration where people go, you make sure that ot is represented, that it’s practical and usable, because if it’s not practical and usable at the operations level, this is never going to work.

24:02
Speaker 1
But also, if it is so focused on ot that when it gets it’s not usable by them, it doesn’t make sense, then once again it’s going to fail and it’s not going to get adopted. Right. And so it has to be that balance of both parties together. So we talked about it’s the enterprise, we talked about that it’s OT and it together. And so I want to do an open question. How many of your organizations are already working on this today, or how many of you as partners have already worked with customers that are doing this today? Yeah. How is it going?

24:46
Speaker 2
It’s a very collaborative process and it’s difficult to get all parties together because it’s such a, you need to work with it and ERP systems, and then you’ve got the operations side as well. It’s a lot of systems to collaborate, to get Unh to work. It’s an enterprise.

25:12
Speaker 1
Right. So has anybody finished a project with this that’s deployed and is successful and is awesome? No one. So several people have started them, but nobody’s. Or did you say you were? Yeah, tell me about it.

25:32
Speaker 2
We sort of had a ground recognition and going there as simple as same area, same name was spelled. So just getting updated from that very much like.

25:58
Speaker 1
Layout.

26:00
Speaker 2
It’s been going for about a year now. Everything’s fine. EveryThing’s fine because no one is able to drive adding. So we’ll see how it goes.

26:13
Speaker 1
Awesome. Yeah. It is interesting because the whole goal is, right, that it’s going to work now, but that it will also work later. Right. And so interested is here next year how this all goes. Right. But we have certainly seen customers go through this process, and we’ve helped people go through this Process, and we have found that when people have the right stakeholders involved, then it has been successful. We’ve seen some very large organizations define this and they are publishing data in meaningful ways and they have lots of applications that are subscribing to that.

26:55
Speaker 1
But one thing that I found is we’ve had a few that have done this on open standards where the data is going into like an MQTT broker or is going into a centralized, even just database that people have been leveraging, but that they have that centralized structure and then all these systems can tie into that. Those have been successful. Where we have seen people struggle is when they have bought a product for uns that it’s like we will just ingest all the data. And then people have started building custom integrations for things of how it all starts signing together. Also, we’ve had customers, and I’m not saying it’s just other people’s products. I’ve seen people just have ignition, try to bring everything into ignition and then create custom integrations from everything else into ignition, and it breaks down a little bit. Right.

27:49
Speaker 1
And so instead of getting away from proprietary products, going with open standards, it helps you prevent creating daisy chained integrations, because that’s kind of the worst part of this is sometimes you get it where you’re like, all right, I’ve got this old PlC, and it’s an old protocol. So now I’m going to put something next to that to convert that protocol into something else, which now goes into my SCADA system. And then my SCaDa system publishes that app to something else, and then I’m pushing that to this other system, which then this other system can consume. And then that goes into this uns. And now the PLC code changes, and there’s all these jumps that it just never makes it that far. Right.

28:36
Speaker 1
And so then nobody updated all those integrations, and now what’s in the PLC doesn’t match what they see in the uns. And now ot completely loses faith in the uns at all, because it doesn’t reflect what the plants actually show. And then they stop using it entirely. And we see that all the time, where if there’s a breakdown somewhere in a chain, and now it doesn’t reflect the real data, the accurate data, all bets are off. And so, having as few hops as possible for when things get to the know, having everything go directly to the UNS helps you help prevent that from happening. Now, one other thing. We talk about all these things going into the uns. I just lost my train of thought. I was going to tell you something really amazing and impactful. Oh, Isa 95.

29:42
Speaker 1
I am obviously going the wrong way. All right, this thing. So this is part of Isa 95, but another part of it is something that often gets referred to as the Purdue model. It’s got the pyramid, right? And there’s like level zero and level 1234. Anybody know what I’m talking about? Yeah. And we talk about separation between those different bars in the pyramid. And so all my equipment’s down here at the bottom, and then I’ve got my Scada, and then I’ve got, like, my mes, and then I’ve got DMZ in the middle, and then I’ve got my business applications up here. How does this translate into that? It’s not an easy fit. And so we’ll talk about that a little bit in the next session as well.

30:35
Speaker 1
But to go with this, you have to look at a more modern approach as well, about security and how things are connected, where it can’t be quite as isolated, where you say, all right, level two has to go to level three, but level two can never talk to level four, and all these things. Right. And so you have to be really careful with how people are accessing this uns. Sometimes it requires replication of your uns or proxying or all that kind of stuff. Right. But it is achievable. And you can do this in a secure way. But I wanted to mention that, too, as part of that Isa 95 standard. Now, we’re going to roll in a second here to the next session. Which is also me going deeper into uns to how ignition can help you achieve this.

31:20
Speaker 1
But any questions before we get to the practical side? No. You’re like, no, just show us how to do it. Enough talking about it. Great. All right. Right? Am I good? Just keep going. I get to just roll. All right, cool. Thank you.