3 Things you NEED to know about UNS!

Transcript of the tutorial by Walker Reynolds and 4.0 Solutions on the basics of the Unified Namespace

As part of the 4.0 Solutions community, I wanted to do my part in helping raise awareness of Industry 4.0. So, I created a word-for-word transcript of this illuminating tutorial with Walker D. Reynolds leader of 4.0 Solutions on the Unified Namespace.

It took a while to eliminate all the errors in the automated transcript. But it is my hope that others interested in learning about Walker’s mission to explain the UNS now find this content more easily.

If you are keen to learn more what Walker is doing, plus other Industry 4.0 topics in general, I recommend you join the Industry 4.0 Community Discord, where you can get all your questions answered!

The source video is here:

Transcript

The unified namespace is really simple. It’s not difficult. The thing you need to understand is we need to remember our layers of the automation stack.

What Is the Automation Stack?

The actual automation stack is this: Cloud all the way up at the top. This is Big Data, all that cool stuff, algorithms, machine learning. At the bottom what we have is PLC/HMI. We have supervisory control and data acquisition. We have manufacturing execution systems. And we have ERP.

What Software Do I Need?

Q: What software do I need to build the unified namespace?

A: A software that meets your minimal technical requirements which is MQTT and Sparkplug B with an engineering user interface. I’ll give you the most common example. The most common example is: this is a standalone broker. This is EMQX. We prefer the EMQX broker. It is the most scalable, most cost efficient, and it has 30% more throughput than any other broker on the market. But it’s made by the Chinese. Not everybody wants to use it because it’s from China. So, if you say forget the Chinese, we don’t want to use your broker, then HiveMQ is the backup. In small implementations, we’ll use MQTT distributor which is in a Cirrus Link module which runs inside of Ignition. But this could be Mosquito. It could be lots of things. But in general, this is going to be EMQX as the broker up here. This big example here is going to be Ignition. And we’re going to build all these circles. We’re going to solve all these problems inside the Ignition platform, in general. Same thing here.

Q: Other than Ignition, what’s some of the other platforms?

A: HighByte, Frameworx, Tulip, Litmus, SORBA.ai or IoT ... I mean there’s many, many, many platforms out there. I try to only talk about the ones I generally use. Because if I were to list off a whole list of them, I leave important ones off the list. And because I’m an influencer, people will say, “Oh, because Walker didn’t say that, it must mean something.” Well, no, it could mean I just forgot to mention it. In general, this is EMQX here. In general, this is Ignition here. In general, these circles are being built inside the Ignition platform on top of this digital foundation which is all the purple stuff.

What is UNS? Why do I need it?

So I’m going to talk about the Unified Namespace matters first. Number one. In previous videos, we’ve touched on this. If you guys are familiar with the automation stack, the way that data used to go up the stack, we had multiple connections, discrete connections between disparate applications. So what does that mean?

If at some point I wanted to get information from the ERP system into the SCADA system, I would have to do two things. I would have to connect the ERP system to the MES system, whatever specific new data the SCADA system wanted. And then I would have to map it from the MES system to the SCADA system. In order for us to be able to scale — and that is scale and enterprise implementation — in order for us to fully leverage IoT and Industry 4.0 concepts and digitally transform a business, then what we have to do is change this bastardization in terms of the way that we connect applications together. We do that by creating a unified namespace.

So, the unified namespace is a couple of things. Number one, it’s the single source of truth for all data and information in your business. It’s a single source of truth. Number two, for all this data, we need to structure it and we need to keep it updated. The unified namespace is the structure and the events of your business — the whole business. Number three, it is the hub where all the smart things in the business that have data connect to each other. And number four, it is the foundation of your digital future.

So, what we do is we treat all applications, everything in the plant and on the plant floor, as a node in the system. So, what ends up happening is our PLCs publish their data into a unified namespace. The SCADA system and the HMI get their information from the unified namespace. The SCADA system may process it and then post that information back into the unified namespace. The MES system will then grab its information that it needs to do all of its post-processing of data and it will then publish it back into the unified namespace. The ERP system will then grab its information from the unified namespace, do post-processing, and publish back in. Same thing with inventory management. There will be locations in our namespace for inventory management, warehouse management system, and for cloud and machine learning. Literally, the unified namespace is all data for our entire business in one place for all applications to be able to consume from.

What you do is create a semantic hierarchy. So, if it’s enterprise, site, area, line, which is, you’ll notice, is in red. This is the semantic hierarchy of our business. But then what we do is we create functional namespaces. And this function could be process. Underneath process contains all the inputs and outputs for the process and the context. So, if what I wanted to do was take a raw value A and multiply it by raw value B to create information value C, I do that within this process namespace.

And you would have access to A, B, and the results C, all there.

Now, anybody would have access to A, B, and C.

This is the hub through which all the smart things talk to the data. So, we subscribe to the data in our hub, we do stuff with it, and then we publish back information from that data for other things in the business to use. So, it is the hub through which all the smart things talk. Does that mean that you don’t have any more of this?

And the answer is no, but you get rid of most of this. You get rid of most of these linear integrations and over time these phase out. And in a very short time, we will see a business whose smart things only communicate through a unified namespace.

So, if I wanted to add a new piece of software later on down the road which was going to do, let’s say, shipping predictions, let’s do that. This will be our shipping optimization software and it needs information.

Here’s the information that shipping optimization would need: it would need to know information from the ERP system, who the client is and where it’s got to get shipped to. That’s going to come from ERP. It’s going to need information from the warehouse management system. It is going to need information from the MES system.

Let’s say I don’t have the full, the complete order fulfilled. I need to know the status of the orders that are in progress now. So I’m going to need information from the MES system. I might need information from the edge. Is the machine currently running now? Is it not currently running now? I may need information directly from the edge. Alright, did I answer your question?

Yes, sir.

Alright, awesome. So, hopefully, I answered your question. So, like, subscribe, comment down below. Thank you for watching and I’ll see you in the next one. That is the unified namespace.